Incident readiness as evidence: proving you can respond before you have to

Every major framework asks about incident response. SOC 2 Trust Services Criteria cover it. ISO 27001 requires it. HIPAA mandates a written response plan. GDPR requires breach notification to the supervisory authority within 72 hours of becoming aware of a qualifying incident. The compliance answer to these requirements is almost always the same: a written incident response plan, typically a PDF, last updated at some point before the audit, filed in the compliance drive alongside the other policies.

The written plan answers the auditor's question in the way the question is usually asked. It shows that the company has documented what it would do in the event of an incident. What it does not show — and what most frameworks are actually trying to assess — is whether the plan would work. Whether the people named in it are still with the company and in the roles assigned to them. Whether the contact information in the plan reaches the right people. Whether the company has ever practised the plan, and whether the practice produced findings that were acted on. A PDF in a compliance drive is not evidence of readiness. It is evidence that someone wrote a document.

The distinction matters most on the day that counts. When a real incident occurs, the response time is a function of how prepared the organisation actually is, not how well its documentation describes preparation. Response time, in turn, determines exposure. GDPR's 72-hour notification window begins when the organisation becomes aware of a breach — not when it has finished investigating it. HIPAA breach notification duties carry their own timelines and conditions. Every minute spent locating the right people, confirming who has authority to make decisions, and identifying which systems are affected is a minute that runs against a clock that started when the incident was first detected. That preparation either exists or it does not. The plan says it does. The evidence is what proves it.

01 / The difference between a plan and a programme

A plan describes what should happen. A programme is what happens — and leaves a record proving it happened. Most organisations have a plan. Very few have a programme that would withstand scrutiny on whether the plan actually operates.

Contact trees are the most visible gap. An incident response plan typically contains a list of roles and the individuals assigned to them: the incident commander, the legal escalation contact, the communications lead, the technical lead for each major system. Those names were accurate when the plan was written. They may not be accurate now. Organisations with quarterly staff turnover — which includes most mid-market companies — will have at least some turnover among key incident roles between plan updates. A contact tree that has not been verified against current employment records and role assignments is not a contact tree. It is a list of names that may or may not reach the right people when the incident clock starts.

Contact tree currency is not a hard governance problem. It is a maintenance problem. But it requires a process — a scheduled verification against the identity provider, confirmation that each named individual holds the role assigned to them, and a dated record that the verification was completed. That record is what transforms the contact list from an assertion into evidence. Without it, the plan says the right people are in place. The evidence says nothing, because none exists.

02 / Where readiness evidence lives

Incident readiness is evidenced across systems the organisation already operates. The question is whether those systems are being used to build and maintain a readiness record.

Identity providers like Okta hold the current roster of who has access to which systems. When an incident response plan assigns roles based on system access — the person responsible for AWS production, the person with administrative access to Salesforce, the person with the Microsoft 365 tenant administrator credential — those assignments can be verified against what Okta currently shows. The verification produces a record. That record is evidence that the assigned roles are held by the people the plan names.

Paging and alerting tools like PagerDuty hold the on-call schedule. An incident response plan that assigns 24-hour on-call responsibility to named individuals is only as reliable as the actual on-call configuration. If the paging tool shows a different schedule than the plan describes, the plan does not reflect operational reality. Verifying the alignment between the plan and the paging configuration, and recording that verification, is how readiness in this dimension is evidenced.

Ticketing systems hold the record of tabletop exercises and postmortems. A tabletop exercise that was conducted but not documented in a ticketing system leaves no verifiable trace. A postmortem that produced findings but has no ticket tracking remediation of those findings leaves no evidence that the finding was acted on. The governance record of incident readiness is built in the same systems the organisation uses for operational work — Jira, ServiceNow, or equivalent. The exercise happened. The ticket proves it. The remediation ticket proves the finding was addressed. The absence of either means the evidence does not exist.

Readiness is not what the plan says you would do. It is what you can prove you have done — the exercises held, the contact trees verified, the postmortems completed and acted on.

03 / Tabletop exercises as governance artefacts

Tabletop exercises are the primary mechanism for testing whether an incident response plan would work without waiting for a real incident. Most compliance programmes include them in policy. Far fewer treat them as governance artefacts that require a record.

