A.5.26 Response to information security incidents: evidence and audit

What A.5.26 asks you to prove about incident response

A.5.26 asks you to show that information security incidents are responded to in line with documented procedures. If an auditor or a customer questionnaire asks how you handle incidents, the honest answer has two parts: a written procedure that names the steps, roles and decisions, and records from real or exercised events showing that people followed it. The control does not ask for a perfect response. It asks for a repeatable one that you can demonstrate. The risk it addresses is slow, inconsistent or undocumented handling, where containment is delayed, notifications go out late or not at all, and the facts needed to explain what happened are lost before anyone writes them down.

The reason this control is hard to pass is that its evidence is mostly records of events that actually happened. A procedure that looks sound on paper tells an assessor little on its own. What they test is the gap between the written procedure and what responders did: whether the incident ticket shows containment before escalation, whether the decision to notify a customer or regulator was recorded with a timestamp and an owner, whether evidence was preserved, and whether the closure review happened. Most findings in this area come from that gap, not from a missing document. Ask your team to pull the last few incidents, or the most recent tabletop exercise, and compare each one against your written steps before the assessor does.

A.5.26 carries forward the 2013 control A.16.1.5 and works with its neighbors in the organizational controls theme. Planning and preparation sits in A.5.24, triage and the decision that an event is an incident sits in A.5.25, evidence handling sits in A.5.28, and lessons learned sit in A.5.27. A.5.5 covers contact with authorities, which matters when an incident triggers a reporting duty. An assessor will often read these together, so the records for one control should point to the others. Confirm the exact clause wording and any changes with the standard itself at ISO/IEC 27001:2022 and with your certification body before you build the evidence set.

Which incidents, systems and third parties A.5.26 reaches

A.5.26 only works as far as the incident process reaches. The scoping decisions below determine which event sources feed the response, which systems and suppliers sit inside the ISMS, and where personal data or regulated customers need their own track. Settle them before the response procedure is written, because each one changes who must act and what evidence must exist.

Event sources that feed incident handling

List every source that can start a response: SIEM alerts, EDR detections, cloud audit and control-plane logs, service desk tickets, and reports from customers and staff. Each source needs a named owner, a route into the incident process, and a record of how events were triaged. Confirm which sources are actually connected and which ones depend on a person noticing and forwarding something. An unconnected source is a gap an assessor will ask about, since A.5.26 expects incidents to be handled under documented procedures regardless of where they began.

Systems and assets inside the ISMS

Incident response reaches only the assets the organization has inventoried and placed in scope. Check that every system that stores or processes in-scope information appears in the asset inventory with an owner, and that logging covers it. Systems left out of scope often have no detection and no response route, which means an incident there can go unrecorded. Document the scope boundary and confirm that the response procedure names the same systems the scope statement does.

Supplier-run services and cloud providers

Many incidents begin in a service the organization does not operate itself. Contracts should require suppliers and cloud providers to notify the organization of security incidents within a stated timeframe, provide logs on request, and cooperate during investigation. Map each provider's notification duty to a step in your own procedure so that the clock starts when the supplier learns of the event. Confirm the actual notification terms in each contract rather than relying on the provider's general security documentation.

Personal data and regulated customer incidents

Some incidents trigger obligations that run on their own clocks, such as breach notification for personal data or reporting duties owed to regulated customers. Decide whether these need a separate track with its own roles, decision criteria and notification templates, or whether the general procedure can carry them with added steps. Record who decides that an incident involves personal data and how that decision is documented, because the timing of outside notifications depends on it.

How an assessor tests incident response

This table sets out each step an auditor takes to test A.5.26, the evidence each step produces, and the findings that most often cause a nonconformity. Read it as a walk-through: start with the procedure, then sample real or simulated incidents and trace each one through the lifecycle.

