Incident response testing evidence
Several frameworks expect you to test your incident response or continuity plans. A discussion-based exercise, a tabletop, is one common way to do that. Calmdrill is designed to help you run one and document it properly. It is never a substitute for your auditor’s judgement.
Note: We will never tell you Calmdrill makes you compliant. Your auditor decides what evidence is sufficient. A tabletop tests decisions. If a control needs you to actually restore a backup or fail over, you still need a technical test.
The evidence pack every drill produces
Six records, kept together. The Game Master writes the log and the report. The Kit has templates for the plan, the attendance record and the tracker. Section 9 of the report records what you changed.
| Record | What it shows | Where it comes from |
|---|---|---|
| Exercise plan | Scope, scenario, objectives, date and the participants invited | Kit template. About 10 minutes to fill in |
| Attendance record | Who took part, and in which roles | Kit template |
| Exercise log and transcript | Timestamped decisions, injects and actions | Written by the Game Master as you play |
| After-Action Report | Timeline, rubric scores with evidence, strengths, gaps and sign-off | Written by the Game Master, then reviewed and signed by you |
| Improvement tracker | Owned, dated actions and their closure | Kit template (CSV). Import it into Jira, Linear or a spreadsheet |
| Plan updates | What you changed in your plan or runbooks as a result | Section 9 of the report |
Pink sheet. The evaluator’s record. Three records from the pack, filled in for one drill.
One drill, three of its records
The drill is CD-01, run as an internal scripted playtest at Harbourline, a fictional company. Its four players were scripted to make the classic mistakes.
The report is the sample we publish in full. The plan and the attendance record are illustrative: we filled them in from the report’s header and participants list, as you would after your own drill.
| No. | Name | Job title | Exercise role | Initials |
|---|---|---|---|---|
| 1 | Sam | Engineering Manager | Incident Commander | |
| 2 | Ana | Backend developer | Tech Lead (held the pager) | |
| 3 | Jo | Head of Customer Success | Comms Lead | |
| 4 | Raj | Platform engineer | Scribe |
Roles played by the AI facilitator: CEO (Dana), CTO (Marcus), Security Lead (Ines), Head of Support (Priya), secondary on-call SRE (Leo), Head of Platform (Tom, auto-reply only), Enterprise customer (Brightwater Dental).
| No. | Finding | Action | Owner | Due | Status |
|---|---|---|---|---|---|
| 1 | Intermediate CA expiry was not monitored | Alert on expiry of every certificate in the chain, including root and intermediate CA, at 30 and 7 days, paging on-call rather than only Slack | Platform | 16 Oct 2026 | Open |
| 2 | Break-glass single point of failure: the third approver was unreachable | Break-glass contact tree: a fourth named approver, phone numbers for all approvers and a 2 a.m. call order | Security | 13 Oct 2026 | Open |
| 3 | Restart approved without evidence (T+00:12) | IC checklist: "errors first, then changes. No rollback or restart without one line of evidence and a named approver" | IC rotation (Sam) | 9 Oct 2026 | Open |
White sheet. For everyone. What each framework’s text says about testing.
Framework by framework
Where testing comes up in each text, whether the text requires it, and how often. Four have a page of their own.
Note: Summaries are paraphrased from the published standards and regulator guidance as of September 2026. They are not legal or audit advice. Check the current primary text and your auditor’s expectations.
| Framework | Where testing comes up | Does the text require testing? | How often, in the text |
|---|---|---|---|
| SOC 2 (AICPA Trust Services Criteria) | CC7.4 and CC7.5 points of focus: periodic evaluation of incident response, and recovery-plan testing that includes scenarios where key personnel are unavailable. A1.3 when Availability is in scope. | A1.3: yes, if Availability is in scope. CC7: through points of focus, which are guidance rather than requirements. Auditors expect to see it. | “Periodic”. Annual is a common auditor and platform convention, not the text. |
| ISO/IEC 27001:2022 | Annex A 5.24 to 5.27 (incident management), 5.29, and 5.30 (ICT readiness is “tested”). Clause 10.2, corrective action. ISO 22301 clause 8.5 for a BCMS. | A.5.30 includes testing, unless excluded in your Statement of Applicability with justification. | Not fixed. ISO 22301: planned intervals. |
| PCI DSS v4.0.1 | Requirement 12.10.2: review and test the incident response plan, including every element listed in 12.10.1. | Yes, for in-scope merchants and service providers. | At least once every 12 months. |
| EU DORA (Regulation 2022/2554) | Art. 11(6), testing of ICT business continuity and response and recovery plans. Art. 24 and 25, the testing programme. Art. 30, contract terms for ICT providers. | Yes, for in-scope financial entities. SaaS suppliers may be required to take part by contract. | At least yearly. |
| EU NIS2 and Implementing Regulation 2024/2690 | Art. 21(2)(b) and (c). The Implementing Regulation asks for incident procedures and continuity plans to be tested. | Yes, for covered entities. | At planned intervals. |
| HIPAA Security Rule | 45 CFR 164.308(a)(7)(ii)(D): testing and revision of contingency plans. | Currently “addressable”. A 2025 proposed rule would add 12-monthly incident response testing, but it is not final. | Periodic. |
| UK FCA and PRA operational resilience | SYSC 15A: scenario testing of important business services. | Yes, for in-scope firms (full compliance since 31 March 2025). | Regularly, and after material change. |
| NIST CSF 2.0 | ID.IM-02 (improvements from tests and exercises) and ID.IM-04. | No. A voluntary framework. | None set. |
What we suggest you do
Three steps, in this order, before the audit window opens.
- Ask your auditor whether a facilitated tabletop with a signed After-Action Report meets their expectation for the control. Most say yes to a well-documented tabletop. Some want a technical test as well.
- Pick a scenario that matches the risk the control cares about. For example, CD-04 (a restore) for continuity, CD-07 (leaked keys) for security incident response, and CD-11 (key people unavailable) for SOC 2 CC7.5’s “key personnel unavailable” point of focus.
- Keep the full evidence pack together and close your actions. An exercise with open actions from last year is a finding waiting to happen.