Building an Incident Response Program for ISO 27001 (A.5.24-A.5.29)

Incident response is one of the most critical areas of an ISO 27001 audit, and one of the most commonly failed. Controls A.5.24 through A.5.29 cover the complete incident lifecycle — from planning and preparation through response, evidence collection, and lessons learned.

Here's a practical walkthrough of what each control requires and how to implement it.

A.5.24 — Incident Management Planning and Preparation

Tier: Critical | NIST: IR-1, IR-2, IR-3, IR-6, IR-8

This is the foundation. You need a documented incident response plan that covers roles, communication procedures, escalation paths, and post-incident review processes.

What auditors check

Three things: (1) the plan exists, (2) the plan has been tested, and (3) people know the plan.

A plan that hasn't been tested in over 12 months is a finding. "Tested" means a tabletop exercise at minimum — a full simulation is ideal but not required for startups. The plan must include notification requirements (GDPR requires 72-hour regulatory notification). Contact lists must be current.

What your plan should include

• Severity definitions — P1 through P4 with response time SLAs
• Roles and responsibilities — Incident commander, communications lead, technical responder
• Communication channels — How the team coordinates during an incident
• Escalation procedures — When to involve leadership, legal, or external parties
• Evidence preservation — How to capture logs and artifacts before they rotate
• Post-incident review — Mandatory debrief for every P1 and P2 incident

Evidence to collect

• Incident response plan document (version-controlled)
• Tabletop exercise records (date, participants, scenario, findings)
• Communication tree with last-verified date
• Training records showing IR training for relevant personnel

A.5.25 — Assessment and Decision on Security Events

Tier: Critical | NIST: IR-4, IR-5, IR-8

Not every security event is an incident. You need documented criteria for triaging events and classifying their severity.

What auditors check

They want a classification scheme — not just "high/medium/low" but criteria for each level. They'll ask: "Show me an event that was NOT classified as an incident" to verify that triage works both ways.

If everything is classified as an incident, triage isn't working. If nothing is, detection isn't working.

What to implement

Define a classification matrix:

Severity	Criteria	Response Time
P1 Critical	Data breach, complete service outage	15 minutes
P2 High	Partial outage, unauthorized access detected	1 hour
P3 Medium	Vulnerability exploited, suspicious activity	4 hours
P4 Low	Policy violation, failed login pattern	Next business day

A.5.26 — Response to Information Security Incidents

Tier: Critical | NIST: IR-4, IR-6, IR-8, IR-9

Respond according to the plan. Contain the impact, preserve evidence, communicate with stakeholders, and document all response actions.

What auditors check

They review actual incident records, not just the plan. They look for: timeline of response actions, evidence of containment, stakeholder notifications. If there have been zero incidents in the audit period, they'll ask about near-misses to verify the capability exists.

Post-incident review (lessons learned) is required — just closing the ticket isn't enough.

A.5.27 — Learning from Incidents

Tier: Checkbox | NIST: IR-9

Use incident knowledge to strengthen controls and prevent recurrence. Feed lessons learned back into your risk assessment.

What auditors check

The feedback loop: incident leads to root cause analysis, which leads to corrective action, which leads to control update. They'll ask: "After your last incident, what changed?" If nothing changed, it's a finding.

A.5.28 — Collection of Evidence

Tier: Checkbox | NIST: IR-4

Establish procedures for collecting and preserving evidence related to security incidents, ensuring chain of custody.

What auditors check

Can you reconstruct what happened after a breach? If logs rotate too fast or aren't centralized, the answer is no. Immutable log storage is best practice for audit trails.

A.5.29 — Security During Disruption

Tier: Checkbox | NIST: IR-4

Maintain security controls during business disruptions. Security shouldn't be bypassed during incidents or DR scenarios.

What auditors check

The classic failure: disabling MFA or firewall rules during an outage "to speed up recovery." DR plans should explicitly state which security controls remain active during failover. "Break glass" procedures must be logged and reviewed.

A.6.8 — Security Event Reporting

Tier: Relevant | NIST: IR-4, IR-6

All personnel should know how to report security events. There should be a clear, accessible reporting channel.

What auditors check

They ask random employees: "If you noticed suspicious activity, who would you report it to?" The reporting channel must be easy — a dedicated Slack channel, email alias, or phone number. Training records should show that employees know how to report. A no-retaliation policy should be documented.

Building Your Program from Scratch

If you're starting from zero, here's the priority order:

1. Write the Incident Response Plan — Even a two-page document is better than nothing
2. Define severity levels — Four tiers with response time SLAs
3. Designate an incident commander — One person, with a backup
4. Set up a reporting channel — Slack channel or email alias that everyone knows about
5. Run a tabletop exercise — Simulate a realistic scenario and document the results
6. Create a post-incident review template — Standard form for capturing lessons learned

You can build a functional incident response program in a week. Keeping it operational requires running tabletop exercises at least annually and updating the plan after every real incident.

Need your incident response program assessed? Book an internal audit and we'll evaluate your readiness across all incident management controls.