The Supplier-Breach Tabletop Exercise, Ready to Run

Key takeaways

• This is the scenario plans skip. A supplier breach is an incident you do not control but must answer for, and most plans have no section for it. Teams postpone the scenario because it feels like someone else's problem, and because designing it looks like a project. It is neither.
• The scenario is a cascade, not an event. Outage first, data-exposure questions second, your notification clocks third. Each phase forces a different function to speak: operations, then legal and communications, then the business owner who signs the resumption decision.
• Three questions are the spine. Which business service is affected first. Who coordinates the response across security, operations, communications, and that supplier. What evidence would give the business confidence that the service is ready to resume. The team answers each one in specific terms, or the vagueness itself is the finding.
• The debrief is the deliverable. A run that ends without a written gap list with owners and dates was a meeting. The kit's debrief form records answers verbatim and is built to drop straight into the post-incident review process.

Why the supplier-breach scenario is the one teams skip

Our tabletop exercise guide teaches how to design an exercise from scratch: pick the scenario from your world, write it in stages, write the injects. That method is right, and it is also the reason the supplier scenario keeps getting postponed. It looks like it needs a named supplier, a read contract, and a modeled cascade before the exercise can start, so teams file it under next quarter and rehearse ransomware on their own estate instead.

CISA publishes free tabletop exercise packages at cisa.gov: downloadable, off-the-shelf kits the agency describes as comprehensive resources for stakeholders conducting their own exercises, and they are the authoritative generic source. Use them. What a generic package does not hand you is the specific question a supplier breach raises: an incident on infrastructure you pay for but do not control, holding data you must answer for, resolved on evidence you cannot collect yourself. This kit is the supply-chain-specific companion. The design work is done, the cascade is already written, and the only preparation left is swapping in your supplier's real name.

The scenario has also moved up the regulatory list. Under CIRCIA's proposed reporting rule, unauthorized access through a cloud service provider, managed service provider, or supply chain compromise is one of the four triggers that would make an incident substantial for covered entities. The rule is proposed, the clocks are not running, and no compliance date exists yet. But the proposed test turns someone else's intrusion into your reportable event, and the time to learn whether your plan handles that is before the rule lands.

The scenario in brief

The kit's scenario is a ransomware event at a critical software supplier, and it arrives in three moves.

The outage comes first, on a Friday morning. The business service you run on their platform degrades. Customers notice before the supplier says anything, so the first signal in the room is a screenshot, not an alert from your own monitoring.

The data questions come second. Over the weekend the supplier confirms ransomware in three sentences and says it is investigating whether customer data was affected. Then your security team finds that credentials you issued to the supplier appear in the data the ransomware group leaked. Your data lived in their estate, which turns their incident into your exposure.

Your clocks come third. The systems were theirs, but the duty to notify your customers, your regulator, and possibly CISA can be yours, and some of those clocks start when you learn of the exposure, not when the supplier finishes investigating.

The kit's spine is three discussion questions, one per phase, and every inject exists to force them into the open:

1. If a key supplier becomes unavailable, which business service is affected first?
2. Who coordinates the response across security, operations, communications, and that supplier?
3. What evidence would give the business confidence that the service is ready to resume?

The phased walkthrough

Phase 0: setup and roles. Twenty minutes before any scenario text is read. The facilitator is named and is not on the response team. The room holds security, operations, communications, legal, and the person who owns the supplier relationship day to day. If that person has no seat, stop and write it down, because the exercise has produced its first finding before it started. Three documents are in the room: the incident response plan template, the contact tree, and the contract with the supplier. Nobody reads them yet. Looking things up mid-exercise, on the clock, is part of the test.

Phase 1: the outage. The facilitator reads the scenario brief and the first injects. Tickets stack and a customer posts a screenshot before any vendor notice arrives. The supplier's status page says it is investigating a service disruption, with no cause and no ETA. The account manager, reached on a personal cell phone because the support portal is down, asks the team not to tell anyone. The facilitator asks spine question 1 and records the answer verbatim. The follow-ups that matter: which service breaks second and third, what the dependency map says, and whether the answer came from a document or from someone's memory.

