An auditor reading an incident log with zero entries for a twelve-month period does not think “well run”. They think “the definition of incident is too narrow, or nobody is writing things down”. A company that reports forty incidents, classifies them consistently and closes out the corrective actions is in a stronger position than one that reports none.
That is the frame to hold onto. Incident response controls are tested on whether you can detect, classify, respond, communicate and learn — and on whether the process in your policy is the process that actually ran when something went wrong at 2am.
What the auditor is actually testing
For a Type 2, expect testing across three layers.
The plan itself. Does it exist, was it approved, was it reviewed during the period, and does it name roles that correspond to real people? A plan referring to a security operations centre you do not have is a design problem before anyone looks at a single incident.
The population of incidents. A complete list of what happened during the period, drawn from a system rather than from memory.
A sample of individual incidents. For each one, the auditor traces the full lifecycle: detection, classification, response, resolution, communication where required, and follow-through on corrective actions.
They will also test the ancillary commitments in your plan. If it says you run a tabletop exercise annually, that is a testable statement with a date attached.
Your definition of “incident” determines your population
This is the crux, and it is worth thinking about before your observation window rather than during fieldwork.
If your policy defines an incident narrowly — say, only a confirmed compromise of customer data — your population will be small or empty, and the auditor will immediately ask what happened to all the security alerts, availability degradations and customer-reported issues that clearly occurred. Now you are explaining why events that a reasonable reader would call incidents were excluded, which is a worse conversation than having recorded them.
If your definition is very broad, you generate a large population and commit yourself to full lifecycle documentation for every noisy alert.
The workable middle is a defined severity scale where the response obligations scale with severity. Everything that meets the definition gets logged and classified; only the higher severities trigger the full process — incident commander, timeline, postmortem, customer communication assessment. Then the population you hand the auditor is everything logged, and the sampling naturally weights toward the severe ones.
Demonstrating that the incident list is complete
The completeness question here is harder than for access or change management, because incidents are declared by humans rather than emitted by a pipeline. The answer is corroboration from adjacent sources that were recording anyway.
Reconcile your incident log against:
- Your status page history — every published incident should appear in your internal log
- On-call paging records — pages that escalated but produced no incident record need an explanation
- Alerting tool history for the alerts your policy says are incident-triggering
- Support ticket queues filtered to the categories that indicate a security or availability problem
- Customer notifications you sent during the period
The status page mismatch is one of the most common findings we see. A company tells its customers about a four-hour outage on its public status page and has no corresponding internal incident record, timeline or postmortem. That comparison takes ten minutes and an auditor will absolutely run it.
Make the population itself system-generated: a query against the incident ticket type or your on-call tool, exported with a date, that the auditor could re-run.
What each incident record should contain
For a sampled incident, the auditor is looking for a coherent narrative with timestamps:
- Detection — how it was found (alert, customer report, internal discovery) and when, ideally from the alerting system rather than from someone’s recollection
- Classification — the severity assigned and, importantly, the criteria it was assigned against
- Who was engaged — the responders and, for higher severities, whoever your plan says must be notified
- Timeline of actions — what was done and when, including containment steps
- Resolution — when service or security was restored, and how that was confirmed
- Root cause — the actual cause, not the symptom
- Corrective actions — with named owners, due dates, and evidence they were completed
- Communication decisions — who was notified, or a recorded decision that notification was not required and why
The last two are where records most often thin out. A postmortem listing five action items with nobody assigned and no completion evidence tells the auditor that you identified the problem and did not fix it. If any of those actions relate to an exception the auditor already found elsewhere, the two findings compound.
Where notification obligations exist — under HIPAA, under contract terms with your customers, or under privacy law — the timing evidence matters as much as the notification itself. What those obligations are and when the clock starts depends on your specific arrangements and jurisdiction, and is worth confirming with counsel rather than inferring from a template plan.
Failure modes
Retroactive severity. The severity was assigned after the fact to match the response that happened, rather than the response following from the classification. Auditors notice when the classification timestamp is after resolution.
Slack as the system of record. The entire incident was handled in a channel with ninety-day retention, and by fieldwork the transcript is gone. Channel history is fine for coordination and unreliable as evidence.
Open corrective actions. Items from month two still open in month twelve with no status updates.
A plan nobody has read. Contact lists naming people who left, escalation paths to roles that no longer exist, a plan version approved three years ago with no evidence of review during the period.
No decision record for non-notification. You concluded a breach notification was not required. That conclusion is defensible; the absence of any record that you reached it deliberately is not.
The zero-incident period. If genuinely nothing happened, the auditor will test the control another way — usually through walkthrough, through evidence that alerts route into the incident process, and through your tabletop exercise. In a quiet period, the tabletop carries substantially more weight, so it is the wrong year to skip it.
Tabletop exercises that count as evidence
A slide deck is not evidence of an exercise. What holds up is a record showing the date, the scenario, who participated and in what role, the decisions taken during the exercise, what broke down, and what changed as a result.
That last element is what makes it credible. An exercise where everything went perfectly and nothing was learned reads as theatre. An exercise that discovered nobody knew who could authorise customer notification, followed by a plan update fixing that, demonstrates a functioning process — and it gives the auditor something concrete to tie to.
Making the evidence a by-product
Use an incident ticket type with the required fields built in: severity, detection time and source, responders, resolution time, root cause, and linked corrective actions. If the fields are mandatory, the record is complete by construction rather than by discipline at the end.
Create the incident record automatically from the alert or the page where you can, so detection timestamps come from the system rather than from someone typing what they remember. Link the postmortem document to the ticket and create corrective actions as real tickets in the normal backlog, so they get the same visibility as everything else the team owes.
Then review open incident actions in a recurring meeting once a month. That single habit closes the most common exception in this area, and it produces its own dated record.
What to do next
Open your status page history for the last twelve months and check that every incident on it has a matching internal record with a timeline and a postmortem. Then open your incident response plan and confirm the people named in it still work at your company.
Those two checks take under half an hour and will tell you whether your incident evidence is a story you can tell with documents or a story you will be telling from memory.
Assurion performs SOC 2 and HIPAA-related work and can walk your incident records during readiness, while the gaps are still fixable within the period.