A tabletop exercise that produces a record — participants, scenario, date, findings, owners for each finding, and a linked remediation process — is evidence of a programme in operation. An exercise that was held but produced no documentation is evidence of an activity. The distinction matters when an auditor asks, or when a customer security questionnaire asks whether incident response exercises are conducted and how often, and what findings the most recent exercise produced.

The findings themselves are where the operational value lives. A tabletop exercise that concludes with "everything went well" is less useful than one that surfaces a gap — a role that could not be reached, a system access credential that no one could locate, a decision authority that was unclear. Those findings, documented and tracked, are what improve the plan between the exercise and the next real event. A programme that generates findings and acts on them is a programme that learns. A programme that generates tidy completion records is a programme that checks a box.

Postmortem discipline applies to real incidents as well. When an incident occurs — even a minor one, a near-miss, an event that did not require external notification — the postmortem is the mechanism for capturing what the response revealed about the programme. Who was hard to reach. Which escalation path was unclear. Which system took longer to investigate than the plan anticipated. A postmortem with named owners for each finding, tracked in the ticketing system, is a governance record. It demonstrates that the organisation learns from events and acts on what it learns. That record is one of the most compelling forms of readiness evidence available.

04 / Response time and the notification clock

Breach notification obligations are defined by frameworks and jurisdictions, and the specifics depend on facts that legal counsel must assess for each situation. What can be said generally is that notification timelines are short, and they begin at detection, not at the conclusion of investigation.

GDPR requires notification to the competent supervisory authority within 72 hours of the controller becoming aware of a personal data breach, where the breach is likely to result in a risk to the rights and freedoms of natural persons. That 72-hour window begins when awareness is established — not when the investigation is complete, not when legal counsel has been consulted, not when the impact has been fully quantified. Organisations operating under GDPR need to be able to move quickly from initial detection to a sufficient understanding of the incident to make a notification decision. That speed is a product of preparation.

HIPAA imposes breach notification requirements on covered entities and their business associates, with specific timelines and conditions set out in the Breach Notification Rule. The specifics — thresholds, timing, content of notification, which parties must be notified — depend on facts that HIPAA counsel must assess. The operational point is the same: preparedness compresses response time, and response time determines whether notification obligations are met within the required window.

An organisation with evidenced readiness — verified contact trees, confirmed role assignments, practised escalation paths — is an organisation that can move within the notification window. An organisation that discovers, at the moment of a real incident, that the person listed as incident commander has left, that the AWS access credentials belong to someone on a different team, and that the legal escalation contact is unreachable after hours — that organisation is not going to meet a 72-hour window. The plan says it would. The evidence would have said otherwise, if the evidence had been built.

05 / How evidenced readiness changes the audit conversation

An auditor assessing incident response against a written plan is assessing documentation. An auditor assessing incident response against a programme record is assessing evidence of operation. The conversations are different, and so are the findings.

When the evidence record includes dated tabletop exercises, remediated findings, verified contact trees, and confirmed role assignments, the auditor has something to examine. They can confirm that the exercises occurred on the schedule the policy commits to. They can confirm that findings from previous exercises were addressed. They can confirm that the contact tree was verified after the last significant personnel change. These are checks against reality, not checks against a document.

The difference is also visible in enterprise sales. Security questionnaires regularly ask about incident response testing cadence, the date of the most recent tabletop exercise, and whether the organisation has experienced any incidents and how they were handled. An organisation with a programme record answers these questions with specifics. Dates. Finding counts. Remediation completion. The organisation with only a policy answers with generalisation — "we conduct annual tabletop exercises" — and the customer's security team is left to judge whether that assertion is backed by anything. In a competitive sales situation, specificity wins.

The bad day will come. It may be a minor incident or a significant one. It may involve one system or several. It may require notification or may not. What it will always require is a response — and the quality of that response will be determined by the preparation that preceded it. Evidenced readiness is not primarily a compliance asset. It is an operational asset. The compliance record of that readiness is what remains after the incident is resolved, and what demonstrates to auditors, regulators, and customers that the organisation was prepared rather than lucky.