ISO 27001:2022 Annex A 5.26 response to information security incidents

A prospect's security questionnaire asks you to walk through your last incident, start to finish. Or a file server starts encrypting at 2am and nobody is sure who may pull the plug. This guide covers ISO 27001:2022 Annex A 5.26 response to information security incidents for UK firms of 25–250 people: what the control requires, which decisions to settle before anything happens, and how your ticketing trail becomes the audit evidence.

It is written for security managers, compliance leads and technical founders who want a procedure an auditor can test without a SOC behind it.

What does ISO 27001 Annex A 5.26 require?

ISO 27001:2022 A.5.26 response to information security incidents is a corrective control: it activates once an incident is confirmed and requires a designated, competent team to follow the written procedure, limit the damage and restore normal operation. Improvisation stops at that point; the procedure, not the loudest voice in the channel, decides what happens next.

Being corrective, the control does not stop an attack happening. It limits the damage once a compromise is real. It protects confidentiality, integrity and availability in whatever mix the incident attacks: data theft hits confidentiality first, ransomware hits availability first.

Response quality separates a bad week from a crisis that threatens the firm. Take the same ransomware attack at two firms. One isolates within the hour and holds clean backups. The other debates authority in a group chat while the infection spreads.

What are the core ISO 27001 Annex A response to information security incidents requirements?

ISO 27001 A.5.26 asks for four things during a confirmed incident: containment of anything that could spread, evidence preservation before rebuild, controlled communication to the people who need to know, and formal closure with root cause understood. Each needs a written owner, a trigger and a record.

Write each duty into the procedure as a line with those three parts:

• Containment. Isolate the systems, accounts or networks that could spread the damage, starting at the severity level your matrix names.
• Evidence preservation. Capture and hash what the incident leaves behind before anything is rebuilt, and record who handled it.
• Communication. Keep people informed on a need-to-know basis, escalate when the incident outgrows the operational level, and start the notification clocks.
• Formal closure. Confirm recovery, eradication and root cause before the ticket shuts.

The later sections give the first three their detail. Closure lives here because it is the easiest duty to skip. An incident can be closed when service is verified restored and containment and eradication are confirmed. Your own closure criteria must also be met and the post-incident write-up done. A ticket that quietly goes stale is not a closed incident.

Put the criteria on the ticket's closing step as a checklist. Require a linked finding for the risk assessment, or a recorded reason why nothing changed.

Where does ISO 27001:2022 Annex A 5.26 response to information security incidents sit in the incident lifecycle?

A.5.25 decides whether a security event is an incident; A.5.26 starts the moment that decision is made and executes containment, eradication and recovery. A.5.24 builds the capability beforehand, A.5.28 governs the evidence handling A.5.26 invokes, and A.5.27 takes the lessons forward after closure.

Here is how the neighbouring controls divide the work:

• A.5.24, planning. Builds the team, roles and procedure before anything happens.
• A.5.25, assessment. Classifies the event and decides whether it is an incident.
• A.5.26, response. Contains, eradicates and recovers under the written procedure.
• A.5.28, evidence. Governs how the material captured during the response is collected and handled.
• A.5.27, learning. Turns the closed incident into risk and control changes.

The practical difference between A.5.25 and A.5.26 is the question each asks. A.5.25 asks whether this is an incident and how severe it is. A.5.26 asks what you do now and who does it. The severity from the first becomes the input to the second. It decides who is woken, how fast containment must start and which notification clocks begin.

In ticketing terms, the handoff is a status change. The triage record becomes the parent of the response ticket, so severity and the time of classification travel with it. After closure, the review findings flow into ISO 27001 Annex A 5.27, learning from information security incidents.

Do you need a playbook for every incident scenario?

No. At 25–250 people, one incident response procedure with short scenario annexes — ransomware, data theft or exposure, lost or stolen device, denial of service — is the right shape. Modular playbook libraries are a large-enterprise pattern; at this scale they rot on the intranet and fail the first tabletop.

The core procedure carries the shared machinery once: roles, authority, severity matrix, evidence gate, notification triggers and closure criteria. Each annex then adds only what differs.

• Ransomware: which hosts to isolate first, whether backups are clean, and when to capture memory.
• Data theft or exposure: what left, whose data it was, and whether the ICO clock starts.
• Lost or stolen device: the remote-wipe decision, encryption status and who reports the loss.
• Denial of service: upstream provider contacts, traffic filtering and customer messaging.

Pair the annexes with a simple severity matrix tied to asset criticality. Three or four levels are enough. Maintenance stays light too. One procedure and four annexes can be reviewed together at the annual tabletop. A library of dozens would each need its own owner and review date.

Drafting takes a few days. The real cost is a half-day tabletop exercise, which you should run before certification. It tests the procedure and tells the people named in it what it says.

A response procedure nobody has exercised is a document, not a capability.

Who can isolate production at 2am, and how do they get in?

The named response team, through written pre-agreed authority. Taking a production system offline at 2am cannot wait for a committee, and auditors look for that authority being explicit. Access comes from a sealed, MFA-protected emergency admin credential with usage logging, plus an out-of-band channel for when email or Slack is compromised.

The NCSC 10 Steps to Cyber Security: Incident Management guidance makes the same point. It advises naming the specific situations where the technical team can act on its own. Those situations rest on the highest business risks, and on where early containment is likely to reduce impact. It also advises keeping a careful record of decisions and actions, especially if you may need to show your response to a regulator.

