A critical SaaS or third-party vendor that holds your data or runs part of your operations has been breached. The uncomfortable truth: it is still your event. This playbook gives you the structure to run your own response defensibly — triage your exposure, pull the contract levers, decide notification on your legal duties, apply interim controls, and brief the board on concentration risk.
Educational template — not legal advice. The regulatory references are summarised for orientation and can change; adapt this with qualified counsel.
Privileged & confidential — prepared at the direction of counsel. A critical third-party or SaaS vendor that holds your data or runs part of your operations has been breached. This playbook records your own response: the triage, the contract levers, your notification decision, the interim controls, the concentration-risk picture, and the brief to the board. A vendor’s breach is still your event — the vendor’s obligations do not discharge yours.
01Triage — what we know
Capture the facts about OUR exposure, not the vendor’s internal incident. Every downstream decision depends on scope.
Vendor
Vendor name and the service they provide to us
How/when we were notified
Date/time and channel — vendor notice, news, our own detection
Our data affected
Data categories — PII, SSNs, credentials, financial, PHI — and record counts; mark estimates
Our systems / integrations affected
APIs, SSO/SAML trust, shared service accounts, data flows
Customers / employees affected
Which populations and jurisdictions
Vendor status
Contained / unconfirmed / ongoing — treat as potentially compromised until eradication is confirmed
Fourth parties (vendor’s sub-processors)
Known sub-processors our data may have flowed to
Do not assume the vendor carries your obligations. As the data owner/controller you keep your notification, disclosure and customer duties regardless of whose systems were breached. Record what is known, estimated and still unknown — the duty continues as facts develop.
02Contract levers
The contract is an active response tool, not post-incident cleanup. Review the master agreement and data processing addendum and move these in parallel with the technical response.
Lever
Clause / basis
Action
Breach-notification SLA
DPA / MSA notification clause and deadline
Put the vendor on the clock; demand facts within the SLA window
Audit / right to information
Audit & right-to-information clause
Exercise it to obtain forensic facts, scope and sub-processor detail
Indemnity
Indemnity / liability clause and its notice conditions
Preserve the claim — give notice exactly as the clause requires
Termination / exit
Termination-for-cause and exit/transition clause
Keep on the table; begin an exit/transition plan if warranted
Follow indemnity notice requirements precisely — a late or defective notice can forfeit the claim. Coordinate with the vendor on facts, but do not cede control of your own legal disclosures to them.
03Our notification decision
Notification duties are driven by the categories of data and the jurisdictions of the people affected — mapped to OUR legal duties — not by the vendor’s template or preferred announcement date. The same incident can trigger several regimes, each on its own threshold and clock.
Regime / trigger
Applies to
Deadline
Decision
GDPR / UK GDPR
EU/UK personal data affected
72h to authority; data subjects if high risk
Notify / not / assessing
US state breach laws
State residents; esp. SSNs, financial
Per state — often “without unreasonable delay”
Notify / not / assessing
HIPAA / sector rules
PHI or regulated data affected
Per rule
Notify / not / assessing
Contractual customer notice
Customers owed notice by contract
Per contract
Notify / not / assessing
Notification decision owner
Who signs off — legal, privacy, security
Rationale
Tie each decision to the data and the affected people, not the vendor’s timeline
Your clocks run on YOUR awareness and the data involved. A vendor’s slower announcement date does not extend your statutory deadlines.
04Interim controls
Assume the vendor may still be compromised and that shared trust is a path into your estate. Apply on the assumption of compromise — do not wait for proof your specific credentials were stolen.
Rotate all credentials shared with the vendor (API keys, passwords, service-account secrets)
Revoke OAuth tokens, session cookies and SSO/SAML trust tied to the integration
Isolate or pause the integration / data flow with the vendor
Enforce MFA on any account touching the vendor relationship; reset reused passwords
Increase monitoring/logging on the integration and on data paths from the vendor
Restore only on verified-clean terms — rotated credentials, least-privilege scoped and short-lived tokens — gated on the vendor’s confirmed eradication, not the pre-incident trust
Business pressure to “get back to normal” is exactly when a re-enabled integration on old, possibly-compromised credentials re-opens the breach. Gate restoration on confirmed eradication.
05Concentration-risk register & board message
A vendor breach is the moment concentration risk becomes concrete. Show the board how much depends on this one supplier and what reduces it.
Critical service / process
Dependency on this vendor
Single point of failure?
Remediation / de-risking
e.g. payroll
Sole provider / primary / one of several
Yes / partial / no
Redundancy, tested exit plan, split dependency
e.g. identity / SSO
…
…
…
Add rows as needed
…
…
…
Board message
The incident + the structural fix: how many critical processes hinge on one vendor and what we are doing about it
Vendor-risk register update
Re-score inherent/residual risk; decision on the relationship — new controls, remediation, or exit
Close the loop in your third-party risk program: a vendor breach is a data point to re-score the vendor and formally reassess the relationship, not a ticket to close once the integration is restored.
06Board brief skeleton
A tight, decision-oriented brief for the board — facts, our exposure, what we have done, what we owe, and the structural question.
What happened: the vendor was breached and our data/operations are affected (state facts, not blame — fault is for after the facts and contract review).
Our blast radius: which data, which systems, how many records, which customers and jurisdictions.
What we have done: interim controls applied (credentials rotated, integration isolated, MFA enforced, monitoring raised).
What we owe: our notification decisions by regime, on our clocks; SEC materiality assessment underway — third-party incidents are not carved out of Item 1.05.
The structural question: concentration risk on this vendor and the remediation path (redundancy, exit plan, de-risking the dependency).
Keep comms coordinated with the vendor on facts and timing, but keep your own counsel and control of your notifications and filings. Do not let the vendor approve your legal disclosures.
Practice the decision
This playbook records calls you can rehearse. The free Vendor-Breach Board Response Lab puts you in the response committee and grades you on ~14 of the exact decisions this playbook documents — sizing the blast radius, rotating shared credentials, pulling the contract levers, and deciding notification on your own clocks rather than the vendor’s.
TL;DR
What this template is
A board-ready playbook that records YOUR response when a critical third-party or SaaS vendor is breached and your data or operations are affected — triage, contract levers, notification decision, interim controls, concentration risk and the board brief.
Built on the principle that a vendor’s breach is still your event: the vendor’s obligations do not discharge your own notification, disclosure and customer duties.
Sections: what we know (scope), contract levers, our notification decision by regime, interim controls, concentration-risk register + board message, and a board brief skeleton.
Copy it or download it as Markdown and adapt it in your own document — nothing is uploaded.
Practise the underlying decisions in the free Vendor-Breach Board Response Lab. Educational template — not legal advice. Use it with qualified counsel.
Frequently asked questions
What is this template for?+
It is a response playbook and board brief a company can use when a critical third-party or SaaS vendor is breached and its own data or operations are affected. It captures the triage of your own exposure, the contract levers to pull, your notification decision mapped to the data and jurisdictions, the interim controls, the concentration-risk picture and a board brief skeleton.
If the breach was at the vendor, are the notification duties really ours?+
Usually yes. As the data owner/controller you keep your legal duties regardless of whose systems were breached, and notification clocks (GDPR’s 72 hours, US state laws, HIPAA, sector and contractual rules) run on your awareness and the data involved — not on the vendor’s preferred announcement date. Coordinate with the vendor, but your deadlines are yours.
Does the SEC 8-K rule apply to a vendor-hosted incident?+
Third-party incidents are not carved out of the SEC cybersecurity disclosure rules. If the impact on your company is material you must assess and, if required, disclose on Form 8-K Item 1.05 to the extent of your knowledge — relying on the vendor for facts that may be incomplete at filing. Pair this with the 8-K materiality memo.
Is this legal advice?+
No. It is an educational template. The regulatory references are summarised for orientation and can change; confirm current requirements and apply them to your specific facts and contracts with qualified counsel.
🎉 New here? Use code WELCOME10 for 10% off any plan at checkout