When a vendor discloses a breach, know what to check, what to rotate and what to tell customers, within one working day

The first 60 minutes: triage questions

A vendor has announced a breach. You have an email, a status page post, or a link in a group chat. You don't yet know if it affects you. This section gets you from "something happened" to "we know what we're doing next" in one hour, without rotating everything in a panic or ignoring it.

Rule for the hour: answer questions first, change things second. The exception is a secret you can confirm was exposed; rotate that immediately (the full order is in a later section).

Minute 0-10: Open the incident and assign roles

1. Create one place for notes. A doc or a channel named incident-vendor-YYYYMMDD. Everything goes there with timestamps.
2. Assign three roles (one person can hold two in a team of 2-5):

• Lead: makes decisions, keeps the clock.
• Investigator: reads the vendor notice, checks your systems.
• Communicator: drafts internal and customer messages, handles inbound questions.

1. Save the source. Paste the vendor's announcement URL and a copy of the text into the doc. Notices get edited, and you'll want the original wording later.

INCIDENT LOG
Vendor:
Announced (vendor's timestamp + timezone):
Source URL:
We learned of it at:
Lead / Investigator / Communicator:
Status: TRIAGE

Minute 10-30: Answer the six triage questions

Write one-line answers. "Unknown" is a valid answer, but it must come with an owner and a way to find out.

1. Do we use this vendor, and for what? Check your inventory sheet (built in the next section). No inventory yet? Search your password manager, billing statements, SSO app list, .env files and CI secrets for the vendor name.
2. What did the vendor say was affected? Separate their wording into: systems accessed, data types, time window, and whether they've confirmed customer data was involved. Note vague phrases ("a subset of customers", "limited access") and treat them as unknown, not as reassurance.
3. What do we send them? Customer data, employee data, source code, internal docs, payment data, or only metadata?
4. What credentials do they hold or can they reach? API keys you gave them, OAuth tokens, SSO/SAML config, webhook signing secrets, service accounts, and keys pasted into their documents or pages.
5. What can their access reach in our systems? An auth provider may reach every login. A docs tool may hold pasted credentials. A billing provider may reach customer payment references.
6. Did the exposure window overlap with our usage? If the vendor says access occurred in a given date range, did we have an active integration or stored data then?

Worked example. Vendor: a hosted documentation platform. Announcement says an attacker accessed internal storage; some customer content may have been viewed.

Q1 Use it? Yes, public docs + internal runbooks (owner: Priya)
Q2 Affected: storage access, "customer content", window unclear -> UNKNOWN
Q3 We send: page content, editor emails
Q4 Credentials: API token for CI doc publishing; SSO via Google
Q5 Reach: token can publish to docs; no prod access
Q6 Window: we've used it for 2 years -> assume overlap
Likely exposure: internal runbooks (check for pasted secrets), editor emails

Minute 30-45: Classify and decide

Choose one level. When in doubt, pick the higher one for the first hour; you can downgrade later with evidence.

Quick-decision checklist:

• Can any exposed credential reach production data? If yes, rotate first.
• Did we ever paste a secret into this vendor's tool (docs, tickets, chat)? Search for key, token, password, secret, BEGIN PRIVATE.
• Does the vendor hold personal data of our customers? If yes, note it for possible legal notification review (ask a qualified lawyer; this playbook doesn't give legal advice).
• Is the vendor an SSO/login path? Check for unusual sessions and consider forcing re-authentication.

Minute 45-60: Contact, communicate, schedule

1. Ask the vendor for specifics. Send it from your account's support channel or security contact:

Subject: Security incident inquiry - [Account/Workspace name]

We use [product] under account [ID/email]. Regarding your notice dated [date]:
1. Was our account's data or any credential associated with it accessed?
2. What is the exposure time window?
3. Which secrets or tokens do you recommend we rotate?
4. Are there indicators of compromise (IPs, user agents) we should search for?
Please reply with a named contact and expected update time.

1. Post an internal update (even if the only news is "investigating"):

[Time] Vendor incident: [Vendor]. Level: [A/B/C].
Known: [one line]. Unknown: [one line].
Doing now: [rotation / log review / vendor contact].
Please do not: post about this publicly or message customers.
Next update: [time, within 2 hours].

1. Set the next checkpoint on the calendar. Vendors update notices for days.

Common mistakes

• Rotating everything at once. You break production and lose track of what mattered. Rotate by exposure and privilege.
• Trusting "no evidence of customer data access." That means they haven't found it, not that it didn't happen. Treat as Level B.
• Forgetting secrets pasted in docs, tickets or chat. Search the vendor's own tools.
• No timestamps. You'll need them for the review and any customer questions.
• Telling customers too early or never. Draft early; send only what you can state accurately. Templates come later in this playbook.