A useful authority statement answers four questions:

• Who: the named responders and their deputies.
• What: the actions they may take without approval, such as isolating a host, disabling an account or taking a service offline.
• When: the severity level at which that authority switches on.
• Afterwards: who is told, and where the decision is recorded.

A responder who must ask permission to isolate a server has already lost the first hour.

Authority is useless without access. The sealed credential lets responders work when normal accounts, or the identity provider itself, are part of the problem. Every use leaves a log, and that log becomes audit evidence. For the day the primary channels sit inside the blast radius, keep a Signal group and a personal contact list outside them. Responders who know what to do but lack authority, access or a fallback channel are a common gap. These three fixes close it.

Why must evidence preservation come before any reimage?

Rebuilding a machine before capturing evidence can forfeit the forensic basis for an insurance claim, a criminal referral or a defensible account to a regulator. Make preservation a hard gate before rebuild: capture logs, disk images and memory where proportionate, hash what you collect, and record who handled it.

The instinct to just reimage the host is the single most expensive mistake in small-firm response. It restores service, which is why it tempts. But it also wipes memory, volatile state and often the logs that showed how the attacker got in.

Build the gate as a short sequence on the incident ticket:

1. Scope the capture. Severity and the data involved decide how deep you go.
2. Take volatile data first. Memory is lost the moment the host is rebooted or shut down.
3. Collect logs and disk images. Copy them to storage the attacker cannot reach.
4. Hash everything. Record the hash values next to the files.
5. Record custody. Note who handled each item, when, and where it is stored.
6. Release the gate. The responder signs off in the ticket before the rebuild task unblocks.

The gate works best as a ticket status, not a good intention: the rebuild task stays blocked until the preservation record is attached. How the material is handled in detail sits with A.5.28. Reimaging after capture costs a few hours, whereas reimaging before capture can cost the claim.

How do you meet the 72-hour ICO and client notification clocks?

UK GDPR requires you to report a reportable personal data breach to the ICO without undue delay and within 72 hours of becoming aware of it. Regulated clients often impose 24–48 hour contractual windows. Define what triggers each clock at classification and who calls legal, so no deadline depends on someone remembering.

The ICO personal data breach response guidance is explicit that the duty applies when a breach meets the threshold for reporting. Not every incident does, which is why the legal call needs a named owner.

Settle these items in the procedure before an incident:

• The awareness point. Agree the moment you treat yourself as aware, and timestamp it in the ticket.
• The clocks. List the ICO window and every client contract with its own deadline.
• The decision owner. Name who calls legal on whether the reporting threshold is met.
• The templates. Pre-draft notifications mapped to each statutory and contractual clock.
• The record. Keep timestamps for every notification against its window.

Missed deadlines are rarely negligence. Usually nobody defined what starts the clock or who calls legal. Put the triggers into the classification step and the deadline stops depending on memory.

What do auditors sample when they test A.5.26?

Auditors pick your most recent significant incident and walk its log end-to-end against the written procedure, checking that logging, escalation and closure happened as documented. With no incidents on file, the tabletop exercise report gets the same treatment, including whether it produced follow-up actions.

Expect questions like these in the room:

• "Show me your response procedure, then walk me through your most recent incident against it."
• "How long passed between classifying that incident and starting containment?"
• "Who is authorised to take systems offline, and how would they get access if normal credentials were unavailable?"
• "What did you preserve before you rebuilt the affected machine, and where is the custody record?"
• "Which notification deadlines applied, and how do you evidence you met them?"
• "What changed in controls, risk assessment or policy as a result of that incident?"

A well-kept Jira or Linear trail is entirely acceptable, and no SOC platform is required. For a firm with no real incidents, the exercise report carries most of the weight. The evidence set looks like this:

• An approved procedure with scenario annexes.
• Incident tickets whose timestamps show the path from classification through containment to closure.
• A team roster with the authority and escalation rules written down.
• Hashes and custody notes for any incident that produced forensic material.
• Notification records timestamped against the statutory windows.
• Post-incident review write-ups linked to the corrective actions they produced.
• Logs from any emergency-credential use, and the latest exercise report.

In certification-body practice, no documented procedure, or a real incident handled entirely ad hoc against the documented process, grades major. A single incident with patchy logging, a lapsed exercise or a missed post-incident review grades minor, and minors aggregate to major as a pattern.

How do you automate the A.5.26 audit trail in Jira or Linear?

Configure the ticketing workflow so the response records itself. Severity, timestamps, actions and approvals are captured as the response happens. Marking a ticket as notifiable starts the notification countdowns, and review findings become linked tickets. The audit timeline then assembles itself instead of being reconstructed from memory.

Four configuration choices do most of the work:

• One incident issue type. Mandatory severity and classification fields, with status changes that stamp the time automatically.
• Classification starts the clocks. Flagging an incident as notifiable creates countdown tasks for the ICO and each client contract, with legal review in the loop.
• Findings as tracked work. Review actions link to the risk register, so "did the incident change anything" is answerable by query.
• Exercises on the calendar. The annual tabletop is scheduled, run from the same workflow, and leaves the same evidence trail as a real incident.

At 25–250 people, that is a handful of workflow rules rather than a platform purchase. It satisfies auditors and enterprise customers with the same artefact.

Frequently asked questions