1. Purpose
An Incident Response Tabletop Exercise is a structured discussion-based exercise used to evaluate whether an organization can effectively detect, assess, escalate, contain, investigate, communicate, recover from, and learn from a security incident.
The exercise does not normally involve real system changes or production disruption.
It is designed to answer a practical question:
If this incident happened today, would our people, processes, technology, and decision-making work as expected?
The exercise should identify weaknesses in:
- Incident detection
- Incident reporting
- Severity classification
- Escalation
- Roles and responsibilities
- Evidence preservation
- Technical response
- Customer communication
- Regulatory assessment
- Business continuity
- Recovery
- Decision-making
- Corrective actions
2. Scope
The exercise may cover:
- Phishing
- Account compromise
- Cloud compromise
- Data breach
- Ransomware
- Malware
- Insider incidents
- Supplier incidents
- Vulnerability exploitation
- Production outage caused by a security event
- CI/CD compromise
- API compromise
- Customer data exposure
- Credential theft
- Business email compromise
The scenario should be selected according to the organization’s risk profile.
3. Exercise Information
| Field | Details |
|---|---|
| Exercise ID | TRE-2026-001 |
| Exercise Name | Cloud Account Compromise Tabletop |
| Exercise Date | DD-MMM-YYYY |
| Start Time | HH:MM |
| End Time | HH:MM |
| Time Zone | IST/UTC |
| Exercise Owner | |
| Facilitator | |
| Recorder | |
| Scenario | |
| Exercise Type | Tabletop |
| Version | |
| Participants | |
| Business Unit | |
| Systems in Scope | |
| Exercise Classification | Internal |
4. Exercise Objectives
The objectives should be defined before the exercise.
Example objectives:
- Test whether employees know how to report a suspected security incident.
- Test incident severity classification.
- Test the Incident Response Team RACI.
- Test escalation and management notification.
- Test evidence preservation.
- Test cloud compromise response.
- Test customer-impact assessment.
- Test personal-data breach assessment.
- Test internal and external communication.
- Test business continuity and recovery decisions.
- Identify gaps in incident response procedures.
- Define corrective actions.
5. Exercise Method
The exercise follows a discussion-based approach.
Basic lifecycle
Scenario Introduction
↓
Inject
↓
Participant Discussion
↓
Decision
↓
Facilitator Challenge
↓
Next Inject
↓
Decision / Action
↓
Observation
↓
Exercise Debrief
↓
Findings
↓
Corrective Actions
↓
Management Review
6. Exercise Rules
Participants should understand the following rules before starting.
Rule 1 — Treat the Scenario as Real
Participants should respond as if the incident is actually occurring.
Rule 2 — Do Not Make Production Changes
The exercise must not result in unauthorized production actions.
Rule 3 — Use Existing Procedures
Participants should use the organization’s current:
- Incident Response Policy
- Incident Response Procedure
- Incident Reporting Form
- Incident Severity Matrix
- Incident Escalation Matrix
- Incident Response RACI
- Communication Procedure
- Specialized Incident Playbooks
Rule 4 — Ask Questions
Participants should identify information they would need rather than inventing facts.
Rule 5 — Document Decisions
Important decisions should be recorded with:
- Decision
- Decision maker
- Reason
- Information available
- Time
- Follow-up action
Rule 6 — Focus on Learning
The objective is to identify weaknesses, not blame individuals.
7. Participants
Recommended participants include:
| Role | Participant | Responsibility |
|---|---|---|
| Incident Commander | Overall coordination | |
| Security Lead | Security response | |
| IT/Cloud Lead | Infrastructure response | |
| Application/DevOps | Application and CI/CD response | |
| Investigator | Investigation and evidence | |
| Privacy/Data Protection | Privacy assessment | |
| Legal/Compliance | Legal/regulatory assessment | |
| Business Owner | Business impact | |
| Customer Success | Customer communication | |
| Communications | External communication | |
| Supplier Owner | Supplier coordination | |
| Executive Management | Major decisions | |
| BCP/DR | Continuity and recovery |
For a startup, one person may perform multiple roles.
8. Scenario Selection
The scenario should be realistic and relevant to the organization’s environment.
Consider:
- Critical business processes
- Critical information
- Important cloud services
- Customer data
- Privileged accounts
- External suppliers
- Internet-facing applications
- Known vulnerabilities
- Previous incidents
- Threat landscape
- Regulatory requirements
Example Scenario
Scenario: Compromised AWS Administrator Account
A security monitoring alert indicates that an administrator account has logged into the AWS environment from an unusual location.
Shortly afterward:
- A new IAM role is created.
- An existing IAM policy is modified.
- Several S3 objects are accessed.
- A security-group rule is changed.
- CloudTrail shows unusual activity.
- A customer-facing application remains operational.
The team must determine what to do.
9. Scenario Background
Record the information provided to participants before the exercise.
Organization
Example: SaaS company providing a B2B application hosted on AWS.
Critical Systems
- AWS production environment
- Customer application
- Customer database
- S3 storage
- IAM
- CI/CD platform
- Monitoring platform
Important Information
- Customer information
- Employee information
- Application data
- Source code
- Credentials and secrets
Existing Controls
- MFA
- IAM
- CloudTrail
- Security monitoring
- Backup
- Incident response procedures
- Incident escalation matrix
10. Exercise Injects
An inject is new information provided to participants during the exercise.
Injects should progressively increase the complexity of the incident.
Inject 1 — Initial Alert
Time: 09:00
Security monitoring generates an alert:
A privileged AWS identity has authenticated from an unusual location.
Questions
- Who receives the alert?
- Is this a security event or incident?
- Who validates it?
- Who should be notified?
- What evidence should be preserved?
- What is the initial severity?
Expected Discussion
Participants should identify:
- Identity
- Authentication event
- Source location
- Time
- Previous activity
- Related alerts
- CloudTrail evidence
11. Inject 2 — Suspicious IAM Activity
New information:
The account created a new IAM role approximately 10 minutes after authentication.
Questions
- Does the severity change?
- Should the account be contained?
- Who has authority to disable the identity?
- What evidence should be preserved?
- Should CloudTrail records be exported?
- Should the incident be escalated?
Expected Decisions
Participants should discuss:
- Identity containment
- Session revocation
- Access-key rotation
- Role investigation
- Privilege escalation
- Evidence preservation
- Incident escalation
12. Inject 3 — Production Changes
New information:
The newly created IAM role modified a production security-group rule.
Questions
- Is the production environment compromised?
- Should the affected resource be isolated?
- Should the security-group change be reverted?
- What evidence should be preserved first?
- Who approves the change?
- Does business continuity need to be considered?
13. Inject 4 — Customer Data Access
New information:
Cloud logs show that the compromised identity accessed an S3 bucket containing customer information.
Questions
- What information was accessed?
- Was information downloaded?
- How many customers may be affected?
- Does this constitute a data breach?
- Who performs the privacy assessment?
- Should Legal/Privacy be involved?
- Are customer notifications potentially required?
Participants should distinguish:
Evidence of access
from
Evidence of data exposure
from
Confirmed data exfiltration.
The exercise should not assume that data was exfiltrated merely because unauthorized access occurred.
14. Inject 5 — Customer Notification Pressure
New information:
A customer contacts Customer Success asking whether their information has been compromised.
Questions
- Who can respond?
- What information can be disclosed?
- Has the organization confirmed the facts?
- Does Legal/Privacy need to approve the response?
- What should the customer communication say?
- How should uncertainty be communicated?
Participants should avoid making unsupported statements.
15. Inject 6 — Media/Social Media Question
New information:
A customer posts publicly that the company may have suffered a security breach.
Questions
- Who manages external communications?
- Should the company respond publicly?
- What information has been verified?
- Who approves the statement?
- Could the response reveal sensitive investigation information?
16. Inject 7 — Recovery Decision
New information:
The security team confirms that unauthorized IAM activity has stopped. However, the investigation identifies several configuration changes.
Questions
- Is the environment safe to return to normal operation?
- Which configurations need validation?
- Which credentials should be rotated?
- Should systems be rebuilt?
- Should backups be checked?
- How will recovery be verified?
17. Inject 8 — Investigation Finding
New information:
Investigation shows that the attacker obtained access through a compromised developer credential.
Questions
- What was the root cause?
- Was MFA enabled?
- Were excessive permissions available?
- Were credentials stored securely?
- Was the developer endpoint compromised?
- Was lateral movement possible?
- Are other accounts affected?
- What corrective actions are required?
18. Decision Log
Every significant exercise decision should be recorded.
| Time | Decision | Decision Maker | Information Available | Reason | Follow-up |
|---|---|---|---|---|---|
| 09:05 | Escalate incident | Incident Commander | Cloud alert | Privileged identity activity | Investigate |
| 09:12 | Preserve CloudTrail | Security Lead | Suspicious role | Evidence retention risk | Export logs |
| 09:18 | Restrict account | Security Lead | Unauthorized activity | Prevent further access | Monitor |
19. Exercise Observation Log
The facilitator should record what actually happened.
| Area | Observation | Expected | Actual | Gap |
|---|---|---|---|---|
| Reporting | Employee knew reporting channel | Immediate report | Correct | No |
| Severity | Team classified incident | SEV-1/2 discussion | Delayed | Yes |
| Escalation | Management notified | Per matrix | 25 min delay | Yes |
| Evidence | Logs preserved | Immediate | Completed | No |
| Customer | Communication controlled | Authorized response | Correct | No |
20. Capability Assessment
Assess the exercise against key capabilities.
| Capability | Effective | Partially Effective | Not Effective | Notes |
|---|---|---|---|---|
| Incident Reporting | ☐ | ☐ | ☐ | |
| Detection Validation | ☐ | ☐ | ☐ | |
| Severity Classification | ☐ | ☐ | ☐ | |
| Escalation | ☐ | ☐ | ☐ | |
| RACI | ☐ | ☐ | ☐ | |
| Evidence Preservation | ☐ | ☐ | ☐ | |
| Containment | ☐ | ☐ | ☐ | |
| Investigation | ☐ | ☐ | ☐ | |
| Data Breach Assessment | ☐ | ☐ | ☐ | |
| Customer Communication | ☐ | ☐ | ☐ | |
| Regulatory Assessment | ☐ | ☐ | ☐ | |
| Recovery | ☐ | ☐ | ☐ | |
| Corrective Action | ☐ | ☐ | ☐ |
This assessment is an exercise evaluation, not an overall ranking of the organization’s security capability.
21. Key Questions for the Facilitator
The facilitator can challenge participants with questions such as:
Detection
- How did we discover the incident?
- Who validates the alert?
- What evidence is available?
Classification
- What makes this an incident?
- What severity should initially be assigned?
- What could increase the severity?
Escalation
- Who must be notified?
- How quickly?
- Who has decision authority?
Containment
- What can we safely disable?
- What could containment affect?
- What evidence should be preserved first?
Investigation
- What happened?
- When did it happen?
- Which accounts were involved?
- Which systems were accessed?
- Was data accessed?
- Was data exfiltrated?
Communication
- Who communicates internally?
- Who communicates with customers?
- Who communicates externally?
- What information has actually been verified?
Recovery
- How do we know the environment is clean?
- What needs to be restored?
- How do we validate recovery?
Improvement
- What failed?
- Why did it fail?
- What needs to change?
- Who owns the change?
- When will it be completed?
22. Evidence to Review During the Exercise
The exercise should test whether participants know where evidence would come from.
Examples:
- Incident reports
- Incident Register
- CloudTrail
- CloudWatch
- GuardDuty
- Security Hub
- IAM logs
- Application logs
- Database logs
- WAF logs
- VPC Flow Logs
- EDR
- Email logs
- Authentication logs
- CI/CD logs
- Backup records
- Supplier records
The exercise does not require participants to access or modify production systems.
23. Communication Exercise
The facilitator may ask participants to draft or verbally explain:
Internal Notification
- What happened?
- Severity
- Known impact
- Unknown information
- Actions underway
- Incident owner
- Next update
Customer Notification
- What has been confirmed?
- What information may be affected?
- What actions have been taken?
- What should the customer do?
- Who is the authorized contact?
Management Notification
- Business impact
- Customer impact
- Security impact
- Regulatory considerations
- Current response
- Decisions required
- Expected next steps
24. Exercise Performance Indicators
The following measurements can be captured:
| Metric | Result |
|---|---|
| Time to recognize incident | |
| Time to report | |
| Time to classify | |
| Time to escalate | |
| Time to assign Incident Commander | |
| Time to preserve critical evidence | |
| Time to contain | |
| Time to assess customer impact | |
| Time to assess privacy impact | |
| Time to establish communication owner | |
| Time to recovery decision |
These measurements should be used to identify improvement opportunities rather than to create artificial targets without considering incident complexity.
25. Findings
Each finding should be documented.
| Finding ID | Area | Observation | Risk/Impact | Root Cause | Priority | Owner | Target Date |
|---|---|---|---|---|---|---|---|
| F-001 | Escalation | Escalation ownership unclear | Delayed response | RACI unclear | High | Security | |
| F-002 | Evidence | Cloud log preservation delayed | Evidence loss risk | Retention not understood | High | Cloud | |
| F-003 | Communication | Customer response approval unclear | Inconsistent communication | Procedure gap | Medium | Legal |
26. Corrective Action Plan
Findings should be converted into actionable improvements.
Possible actions include:
- Update Incident Response Procedure.
- Update Incident Escalation Matrix.
- Update Incident Response RACI.
- Improve cloud logging.
- Increase log retention.
- Improve monitoring.
- Review privileged access.
- Strengthen MFA.
- Improve evidence preservation.
- Update communication templates.
- Conduct employee awareness training.
- Improve backup controls.
- Conduct another tabletop exercise.
- Update supplier escalation contacts.
Each action should have:
Owner + Action + Priority + Target Date + Evidence + Verification
27. After-Action Review
Immediately following the exercise, conduct a structured discussion.
What Worked?
- Which processes worked?
- Which decisions were made quickly?
- Which controls supported the response?
What Did Not Work?
- Where were participants uncertain?
- Which procedure was unclear?
- Which information was unavailable?
- Which roles were unclear?
What Was Missing?
- People
- Technology
- Documentation
- Access
- Monitoring
- Communication
- Training
What Should Change?
Identify specific corrective actions.
28. Lessons Learned
The exercise should produce documented lessons.
Examples:
- Security escalation contacts were outdated.
- Cloud log retention was insufficient.
- Participants were unclear about who could authorize account disablement.
- Customer communication approval was unclear.
- Evidence preservation responsibilities were not understood.
- Privacy assessment required earlier involvement.
- Recovery validation steps were not sufficiently defined.
29. Exercise Conclusion
The facilitator should document:
Exercise Objective
Whether the objectives were achieved.
Key Strengths
Processes that worked as intended.
Key Gaps
Material weaknesses identified during the exercise.
Key Decisions
Important decisions participants made.
Priority Improvements
Actions requiring attention.
Residual Risk
Any remaining risk that requires management consideration.
Follow-up Exercise
Whether another tabletop exercise is required.
30. Management Review
Exercise results should be presented to appropriate management.
Management review may consider:
- Major findings
- High-risk gaps
- Corrective actions
- Resource requirements
- Risk acceptance
- Changes to procedures
- Changes to security controls
- Additional training
- Future exercise requirements
Management decisions should be documented.
31. Exercise Closure Checklist
- Exercise objectives defined
- Scenario approved
- Participants identified
- Facilitator assigned
- Exercise conducted
- Injects completed
- Decisions recorded
- Observations recorded
- Response capabilities assessed
- Findings identified
- Root causes considered
- Corrective actions assigned
- Owners identified
- Target dates established
- Management review completed
- Residual risks assessed
- Exercise record retained
- Follow-up exercise scheduled if required
32. Startup-Friendly Tabletop Model
A startup does not need a large-scale simulation to test its incident response capability.
A practical 60–90 minute tabletop can test a complete incident lifecycle.
Example
0–10 min
Scenario introduction
10–20 min
Detection and reporting
20–35 min
Severity and escalation
35–50 min
Containment and investigation
50–65 min
Customer/privacy impact
65–75 min
Communication
75–85 min
Recovery
85–90 min
Lessons learned and actions
The goal is not to make the exercise complicated.
The goal is to expose gaps before a real incident does.
33. Tabletop Exercise Frequency
Exercise frequency should be based on:
- Risk
- Business criticality
- Regulatory requirements
- Customer requirements
- Major technology changes
- Significant organizational changes
- Previous incidents
- Results of previous exercises
A startup may begin with an annual tabletop and conduct additional exercises when there are significant changes or identified weaknesses.
Specialized exercises can also be conducted for:
- Ransomware
- Cloud compromise
- Data breach
- Account compromise
- Supplier incident
- Disaster recovery
34. ISO 27001 Connection
Tabletop exercises provide practical evidence that the organization’s incident management arrangements are not only documented but also tested.
They can help validate processes relating to:
- Information security incident management
- Incident assessment and response
- Evidence preservation
- Communication
- Roles and responsibilities
- Business continuity
- Recovery
- Corrective action
- Continual improvement
The exact exercise frequency and scope should be determined based on the organization’s risk, applicable requirements, and ISMS objectives.
A tabletop exercise is an organizational implementation and testing practice; ISO 27001 should not be interpreted as requiring one specific tabletop format or scenario.
35. Audit Evidence
Useful evidence from the exercise may include:
- Approved exercise plan
- Scenario
- Participant list
- Exercise agenda
- Injects
- Decision log
- Observation log
- Attendance record
- Exercise results
- Findings
- Corrective Action Tracker
- Management review record
- Updated procedures
- Updated incident playbooks
- Follow-up exercise record
An auditor should be able to trace:
Exercise → Observation → Finding → Corrective Action → Owner → Implementation Evidence → Verification → Closure
36. Recommended Exercise Record Structure
For each completed exercise, maintain:
1. Exercise Information
2. Objectives
3. Scenario
4. Participants
5. Injects
6. Decisions
7. Observations
8. Capability Assessment
9. Findings
10. Root Cause
11. Corrective Actions
12. Management Review
13. Lessons Learned
14. Residual Risk
15. Closure
37. Final Audit Trail
Exercise Planned
↓
Objectives Defined
↓
Scenario Approved
↓
Participants Assigned
↓
Tabletop Conducted
↓
Scenario Injects Delivered
↓
Response Decisions Recorded
↓
Capabilities Observed
↓
Gaps Identified
↓
Root Causes Considered
↓
Corrective Actions Assigned
↓
Management Review
↓
Residual Risk Assessed
↓
Actions Implemented
↓
Effectiveness Verified
↓
Exercise Closed
Final Principle
Test Before the Incident + Simulate Real Decisions + Expose Gaps + Record Evidence + Assign Corrective Actions + Verify Improvements + Test Again.