Crisis Simulations
Tabletop Exercise Scenarios — Six Crisis Simulations
Pressure-tested scenarios drawn from real breach patterns. Each one designed to expose gaps before an actual attacker does.
Sherlock Forensics offers six cybersecurity tabletop exercise scenarios: ransomware attack, business email compromise, data breach and exfiltration, insider threat, supply chain compromise and cloud infrastructure attack. Each scenario uses the 3-phase inject model with escalating pressure and targeted probing questions.
Scenario 1
Ransomware Attack
Monday morning. File servers encrypted. A ransom note demands $500K in Bitcoin within 48 hours. IT discovers that backup integrity is uncertain. Operations are grinding to a halt and staff are calling in asking what to do.
- Phase 1 — Initial Detection
IT discovers encrypted files on the shared drive at 7:42 AM. The ransom note references a Tor payment portal. File extensions have been changed to .locked across three departments. The helpdesk is flooded with tickets. - Phase 2 — Escalation
Encryption is spreading to additional servers. The ERP system is now affected. Business operations are halted. The attacker contacts you through a secondary channel claiming they exfiltrated data before encrypting. They threaten to publish customer records if payment is not received. - Phase 3 — External Pressure
Ransom deadline is in 24 hours. A local journalist calls asking for comment on "a major cybersecurity incident at your company." Your cyber insurance carrier needs a call within the hour. Two key clients are asking whether their data was compromised.
- Who has the authority to approve or deny ransom payment?
- Most organizations discover during the exercise that this question has never been formally answered. The CEO assumes the board decides. The board assumes the CEO decides. The delay costs hours.
- Where are your offline backups and when were they last verified?
- Backups that have not been tested are not backups. This question forces teams to confront whether their recovery strategy is theoretical or functional.
- Who notifies the cyber insurance carrier and what triggers that notification?
- Late notification can void coverage. Teams need to know the carrier's contact number, the policy number and the notification window without having to search for it during a crisis.
Common Gaps Found
- No offline backup verification process. Last restore test was over 12 months ago or never performed.
- Unclear payment authority. No pre-established decision framework for ransom demands.
- No media spokesperson designated. Communications team has no prepared holding statement for cyber incidents.
- Insurance carrier contact information not readily accessible to the incident response team.
Scenario 2
Business Email Compromise (BEC)
The CFO receives a spoofed email from the CEO authorizing a $250K wire transfer to a new vendor account. The email references a real acquisition discussion that only senior leadership would know about. Accounting processes the transfer. The funds are gone.
- Phase 1 — Discovery
Accounting flags an unusual wire transfer request during a routine reconciliation. The amount is $250K to an account that does not appear in the vendor master file. The requesting email came from what appears to be the CEO's address. - Phase 2 — Confirmation
The bank confirms funds were sent and received by an overseas account. A recall request has been initiated but the receiving bank is not responding. Further examination reveals the email originated from a lookalike domain registered 48 hours prior. - Phase 3 — Scope Expansion
Three additional spoofed emails are discovered in other executives' inboxes. One targets a second wire transfer. Analysis suggests the CEO's actual email account may be compromised. The attacker has been reading email threads for weeks.
- What verification steps exist for wire transfers above a defined threshold?
- BEC attacks succeed because financial controls assume email is a trusted channel. This question exposes whether out-of-band verification is policy or just a suggestion.
- Who has authority to halt outgoing payments and how quickly can they act?
- Speed matters. The window to recall a wire transfer is measured in hours. If the person with authority is unavailable, the funds are unrecoverable.
- How do you confirm email authenticity when the sender appears to be a known executive?
- Phone call verification, code words and separate communication channels are the countermeasures. Most organizations have none of these formally established.
Common Gaps Found
- No dual-authorization requirement for large transfers. Single-person approval enables BEC success.
- No out-of-band verification process. Staff rely on email as the sole confirmation channel.
- Email compromise not detected by existing security tools. DMARC, SPF and DKIM either not configured or not enforced.
- No process to quickly freeze outgoing payments when fraud is suspected.
Scenario 3
Data Breach / Exfiltration
Your threat intelligence vendor alerts you that customer PII has appeared on a dark web forum. The data includes names, email addresses, phone numbers and partial payment card numbers. The source of the breach is unknown. A journalist has the story and plans to publish tomorrow morning.
- Phase 1 — Alert
Threat intelligence vendor sends an urgent notification: a dataset matching your customer records has been posted to a dark web marketplace. The listing claims 50,000 records. A sample of 200 records appears legitimate based on formatting and field structure. - Phase 2 — Forensic Confirmation
Your forensic team confirms the data is authentic. Log analysis reveals unauthorized access to the customer database over a 3-week period. The attacker used a compromised service account with excessive privileges. 50,000 customer records were exfiltrated through an unmonitored egress point. - Phase 3 — Regulatory and Media Pressure
A journalist calls for comment. They already have the story and plan to publish in the morning edition. The PIPEDA 72-hour notification clock has started. Your legal team needs to determine which provincial and federal regulators require notification.
- Who leads the breach investigation and who has the authority to make containment decisions?
- Incident response leadership must be established before the incident. During the exercise, teams often discover that roles are ambiguous and decision-making stalls while people wait for direction.
- What is your breach notification process and who owns each step?
- Notification involves legal review, regulator communication, customer notification drafting, call center preparation and board notification. Each step needs an owner identified before the breach occurs.
- Who drafts the public statement and who approves it before release?
- The gap between "we need to say something" and "here is our approved statement" can be days if the approval chain is not pre-established. Every hour of silence erodes trust.
Common Gaps Found
- No breach notification template. Legal and communications teams start from scratch under pressure.
- Unclear regulatory timeline. Teams do not know the specific notification deadlines for their jurisdiction.
- No designated media spokesperson. Multiple people speak to the press with inconsistent messaging.
- Service accounts with excessive database privileges and no access review schedule.
Scenario 4
Insider Threat
A departing senior engineer downloaded 50GB of proprietary data to a personal USB drive two weeks before submitting a resignation letter. The DLP system flagged the transfer but the alert sat in a queue. The employee's last day is Friday.
- Phase 1 — Alert Triage
A DLP alert shows a large data transfer from a senior engineer's workstation to an unregistered USB device. The transfer occurred at 11:47 PM on a Tuesday. The data includes source code repositories, product roadmaps and customer pricing models. - Phase 2 — Context
HR confirms the employee submitted a resignation letter three days after the transfer. Their last day is Friday. The employee has accepted a position at a direct competitor. They still have full access to all systems including the production environment. - Phase 3 — Long-Term Impact
Three months later, the competitor announces a product with features that closely mirror your unreleased roadmap. Your sales team reports losing three deals to the competitor using suspiciously similar pricing. Legal needs to evaluate options.
- What access controls exist for employees who have submitted their resignation?
- The period between resignation and departure is the highest-risk window. Most organizations do not modify access until the employee's last day. By then, the damage is done.
- Who reviews DLP alerts and what is the response time expectation?
- A DLP alert that sits in a queue for two weeks is the same as having no DLP at all. This question forces teams to confront the gap between detection and response.
- What legal options exist for intellectual property theft and what evidence is needed?
- Trade secret litigation requires demonstrating that the information was protected, that the employee knew it was confidential and that the transfer was unauthorized. Forensic preservation must begin immediately.
- Does your offboarding checklist include forensic preservation of the departing employee's workstation?
- Most offboarding checklists cover badge collection and laptop return. Few include forensic imaging of the device before it is wiped and reissued.
Common Gaps Found
- No offboarding checklist that addresses security concerns. Access revocation happens on the last day rather than at resignation.
- DLP alerts not reviewed in real-time. Alert fatigue and understaffing leave critical transfers unexamined for days or weeks.
- No legal playbook for IP theft. Legal counsel must research options from scratch rather than executing a pre-defined response.
- No forensic imaging of departing employee workstations. Evidence is lost when devices are wiped during standard IT recycling.
Scenario 5
Supply Chain Compromise
Your critical SaaS vendor sends a breach notification. They were compromised and your data may have been exposed through their API integration. The vendor cannot confirm what data was accessed or how long the attacker had access. Your customers are already asking questions.
- Phase 1 — Vendor Notification
You receive a breach notification email from your CRM vendor. The email is vague: "unauthorized access to our systems" with no specifics about scope, timeline or affected data. The vendor promises an update within 48 hours. - Phase 2 — Scope Assessment
Your security team confirms that API tokens used to connect your systems to the vendor were exposed. The vendor's compromised environment had read access to your customer database through the integration. The vendor still cannot confirm the scope of access or whether data was exfiltrated. - Phase 3 — Vendor Communication Breakdown
The vendor goes silent. Their status page says "investigating" with no updates for 36 hours. Your largest client sends a formal inquiry asking whether their data was compromised. Your legal team needs to determine your notification obligations for a breach that originated at a third party.
- What data did the vendor have access to through the API integration?
- Most organizations cannot answer this question quickly. API permissions are configured once and forgotten. A vendor data inventory is the only way to know what was exposed.
- Can you revoke API access immediately and what breaks if you do?
- Revoking access stops the bleeding but may break production workflows. Teams need to know the blast radius of disconnecting a vendor before they pull the trigger.
- What does your vendor agreement say about breach notification timelines and liability?
- Vendor contracts often lack specific breach notification SLAs. When the vendor goes silent, your legal options depend entirely on what the contract says. If the contract is silent, so is the vendor.
Common Gaps Found
- No vendor data inventory. Teams cannot quickly identify what customer data each vendor can access.
- No API key rotation process. Tokens remain active indefinitely with no scheduled rotation or access review.
- Vendor agreements lack breach notification SLAs. Contracts do not specify notification timelines or data access scope documentation.
- No pre-defined process for evaluating your own notification obligations when a vendor is breached.
Scenario 6
Cloud Infrastructure Compromise
A security researcher contacts you through your responsible disclosure program. Your AWS root account credentials are sitting in a public GitHub repository. The commit was pushed 72 hours ago. You have no idea what has happened in those three days.
- Phase 1 — Credential Exposure
A security researcher reports your AWS access keys on a public GitHub repo. The keys belong to the root account. The commit was pushed by a developer who was testing a deployment script locally and accidentally committed the .env file. The repo has been public for 72 hours. - Phase 2 — Unauthorized Activity
CloudTrail logs show unauthorized API calls beginning six hours after the commit. New EC2 instances were created in regions you do not normally use. IAM users were created with administrative privileges. Security groups were modified to allow inbound access on non-standard ports. - Phase 3 — Business Impact
Crypto mining workloads are detected across 14 new EC2 instances. Your AWS bill has spiked by $23,000 in three days. More critically, CloudTrail shows ListBuckets and GetObject calls against S3 buckets containing customer data. You cannot confirm whether data was downloaded.
- Who has access to rotate root credentials and how long does it take?
- If the answer involves finding someone who knows the root account password, the delay could be hours. Root credential rotation should be a documented runbook that any authorized team member can execute.
- Can you identify all resources created by the attacker across all regions?
- Attackers deliberately spin up resources in regions you do not monitor. If CloudTrail is not enabled in all regions, you have blind spots that the attacker exploits deliberately.
- What S3 buckets contain sensitive data and do you have access logging enabled?
- Without S3 access logging or CloudTrail data events enabled, you cannot determine whether the attacker downloaded customer data. The difference between "we do not know" and "we confirmed no access" is the difference between a reportable breach and a contained incident.
Common Gaps Found
- Root credentials not protected by MFA. The most powerful account in the environment has the weakest protection.
- No CloudTrail monitoring across all regions. Attackers operate in unmonitored regions to avoid detection.
- No S3 bucket inventory. Teams cannot quickly identify which buckets contain sensitive data and which have access logging enabled.
- No secret scanning in CI/CD pipelines. Credentials in code are pushed to public repositories without automated detection.
Tailored
Custom Scenarios
Every organization faces different threats. The six scenarios above cover the most common incident types, but generic exercises miss the specific pressure points that matter to your business. We design custom scenarios based on your industry, technology stack and regulatory environment.
Financial services organizations need scenarios that incorporate OSFI B-13 reporting obligations and PCI DSS requirements. Healthcare organizations need scenarios that address PHIPA notification timelines and patient safety implications. Manufacturing environments need scenarios involving OT/IT convergence and industrial control system compromise.
SaaS companies face scenarios involving multi-tenant data exposure and customer notification at scale. Law firms deal with privilege concerns when client data is compromised. Government agencies navigate inter-departmental coordination and public disclosure requirements that differ fundamentally from private sector obligations.
Custom scenarios start with a threat assessment of your environment. We review your incident response plan, identify the gaps that generic exercises would miss and build injects that target those specific weaknesses. The result is an exercise that tests what actually matters to your organization rather than what matters to a generic template. Learn more about how our tabletop exercises work.
Questions
Scenario FAQ
Which scenario is most common?
Ransomware is our most requested scenario. It tests the widest range of organizational functions: IT operations, legal, communications, executive leadership and insurance coordination. Most organizations start with ransomware because the threat is immediate and the gaps it reveals apply to nearly every other incident type. After ransomware, business email compromise is the second most requested because it targets financial controls that many organizations have never stress-tested.
Can we combine multiple scenarios?
Yes. Full-day exercises can chain two or three scenarios together to simulate compounding crises. A business email compromise that escalates into a data breach tests both financial controls and breach notification processes in a single session. Combined scenarios reveal how teams perform under sustained pressure and whether they can manage parallel workstreams. We recommend single-scenario exercises for organizations running their first tabletop and combined scenarios for mature teams.
Are these scenarios based on real incidents?
Yes. Every scenario is based on patterns from actual breaches and incident response engagements. We strip identifying details and generalize the attack patterns so they apply across industries. The injects reflect real attacker behavior, real escalation timelines and real organizational pressure points that surface during live incidents. Participants consistently tell us the exercises feel uncomfortably realistic because they are built from experience rather than theory.
Do you create scenarios for specific industries?
Yes. Healthcare, financial services, manufacturing, SaaS, law firms and government organizations each face distinct regulatory requirements and threat profiles. A healthcare scenario incorporates PHIPA notification timelines and patient safety implications. A financial services scenario addresses OSFI B-13 reporting and PCI DSS breach procedures. We build the scenario around your regulatory environment so the exercise tests the obligations your team will actually face.
How realistic are the scenarios?
We base injects on real attack patterns and escalation timelines from incidents we have investigated. Scenarios include realistic details: specific ransom amounts, regulatory deadlines, media calls, vendor communication breakdowns and conflicting priorities between departments. The goal is to create enough pressure that participants respond as they would during a real incident. Comfortable exercises do not reveal gaps. Uncomfortable ones do.
Can we use these scenarios for board presentations?
Yes. Executive-level scenarios are designed to demonstrate risk to non-technical leadership. We create board-ready versions that focus on business impact, financial exposure, regulatory liability and reputational damage rather than technical implementation details. Board members engage more effectively when the scenario is framed as "we lost $250K in 20 minutes because of an email" rather than "the attacker exploited SPF misconfiguration." We also provide post-exercise reports suitable for board risk committee review.
Ready to Test Your Team?
Run a Scenario Before an Attacker Runs One for You
Every gap found in a tabletop exercise is a gap that does not get exploited in production. We facilitate exercises for teams of 5 to 50, from technical incident responders to executive leadership. Start with a single scenario or build a full-day program. See our tabletop exercise overview, review how exercises work or prepare with our incident response checklist.
Since 2006CISSP, ISSAP, ISSMP certified604.229.1994
Not Sure Which Scenario Fits Your Organization?
Call us. We will discuss your industry, your threat profile and your team's experience level. In 15 minutes we can recommend the right scenario and format for your first exercise.
Call 604.229.1994- Phone
- 604.229.1994