Free guides

A vendor breach notice usually arrives as an email, a status page post, or a link someone shared in chat. You don't know yet whether it affects you, and the pressure to act is high. Teams tend to fail in one of two ways: they rotate everything in a panic, or they read the notice, decide it's not their problem, and move on. This method takes you from "something happened" to "we know what we're doing next" in about an hour.

The main rule is to answer questions before changing things. The exception is a secret you can confirm was exposed. Rotate that immediately.

Step 1: Open one record and assign roles

Create a single place for notes, such as a document or a chat channel named something like incident-vendor-YYYYMMDD. Every decision and finding goes there with a timestamp. Then assign three roles. In a team of two to five people, one person can hold two of them.

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

Save the source too. Paste the vendor's announcement URL and a copy of the text into the record. Vendors often edit notices after publishing, and you will want the original wording later when you compare what they said at different times.

Step 2: Answer six triage questions

Write a one-line answer to each question. "Unknown" is an acceptable answer, but only if it has an owner and a plan for finding out.

1. Do we use this vendor, and for what? If you don't have an inventory, search your password manager, billing statements, SSO app list, environment files, and CI secret stores for the vendor's name.
2. What did the vendor say was affected? Split their wording into systems accessed, data types, time window, and whether they have confirmed customer data was involved. Treat vague phrases like "a subset of accounts" or "limited access" as unknown, not as reassurance.
3. What data do we send them? Customer data, employee data, source code, internal documentation, payment references, or only metadata?
4. What credentials do they hold or can reach? Think about API keys you gave them, OAuth grants, SSO configuration, webhook signing secrets, service accounts, and any secrets pasted into their documents, tickets, or pages.
5. What can their access reach in our systems? An identity provider may reach every login. A documentation tool may hold pasted credentials. A webhook integration may be able to trigger actions in production.
6. Did the exposure window overlap with our use? If the vendor names a date range, did we have an active integration or stored data during that range?

Here is an example of how a filled-in record might look for a hosted documentation platform. The notice says an attacker accessed internal storage and that some customer content may have been viewed:

Q1 Use it? Yes, public docs and internal runbooks (owner: Dana)
Q2 Affected: storage access, "customer content", window unclear -> UNKNOWN
Q3 We send: page content, editor email addresses
Q4 Credentials: CI publishing token; SSO via company identity provider
Q5 Reach: token can publish docs; no production access found
Q6 Window: used for two years -> assume overlap
Likely exposure: internal runbooks (check for pasted secrets), editor emails

Notice that the answer to Q2 is "unknown", but the record still says what to do next. That is the point of the exercise.

Step 3: Classify the incident

Choose one level. When you are unsure during the first hour, pick the higher level. You can downgrade later when you have evidence.

• A: Confirmed. The vendor says your data or credentials were exposed, or you have found evidence of that. Rotate exposed secrets now, start a review of relevant logs, and prepare a customer notice.
• B: Possible. You use the vendor and the scope is unclear. Rotate high-privilege secrets, review logs, request details from the vendor, and draft a notice without sending it.
• C: Not affected. You don't use the vendor, or the affected product is not one you use. Record your reasoning and check again in 24 hours, because vendor notices often get updated.

Before you settle on a level, run four quick checks:

• Can any exposed credential reach production data? If yes, rotate it first.
• Did anyone ever paste a secret into this vendor's tools? Search exported content for patterns such as key, token, password, secret, and BEGIN PRIVATE KEY. For example:

grep -rniE "api[_-]?key|secret|token|password|BEGIN (RSA|OPENSSH|EC) PRIVATE" ./vendor-export/

• Does the vendor hold personal data about your customers? If yes, note it for a legal review of notification obligations. Ask a qualified lawyer for that decision. This method is an engineering checklist, not legal advice.
• Is the vendor a login path, such as an SSO provider? If so, check for unusual sessions and consider forcing re-authentication.

Step 4: Ask the vendor specific questions

Vague notices need specific answers. Send your question through the account's support channel or security contact, and include your account identifier. Ask for:

1. Whether data or credentials associated with your account were accessed.
2. The exact time window of exposure.
3. Which secrets or tokens they recommend rotating.
4. Any indicators of compromise, such as IP addresses or user agents, that you can search for.
5. A named contact for follow-up.

Write down when you sent the request and when you received the answer. If you get no reply, that goes in the record too.

Step 5: Set the next checkpoint

Before the hour is up, set a time for the next review. For a Level A or B incident, that is usually a few hours away, when the Investigator reports on rotation progress and log findings. For a Level C incident, set it for 24 hours later. Write the next checkpoint at the top of the record so anyone who joins late knows what to expect.

The one-hour pattern works because it forces an order of operations: roles, facts, classification, then action. Teams that skip to action usually rotate the wrong things and miss the one secret that actually matters.

If you want a more detailed version of this process, including rotation order and log-review steps, the full "Vendor Breach Response Runbook for Small SaaS Teams" is available at https://heracles-store.pages.dev/p/vendor-breach-response-runbook-for-small-saas-teams/.

Written with AI assistance and reviewed for accuracy before publishing.

This guide was researched and written with the help of AI and reviewed by an automated quality check. It is general educational information, not professional advice.