A vendor breach notice tabletop tests whether you can find every integration you have with a supplier, revoke its access, ask the right questions and decide what to tell your own customers, all from a vague email. This script runs 45 minutes with three injects.
Why vendor notices need rehearsal
Most vendor notices are short and say little. "Some customers may have been affected" leaves you to work out whether you are one of them. The work is internal: inventory what the vendor can reach, what you let it hold, and which of your credentials it stores. Teams that have never mapped these find out under pressure.
Use a fictional vendor, "Acme Metrics," a product analytics service connected to your app, your data warehouse and a chat workspace.
Setup
- Facilitator, scribe, an engineer who owns integrations, a security lead, a customer contact, and someone from procurement or legal if you have one.
- Handouts: nothing. The team should find its own integration list, or note that it cannot.
Injects
Inject 1, minute 5. An email from Acme Metrics says it detected unauthorised access to part of its systems and is investigating. No indicators, no date range.
Ask:
- Where do we use this vendor? How would we search code, secrets, SSO apps and billing?
- Who owns the relationship?
- What data do we send it? Is any personal or customer data included?
Inject 2, minute 20. You confirm the vendor holds an API key to your warehouse and an OAuth connection to your chat workspace.
Ask:
- How do we revoke each, and what breaks?
- What scopes were granted? Were they broader than needed?
- Should we wait for the vendor's detail before acting?
Inject 3, minute 35. A customer writes: "Your vendor was breached. Is our data affected?"
Ask:
- Who responds, and what can be said truthfully today?
- What do we refuse to speculate about?
- What contract or legal duties might apply? Name the person who would check.
What to listen for
| Topic | Strong sign | Weak sign |
|---|---|---|
| Inventory | A current list of third party integrations | Search in email and chat |
| Access | Scoped, revocable, owned credentials | Shared admin tokens |
| Data | Known data flows | "We think it is only analytics" |
| Communication | Holding statement ready | Debate about who may speak |
Questions to send the vendor
Rehearse writing these during the exercise:
- What systems and data of ours were accessible to the attacker?
- What is the time window?
- Which of our credentials do you hold, and have you rotated them?
- Will you share indicators and a final report, and when?
Write them down and decide who sends them. Do not assume the vendor will volunteer detail. If you want to practise the "are we affected" answer more fully, read how to answer are we affected after a supply chain incident and the contact sheet guide.
Debrief
Agree on three fixes: a maintained third party integration list, a rule that new integrations record scope and owner, and a holding statement template. Capture them in an after-action report.
Safeguard's asset discovery and compliance evidence automation can help keep an integration inventory current. A free scan of your repositories also shows which external packages and services your code references.
Quick check
Should we revoke access before the vendor finishes investigating?
Often yes, if the vendor holds credentials that can reach sensitive data and you can tolerate the interruption. Decide in advance who may approve it.
Do we have to tell our customers right away?
It depends on what you confirm and on your contract and legal duties. Check with the person responsible for those before you speak, and do not guess.
Last reviewed: 19 October 2026.