Test step	What the assessor checks	Evidence requested
Confirm the procedure exists	A documented incident response procedure exists, covers containment, escalation, communication, recovery and closure, and shows approval and a current review date	Approved procedure, version history, review record
Sample incidents	A sample of real incidents or, where none occurred, simulated exercises, selected to cover different severities and categories	Incident register extract, exercise scenarios and selection rationale
Trace containment and escalation	Each sampled case shows containment actions and escalation to the roles and thresholds the procedure defines, with timestamps	Incident tickets, timelines, escalation records, paging logs
Check communication	Internal and external notifications match the procedure, including any contractual or regulatory notice duties and who approved them	Notification drafts and sent records, approval trail, contact lists
Verify recovery and closure	Recovery actions are recorded and verified, and each incident is formally closed by an accountable role	Recovery validation notes, closure sign-off, post-incident review
Confirm named roles were used	People named in the procedure actually acted in the roles assigned to them, not only on paper	Role assignments, on-call rota, case assignment history
Verify lessons feed back	Findings from reviews lead to tracked corrective actions that change controls, linked to A.5.27	Action tracker, updated controls or procedures, follow-up closure evidence

Implementing A.5.26 in the order an auditor expects

This sequence turns A.5.26 from a policy statement into a working incident response capability with documented procedures, named roles, a case record for each incident and exercise evidence that the procedure works. Each step produces an artifact an auditor can sample.

Define the incident response procedure
Write the documented incident response procedure with its phases (preparation, detection and triage, containment, eradication and recovery, communication, and closure), the severity levels that set how fast and how widely each incident is handled, and the decision points where the procedure hands off to legal, management or external parties. Management approves the procedure and it is version controlled. The output is an approved, dated procedure that the people named in it can find. Confirm with your own legal and regulatory advisers which notification duties apply to your sector and jurisdictions before fixing the severity thresholds.
Assign roles and escalation paths
Record who does what during an incident in a RACI matrix covering the incident lead, technical responders, communications, legal, management and the people who hold contacts with authorities. Define the escalation path from the first responder to the incident lead and on to management, with named alternates for each role so that absences do not stop escalation. The output is a RACI and a contact list that is checked at a set interval. Auditors often test whether the people named still hold those roles, so keep the list tied to your joiner and leaver process.
Set up one case record per incident
Create a case template that holds the incident summary, severity, affected assets, indicators of compromise, tasks, evidence items, decisions and a timeline, so that each incident has a single record from first report to closure. DFIR-IRIS is an open-source option that keeps each case as one record of assets, IOCs, tasks and evidence with a full audit trail, and it can generate reports from case data. Whatever tool you choose, confirm that it keeps an audit trail of who changed what and when. The output is a working template and one test case showing it is complete.
Configure detection and triage inputs
Connect the sources that will feed the case record, such as SIEM alerts, endpoint detections and user reports, and define how each event is triaged into an incident or closed as a non-incident. This is where A.5.25 decisions are recorded. Shuffle, an AGPL-3.0-only workflow tool, can start automations from a webhook, a schedule or a manual run and connect tools such as a SIEM, ticketing system and firewall without custom code. For endpoint evidence, osquery can run scheduled queries across a fleet and Velociraptor can collect forensic artifacts from endpoints. The output is a short list of tested inputs with a documented triage rule for each.
Run a tabletop exercise
Walk the named roles through a realistic scenario written for your organization, such as a compromised administrator account or a ransomware alert on a file server, and test whether each step of the procedure works in practice. Record the decisions taken, the time each escalation took, gaps found and owners for each fix. An illustrative example: the exercise reveals that no one has authority to take a payment system offline, so the procedure is amended and the escalation path is re-tested. The output is an exercise report with dated actions. Some organizations also test technical responses, which is a separate effort to plan.
Close exercise gaps and approve the procedure
Update the procedure, RACI, contact list and case template with the changes from the exercise, and have management approve the revised version. Confirm that the escalation path works end to end for at least one tested route. The output is a revised, approved procedure with a change log that links each change to a finding in the exercise report. This closing record is what an assessor will compare against the earlier version when checking that the procedure is maintained.
Start recording live and exercised incidents
From this point, every event that is triaged as an incident gets its own case record, with the decisions, containment actions, evidence and communications logged as they happen rather than reconstructed afterwards. Evidence should be handled under A.5.28, with hashes and chain of custody where it may later be needed. DFIR-IRIS can log evidence with SHA-256 verification and chain of custody. The output is a case record per incident that shows the procedure was followed, and a closure review that feeds A.5.27. Ask your certification body or auditor which records they will sample before the first audit, because their choice shapes what you keep.

