Incident Response Policy: What Auditors Expect
An incident response policy passes an audit when there is a log behind it, not just a document. Auditors want to see that events were evaluated, that a real or minor incident was handled according to the stated process, and that something was learned from it afterward. A policy with no activity to point to for an entire audit period is the single most common finding in this area.
Quick answer. An incident response policy that passes audit defines what counts as an incident, names who responds and how they escalate, and is backed by a log showing events were evaluated and at least one incident, even a minor one, was handled end to end. Under SOC 2 it maps to CC7.3 through CC7.5. Under ISO 27001:2022 it maps to Annex A 5.24 through 5.28.
What a policy needs to say
A policy that survives sampling covers four things directly:
- What counts as an incident, with a clear threshold that separates a real incident from a routine alert.
- Who is responsible for triage, and how an event gets escalated from "alert" to "incident."
- How the team responds, including roles, communication steps, and expected timelines for containment.
- What happens afterward, meaning a review step that captures what was learned and tracks fixes to completion.
A policy that only says "we will respond to incidents appropriately" gives an auditor nothing to test. The value is in naming the threshold, the owner, and the steps specifically enough that a sampled event can be checked against them.
Where it maps: SOC 2 CC7.3 to CC7.5
CC7.3 covers evaluating security events to decide whether they are incidents. Your policy needs a stated definition of what qualifies, and your log needs to show that alerts were reviewed and dispositioned, including the ones that turned out to be nothing. Auditors do not accept the absence of incidents as evidence that this evaluation happened.
CC7.4 covers the actual response: a documented procedure with roles, escalation paths, and communication requirements, applied to real events. The log for this control should show a timeline, when something was detected, when it was contained, and what actions were taken.
CC7.5 covers what happens after an incident closes. A post-mortem or root cause review should exist for any significant incident, with findings written down and improvements tracked until they are actually done, not left as a suggestion in a document nobody revisits.
For the full breakdown of CC7, including the detection and monitoring controls that feed into incident evaluation, see SOC 2 CC7 monitoring requirements explained.
Where it maps: ISO 27001 Annex A 5.24 to 5.28
ISO 27001:2022 splits the same ground across five controls:
- 5.24 Information security incident management planning and preparation - the roles, responsibilities, and procedures defined before anything happens, the equivalent of the written policy itself.
- 5.25 Assessment and decision on information security events - the triage step that decides whether an event is an incident, matching CC7.3.
- 5.26 Response to information security incidents - the actual response, matching CC7.4.
- 5.27 Learning from information security incidents - the post-incident review and the fixes that come out of it, matching CC7.5.
- 5.28 Collection of evidence - preserving evidence from an incident in a way that holds up, whether for internal review or a legal or regulatory need.
The overlap with SOC 2 CC7.3 through CC7.5 is close enough that one incident response program, run and logged consistently, satisfies both frameworks with the same evidence.
What makes a policy fail under sampling
Common gap
Common gap: The policy exists and reads well, but the incident log for the entire audit period is empty, with no record of alerts being reviewed or dispositioned as non-incidents.
Common gap
Common gap: An incident happened, but there is no timeline showing detection, containment, and resolution, only a brief note after the fact.
Common gap
Common gap: A post-mortem was written once, but the fixes it identified were never tracked to completion, so the same gap resurfaces later.
What good evidence looks like
Keep an incident log that covers every reviewed event, not just confirmed incidents: the date, what triggered it, whether it was classified as an incident, who handled it, and what the outcome was. For any real incident, keep the timeline of detection through containment and the post-mortem that followed. For a quiet audit period, keep the record of alerts that were investigated and closed, since that is the evidence that the evaluation step in CC7.3 and Annex A 5.25 actually ran.
Standing this program up, and keeping the log current through an entire audit period, is exactly the kind of ongoing work a fractional CISO owns for you. If you want someone to write this policy and run the log, see the SOC 2 readiness plan or book a call. See pricing if you want the numbers first.