Your internal incident response plan assumes you can pull the logs, image the host, and set the pace. In a vendor breach you can do none of that. The vendor controls the evidence, the vendor's timeline decides how much you know and when, and yet it is your data, your customers, and in most regimes your regulatory deadline. The playbook below is organized around that gap. It complements, rather than replaces, the general guidance in NIST SP 800-61 Rev. 3, which frames incident response as part of overall cybersecurity risk management and aligns it with the CSF 2.0 functions. For how automation fits into this, see incident response and SOAR in TPRM; this page is the human-readable runbook that automation would execute.
Hour 0 to 1: triage before you panic
Vendor incidents reach you through four doors: the vendor's own notice, a regulator or law-enforcement contact, press or a researcher, and your monitoring. The first job is the same for all of them - establish what you actually know and who owns the response.
- Open one incident record and name one owner. Not a thread, not a channel. Security leads technically; privacy/legal owns notification decisions; procurement or the relationship owner owns the vendor conversation. Write the roles down before the first call.
- Pull the vendor's profile. Tier, data categories shared, integrations, credentials issued, contract notice terms, and subprocessors. If you cannot get this in ten minutes, that is the first finding of the post-incident review, because it means your inventory is not usable under pressure (see vendor tiering).
- Classify the trigger. A confirmed breach at the vendor, an exploited vulnerability in the vendor's stack (check the CISA Known Exploited Vulnerabilities catalog), and a rumor are three different levels of response. Do not treat them the same, but do not wait for confirmation before the containment steps below that cost you nothing.
Hour 1 to 4: scope your exposure, not their breach
You do not need to understand the attacker's full kill chain. You need to answer one question: what of ours could the attacker reach through this vendor?
| Exposure path | What to establish |
|---|---|
| Data held by the vendor | Which data sets, which customers or employees, which jurisdictions, and whether the data was encrypted with keys the vendor also holds. |
| Credentials and tokens | API keys, service accounts, OAuth grants, SSO trust, SFTP and VPN accounts issued to or by the vendor. Anything the vendor stores can be assumed stolen if its secrets store was in scope. |
| Network and integration paths | Inbound connections from the vendor into your environment, allow-listed IP ranges, webhooks, and agents or connectors running inside your network. |
| Downstream dependencies | Your other vendors that depend on this one, and the vendor's own subprocessors. See fourth-party risk and concentration risk. |
Contain what you control
You cannot contain the vendor's environment, but you can shrink what it can reach. These actions are usually low-regret and should be pre-approved in the playbook so nobody debates them at 2 a.m.:
- Rotate every credential and API key issued to or held by the vendor, and revoke OAuth and SSO trust relationships you can re-establish later.
- Tighten or suspend inbound access from vendor networks and disable integrations that push data outward.
- Increase logging and alerting on the accounts, tokens, and data stores the vendor touches, and look backward over the likely compromise window for anomalous use.
- Pause new data transfers to the vendor where the business can tolerate it. This is the one that needs a business decision; make the call explicitly and record who made it.
Start the notification clocks early
Most privacy and security regimes start your clock when you become aware, or in some cases when the vendor does, not when the vendor gets around to telling you. Counsel decides what is reportable; your job is to make sure nobody learns on day three that a deadline passed on day one. The table lists the common triggers - confirm the specifics against the primary text for your situation.
| Regime | What it says about vendor-originated incidents |
|---|---|
| GDPR | A processor must notify the controller "without undue delay" after becoming aware of a personal data breach, and the controller has 72 hours after becoming aware to notify the supervisory authority where required (Article 33). See GDPR and third-party risk. |
| HIPAA | A business associate must notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery (45 CFR 164.410). Where the business associate is the covered entity's agent, the covered entity's own discovery date can be imputed earlier. See HIPAA and third-party risk. |
| NYDFS Part 500 | Notice to the Superintendent within 72 hours of determining a cybersecurity event has occurred at the covered entity, its affiliates, or a third-party service provider (23 NYCRR 500.17). See NYDFS 500 and third-party risk. |
| SEC (US public companies) | Form 8-K Item 1.05 requires disclosure within four business days after the company determines an incident is material, and the SEC's adopting release (Release No. 33-11216) does not exempt incidents on third-party systems from that analysis. |
| DORA | Financial entities report major ICT-related incidents to their competent authority in stages (initial, intermediate, final) under Regulation (EU) 2022/2554, Article 19, including incidents originating at an ICT third-party provider. See DORA third-party risk. |
| NIS2 | Essential and important entities owe an early warning within 24 hours and a fuller notification within 72 hours of becoming aware of a significant incident. See NIS2 supply chain obligations. |
The questions to put to the vendor, in order
Vendors under pressure send reassuring, vague updates. Send a short, numbered list of questions and ask for written answers on a stated schedule. The ones that matter most:
- When did the vendor detect the incident, and what is the earliest date of attacker activity it has evidence for?
- Was any of our data, or any credential or token that can reach our systems, in the affected environment? If the vendor does not know yet, when will it know?
- Is the attacker's access contained and eradicated, and how does the vendor know?
- Which subprocessors were affected, and have they been notified?
- Has a forensic firm been engaged, and will we receive its findings or an attestation of scope?
- What is the vendor's notification position under the laws that apply to our data, and will it support ours?
Treat a refusal to answer item two as a finding in itself. If the contract has a notification window and a cooperation clause, cite them; if it does not, record that for the renegotiation.
Decide: stay, restrict, or exit
Once scope is clearer, make the relationship decision deliberately and write it down. Continue with compensating controls, continue with restricted access and a remediation plan, suspend, or begin offboarding. For a critical vendor the realistic answer is usually the middle option, because replacing a critical provider takes months. That is exactly why the contingency and exit planning should exist before the incident; a decision made without a tested alternative is not really a decision.
Close the incident properly
- Hold a review within a few weeks, not months. Measure time from vendor detection to your awareness, from awareness to containment, and from awareness to each notification decision. These are the numbers that tell you whether the program works.
- Re-assess the vendor on evidence. A remediation letter is a claim. Ask for evidence of the fix and re-test what can be observed from outside; see automated evidence collection.
- Update tier, contract, and monitoring. Shorten notification windows, add cooperation and forensic-access terms, and move the vendor to tighter monitoring if it stays.
- Feed the lesson back into the playbook. Every missing inventory field, unclear owner, or unapproved containment step you hit is an edit to this document.
Where tooling helps and where it does not
Governance platforms such as OneTrust and ProcessUnity are well suited to holding the vendor inventory, contract terms, and notification obligations this runbook depends on. Security-rating and monitoring providers such as BitSight, SecurityScorecard, UpGuard, and Panorays can surface an externally visible compromise or exposed service early. Rescana pairs continuous attack surface monitoring with evidence-based findings and tracked remediation, which is useful for the detection and re-assessment steps. Your approvals. Our agents. What gets acted on stays under your rules. None of these replaces the part only your own team can do: deciding what to contain, what to disclose, and whether the relationship survives.
Talk to an expert about running this first-24-hours playbook on a vendor incident.
Frequently asked questions
What should you do first when a vendor reports a data breach?
Open a single incident record with one named owner, pull the vendor's profile (tier, data shared, credentials and integrations issued, contract notice terms), and scope your exposure rather than the vendor's breach: which of your data and access could the attacker reach through them. In parallel, take the low-regret containment steps you control - rotating credentials and API keys issued to or held by the vendor, tightening inbound access, and increasing logging - and alert legal or privacy so notification clocks are tracked from the start.
How quickly must a vendor notify you of a breach?
It depends on the regime and the contract. GDPR requires a processor to notify the controller 'without undue delay' after becoming aware of a personal data breach. HIPAA requires a business associate to notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery, though contracts commonly set far shorter windows. NYDFS Part 500 and NIS2 set 72-hour regulator-facing clocks for the regulated entity itself. Because statutory windows are outer limits, negotiate a specific contractual notification period, commonly 24 to 72 hours, and a duty to cooperate.
Does a breach at your vendor trigger your own reporting obligations?
Often yes. The regulated company usually remains accountable for its data and its operations even when the incident happens in a vendor's environment. NYDFS Part 500.17 explicitly covers cybersecurity events at a third-party service provider, the SEC's 2023 cybersecurity disclosure rules do not exempt incidents on third-party systems from the materiality analysis, GDPR makes the controller responsible for notifying the supervisory authority, and DORA covers major incidents originating at ICT third-party providers. Have counsel confirm which regimes apply to the specific facts.
What questions should you ask a vendor after a breach?
Ask when the vendor detected the incident and the earliest attacker activity it can evidence; whether your data or any credential that reaches your systems was in the affected environment; whether access is contained and eradicated and how it knows; which subprocessors were affected; whether an independent forensic firm is engaged and whether you will receive its scope findings; and what the vendor's own notification position is. Put the questions in writing with a response deadline, and treat a refusal to say whether your data was involved as a significant finding.
How do you close out a vendor breach incident?
Run a post-incident review within a few weeks that measures time from vendor detection to your awareness, to containment, and to each notification decision; re-assess the vendor on evidence rather than accepting a remediation letter; update its tier, contract terms (notification window, cooperation, forensic access), and monitoring intensity; and decide explicitly whether to continue, restrict, or exit the relationship. Then edit the playbook to fix every gap the incident exposed.