How the incident record trail proves the procedure was followed

Auditors judge A.5.26 through the records an incident leaves behind, not through the incident response policy alone. A documented procedure shows what the organization intended to do; the case record shows what it actually did. A complete record for one incident should run from the initial report, through the triage decision that classified it as an incident under A.5.25, to containment actions, escalation and internal or external communication, recovery steps, and a closure entry with lessons captured for A.5.27. Each stage should name the person who acted, the role under which they acted, and the approval they relied on. Ask your team to pick one closed incident from the past year and check whether a sampler could follow it from first alert to closure without asking anyone for missing context.

Consistency matters more than volume. Timestamps must use one time source and one time zone across the SIEM, endpoint tools, ticketing system and the case management platform, or the sequence of events will not hold together when an assessor reconciles them. Decisions need a stated reason and an approver, and escalations need to match the thresholds in the response plan. Open-source case management such as DFIR-IRIS keeps each case as one record of assets, indicators, tasks and evidence with a full audit trail, and it builds a consolidated investigation timeline from the entries. Confirm with the vendor how its audit trail records edits and deletions, and whether those entries can be protected from change by the people they describe.

Where an incident may lead to disciplinary action, a legal claim or a report to a regulator, the evidence has to be handled so it can be relied on later. That is the subject of A.5.28, but the record trail is where it is proven. Hash each collected artifact when it is acquired and record the algorithm, for example SHA-256, along with who collected it, when, from which system and where it is stored. DFIR-IRIS logs evidence with SHA-256 verification and chain of custody, so that each transfer between analysts is visible. Velociraptor hunts and osquery queries can produce the endpoint data behind these entries. Confirm that the hashes are recomputed before analysis and that access to the evidence store is itself logged.

Evidence that passes an A.5.26 audit

An assessor testing A.5.26 checks whether incidents were handled the way the documented procedure says, and whether the paper trail proves it. The six artifacts below connect the procedure to the records produced when real events occur, so each one can be sampled independently. Keep them current between audits rather than assembling them the week before.

Approved response procedure and version history

The incident response procedure is the document an assessor compares every incident against. Show who approved it, the version in force on each incident date, and the review dates that led to changes. Check that roles named in the procedure match the current organization chart and that the procedure references the tools people actually use. A procedure that has not changed since its first approval often signals that lessons learned were never fed back into it.

Incident register

The register is the master list of every event classified as an incident, with date, category, severity, owner and status. Auditors use it to select a sample and then trace each entry to its case record. Review the register monthly, record entries that were considered and rejected as non-incidents, and reconcile it against tickets, alerts and communications so that no incident exists outside it.

Per-incident case records and timelines

Each case record should hold the timeline of detection, triage, containment, eradication and recovery, with the decision made at each step and the person who made it. DFIR-IRIS keeps assets, indicators, tasks, evidence and an audit trail in a single case, which makes it easier to show that actions happened in the order the procedure requires. Confirm that timestamps are consistent across the tools that feed the case.

Communication logs and notifications sent

Keep a dated record of every internal escalation, customer notice, regulator notification and contact with authorities, including who sent it, to whom, and the approved wording. Auditors look for notifications made within the timelines the organization committed to in its contracts and regulatory obligations. Confirm which deadlines apply to your sector, since the notification rules are set by law or contract and not by this control.

