Incident response tabletop exercise

Updated

Scenarios built from your stack, with timed injects, discussion questions and the actions your own Incident Response Policy expects, plus a Word facilitator guide with an attendance sheet, decisions log and after-action report template. Built in your browser from your generator answers, or from the sample company.

Choose and preview a scenario

Up to six scenarios are built from your answers: a leaked cloud key in your source control, an account takeover through your identity provider (worded for whether multi-factor authentication is enforced), a lost or ransomware-hit laptop depending on whether you use device management, a compromised dependency in your CI/CD pipeline, a customer seeing another customer’s data, and a hosting region outage, which is optional unless Availability is in your report scope. One is marked as recommended for your setup.

This is the sample company, Northwind Cloud Inc. The scenarios and the quoted policy text come from its answers and policies, not yours. Answer the generator questions (in your browser) and come back: the scenarios then use your hosting, identity provider, source control, device management and data types, and quote your own Incident Response Policy.

Pick a scenario

Download the facilitator guide

Word file with how to run the session, the severity table from the sample Incident Response Policy, the scenario with its injects and questions, an attendance sheet, a decisions log and an after-action report template. Built in your browser; nothing is uploaded.

Leaked AWS access key in a public GitHub repository

A long-lived AWS access key with write access to production in AWS is found in a public repository on GitHub, six days after it was pushed. The exercise tests reporting, the revoke-first rule, evidence handling and the notification decision once the key turns out to have been used.

87 minutes. Starting severity SEV2. Criteria the record can support: CC7.3, CC7.4, CC7.5.

Objectives

  • Confirm that a report from outside reaches security@northwindcloud.example and is acknowledged within the policy's target.
  • Practice classifying with the policy's severity levels, and raising the level when the facts change.
  • Agree who may revoke a production credential at once, even when it breaks deployments.
  • Walk through the notification assessment for data that may have been read with the key.

Who takes part

RoleWhoPart in the exercise
Facilitator[Fill in: name]Runs the exercise, reads the injects and keeps time. Does not play a response role.
Security Owner, acting as Incident CommanderP13 section 3Dana Whitfield, CTOTriages, assigns severity and directs the response as the single decision-maker unless someone else is appointed.
Engineering (on-call responder)P13 section 3[Fill in: names]Contains, eradicates and recovers in AWS and Vercel, GitHub and related systems, and preserves evidence.
Executive ManagementP13 section 3Priya Natarajan, CEOIs told about SEV1 and SEV2 incidents, decides on customer and regulatory notification and approves external messages.
ScribeP13 section 5.3[Fill in: name]Keeps the decisions log and the timeline during the exercise, the same job the scribe does in a real incident.
Communications leadP13 section 5.3[Fill in: name]Drafts the internal update and any customer message, and routes them for approval.
Legal (outside counsel)P13 section 4.9[Fill in: firm or name, or a stand-in who will brief counsel]Advises on notification duties and deadlines. If counsel cannot attend, someone plays the role and the open questions go to counsel afterward.

Injects

  1. 0:10 · Inject 1: The report (in the story: Tuesday 09:10)

    A security researcher emails security@northwindcloud.example: a public repository on GitHub contains an AWS access key in a configuration file committed six days ago. The repository is a personal fork of an internal Northwind service.

    • Who reads security@northwindcloud.example today, and how fast is the report acknowledged?
    • What severity do you assign right now, and on what facts?
    • Who is the Incident Commander, and who opens the incident record?
    • How do you find out whether the key is still active without using it?

  2. 0:20 · Inject 2: Revoke now or wait? (in the story: Tuesday 09:35)

    Engineering confirms the key belongs to a deployment identity with write access to production storage in AWS. Revoking it will break the GitHub Actions deploy job until a new secret is in place, and a release is planned for 11:00.

    • Do you revoke immediately? Who has the authority to decide, and who has to be told?
    • What do you capture before revoking: the key's last-used record, audit trail exports, the commit?
    • Where is each action and its time written down?

  3. 0:30 · Inject 3: The key was used (in the story: Tuesday 10:20)

    The AWS audit trail shows the key was used three days ago from an unfamiliar address to list storage buckets and download two objects from a bucket that holds personal data.

    • Does the severity change? Who changes it, and is the reason recorded?
    • Who must be told now, and by when, under the policy's notification column?
    • Who starts the notification assessment, and what facts does it need?
    • What do you still not know, and who is finding out?

  4. 0:40 · Inject 4: Still in history (in the story: Tuesday 13:00)

    The commit is still visible in the fork's history and in two forks of the fork. Secret scanning in GitHub did not alert, because the repository sits outside your organization.

    • How do you get the commit removed, and does that matter once the key is revoked?
    • Which other places could hold copies of long-lived keys (laptops, GitHub Actions variables, chat)?
    • What control gap does this show, and which policy should change?

  5. 0:50 · Inject 5: A customer asks (in the story: Wednesday 08:30)

    A customer's security team emails your support address asking whether they are affected, after seeing a social media post about the leaked key.

    • Who may reply, and who approves the reply?
    • What can you say before the investigation confirms which data was read?
    • When does the clock for customer notification start under your policy?

