When a supplier is breached, you inherit an incident you cannot see, did not cause and must still answer for. The supplier controls the evidence and the timeline, yet your organisation decides whether your data was exposed, which credentials to rotate and whether regulators, customers or individuals must be told. This playbook is a fill-in template for any supplier incident: managed service providers and IT outsourcers with remote access, data processors holding your personal data, software and platform vendors, and suppliers whose outage stops your operations. It is for incident managers, TPRM leads, IAM teams and privacy officers. For incidents involving SaaS integrations and OAuth tokens specifically, use it with the Vendor SaaS Breach Response Playbook; for compromised software updates or packages, use the Supply Chain Compromise Response Playbook.
How to use this template
- Replace placeholders: text in square brackets, such as [Organisation], [Incident Manager] or [TPRM Lead], must be replaced with your own names, roles and systems before adoption.
- Pick the incident type: section 1 defines four supplier incident types. Each later section marks steps that apply only to some types.
- Record decisions: decision points are numbered D1 to D5. For each, record who decided, when, on what evidence and what was decided.
- Separate claims from facts: keep a running log with two columns: what the supplier has told you, and what you have confirmed from your own logs. Regulators and customers will ask which is which.
- Integrate, do not duplicate: this playbook sits under [Organisation]'s incident response plan and uses its severity scale, war room and approval routes. See the Incident Response Plan Template.
1. Scope and triggers
1.1 This playbook applies when an incident at a supplier, or at the supplier's own subcontractor, may affect [Organisation]'s data, systems, credentials or ability to operate.
| Type | Description | Primary risk to [Organisation] |
|---|---|---|
| A. Access supplier | MSP, IT outsourcer, support vendor or consultant with accounts, remote tools or network paths into [Organisation] | Attacker uses the trusted relationship to enter (MITRE ATT&CK T1199 Trusted Relationship, T1078 Valid Accounts) |
| B. Data holder | Processor, hosting provider or platform storing [Organisation]'s data or customers' personal data | Data theft, extortion and notification duties |
| C. Credential holder | Supplier holding [Organisation]'s secrets, tokens, session artefacts or support files | Stolen credentials reused against [Organisation] (T1539 Steal Web Session Cookie) |
| D. Operational dependency | Supplier whose outage, for example after ransomware, stops [Organisation]'s processes | Disruption, unsafe workarounds, rushed reconnection |
1.2 Triggers include: a supplier breach notice; a platform or regulator alert; threat intelligence or a leak site listing naming the supplier; media reports; [Organisation]'s own detections involving supplier identities or IP ranges; and a supplier service outage without explanation.
1.3 A media report or leak site claim alone is enough to start triage. Do not wait for the supplier to confirm.
2. Roles and contacts
| Role | Responsibility | Name |
|---|---|---|
| Incident Manager | Owns the response, decisions log and timeline | [Name] |
| TPRM Lead | Supplier contacts, contract obligations, sub-processor list | [Name] |
| Supplier Relationship Owner | Business impact, escalation inside the supplier | [Name] |
| IAM Lead | Revocation and rotation of supplier-related identities and secrets | [Name] |
| SOC Lead | Log preservation, hunting, monitoring | [Name] |
| DPO or Privacy Lead | Personal data assessment and regulator notification | [Name] |
| Legal Counsel | Contract rights, privilege, regulatory and disclosure advice | [Name] |
| Communications Lead | Customer, staff and media statements | [Name] |
| Executive Sponsor | Approves suspension, exit and external disclosure | [Name] |
2.1 The supplier register must hold, for each critical supplier: a 24/7 security contact, the contractual breach notification window, the access paths (accounts, keys, tokens, network routes), the data held and the current sub-processor list. See the Incident Response Contact and Call Tree Template.
3. Detection and triage
- Open an incident record and assign the Incident Manager. Start the decisions log and the facts and claims log.
- Pull the supplier's register entry. List every access path, every credential the supplier held for [Organisation] and every data set it holds.
- Send the supplier a written information request: what happened, when it started, which systems and customers are affected, whether [Organisation]'s data, credentials or support files were accessed, indicators of compromise, and the supplier's next update time.
- Preserve [Organisation]'s own evidence: sign-in logs for supplier identities, API and audit logs for integrations, remote access session logs, VPN and firewall logs for supplier ranges. Extend retention now.
- Hunt for misuse: activity by supplier accounts outside normal hours or sources, new accounts or keys created by them, unusual data exports, and use of any supplier indicators.
- For Type C, list every artefact [Organisation] gave the supplier, such as support uploads or diagnostic files, and check whether they contained session tokens or secrets. In the Okta support system breach, customer-uploaded HAR files contained session tokens, and BeyondTrust detected an attempted admin login with a stolen cookie on 2 October 2023, well before public disclosure on 20 October.
D1, exposure classification: classify [Organisation] as Confirmed impact, Possible impact or Not exposed. Treat Possible as Confirmed for containment. Record the evidence.
4. Containment
4.1 Preserve logs and configuration before revoking. Then apply the actions for the incident type.
| Type | Containment actions |
|---|---|
| A. Access supplier | Disable supplier accounts and remote access tools; revoke sessions; block supplier IP ranges except an agreed emergency route; require re-verification for any supplier help desk request |
| B. Data holder | Suspend new data flows to the supplier; restrict integration permissions to read-only or off; revoke API keys used to push data |
| C. Credential holder | Revoke and replace every credential and session the supplier held or could see, regardless of whether the supplier says it was accessed |
| D. Operational dependency | Isolate connections to the supplier until it confirms containment; activate manual or alternate processes; do not accept files or updates from the supplier without checks |
D2, suspension: decide whether to suspend all connectivity with the supplier. Weigh business impact against the chance of attacker access through the supplier. Executive Sponsor approves.
5. Eradication
- Rotate every secret the supplier held or could read: API keys, service account passwords, OAuth client secrets, certificates and webhook signing keys. See the Secrets Rotation Runbook Template.
- Remove anything the attacker created through supplier access: accounts, keys, mail rules, scheduled tasks, OAuth grants and remote tools.
- Re-check the rotation list against the full inventory. After the Okta breach, Cloudflare missed one service token and three service accounts it believed were unused, and an attacker used them weeks later. See the Cloudflare Thanksgiving breach.
- For Type B, check your own controls on the supplier's platform. In the Snowflake breach the platform itself was not breached; customer accounts without MFA were accessed with infostealer credentials, so customers had to fix their own configuration.
6. Recovery
- Obtain the supplier's written statement of containment and remediation, and where available an independent investigator's summary.
- Reconnect with least privilege: new credentials, narrower scopes, network restrictions and MFA for every supplier login.
- Monitor supplier identities and connections at raised sensitivity for at least 30 days.
- For Type D, validate data and files received from the supplier during and after the incident before using them, and reconcile transactions processed through manual workarounds.
D3, relationship decision: reconnect, reconnect with conditions, replace or exit. If exiting, follow the Vendor Offboarding and Termination Guide.
7. Communication and notification
D4, notification: Legal and the DPO decide which duties apply, using confirmed facts, and record the decision even when nobody is notified.
| Audience | Trigger and timing | Owner |
|---|---|---|
| Data protection regulator (GDPR and UK GDPR) | Where [Organisation] is controller and the breach is notifiable: without undue delay and not later than 72 hours after becoming aware (Article 33(1)); information may be given in phases (Article 33(4)) | DPO |
| Individuals | Where likely to result in high risk: directly and without undue delay (Article 34), with advice on protective steps | DPO, Communications |
| Your own customers (where you are their processor) | Without undue delay after you become aware (Article 33(2)), and as your contracts require | TPRM Lead, Legal |
| Sector regulators and securities disclosure | Per [Organisation]'s regulatory register, for example NIS2, DORA or SEC rules | Legal |
| Staff | Where staff data or working practices are affected | Communications, HR |
7.1 Record every breach in the internal breach register, including the decision not to report, as Article 33(5) requires. See the Data Breach Notification Checklist, the DORA Major ICT Incident Reporting Guide and the SEC Cybersecurity Disclosure Rules Guide.
7.2 Statements must attribute supplier claims to the supplier and must not repeat unconfirmed assurances as fact.
8. Post-incident review
- Hold the review within [10] working days of closure, including the supplier where it will take part.
- Compare the supplier's notification time with the contractual window and with when [Organisation] first had signals.
- List register gaps found: unknown access paths, missing contacts, stale sub-processor lists, credentials without owners.
- Review contract terms: notification window, cooperation, log access, audit rights, right to suspend.
- D5, actions: the Executive Sponsor approves actions and owners; TPRM updates the supplier's risk rating and reassessment date.
Implementation guidance
Before an incident
- Register access paths now: the triage step only works if the supplier register already lists credentials, integrations and data sets per supplier. See the Third-Party Risk Management Guide.
- Contract for incidents: fixed breach notification windows, named security contacts, cooperation with investigations, access to relevant logs and the right to suspend connectivity. See the Third-Party Security Contract Clauses Template.
- Exercise it: run one tabletop a year on a supplier scenario, ideally with a critical supplier taking part.
- Know your fourth parties: many supplier incidents start at the supplier's own provider. See the Fourth-Party and Nth-Party Risk Guide.
Scaling
Small organisations can merge roles so that one IT lead covers IAM and SOC, and one manager covers TPRM and the supplier relationship; the decision points still need recording. Large organisations should automate the D1 inventory pull from the supplier register, IGA and cloud access reports, so that a supplier name returns every related identity within minutes.
Metrics
- Time from first external signal to D1 classification.
- Time from D1 to full rotation of supplier-held credentials.
- Percentage of critical suppliers with complete access-path records.
- Supplier notification time against the contractual window.
- Credentials found during eradication that were missing from the register.
Common failure patterns
- Waiting for the supplier: triage starts only when the supplier confirms impact, days or weeks after the first public signal.
- Rotating only what the supplier names: the supplier lists what it knows was accessed; anything it held or could read must still be rotated.
- Revoking before preserving: accounts and integrations are deleted before their logs are exported, so impact can never be confirmed or ruled out.
- Repeating supplier assurances: customer statements say "no data was affected" on the supplier's word and must later be corrected.
- Rushed reconnection: after an operational outage, connections are restored with the same credentials and permissions as before, without evidence of supplier remediation.
- Forgetting downstream duties: where [Organisation] is itself a processor, its own customers are not told in time because the incident was treated as the supplier's problem.
Framework mapping
| Framework | Reference |
|---|---|
| NIST CSF 2.0 | GV.SC-08 suppliers in incident planning and response; RS.MA-01 plan executed with third parties; RS.CO-02, RS.CO-03 notification and sharing; ID.IM-02 exercises with suppliers |
| NIST SP 800-53 Rev. 5 | IR-4 Incident Handling, IR-6 Incident Reporting, IR-8 Incident Response Plan, SR-8 Notification Agreements |
| ISO/IEC 27001:2022 Annex A | 5.19 to 5.22 supplier controls, 5.24 to 5.28 incident management and evidence |
| MITRE ATT&CK | T1199 Trusted Relationship, T1078 Valid Accounts, T1539 Steal Web Session Cookie |
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
- ICO: Personal data breaches, a guide
- MITRE ATT&CK: Trusted Relationship
- MITRE ATT&CK: Steal Web Session Cookie
Related NHI Mgmt Group resources: Vendor SaaS Breach Response Playbook · Incident Response Guide · Third-Party Access Guide · NIST SP 800-61 Incident Response Guide