Closure reports and post-incident reviews

A closure report states the root cause, the impact, the actions taken, and the open follow-up items with owners and due dates. The post-incident review links those findings to changes in controls, which is where A.5.27 picks up. Check that closure is approved by someone other than the case handler and that open actions are tracked to completion rather than closed by default after a set period.

Exercise records and test reports

Tabletop and technical exercises show that the procedure works before a real event tests it. Keep dated exercise plans, attendance, injects used, observations and the corrective actions raised. Schedule exercises across the year so the records show regular practice rather than one event before the audit. Where a tool such as Velociraptor or osquery is part of the response, record the test runs that confirm it still collects evidence as expected.

What meeting A.5.26 costs in money and effort

This table breaks down the cost and effort components of meeting A.5.26, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to scope internal work against outside help and to know what to request in a quote. No prices or durations are stated because none were supplied; the drivers and quote questions are the reliable guide.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it and what to ask for in a quote
Incident tooling or licenses	Software vendor, or no license fee for self-hosted open source	Often one-time setup, with recurring license or hosting fees	Number of event sources and users; ask whether the quote includes licenses, hosting and upgrades
Engineering time to connect detection to case management	Internal engineers or an implementation partner under a fixed-scope agreement	One-time, with later changes as sources change	Number of SIEM, EDR and ticketing integrations; ask for the list of sources in scope
Designing playbooks and workflows	Internal security staff or an implementation partner	One-time, then periodic revision	Number of incident categories and automated actions; ask which playbooks are delivered
Training role holders	Internal time, or trainers if external	Recurring, usually tied to staff turnover	Headcount of responders and deputies; ask whether training materials are delivered
Running tabletop or technical exercises	Internal staff, or an external facilitator if used	Recurring, usually at planned intervals	Number of scenarios and participating teams; ask who writes and runs each exercise
Penetration test or red team, if used	External testing firm	Recurring, usually tied to a planned test	Scope of systems and whether the test includes incident response; treat as optional, not required by A.5.26
Evidence upkeep	Internal incident owners and records staff	Recurring with every incident and review	Volume of incidents, retention rules and the depth of post-incident records
Auditor sampling time	Internal staff supporting the audit, and the independent auditor	Recurring at each audit cycle	Number of incidents in the sample period; keep one complete record per incident to shorten sampling
Self-hosted open source in place of license spend	Staff time still applies for setup, hardening and operation	Setup is one-time, operation is recurring	License spend can fall, but staff time to deploy, maintain and test the tooling remains

Self-hosted open-source tools that produce incident evidence

A.5.26 is tested through case records. An assessor usually picks a sample of incidents and asks for the record showing who did what, when, and why. DFIR-IRIS, an open-source case management platform licensed under LGPL-3.0-or-later, is designed to hold each case as a single record. That record can group affected assets, indicators of compromise, tasks, and evidence items, with a full audit trail and a consolidated investigation timeline. It can also triage alerts from SIEM, EDR, and REST sources into cases and generate reports from case data.

Single case record: Assets, indicators, tasks, and evidence sit in one place, so the record an auditor samples is the same record the responders used.
Evidence logging: Evidence entries are logged with SHA-256 verification and chain of custody, supporting the handling expectations in A.5.28.
Audit trail: Changes to the case are logged, which helps show that procedures were followed in sequence.
Timeline and reports: The timeline supports post-incident review under A.5.27, and reports can be generated from case data for management and customers.
Triage intake: Alerts from SIEM, EDR, and REST sources can be routed into cases, so the decision to open a case is recorded.

Confirm with your team which alert sources, authentication method, and retention settings fit your environment, and whether your procedure defines the severity fields that the case template must capture.

Where incident response audits usually fail

Auditors testing A.5.26 rarely find that an organization has no incident procedure. They find that the procedure exists on paper but was never exercised, that roles are assigned to people who do not hold them, or that the records do not show the steps were followed. The gaps below are the ones that most often turn a documented process into an audit finding.