Expected actions, from the sample policies

Each line quotes the policy text that sets the requirement. Compare the team’s answers with these; a difference is a finding, either in how you work or in the policy.

  • Whoever spots it reports it to security@northwindcloud.example. (P13 section 4.1)“Anyone who observes or suspects a security incident must report it to security@northwindcloud.example within one hour of discovery.”
  • Treat a leaked production key as a likely compromise of one system. Classify it as SEV2 - High and meet the SEV2 response targets. (P13 section 2)“Acknowledge in 30 minutes; Incident Commander in 1 hour; containment in 4 hours; updates every 4 hours”
  • Tell the people the policy names for SEV2. (P13 section 2)“Executive Management within 4 hours; affected customers”
  • Once the key is shown to have read customer data, treat it as confirmed exposure. Classify it as SEV1 - Critical and meet the SEV1 response targets. (P13 section 2)“Acknowledge in 15 minutes; Incident Commander in 30 minutes; containment under way in 1 hour; updates hourly”
  • Tell the people the policy names for SEV1. (P13 section 2)“Executive Management immediately; customers and regulators per Section 5”
  • Revoke and rotate the exposed key, then review logs for use of the exposed value. (P04 section 5.6)“If a credential is committed to GitHub, pasted into chat or otherwise exposed, the finder reports to security@northwindcloud.example immediately. Engineering revokes and rotates it within four hours and reviews logs for use of the exposed value; the Security Owner records an incident.”
  • Rotate compromised credentials and revoke sessions as a first action. (P13 section 4.6)“Compromised credentials are rotated and sessions revoked in Okta as a first action; compromised hosts are isolated, not rebuilt, until evidence is captured.”
  • Preserve logs, audit trails and snapshots before any remediation that could destroy them. (P13 section 4.5)“Evidence, including logs in Datadog, cloud audit trails, snapshots and access records, is preserved before any remediation that could destroy it; evidence that may be needed in a dispute is kept in a restricted location with a chain-of-custody note.”
  • Prepare the notification assessment: who must be told, by when, and who approves each message. (P13 section 5.7)“Within 24 hours of confirming that customer or personal data was affected, the Security Owner prepares a notification assessment listing who must be told and by when;”
  • Notify affected customers within the deadline the policy sets once their data is confirmed affected. (P13 section 4.8)“Affected customers are notified without undue delay, within any contractual timeframe, and in every case within 72 hours of Northwind Cloud Inc confirming their data was affected, stating what happened, what Northwind Cloud Inc has done and what the customer should do.”
  • Assess legal, regulatory and contractual notification duties for the data involved, with outside counsel where unclear. (P13 section 4.9)“Where personal data is involved, supervisory authorities are notified within 72 hours where the GDPR or UK GDPR applies, affected individuals and state attorneys general where US state breach-notification laws require it, and customers acting as data controllers in time to meet their own deadlines.”
  • Route every message to customers, the press or other outsiders through the people the policy authorizes. (P13 section 4.7)“Only Executive Management, or their designate for the incident, communicates about it with customers, the press, regulators, law enforcement or the public; personnel must not confirm, deny or speculate about incidents with third parties.”
  • Check why the secret could be committed, and whether secret scanning and push protection cover forks. (P10 section 4.8)“Secrets follow the Encryption and Key Management Policy: never hard-coded or committed to GitHub, always injected from the secrets manager at runtime, and protected by secret scanning and push protection.”
  • Hold the blameless post-incident review and track each corrective action to closure. (P13 section 4.11)“Every SEV1 and SEV2 incident receives a blameless post-incident review within five business days of closure that produces a root cause, impact statement and corrective actions with owners and due dates, tracked to closure and reported to Executive Management.”

