ISO 27001 requires you to test your incident response plan. Not just have one — test it. Most organizations can point to a plan document. Few can point to evidence that anyone ever ran it through a realistic scenario and found out whether it actually works.
If you’re still referencing A.16.1.5, your ISMS documentation is out of date. The 2022 revision reorganized Annex A, and the incident response testing requirement now lives across A.5.24 and A.5.26. The substance hasn’t changed much, but the control structure has — and your auditor will notice if your exercise evidence cites the old numbering on a transitioned ISMS.
The controls that matter
The 2022 revision consolidated 114 controls into 93 and reorganized them into four themes. The old A.16 incident management cluster mapped to five controls under A.5 (Organizational Controls):
| ISO 27001:2013 | ISO 27001:2022 | Title |
|---|---|---|
| A.16.1.1 | A.5.24 | Incident management planning and preparation |
| A.16.1.4 | A.5.25 | Assessment and decision on information security events |
| A.16.1.5 | A.5.26 | Response to information security incidents |
| A.16.1.6 | A.5.27 | Learning from information security incidents |
| A.16.1.7 | A.5.28 | Collection of evidence |
Three of these are directly relevant to testing:
A.5.24 — Planning and preparation. This is where the testing mandate lives. The control requires organizations to define, establish, and communicate incident management processes — and to test them. Specifically: assigning responsibility for implementation, providing training, and testing the plan through drills and simulations. This isn’t buried in guidance text. It’s part of what the control requires you to demonstrate.
A.5.26 — Response. Requires responding to incidents per documented procedures. An auditor’s reasonable question: how do you know your team can follow those procedures under pressure if they’ve never practiced? This control creates the operational expectation that A.5.24’s testing mandate is meant to validate.
A.5.27 — Learning. Requires using incidents — and exercises — to improve future response. This is the improvement loop. Your exercise findings feed directly into corrective actions under Clause 10.1. A well-run tabletop exercise generates evidence for this control automatically.
The testing requirement isn’t a single checkbox. It spans multiple controls — and that’s actually good news. A single well-documented exercise produces evidence across all three. You’re not running three separate activities. You’re running one exercise and documenting it in a way that satisfies the entire cluster.
What auditors look for in ISO 27001 incident response testing
Here’s what certification and surveillance auditors actually evaluate — beyond whether a plan document exists:
Evidence of periodic testing. At least annually, and the evidence needs to be current for your audit cycle. If your surveillance audit is in September and your last exercise was the previous February, that’s 19 months ago. Auditors notice. Time your exercises so evidence is fresh.
Documentation that connects to your ISMS. This is what separates ISO 27001 from other frameworks. Auditors don’t just want a standalone exercise report — they want to see it connected to your management system:
- Scenario linked to your risk assessment (Clause 6.1). The scenario should reflect a threat you’ve actually identified in your risk register. An exercise about a ransomware attack on a company that listed ransomware as a top-5 risk demonstrates the ISMS is working as a system. A generic scenario pulled off the internet demonstrates nothing about your specific risk posture.
- Controls mapped to your Statement of Applicability. Which Annex A controls does this scenario test? If your SoA declares A.5.24, A.5.26, and A.8.7 (malware protection) as applicable, your exercise should touch those controls. Auditors check for alignment.
- Findings feeding into corrective actions (Clause 10.1). Every gap the exercise surfaces should become a corrective action with an owner and a timeline. This closes the Plan-Do-Check-Act loop that ISO 27001 is built on. No corrective actions after an exercise tells the auditor either the exercise wasn’t rigorous or the improvement process isn’t working.
Cross-functional participation. ISO 27001 treats information security as a business concern, not just an IT function. Auditors expect exercises to involve people from across the business — operations, legal, communications, management. The standard requires management commitment (Clause 5.1). An IT-only exercise signals that incident response is siloed.
Consistency with scope. Your exercise should test response within your ISMS scope. If your scope covers customer data processing and your exercise simulates an employee laptop theft with no customer data implications, the exercise doesn’t demonstrate much about your declared scope.
Common findings that certification auditors flag
The patterns are consistent across audit cycles and industries:
No testing evidence at all. The IR plan exists in the document management system, last modified two years ago by someone who no longer works there. Nobody has exercised it. Under A.5.24 this is a nonconformity — the control explicitly requires testing.
Testing disconnected from risk assessment. The exercise used a generic phishing scenario, but the organization’s risk register identifies supply chain compromise and insider threat as the top risks. Auditors check whether your exercise reflects your actual risk profile, not a template.
No improvement loop. The exercise surfaced gaps — unclear escalation paths, outdated contact lists, confusion about who authorizes public communication. But no corrective actions were raised in the ISMS. The exercise happened in isolation, disconnected from the management system. This is a pattern across frameworks — the closed loop matters as much as the exercise itself.
IT-only exercises. Security ran the exercise without anyone from the business side. Legal wasn’t there. Communications wasn’t there. Management didn’t participate. The standard expects information security to be integrated with business processes, and the exercise evidence should demonstrate that.
Outdated control references. The exercise report cites A.16.1.5, but the ISMS transitioned to ISO 27001:2022 six months ago. The transition deadline was October 2025 — if you’ve converted your SoA but your exercise reports still reference 2013 controls, it signals that the exercise documentation isn’t being maintained as part of the ISMS. It’s an afterthought. Auditors read that as a maturity gap, not a typo.
Running a tabletop exercise for ISO 27001
Start from your risk assessment
Pick a scenario based on threats you’ve identified in your Clause 6.1 risk assessment. If your risk register identifies business email compromise targeting financial processes as a high-likelihood threat, that’s your scenario. The exercise should test your response to a risk you’ve already acknowledged — this demonstrates the ISMS is functioning as an integrated system, not a collection of disconnected documents.
Map the exercise to your Statement of Applicability
Before running the exercise, identify which Annex A controls the scenario will test. A BEC scenario might touch A.5.24 (incident management planning), A.5.26 (response), A.6.3 (information security awareness), A.8.5 (secure authentication). Document this mapping in the exercise plan — it gives the auditor a clear line from exercise to controls to SoA.
Include the business side
ISO 27001 is a management system standard. It expects leadership involvement (Clause 5.1) and integration with business processes (Clause 5.3). Your exercise should include people outside IT security — finance (for BEC scenarios), legal (for breach notification), communications (for public response), operations (for business continuity).
Build in the improvement loop
The exercise isn’t complete when the scenario ends. It’s complete when the findings become corrective actions in your ISMS. For every gap identified, raise a corrective action under Clause 10.1 with an owner and a deadline. When the action is completed, document the evidence. This is the PDCA cycle in practice — and it’s what auditors specifically look for.
A single tabletop exercise, properly documented, generates evidence for A.5.24 (testing the plan), A.5.26 (validating response procedures), A.5.27 (learning and improvement), and Clause 10.1 (corrective action). That’s a lot of audit coverage from a two-hour exercise.
Document for the audit trail
This is where ISO 27001 exercises differ from every other framework. It’s not enough to document the exercise — you need to document how the exercise connects to the ISMS. Which risk register entry drove the scenario? Which SoA controls were tested? Which corrective actions were raised? An ISO 27001 auditor will trace the thread from your risk assessment through your exercise to your corrective actions. If that thread breaks anywhere — if the exercise exists as a standalone report disconnected from the management system — you’ve done the work but you haven’t demonstrated the system.
The documentation checklist
Here’s what a clean exercise artifact looks like — the kind that satisfies an ISO 27001 auditor across multiple controls and clauses:
| Element | ISO 27001 Reference |
|---|---|
| Exercise date and duration | A.5.24 (periodic testing evidence) |
| Participant names and roles | A.5.24 (cross-functional involvement) |
| Scenario with risk register reference | Clause 6.1 (risk-based scenario selection) |
| SoA control mapping | Clause 6.1.3 (controls selected and justified) |
| Decision log with timestamps | A.5.26 (response per documented procedures) |
| After-action findings | A.5.27 (learning from incidents and exercises) |
| Corrective actions raised | Clause 10.1 (continual improvement) |
| Remediation evidence | Clause 10.1 (corrective action effectiveness) |
If you’re also maintaining SOC 2 or HIPAA, the documentation requirements overlap significantly. A well-structured exercise artifact can satisfy multiple frameworks with one report — as long as you include the framework-specific elements each auditor expects.
Producing this manually — mapping exercises to ISMS clauses, formatting audit-ready reports, tracking corrective actions back to exercise findings — is hours of overhead per exercise. That’s why most organizations only do it once a year.
We built Breachdeck to close that loop automatically. Every exercise maps to your SoA controls, generates corrective actions from findings, and produces a scored PDF that traces the thread from risk register to exercise to remediation — the PDCA evidence trail your certification auditor is looking for. Run the demo — five minutes, and you’ll see the report.