Procedure never exercised

A written incident procedure that has never been run against a realistic scenario is hard to defend. Auditors ask for records of past incidents, tabletop exercises or simulated events, and check whether the steps match what the document says. Close this gap by running at least one scheduled tabletop per year and one technical exercise, such as a simulated phishing compromise, then keeping the agenda, attendees, timings and the list of corrections made afterward. The record of the exercise is the evidence, so keep it with the procedure.

Roles named but unfilled

Procedures often name an incident commander, a communications lead or a legal contact, but the named person has left, never accepted the role or has no deputy. Auditors check the current roster against the procedure and ask whether people on call can be reached outside working hours. Confirm each role has a current holder, a backup and a documented contact route, and review the roster after every staff change. Keep the acceptance or on-call schedule as a dated record.

Incidents handled in chat only

When responders work in a chat channel and no case record is opened, the organization cannot show when detection happened, what was decided or who approved containment. Auditors sample incidents from alerts and ask for a single record per incident. Use a case management tool, such as DFIR-IRIS, so that alerts, assets, indicators, tasks and decisions sit in one record with an audit trail. Chat can remain the discussion channel, but its key decisions must be copied into the case.

No closure or lessons step

Many incident records stop at containment and never record root cause, corrective actions or the decision to close. A.5.26 is tested together with the learning and improvement expectations around it, so auditors look for closure criteria and follow-up actions with owners and due dates. Add a closure checklist to every case that requires a root cause statement, a list of actions, a review date and a sign-off by someone other than the responder.

Evidence without integrity checks

Logs, memory captures and disk images collected during an incident may later be needed for legal or regulatory action. If they are copied without hashes or a custody record, their value is weakened and auditors will question handling. Record a SHA-256 hash at collection, log every transfer and access, and store the originals read only. Tools such as Velociraptor can collect artifacts from endpoints in a defined way, and DFIR-IRIS can log evidence with verification and chain of custody.

Supplier notification clauses missing

An incident at a cloud provider, managed service or software vendor can trigger your own response, but the contract may not require the vendor to tell you quickly or to share details. Auditors compare the incident procedure with supplier agreements and ask how external incidents reach the response team. Review each critical supplier contract for incident notification duties, named contacts and cooperation obligations, and add the supplier's contact route to the incident contact list. Confirm exact notification timing with your legal team, since the right period depends on your obligations and the contract.

How much effort and outside help does A.5.26 need?

How long does preparing for A.5.26 take?

No supplied fact gives a duration, so the honest answer depends on how far your incident practice already goes. An organization with a tested incident response plan, a named incident team, a working case record and past incidents documented against a procedure has a short gap to close. An organization that handles incidents in chat threads and email, with no written steps for containment, escalation or closure, has a longer one. The main drivers are how many procedures exist, whether they have been exercised, how many systems and suppliers feed events into the process, and how much evidence of past handling is available. Ask any partner to base its timeline on a written gap assessment of your current practice, not on a generic number.

Can a small team run A.5.26 without outside help?

Yes, a small team can run the control if the procedure is proportionate to its size and the roles are clear. A.5.26 asks that incidents are responded to under documented procedures, so the core work is writing workable steps for containment, escalation, communication, recovery and closure, assigning people to them, and keeping records that show the steps were followed. A small team usually needs a named incident lead, a backup, an agreed way to reach outside help at short notice, and a simple case record. Where the team lacks the time or experience to write these steps, or has no one who can test them, an implementation partner can prepare the documents and tools while the team keeps ownership of the decisions.

What does A.5.26 need from management and staff?

Management must approve the incident procedure, allocate people and time to it, and make sure decisions such as taking a system offline or notifying a customer can be made quickly. Staff need to know how to report a suspected incident, who to call outside office hours, and what they must not do, such as deleting files or logging into an affected account to look around. Technical owners need to keep their systems logged and their contact details current. Records need an owner who reviews them. Auditors commonly sample past incidents and ask whether the documented steps were followed, so management must also see that incident reports are read and that gaps lead to changes.