Evidence to keep

  • Signed attendance sheet with the date, start and end time
  • This facilitator guide as used, with the injects and questions read out
  • The decisions log kept by the scribe
  • The after-action report, approved by the Security Owner
  • Action items with owners and due dates, and later proof that each was closed
  • A sample of the records a real incident would produce: the AWS key last-used record and audit trail export, the rotation ticket, and the draft notification assessment

How to run it

  1. Pick a date, a facilitator who does not play a response role, and one scenario. Book 60 to 90 minutes.
  2. Invite the participants listed for the scenario and name a scribe for the decisions log.
  3. Open with the ground rules and the severity table from your policy, then read the injects in order.
  4. After each inject, let the group answer the questions; the facilitator compares answers with the expected actions.
  5. Close with a short debrief and agree an owner and due date for every gap.
  6. Write the after-action report within a week, collect sign-off and track the action items to closure.

The ground rules printed in the guide:

  • No fault. The exercise tests the plan and the policies, not the people. Nobody is graded, and gaps are the useful output.
  • Answer as you would on the day, with the tools and access you really have. If you would need to look something up, say where.
  • Stay in the scenario. Do not argue with the facts the facilitator gives; ask questions instead.
  • Decisions are made by the role that owns them under the policy, and the scribe writes each one down with the time.
  • Phones and chat are for the exercise only. If a real incident starts, the exercise stops.
  • Nothing said in the room is shared outside it beyond the after-action report.

What auditors look for

A tabletop record is evidence of how you test your incident response, not proof that controls operate. What an auditor asks for depends on the firm and on what your policy commits to. Things that may be requested:

  • Evidence that the incident response plan was tested during the period: a dated record of the exercise, the scenario used and who attended.
  • That the exercise involved the roles the policy names, and that decisions were recorded.
  • An after-action report with gaps, owners and due dates, and later evidence that the actions were closed or tracked.
  • Policy or plan updates that trace back to the exercise findings.

The Trust Services criteria the record relates to:

Agree the format of the evidence with your CPA firm before the period starts. The exercise frequency your auditor tests against is the one in your own incident response policy, so do not promise more exercises than you will run.

Related templates

  • Incident response plan template: the step-by-step plan the exercise tests, with severity levels, roles and communication templates.
  • Policy generator: answer the questions once and this page, the plan and all 22 policies use your tools, owners and scope.
  • Audit Kit: the paid kit includes this facilitator guide with every scenario and the action item tracker, built from your tailored policies.

Frequently asked questions

What is an incident response tabletop exercise?
A meeting where the people who would respond to a security incident talk through a realistic scenario, step by step, as a facilitator reveals new facts. Nobody touches production. The point is to find out whether the plan, the contact details and the decision rights work before a real incident tests them.
Does SOC 2 require a tabletop exercise?
The criteria do not name one. They ask for a defined incident response process (CC7.4) and documented recovery (CC7.5), and incident response policies, including the Policyseed template, often commit to testing the plan at least once a year. If your policy says you exercise the plan, the auditor can ask for the record. A tabletop is a low-cost way to produce one; a real incident handled and reviewed under the policy also counts as evidence that the process runs.
How long does it take?
Plan for 60 to 90 minutes for one scenario: about ten minutes of introduction, five injects ten minutes apart, a debrief and a few minutes to agree action items. Writing the after-action report afterward takes another hour or two.
Who should attend?
The people your Incident Response Policy names: the Security Owner, Engineering and Executive Management at minimum, plus a scribe, someone who writes customer communications and whoever advises on legal notification duties. Pick a facilitator who does not play a response role. In a very small team one person may hold several roles; say so in the attendance sheet.
Where do the expected actions and timings come from?
From the 22 policies the generator renders from your answers, rendered again in this browser. The severity table is section 2 of your Incident Response Policy, so a 1 to 10 person team sees the response targets its own policy sets for a small team. Other requirements are quoted word for word with the policy id and section. If you edited your policies after downloading them, check the quotes against your edited text.
Is anything uploaded?
No. Your generator answers stay in this browser's local storage, the policies are rendered here and the Word and Excel files are built here. Without saved answers the page shows the sample company, Northwind Cloud Inc.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.