TTX-09 · Scenario card
Third-Party Breach Tabletop Exercise: The MFT Zero-Day
A third-party breach tabletop exercise: your file-transfer vendor is mass-exploited and you hear it from the news. 8 injects on scoping, contracts and notification.
A third-party breach tabletop exercise rehearses the moment you discover that a supplier holding your data has been compromised, and you do not control the investigation. This scenario models the mass exploitation of a zero-day in a managed file-transfer (MFT) service. You learn about it from news and threat intelligence before the vendor tells you, and your customers' files may have been on its servers.
The scenario is aimed at legal, executive and technical leaders, with procurement and privacy in the room. It tests vendor inventories, contractual rights, the difference between the vendor's timeline and yours, regulatory clocks and customer communication when facts are thin. The vendor and vulnerability are fictional; rename them to match a supplier that matters to you.
Scenario at a glance
| Threat | Mass exploitation of a zero-day in a third-party managed file-transfer service, with data theft from many customers |
| Difficulty | Intermediate |
| Duration | 2.5 hours including a 25-minute hotwash |
| Audience | Legal, executive and technical leaders |
| Recommended participants | CISO, IR lead, general counsel, privacy officer or DPO, procurement or vendor manager, communications lead, customer success lead, COO |
| Prerequisites | Vendor inventory and data-flow map, the MFT contract and data processing agreement, incident response and breach notification procedures |
| MITRE ATT&CK techniques | T1190 Exploit Public-Facing Application, T1199 Trusted Relationship, T1567 Exfiltration Over Web Service |
Exercise objectives
- Test how quickly the organisation can establish whether it uses an affected vendor, and for which business processes and data sets.
- Confirm who owns the vendor relationship during an incident and who can enforce contractual rights to information and cooperation.
- Rehearse scoping exposure when the vendor's information is incomplete or late.
- Validate how regulatory notification clocks are assessed when the breach happened at a processor, and who makes the call.
- Agree how customers are informed, what is said when facts are uncertain, and who approves the message.
- Identify changes to vendor due diligence, contracts and data-retention practice that leadership needs to sponsor.
Starting situation
Read this aloud to players:
It is Monday, 08:30. Your organisation uses a cloud-hosted managed file-transfer service, which we will call FileHarbor, to exchange large files with customers and partners. Operations uses it for weekly data extracts; customer success uses it to receive files from clients during onboarding.
FileHarbor has been a supplier for four years. The contract was signed by procurement and renewed automatically. Nobody on the security team has spoken to FileHarbor since the original due-diligence questionnaire.
Injects timeline
| # | Time | Inject | Delivered to | What players should address |
|---|---|---|---|---|
| 1 | T+00:00 | A threat-intelligence feed reports active exploitation of a FileHarbor zero-day at "hundreds of organisations" | SOC → CISO | Do we use it, for what, and who owns it |
| 2 | T+00:30 | A news site reports a data-extortion group claiming to have stolen files from FileHarbor customers | Communications → CISO | Situational awareness, internal escalation |
| 3 | T+01:00 | The vendor's status page says "investigating an issue"; your account manager does not answer | Vendor manager | Contractual contacts, escalation, rights |
| 4 | T+03:00 | Your logs show large downloads from your FileHarbor account by an unknown IP two days ago | IR lead | Exposure confirmation, scoping, evidence |
| 5 | T+05:00 | Operations confirms the folders held customer extracts with names, emails and account numbers, retained for 18 months | Privacy / DPO | Data inventory, retention, breach assessment |
| 6 | T+24:00 | FileHarbor's formal notice arrives: your account is "potentially affected"; details to follow | General counsel | Processor duties, DPA terms, notification clock |
| 7 | T+30:00 | A major customer's CISO emails asking whether their data was on FileHarbor and demands an answer by tomorrow | Customer success → CISO | Customer communication, consistency |
| 8 | T+48:00 | The extortion group lists your organisation's name on its leak site alongside 50 others | Executive team | Public statement, regulator contact, extortion |
Module 1 — Discovery (T+00:00 to T+01:00)
Inject 1. The SOC analyst forwards a threat-intelligence alert to the CISO: a previously unknown vulnerability in FileHarbor's web interface is being exploited at scale. The report says "hundreds of organisations" are affected and that attackers are downloading stored files. No patch is available yet.
Inject 2. The communications lead sends a link to a technology news site. A data-extortion group claims it has stolen files from FileHarbor customers and will publish names "in the coming days". Two people in the office have already shared the story in an internal chat channel with the comment "don't we use this?".
Inject 3. The vendor manager checks FileHarbor's status page, which says only "We are investigating an issue affecting some customers." The account manager's phone goes to voicemail. The contract lists a security contact email address that bounces.
Discussion questions:
- How long does it take to confirm you use FileHarbor, and which teams use it? Is there a single inventory?
- Who owns the vendor relationship during an incident: procurement, security or the business owner?
- Do you disable your FileHarbor accounts or integrations now, before the vendor confirms anything? What breaks if you do?
- What does the contract say about security incident notification, timelines and cooperation? Who has a copy to hand?
- What do you tell staff who are already talking about it internally?
Module 2 — Scoping your exposure (T+03:00 to T+05:00)
Inject 4. The IR lead pulls audit logs from the FileHarbor admin console. Two days ago, an IP address you do not recognise downloaded 14 GB from three folders in your account over 40 minutes. The activity used no user account that you can identify.
Inject 5. Operations confirms what the three folders contained: weekly customer extracts with names, email addresses and account numbers, plus onboarding files uploaded by clients. The files were meant to be deleted after 30 days, but no deletion job was ever configured, so the folders hold 18 months of data.
Discussion questions:
- Does the download confirm a breach of your data, or only a security incident at the vendor? What is the difference for your obligations?
- How do you preserve the logs you have before the vendor's platform changes or goes offline?
- Who can list which customers' data was in the three folders, and how long will that take?
- Why was 18 months of data retained? Who was accountable for the retention setting?
- Should you engage outside counsel and a forensic firm now, or wait for the vendor's findings?
Module 3 — Notification and fallout (T+24:00 to T+48:00)
Inject 6. FileHarbor sends its formal notice: your account is "potentially affected", investigations continue, and further details will follow "as soon as possible". The notice does not say which files were taken. Legal points out that your own logs showed the download 22 hours ago.
Inject 7. A major customer's CISO emails your customer success lead: "We understand you use FileHarbor. Was our data stored there? Please confirm in writing by tomorrow 12:00 and describe your remediation." Customer success asks security what to say.
Inject 8. Threat intelligence reports that the extortion group has added your organisation's name to its leak site, among about 50 others. No data has been published yet. A journalist asks whether you are one of the affected FileHarbor customers.
Discussion questions:
- When did you become "aware" of a personal-data breach: the news story, your own log review or the vendor's notice? Who decides, and is the reasoning recorded?
- Does the notification clock wait for the vendor's investigation? What do you file with incomplete facts?
- What do you tell the customer who asked, and how do you avoid telling different customers different things?
- Who approves a public statement, and does it name the vendor?
- Do you engage with the extortion group at all? Who is consulted before that decision?
Discussion questions
Consolidated themes for the hotwash and for facilitators who need prompts:
- Inventory: Did anyone know, within the first hour, which vendors hold which data?
- Ownership: Was there a single owner for the vendor during the incident, with authority to push for answers?
- Contracts: Could the team find the notification, audit and cooperation clauses under pressure?
- Regulatory judgement: Were notification decisions based on your own evidence or delayed waiting for the vendor?
- Customer trust: Was there one consistent message for customers, press and regulators?
- Data minimisation: Would shorter retention have reduced the exposure?
Curveballs / optional injects
Use one or two if the group is moving quickly:
- FileHarbor is acquired by a larger company mid-incident and the new owner's legal team takes over all communications.
- A second vendor you use, a payroll provider, turns out to run FileHarbor internally, so your employee data may also be exposed.
- A regulator contacts you first, having seen your name on the leak site, and asks for an update within 48 hours.
- The vendor releases indicators of compromise that show attacker activity began three weeks earlier than first reported.
Facilitator notes
Expected decisions. A well-prepared team confirms its use of the vendor within the first hour, names a single incident owner for the vendor relationship, and disables or restricts the affected integration while it investigates. Legal locates the contract and data processing agreement early. The team does not wait for the vendor to confirm what its own logs already show, and it records when and why it concluded a personal-data breach had occurred. Customer and public messages are drafted once and reused.
Common pitfalls.
- Nobody can say which business teams use the vendor, so scoping stalls for hours.
- The team treats the vendor's notice as the start of the clock, ignoring its own earlier evidence.
- Contract contacts are stale and nobody knows an escalation route inside the vendor.
- Customer success replies to the first customer without legal review, setting a precedent the organisation cannot keep.
- The retention failure is discussed as a technical oversight rather than a governance gap with an owner.
On regulation. Under GDPR the controller generally notifies the supervisory authority within 72 hours of becoming aware of a personal-data breach, where feasible, and informs individuals when the risk to them is high. Sector rules such as NIS2 and DORA may add their own reporting paths. Players should know whom they would consult; the exercise should not attempt to settle the legal question. The data breach notification scenario goes deeper on this.
Adapting the audience. For an executive session, deliver Module 1 as a briefing and spend the time on injects 6 to 8. For a technical session, expand inject 4 into log analysis, evidence preservation and a search for other vendors on the same platform. Compare this with the supply chain compromise scenario, where the vendor's software runs inside your network.
Evaluating the exercise
| Capability | What good looks like | Red flags |
|---|---|---|
| Vendor inventory | Use of the vendor, data sets and owners confirmed within an hour | Teams discover usage by asking around; no data-flow map |
| Incident ownership | One named owner for the vendor, with authority and a working contact route | Procurement, security and legal each assume another team owns it |
| Scoping | Own logs reviewed and preserved; affected data sets and customers listed | Waiting for the vendor to say what was taken |
| Contractual rights | Notification, audit and cooperation clauses found and used | Contract cannot be located; clauses unknown |
| Regulatory notification | Awareness point decided with reasoning; clocks tracked by a named person | Clock assumed to start with the vendor's letter |
| Communications | Consistent approved message for customers, press and regulators | Ad hoc replies to individual customers; conflicting statements |
Related
Frequently asked questions
What is a third-party breach tabletop exercise?
It is a facilitated discussion in which legal, security, procurement and leadership rehearse their response to a security incident at a supplier that holds or processes their data. Players work through timed injects covering discovery, scoping, contractual rights, customer and regulator notification, and communications, so gaps in vendor oversight appear in the exercise rather than during a real incident.
Who is responsible for notifying regulators when a vendor is breached?
Usually the organisation that controls the data. Under GDPR, a processor must inform the controller without undue delay, and the controller decides whether to notify the supervisory authority within 72 hours of becoming aware. Your contracts and data processing agreements should set out timings and cooperation duties; the exercise tests whether anyone knows where those clauses are.
How do you scope your exposure in a vendor breach?
Start with an inventory of what you send to the vendor: which data sets, which business processes, which accounts and for how long files are retained. Then compare that with what the vendor can confirm about the attack window. Most organisations find their inventory is incomplete, which is one of the most useful findings a vendor breach tabletop produces.
How often should we run a vendor breach tabletop?
Run one at least annually alongside your wider exercise programme, and consider inviting a critical supplier to join. Rotating the vendor in the scenario (file transfer, payroll, cloud hosting, customer support platform) tests different data flows and contracts each year without rewriting the whole exercise.