Do we have to run an external incident response exercise for A.5.26?

No. A.5.26 does not by itself require an external exercise, and running one is the organization's choice. A contract, a sector regulator or a framework you are also adopting may set its own testing expectations, so check those obligations before deciding. Where an external exercise is chosen, the scope, rules of engagement and deliverables should be agreed in writing before work starts. Internal tabletop exercises run by your own staff are also a common way to show that the procedure works in practice, and they produce records an auditor can review.

What should a partner include in a fixed-scope quote for A.5.26?

A fixed-scope quote should state exactly what will be delivered and what the client must provide. Ask for the systems and log sources in scope, the incident procedures and templates to be written or reviewed, the tools to be deployed or configured, the number of exercises or training sessions, and the evidence pack to be handed over. Also ask which tasks stay with your staff, such as approving the procedure, and what happens if the scope changes. The quote should name the deliverables, the acceptance criteria and the timeline dependencies, including access to your environment. Ask whether support after handover is a separate retainer. Remember that the partner prepares the evidence, and that an independent auditor is the only party that issues the audit result.

How does A.5.26 relate to A.5.24 and A.5.27?

A.5.26 is the response step in a chain. A.5.24 covers the planning and preparation that must exist before incidents happen, including the process, roles, contacts and training that response relies on. A.5.26 covers how a confirmed incident is handled once it is under way. A.5.27 covers learning from incidents afterward, through post-incident reviews, root cause analysis and follow-up actions that feed back into controls. Assessors often trace one incident across all three: the preparation that made the response possible, the response record itself, and the lessons that changed the organization's controls.

Can a consultant or implementation partner issue the A.5.26 audit result?

No. A consultant or implementation partner can help you prepare systems, procedures and evidence for A.5.26, but it cannot issue an audit report, attestation or certificate. Only an independent auditor or certification body can assess your controls and issue a result, and that assessor must be independent of the party that helped you prepare. Check the auditor's accreditation and confirm it is separate from your implementation partner before you commit to either.

How DeployOpen prepares incident response evidence

DeployOpen prepares the evidence side of A.5.26 inside the client's own infrastructure. The response procedure itself belongs to the organization, and so does the decision to declare an incident. What DeployOpen can plan, implement and harden is the self-hosted platform that carries each step: a case record for every incident, a timeline that shows when containment, escalation and communication happened, and an evidence log with hashes and chain of custody. Before any build starts, the written scope should name which platforms are in play, such as DFIR-IRIS for case management, Shuffle for automated triage and notification, osquery for fleet queries and Velociraptor for artifact collection, and which ones the client already runs. Confirm each tool's current license terms and supported deployment options with its maintainer before committing to it.

Once the platforms are in place, the work moves to proving they work. DeployOpen can run tabletop-style exercises and security tests under a fixed written scope, using a scenario the client's incident team agrees to in advance. A useful exercise checks whether an alert becomes a case with a named owner, whether the escalation path reaches the people listed in the response plan, and whether a dated record exists for each decision. Ask for the exercise to produce the same artifacts a real incident would: the case export, the timeline, the notification log and the lessons-learned entry. Gaps found in these runs become remediation items with owners, which is the kind of follow-up an assessor will look for under the related learning control.

DeployOpen does not issue audit reports, attestations or certifications. An independent auditor or certification body decides whether the response process meets ISO/IEC 27001:2022 and the procedures the organization has documented. Readers planning an assessment should ask a potential partner to show, in writing, which artifacts it will deliver, who keeps custody of the case data and how records will be retained after the engagement ends. If your team is still deciding on scope, a short scoping conversation is the right first step: bring your current response plan, your detection sources and the list of systems that would need evidence, and we can turn those into a fixed-scope proposal.

A.5.26 Response to information security incidents