Phase 2: the data questions and the clocks. The supplier's three-sentence ransomware confirmation lands, then the discovery that credentials you issued them appear in the leak, then legal asking what the contract required the supplier to tell you and when, with nobody able to find the clause. The facilitator asks spine question 2. The discussions that earn their time: what to demand from the supplier in writing, which of your clocks started and on what trigger, who forms the belief that starts them, and what the contain-and-preserve discipline from the breach response checklist looks like when the systems in question are not yours. For data on your people, the state breach notification laws where those people live key off discovery, so the operative question is when your organization learned, not when the supplier confirmed.

Phase 3: the resumption decision. The supplier announces all systems operational and invites reconnection and credential rotation. A security engineer asks whether they rebuilt from clean images or restored from backups, and gets no answer. The business owner wants the service back today because of a quarter-end process. The facilitator asks spine question 3 and does not accept "when the vendor says it is fine."

Thirty minutes or three hours

The 30-minute version is not a warmup that produces nothing. The three spine questions force named answers, and a team that cannot name its first affected business service in seven minutes has found its first finding before the coffee cools. Book the full run before the short one ends, or it will not happen.

The three-hour version adds one thing short runs cannot: live lookups. When legal asks for the contract's breach-notice clause, the clock runs and someone goes to find it. A ten-minute search through a shared drive is a finding with a timestamp. Never circulate the documents in advance; surprise is part of what you are testing.

What good answers look like, question by question

Question 1, the first affected service. A good answer names a business service, not a system: order fulfillment for the east region, not the database. It names the second and third order effects, because the cascade is where the cost sits. And it names the source: the answer came from a dependency map or it came from someone's memory. Memory is a finding. If the room answers with "probably", the exercise has surfaced its first gap: nobody has mapped which services ride on which suppliers.

Question 2, coordination. A good answer names one person who holds the response across security, operations, communications, and the supplier lane, which is the role the incident commander exists for, plus a named owner per lane and a named deputy. "We would set up a call" is a finding with no name attached. The supplier lane deserves the hardest look: the answer must include a contact path that does not run through the support portal, because the portal is down in the scenario and it will be down in reality.

Question 3, evidence-based resumption. A good answer is a list of artifacts, not assurances: the supplier's written summary of what happened and what they did about it; an indicator-of-compromise sweep of your own estate; rotation of every credential and token you ever issued them, with the integration side verified, not just the password side; a signed statement of what they attest to, ideally tied to a contract clause; and a defined monitoring window after reconnection. All systems operational is a status page claim. The phase forces the real question: what would let the business sign its name to the decision, and who is the signer.

How the debrief feeds the post-incident review

The kit's debrief form records three things: the verbatim answers to the three spine questions, every gap surfaced with an owner and a due date, and every document the team tried to find and failed. That is deliberately the same shape as the post-incident review process, so a real incident later starts from paperwork the team has already practiced filling out.

Feed each finding where it belongs. Plan gaps go into the next revision of the plan. Contract gaps, a missing notice clause, no audit rights, no cooperation duty, go to procurement with dates. Contact gaps go into the contact tree the same week. The dependency gap becomes the backlog for the first version of a dependency map.

Then rerun it. A supplier scenario once a year keeps the answers warm, and the second run should test at least one fix the first run produced. That closes the loop the same way a real incident would: exercise, findings, changes, exercise again.

Frequently asked questions

Who has to be in the room? Security cannot answer any of the three spine questions alone. Question 1 belongs to operations and the business owners, question 2 belongs to legal and communications as much as to security, and question 3 belongs to the business owner weighing security's evidence. Add the person who manages the supplier relationship. The facilitator must not be on the response team.

We have no dependency map. Should we still run it? Yes, and the missing map is the point. Run the scenario, record every "probably" and "I think" as the answer to question 1, and that recording is the backlog for the first version of the map. A finished map makes the run smoother. A missing map makes it more productive.

Should the supplier join the exercise? Not the first run. The first run tests your side: your contacts, your contract rights, your clocks. Close the internal gaps it surfaces, then invite the supplier to a second exercise and share the findings that touch the relationship. A joint exercise run before that turns into a performance.

How does this differ from CISA's free tabletop packages? CISA's packages, the free off-the-shelf kits at cisa.gov, are the authoritative generic source for exercise material across many topics. This kit follows the same package shape, a scenario brief, injects, facilitator notes, and a debrief form, with the depth spent on one scenario: a supplier breach with your data exposure, your clocks, and your resumption decision. Use both. Run ours this week, and theirs for the rest of the rotation.

Free download: the full first-days playbook behind this kit: The Incident Response Handbook (PDF, 20 pages) →