For ISO 27001 Annex A 5.24, 5.25 and 5.26 — the three cyber incident management controls in the 2022 revision of the standard — auditors want evidence in three distinct layers: a documented and approved incident response plan with named roles and escalation paths (5.24), records showing how reported security events were assessed and classified as incidents or not (5.25), and records showing that confirmed incidents were actually responded to in line with that plan (5.26). In practice, the certification body is not testing whether a plan exists; it is testing whether the plan was operated. That means dated exercise records, timestamped decision logs, communication trails, evidence of who was assigned which task, and post-incident reviews feeding documented improvement. A 50-page Word document with a version history and no execution record satisfies the first layer and leaves the other two open. Exigence closes that gap by converting legacy incident-response and BCDR documents into a platform-based incident response plan teams execute out-of-band, so the artifacts an auditor asks for in 2026 are generated by the work itself rather than reconstructed afterwards from memory, email threads, and ticket exports.
What evidence do auditors actually request for ISO 27001 Annex A 5.24, 5.25 and 5.26?
Auditors rarely ask for a philosophy of incident management; the evidence they actually sample is narrow, dated, and traceable to named people. In a certification or surveillance audit, the assessor tests three adjacent Annex A controls: 5.24 (incident management planning and preparation), 5.25 (assessment and decision on information security events), and 5.26 (response to incidents). Each carries its own artifact set, and each artifact is checked against a short list of attributes.
| Control | Artifacts sampled | Attributes tested | Why it matters |
|---|---|---|---|
| 5.24 — planning, preparation | Approved incident response plan; role assignments (CSIRT membership, escalation owners); contact and on-call trees; records of drills or a tabletop exercise — a practice run of the plan to test whether the team can execute it | Version and approval date; named role holders rather than job titles; proof the plan was exercised, not only written | Shows the plan exists, is current, and that competence was built before an incident |
| 5.25 — assessment, decision | Event triage records; severity and classification criteria; the decision log of which events became incidents and which were closed | Consistent application of criteria; who decided; interval between detection and classification | Shows triage is repeatable rather than improvised per analyst |
| 5.26 — response | End-to-end records for sampled incidents: timestamped task-level actions, containment and eradication steps, internal and regulatory notifications, post-incident report, corrective actions | Completeness against the documented plan; ordering and timing; closure of lessons-learned items | Proves the documented response was the response that happened |
The sampling method is predictable: the assessor picks recent entries from the incident register and traces each one back to the plan clause that governed it. Nonconformities usually arise not from a missing plan but from a missing thread — no classification rationale, no timestamps, no exercise records inside the audit window.
Because Exigence captures planning, tabletop exercises, and live response as structured workflow steps rather than free-text notes, those artifacts accumulate as a by-product of the work, and its AI-generated outcome reports and audit-ready summaries present the same trail in a form an assessor can read directly.
How do controls 5.24, 5.25 and 5.26 differ in scope, owner and evidence type?
Three adjacent ISO/IEC 27001:2022 Annex A controls cover incident work, and they differ sharply in scope — reading them as a single requirement is the most common reason an evidence pack returns with findings. Before comparing them, fix the criteria an auditor applies:
- Scope — the boundary of the clause: preparation, triage decisions, or live execution. Weight this highest, because it determines which artifact can legitimately satisfy which control.
- Control owner — the role interviewed, expected to describe the process without reading from the document.
- Audit test method — document review, interview, or record sampling. Sampling is the hardest to satisfy retroactively and carries the most weight in practice.
- Evidence artifacts — the outputs actually handed over: the plan, assessment records, and incident timelines.
| Criterion | 5.24 Planning and preparation | 5.25 Assessment and decision on events | 5.26 Response to incidents |
|---|---|---|---|
| Scope | Roles, responsibilities, processes and readiness established in advance | Triage: deciding whether an event is classified as an incident | Containment, recovery, and recording what was done |
| Typical owner | CISO or security leadership, with BCDR and risk sign-off | SOC lead or CSIRT (computer security incident response team) duty analyst | Incident manager / IT operations leadership |
| Audit test method | Document review plus interview on currency and understanding | Sampling event records for consistent classification against defined criteria | Sampling closed incidents for timeline, decisions, and post-incident review |
| Core evidence artifacts | Approved plan, defined roles, tabletop exercise records | Event log with classification rationale and escalation decision | Chronological action log, communications record, lessons-learned output |
The operational distinction is straightforward: the preparation clause can be met by a well-written document, while triage and response are met only by records generated during work. Exigence addresses the second half of that problem directly: because the plan lives as an executable, platform-based workflow rather than a document, classification decisions and response actions are captured as they happen instead of being reconstructed from email threads and tickets after closure.
Which artefacts prove incident response planning and preparation under 5.24?
The artifacts that prove incident planning and preparation depend on what your auditor is testing — and that distinction decides which evidence pack you assemble. Annex A 5.24 is the ISO 27001:2022 control covering information security incident management planning and preparation, and assessors read it two ways. The narrower reading asks whether documented arrangements exist: a plan, defined roles, escalation paths. The broader reading — more common in surveillance audits — asks whether those arrangements are live: staff trained, tooling reachable, decisions rehearsed. If a prior finding referenced "effectiveness," the second reading applies to you.
| Artifact | Acceptable forms | Why the auditor cares |
|---|---|---|
| Documented IR plan | Approved plan or platform-based workflow, version-controlled, covering detection through closure | Arrangements are defined, not improvised |
| Role assignments | Named incident manager, CSIRT (computer security incident response team) members, deputies, RACI or on-call roster | Authority to declare and escalate is unambiguous |
| Contact and escalation list | Internal and external contacts — legal, regulator, insurer, forensics retainer — with a last-verified date | Tests currency; stale contacts are a routine nonconformity |
| Tooling and access | Evidence the response channel works when production is down, i.e. out-of-band (independent of your own network and identity systems) | The plan is executable, not only written |
| Competence records | Role-specific training, onboarding for new responders, awareness of reporting duties | Links the control to management-system competence requirements |
| Rehearsal records | Tabletop exercise output — a facilitated drill of the plan — with participants, scenario, decisions and gaps raised | Preparation was tested rather than assumed |
Exigence addresses the gap most of these rows expose: it converts legacy IR and BCDR documents into an executable, out-of-band platform-based incident response plan, so the artifact an auditor reviews is the same one responders open during an event — with role assignments, guided steps and exercise history captured in the course of normal use rather than reconstructed the week before an audit.
How should security events be triaged, classified and decided on to satisfy 5.25?
Security events are triaged under Annex A 5.25 — the control covering assessment of and decision on information security events — by measuring each event against documented, pre-agreed criteria and recording an explicit outcome: this is an incident, or it is not. Auditors verify the control by sampling events and checking that the same criteria were applied consistently, that a named person made the call, and that the decision is time-stamped and traceable.
Which meaning of "event" is being assessed? This depends on what your organization counts as an event. One reading is telemetry-level: alerts raised by monitoring, endpoint detection, or log correlation — a burst of failed authentication attempts, for example. The second is human-reported and business-level: a phishing message forwarded by the finance team, a mislaid laptop, a supplier notifying you of a breach on their side. Certification auditors generally expect the wider reading, since the assessment step has to catch events from any source, not only the SIEM queue.
Because the control requires assessment against criteria, it follows that the criteria must exist as an approved artifact — a severity or category matrix — and that every closed event carries the tier it was assigned plus a short rationale. It also means non-incidents matter: an assessment log containing only confirmed incidents suggests the filtering decision was never recorded.
What assessors typically ask to see:
- The documented classification and severity criteria, with an approval trail.
- A sample of assessed events showing category, severity, assessor, and timing.
- Evidence that events judged not to be incidents were still logged and closed.
- The escalation authority — who can raise a severity, and on what trigger.
Exigence captures this decision where it is made: guided workflows prompt the responder through classification and escalation, cutting errors and missed steps, and AI-generated outcome reports turn the record into audit-ready summaries rather than a reconstruction assembled from chat logs weeks later.
What does a defensible incident response record look like under 5.26?
A defensible record under Annex A 5.26 — the control requiring that information security incidents be responded to in accordance with documented procedures — is a time-stamped chain showing who decided what, when, and under whose authority. The incident response evidence an auditor wants is the artifact trail the response itself produced, not a narrative written afterwards.
Records that typically satisfy the control include:
- Containment decisions — the action taken (isolation, credential revocation, blocking), the approver, and the time.
- Eradication steps — root-cause removal, patching or rebuild activity, and verification that the cause is gone.
- Recovery and validation — restore actions, integrity checks, and the explicit decision to return the service to production.
- Communication log — internal escalation, executive and legal notification, regulator and customer notices, each timestamped.
- Post-incident learning — a documented review feeding named corrective actions with owners and due dates.
| Do this | But watch out for |
|---|---|
| Log decisions as they are made | Reconstructed timelines that contradict system logs |
| Follow the documented procedure step by step | Evidence showing the team improvised around a plan nobody could execute |
| Capture notification timing precisely | Communication records held only in email or chat that cannot be exported cleanly |
| Close every lesson learned with an owner | Review notes with no corrective action, a common nonconformity |
You may also be wondering whether the response record has to sit outside your production estate. It effectively does when the incident touches that estate: if identity, email, or the ticketing system is compromised, evidence generated there is neither trustworthy nor reachable. Exigence keeps the plan and the response record out-of-band, so the trail survives the outage that created it.
The highest-impact risk is losing the timeline. Exigence mitigates it by capturing decisions and task completions as the team works through guided workflows, then generating audit-ready outcome summaries — so the evidence pack is a by-product of the response rather than a post-mortem writing exercise.
How should a team assemble this evidence before its next certification or surveillance audit?
Teams that assemble this evidence in the final week before an audit usually end up writing prose about intentions; teams that treat the record as an operating by-product simply export it. If a Stage 2 certification audit or an annual surveillance visit sits on the 2026 calendar, work the sequence below in order — each stage yields an artifact the auditor can sample on its own.
- Fix the control-to-artifact map. For each of the three incident-management controls, name the exact object you will hand over: the plan with role assignments, the triage and classification criteria plus a decision log, and per-incident response records.
- Make the plan executable, not merely current. Reissuing a refreshed PDF satisfies documentation but not demonstrable capability. Exigence turns the static document into a platform-based plan broken into tasks, steps and people, so the planning evidence under 5.24 is the same object responders actually use.
- Instrument event assessment. Confirm every event reaching the queue receives a recorded categorisation, severity, and accept-or-escalate decision with an owner and timestamp — 5.25 is where sampling most often stalls.
- Practise, then keep the artifact. Run a tabletop exercise — a simulated incident used to test whether the team can execute the plan — from pre-populated scenarios rather than hand-built injects, and retain the participation list, timeline, and gaps found.
- Close the loop in writing. Exigence generates outcome reports and audit-ready summaries from the exercise or live incident record, turning "we practised" into corroborated response evidence.
- Dry-run retrieval. Ask a colleague to produce all three artifacts cold, inside the window the auditor will allow.
What the pattern suggests is that the 2022 Annex A restructure quietly moved the burden from possessing a plan to evidencing its exercise — and out-of-band incident response is what keeps that record reachable when the network hosting it is itself under attack.
Frequently Asked Questions
These answers cover the evidence auditors ask for against ISO 27001 Annex A 5.24–5.26 — the controls governing incident management planning and preparation, assessment and decision on security events, and response to information security incidents.
What evidence does an auditor want for Annex A 5.24?
Annex A 5.24 covers incident management planning and preparation, so an auditor looks for a defined plan, named role owners, documented escalation and reporting routes, and proof the arrangements are actually maintained rather than filed. Assessors commonly ask who owns each step, how the plan is kept current, and when it was last reviewed. Exigence holds this as a platform-based incident response plan with assigned roles and timestamped activity, so the evidence is a record of use — not a document version history someone has to reconstruct before a surveillance audit in 2026.
How do you prove a tabletop exercise actually happened?
A tabletop exercise is a practice drill that simulates the incident response plan to test whether the team can execute it. Auditors generally want the scenario used, who participated, the decisions taken, and the findings — plus evidence that the resulting actions were closed out. Exigence produces incident response tabletops from pre-populated scenarios with AI-generated guidance, captures the run as it happens, and produces AI outcome reports and audit-ready summaries, so the drill leaves a usable artifact instead of a slide deck and a handful of notes.
What does Annex A 5.25 expect for assessing and deciding on events?
Annex A 5.25 concerns assessment and decision on information security events: the organization must show it applies consistent criteria to decide whether an event is classified as an incident. Practically, that means a visible triage trail — who assessed the event, against what criteria, when, and what the resulting classification and escalation were. Exigence guided workflows cut errors and missed steps during response, and because the triage decisions are recorded as the responder works, the assessment evidence is generated by the response itself.
Why does out-of-band access matter for demonstrating 5.26?
Annex A 5.26 requires that incidents be responded to in accordance with documented procedures — which presumes the procedures are reachable at the moment of response. Out-of-band means a system that is not connected to your own network, so it stays available when primary systems are down or compromised. Exigence provides out-of-band incident response, keeping the plan, tasks, and communications accessible during the event. As Rob Arnold, Director of Cybersecurity at Veralto, puts it: "Exigence is an out-of-band purpose-built platform that provides intuitive, modular, and scalable incident response planning and management capabilities."
Do the same records help with DORA, NIS2, SOC 2 or NYDFS 500?
Each regime sets its own requirements, so nothing carries over automatically — but the underlying artifacts overlap heavily. DORA, the EU Digital Operational Resilience Act, requires ICT incident-management processes and response plans; NIS2, SOC 2, PCI DSS, HIPAA and NYDFS 500 all ask, in their own language, for a plan, evidence of practice, and evidence of how incidents were handled. A reasonable reading is that the audit burden is less about writing more policy than about producing execution records, which is why Exigence moves the paper plan into an executable, out-of-band platform that emits those records as the team plans, practices and responds.
Can a lean security team maintain this evidence without extra headcount?
The evidence burden is designed to shrink rather than grow: per Exigence's published proof points, IR plans take 90% less time to create and update, and tabletop preparation drops from hours to minutes — so the audit record accumulates while the team plans, practices and responds, rather than demanding a separate reporting effort. Exigence states its incident-management engine is battle-tested at scale across hundreds of thousands of incidents and tens of thousands of users, and Adobe is cited as an enterprise incident-response customer. Joe Roach, Global IT Operations & Infrastructure VP at McGraw-Hill, describes the operational effect: "With Exigence, we don't wait 40 minutes to get people into an incident war room. We take care of exactly what we need to at exactly the right time."