Every organization has an incident response plan, and in a surprising number of them the plan is the only thing that exists. It was written for a certification or an insurer, it names a steering committee that has never met, it assigns roles to people who have since left, and it describes a severity scale that nobody in the security operations center uses at two in the morning. Then an incident happens, and what actually occurs is improvised: the analyst who noticed it calls whoever answers, containment waits for a manager who is on a flight, legal hears about it on day six, and the question of whether a regulator or a customer has to be told is asked for the first time when a deadline that started days earlier has already passed. The plan is then updated. The audit that could have found all of this in advance is the subject of this guide.
This is the method for auditing incident response as a program, from detection to the post-mortem. It defines the eight components that make up the program and the frameworks that describe them, including NIST SP 800-61 Revision 3 and the IIA’s Global Technology Audit Guide on cyber incident response and recovery, sets out the regulatory and contractual clocks that turn a classification decision into a legal obligation, gives the metrics that measure whether the program works and the ones that only look like they do, explains what a tabletop exercise has to contain to count, describes the lessons loop that separates programs that improve from programs that repeat, provides a twelve-test program, and finishes with a worked example at Lakeshore Bancorp, a nine-billion-dollar public bank whose audit found that a credential-stuffing incident had taken nineteen days to reach the people who decide whether it is material. It sits alongside the cybersecurity program audit, of which it is the respond-and-recover half, and the backup and recovery audit, which covers the technology the recovery phase depends on.
In this guide
- What an incident response audit tests, and what it is not
- The eight components of the program, and the controls in each
- The regulatory and contractual clocks
- Metrics that matter, and the ones that only look like they do
- Detection and classification: where consistency is tested
- Tabletop exercises: what counts and what does not
- The post-incident lessons loop
- Ransomware: the scenario that tests everything at once
- The twelve-test program
- Worked example: Lakeshore Bancorp audits its incident response
- Common mistakes
What an incident response audit tests, and what it is not
An incident response audit tests whether the organization can detect a security incident, decide what it is, contain and recover from it, tell the people it is obliged to tell within the time it is obliged to tell them, and learn from it, and whether it has demonstrated all of that under realistic conditions rather than on paper. It is not a penetration test, which asks whether an attacker can get in; it is not a review of the security operations center’s staffing; and it is not an assessment of the technical controls that prevent incidents, which belong to the protect function and the program audit. Its unit of analysis is the incident: real ones from the period, exercised ones from the tabletops, and hypothetical ones the auditor walks through the plan.
The framework landscape shifted in 2025. NIST SP 800-61 Revision 3, published on 3 April 2025, replaced the four-phase lifecycle that had organized incident response thinking since 2012 with a structure built on the six functions of the Cybersecurity Framework 2.0, and its central statement is that incident response is part of cybersecurity risk management and belongs across the whole organization rather than inside a security team. The practical consequence for auditors is that the audit no longer stops at the technical response: governance, identification and protection all have incident response content, and the respond and recover functions are where the program is exercised rather than where it begins. The IIA’s Global Technology Audit Guide on auditing cyber incident response and recovery, in its second edition aligned to the Global Internal Audit Standards, covers the risks and controls under the respond and recover functions and is the natural planning reference; the Cybersecurity Topical Requirement, effective 5 February 2026, makes incident response one of the areas an engagement must assess when cybersecurity is in scope. ISO/IEC 27035 remains the reference for organizations aligned to the ISO family.
The eight components of the program, and the controls in each
Eight components make up an incident response program that works, and the audit evaluates each against the evidence it produces rather than the document that describes it. The table gives the component, its objective, the controls that deliver it and the evidence to ask for. The components are in the order an incident moves through them, which is also the order in which they fail: an organization with excellent playbooks and no on-call roster will not use the playbooks, and one with a superb technical response and no notification procedure will respond well and be fined anyway.
| # | Component | Objective | Key controls | Evidence |
|---|---|---|---|---|
| 1 | Governance and plan currency | An approved plan that reflects the current organization, systems, threats and obligations | Plan ownership; annual review and after every significant incident; alignment to the risk assessment; board reporting | Plan with version history; review records; board minutes |
| 2 | Roles, authority and on-call | The right people are reachable and empowered at any hour | Incident commander role; RACI including legal, communications, HR, business owners; on-call rosters; delegated authority to contain (including to take systems down); retained forensic and legal support | Roster with tested contact details; authority matrix; retainer contracts |
| 3 | Detection and triage | Incidents are noticed quickly across the assets that matter | Logging coverage of critical assets; monitoring and alerting (in-house or managed); triage procedure and time targets; alert backlog management | Log source inventory versus asset inventory; alert and triage records; backlog metrics |
| 4 | Classification and escalation | Every incident receives a consistent severity that triggers the right response and the right clocks | Severity matrix with criteria; classification recorded with rationale; escalation paths by severity; re-classification as facts change | Incident records with severity and rationale; escalation timestamps |
| 5 | Containment, eradication and recovery | Damage is limited and systems return to a known-good state | Playbooks by incident type; containment decision authority; evidence preservation; clean-copy identification; recovery in coordination with business continuity | Playbooks with versions; incident timelines; recovery records |
| 6 | Communication and notification | Internal stakeholders, regulators, customers, insurers and law enforcement are informed as required and no more | Notification decision procedure with clock start documented; legal review; templates; single spokesperson; regulator and contract inventory | Obligation register; notification records with timestamps; legal sign-offs |
| 7 | Exercises and testing | The program has been rehearsed with the people who would run it | Annual tabletop with executives; technical drills; scenarios covering ransomware, data breach, third-party compromise; after-action reports with tracked actions | Exercise records, attendance, after-action reports, action closure |
| 8 | Post-incident review and improvement | Every significant incident makes the next one less likely or less damaging | Review within a defined period; root cause; actions with owners; trend analysis; feedback into the plan, the risk register and controls | Review records; action log; plan changes traced to incidents |
The regulatory and contractual clocks
Component six is where incident response has changed most in the last five years, because regulators have converted “notify promptly” into hours. The clocks differ in what starts them, which is the detail the audit has to test: some start when the organization becomes aware, some when it classifies the incident, some when it determines materiality, and the organization’s classification and escalation process has to produce those determinations, with timestamps, or the clocks cannot be met however fast the technical response is. The table lists the clocks most organizations face; every organization has its own subset plus the contractual ones in its customer agreements and insurance policies, and the first audit test in this component is whether anyone has compiled that inventory.
| Obligation | Who it applies to | What starts the clock | Deadline | Audit point |
|---|---|---|---|---|
| SEC Form 8-K Item 1.05 (adopted 26 July 2023; compliance from 18 December 2023, smaller reporting companies 180 days later) | US public companies | Determination that a cybersecurity incident is material, which must be made without unreasonable delay | Four business days after the determination | Is there a documented process that gets incidents to the people who make the materiality determination, and is the determination date recorded? Annual Regulation S-K Item 106 disclosures on risk management and governance also depend on the program |
| GDPR Article 33 and 34 | Controllers of EU personal data (UK GDPR mirrors it) | Awareness of a personal data breach | 72 hours to the supervisory authority; data subjects without undue delay where risk is high | Is “awareness” defined and timestamped; is the privacy function in the escalation path from severity two upward? |
| DORA Articles 18 and 19 (applies from 17 January 2025) | EU financial entities | Classification of an ICT-related incident as major under the Article 18 criteria | Initial notification within 4 hours of classification and no later than 24 hours after awareness; intermediate report within 72 hours of the initial notification; final report within one month of the intermediate report | Does the severity matrix embed the Article 18 criteria so that classification and the DORA determination are the same act? |
| NYDFS 23 NYCRR Part 500 (as amended November 2023) | New York licensed financial services entities | Determination that a cybersecurity incident has occurred; an extortion payment | 72 hours’ notice; 24 hours’ notice of an extortion payment with a written explanation within 30 days | Is the ransomware playbook wired to the notification procedure? |
| HIPAA breach notification rule | US covered entities and business associates | Discovery of a breach of unsecured protected health information | Individuals without unreasonable delay and within 60 days; HHS and media rules by size | Is the discovery date determined and recorded? |
| US state breach notification laws | Anyone holding residents’ personal information | Discovery, with definitions varying by state | Commonly 30 to 60 days; some states shorter; attorney general notices above thresholds | Does the obligation register cover every state whose residents’ data is held? |
| Payment card brands and acquirers (PCI DSS) | Merchants and service providers handling cardholder data | Suspected compromise of cardholder data | Immediate notification per the brand and acquirer agreements; forensic investigator engagement | Is the acquirer contact in the playbook? |
| Customer contracts and cyber insurance | Everyone | Per the contract: often awareness or confirmation | Commonly 24 to 72 hours in customer agreements; policy notice periods in insurance | Has anyone read the contracts and put the deadlines in the register? |
Two design points follow. The severity matrix has to be built so that the classification that starts a regulatory clock is a defined level with defined criteria, not a separate judgment made later by a different group. And the timestamps have to exist: when the alert fired, when a human looked at it, when it was classified, when it was escalated, when the materiality or breach determination was made and by whom. An incident record without those five timestamps cannot demonstrate compliance with any clock, and the audit tests that they are captured as a matter of routine, not reconstructed afterward.
Metrics that matter, and the ones that only look like they do
Security reporting is full of numbers that measure activity rather than outcome: alerts generated, attacks blocked, phishing emails filtered. None of them says whether an incident that got through would be found and handled. The metrics that matter measure time and completeness across the incident lifecycle, and they can be computed from the incident records the organization already keeps, which is why the audit computes them rather than accepting the dashboard. The table gives the set, with the question each answers and the trap in each.
| Metric | Question it answers | How to compute it | Trap |
|---|---|---|---|
| Time to detect (dwell time) | How long attackers or failures go unnoticed | First malicious or anomalous activity (from forensics) to first alert or report, per incident; median and worst case | Measuring from alert to ticket, which ignores the dwell before the alert |
| Time to triage | How long an alert waits for a human | Alert timestamp to first analyst action; distribution by hour and day | Averages that hide the weekend queue |
| Time to classify and escalate | Whether severity and the clocks start promptly | Triage to recorded severity; severity to escalation notification | Classification recorded at closure rather than at the time |
| Time to contain | How long the attacker keeps access after discovery | Detection to containment action (isolation, credential reset, block) | Containment defined as “ticket assigned” |
| Time to recover | How long the business is impaired | Containment to restoration of affected services against recovery objectives | Recovery declared before validation |
| Logging coverage of critical assets | Whether detection is even possible where it matters | Critical assets in the inventory with logs flowing to monitoring, as a percentage; retention against the longest expected dwell | Coverage counted by log source rather than by critical asset |
| Post-incident review completion | Whether the organization learns | Significant incidents with a review within the policy period; actions raised, closed and overdue | Reviews performed but actions never assigned |
| Exercise coverage | Whether the program has been rehearsed with the right people | Exercises in the period by scenario and participants; executives, legal and communications attendance; actions closed | A technical drill counted as an executive exercise |
| Repeat incidents | Whether root causes are fixed | Incidents in the period sharing a root cause with a prior reviewed incident | Never computed because incidents are not categorized by cause |
Detection and classification: where consistency is tested
Two audit tests carry most of the weight in the first half of the program. The first is completeness of the incident population. The organization’s incident list is usually the ticketing system’s incident category, and it is incomplete in the same way a change ticket export is incomplete: the incidents that were handled informally, the alerts closed as false positives that were not, the events reported to the help desk and never recognized as security incidents. The auditor builds the population from the sources upstream of the ticket, the monitoring platform’s alert history, the help-desk tickets with security keywords, the managed provider’s reports, the phishing-report mailbox, and reconciles them to the incident list, exactly as the change management audit reconciles production changes to tickets. The unrecognized incidents found this way are a finding about detection and triage before any individual incident is examined.
The second is re-performance of classification. Take a sample of incidents, apply the organization’s own severity criteria to the facts recorded, and compare the result with the severity assigned. Consistent under-classification is the most common finding in the domain, and its consequences are exact: an incident rated severity three that met the criteria for severity two was not escalated to legal, did not start the notification analysis, and was not reviewed afterward, all because of a rating decision made by a tired analyst with an incentive to keep the queue moving. The test also reveals whether the criteria are usable; a matrix that requires the analyst to estimate financial impact at the moment of triage will be ignored, and one built on observable facts, systems affected, data types involved, attacker presence confirmed, will be applied. The severity ratings guide covers calibration for audit findings, and the same discipline applies to incident severity.
Tabletop exercises: what counts and what does not
A tabletop exercise is a facilitated walk-through of a scenario by the people who would actually handle it, with injects that force decisions and an after-action report that records what did not work. It is the only way to test components two, five and six without a real incident, and it is also the easiest control to fake: a one-hour presentation to the IT team about a hypothetical malware infection, recorded as “annual exercise completed.” The auditor evaluates an exercise on five properties. The scenario is realistic and current, drawn from the organization’s threat assessment, and covers the hard cases: ransomware with backup destruction, a data breach with notification obligations, a third-party compromise where the organization depends on a vendor’s response. The participants include the decision-makers, an executive with authority to approve a shutdown or a payment, legal or outside counsel, communications, the business owners of affected processes, and the security and IT responders, not IT alone. The injects force the decisions the plan says these people will make, including the classification, the notification decision with its clocks, the containment trade-off against business disruption, and the payment question. The outputs are an after-action report with specific findings, actions with owners and dates, and evidence that the actions were closed. And the frequency is at least annual for the executive exercise with more frequent technical drills, with the scenario varied each time.
The strongest audit procedure is to observe an exercise, or to facilitate one as an advisory component of the engagement, with the auditor scoring the five properties and, crucially, timing how long it takes the room to reach the notification decision and whether anyone can name the clocks that apply. The second strongest is to read the after-action reports for the last three exercises and trace the actions; an organization whose after-action reports list the same three findings every year has been holding exercises without learning from them.
The post-incident lessons loop
Component eight is where mature programs separate from the rest. A post-incident review, held within a defined period after closure for every incident above a severity threshold, establishes the timeline, the root cause, what worked, what did not, and the actions that will prevent recurrence or improve the response; the actions have owners and dates and are tracked to closure in the same issue log discipline the audit function uses for its own findings. The audit tests the loop by tracing: the incidents in the period above the threshold, the reviews held, the root causes recorded, the actions raised, the actions closed, and the changes to the plan, the playbooks, the controls and the risk register that resulted. The failure modes are predictable: reviews held for the dramatic incidents and skipped for the near-misses that would have taught more; root causes recorded as the technical vector (“phishing email”) rather than the control failure (“no multi-factor on the mail platform’s legacy protocol”); actions assigned to nobody; the same root cause appearing in three reviews two years apart. The root cause method transfers directly, and the repeat-incident metric above is the loop’s outcome measure.
Ransomware: the scenario that tests everything at once
Ransomware is the incident type that exercises every component simultaneously, which is why it is the scenario every program should have rehearsed and the one the audit should walk through the plan in detail. Detection and triage face an attacker who has usually been present for days or weeks before encryption. Classification is immediate and the clocks start at once, including, for regulated entities, the extortion-payment notices. Containment involves taking down production systems and the authority to do so has to be pre-delegated. Recovery depends entirely on backups the attacker has tried to destroy, on the ability to identify the last clean copy, and on a rebuild-versus-restore decision for systems where persistence cannot be excluded, all covered in the backup and recovery guide. Communication involves customers, regulators, insurers, law enforcement and possibly the public, and the payment decision involves legal exposure, including sanctions screening of the recipient, insurer consent, and the practical question of whether payment would restore anything. The audit asks whether the plan answers each of these in advance: who decides on payment and on what criteria, who contacts law enforcement and the insurer, what the sanctions check looks like, where the clean-room recovery environment is, and whether the tabletop covered the moment when the backup console is found encrypted too. An organization that cannot answer these in a meeting will not answer them at three in the morning.
The twelve-test program
The program covers the eight components for a twelve-month period. Incident populations are usually small enough to test in full above the severity threshold and to sample below it; where sampling is used the standard sizes apply and the rationale goes in a sampling memo. The work program guide covers layout and the workpaper example the evidence conventions.
| # | Test | Population | Evidence | What a failure looks like |
|---|---|---|---|---|
| 1 | Evaluate plan currency, ownership, alignment to the risk assessment and board reporting | The plan and its history | Versions, review records, board papers | Plan older than a year; no change after significant incidents; board never sees incident metrics |
| 2 | Test roles, authority and on-call | RACI, rosters, retainers | Rosters tested by calling a sample of contacts; authority matrix; retainer contracts current | Named people who have left; no delegated authority to isolate systems; forensic retainer lapsed |
| 3 | Build the incident population from upstream sources and reconcile to the incident list | Alerts, help-desk tickets, provider reports, phishing mailbox for the period | Reconciliation with dispositions | Security events handled outside the process; false positives that were incidents |
| 4 | Test logging coverage and retention for critical assets | Critical asset inventory versus log sources | Coverage percentage; retention settings versus expected dwell | Critical systems not logging; retention of 30 days |
| 5 | Re-perform severity classification on a sample | All incidents above threshold plus 25 below | Facts recorded versus criteria; comparison of ratings | Systematic under-classification; criteria unusable at triage |
| 6 | Compute the lifecycle metrics from incident records | All incidents in the period | Timestamps for alert, triage, classification, escalation, containment, recovery | Timestamps missing; medians acceptable but worst cases of weeks |
| 7 | Trace clock-triggering incidents through the notification procedure | All incidents that met any regulatory or contractual trigger | Obligation register; determination dates; notifications sent; legal sign-off | No obligation register; determinations made late or not recorded; notifications missed |
| 8 | Test containment and recovery against playbooks for a sample | Significant incidents in the period | Incident timelines versus playbook steps; evidence preservation; recovery validation | Playbooks not followed or not applicable; evidence lost; recovery without validation |
| 9 | Evaluate exercises | All exercises in the period | Scenarios, participants, injects, after-action reports, action closure; observation of one exercise | IT-only exercises; no decision injects; repeated findings |
| 10 | Trace the lessons loop | Incidents above the review threshold | Reviews, root causes, actions, closure, changes to plan and controls | Reviews skipped; root causes as vectors; actions unowned; repeat incidents |
| 11 | Walk the ransomware scenario through the plan | The plan, playbooks and backup architecture | Answers to the pre-decided questions; tabletop coverage; link to backup audit | Payment and law-enforcement decisions undecided; no clean-room recovery |
| 12 | Assess third-party incident handling | Critical providers | Contract notification clauses; provider incident reports received; the organization’s response to provider incidents | No clauses; provider incidents learned from the press |
Worked example: Lakeshore Bancorp audits its incident response
Lakeshore Bancorp is a nine-billion-dollar publicly traded regional bank with twenty-two internal auditors and an in-house security operations team supplemented by a managed detection provider overnight. Its incident response plan had been in place since 2019 and reviewed annually by the security function. The FY26 audit plan included a 320-hour incident response engagement as the respond-and-recover half of the cybersecurity program review, staffed by two IT auditors with the head of security operations as the main contact and the general counsel’s office as a second.
The population test set the tone. The incident list for the twelve months held 96 incidents. The auditors rebuilt the population from the monitoring platform’s 1,140 escalated alerts, the help desk’s 214 tickets with security keywords and the managed provider’s 38 overnight reports, and found 17 security events handled outside the process, including a lost laptop with unencrypted customer correspondence reported to the help desk and closed as a hardware replacement, and a business-email-compromise attempt against the treasury team that the team had handled by phone with the bank. Re-performing classification on the 34 incidents above severity three and a sample of 25 below found seven under-classified against the bank’s own criteria, five of them involving customer data, none of which had reached the privacy officer. The lifecycle metrics from the 96 records showed a median time to triage of 41 minutes during business hours and 6 hours overnight, a median time to contain of 9 hours, and three incidents with dwell times over 20 days established by later forensics. Logging coverage of the 61 critical assets in the IT audit plan’s universe was 78 percent; the missing assets were mostly in the loan servicing platform’s database tier.
The clock test produced the finding the audit committee remembered. A credential-stuffing attack on the online banking platform had been detected, contained and closed by the security team as a severity-two incident in nine days; the general counsel’s office learned of it on day nineteen, when the security team’s monthly report circulated, and the materiality determination for the SEC’s four-business-day clock was made on day twenty-one. It was determined not to be material, which was defensible, but the plan had no step that delivered incidents to the people who make that determination, and the bank had relied for two years on a monthly report to satisfy an obligation measured in days. The tabletop exercise held eight months earlier had involved the security and IT teams only, with no legal, communications or executive participation, and its after-action report listed two of the three findings the previous year’s had listed. Post-incident reviews existed for four of the eleven incidents above the review threshold.
| Component | Result | Finding and rating |
|---|---|---|
| Governance and plan | Reviewed annually by security only; no change after the credential-stuffing incident; board received alert-volume metrics only | Plan governance (Medium) |
| Roles and on-call | Roster current; delegated isolation authority absent below the CIO; forensic retainer current | Containment authority (Medium) |
| Detection and triage | 17 unrecognized security events; overnight triage 6-hour median; 78 percent critical-asset logging coverage | Detection coverage and intake (High) |
| Classification | 7 of 59 re-performed classifications under-rated; privacy officer not in escalation | Classification consistency (Medium) |
| Containment and recovery | Playbooks for 9 types, 3 outdated; recovery validated in sampled incidents | Playbook currency (Low) |
| Notification | No obligation register; SEC materiality determination reached on day 21 through a monthly report; state breach obligations not analyzed for the lost laptop | Notification process (High) |
| Exercises | Technical-only tabletop; repeated after-action findings | Exercise design (Medium) |
| Post-incident review | 4 of 11 significant incidents reviewed; actions unowned | Lessons loop (Medium) |
The report carried two High findings and five Medium, with one root cause stated at the top: the plan had been designed as a security-team procedure rather than an enterprise process, so every component that required someone outside the security team, legal, privacy, communications, executives, the business, had no mechanism to reach them. The recommendations followed: an obligation register owned by legal with clock-start definitions embedded in the severity matrix; an escalation rule that delivered every severity-two incident to counsel and the privacy officer within 24 hours with the determination dates recorded; an intake path from the help desk and the treasury team into the incident process; logging coverage for the loan platform’s database tier; an executive tabletop with a ransomware scenario within the quarter, which internal audit observed and scored; and post-incident reviews for every incident above severity three, tracked in the bank’s issue log. The audit committee asked for the lifecycle metrics quarterly, and for the tabletop’s after-action report to be presented by the general counsel rather than by security.
Common mistakes
- Auditing the plan instead of the program. The plan is component one of eight. Test incidents, exercises, clocks and the lessons loop.
- Accepting the incident list as the population. Rebuild it from alerts, help-desk tickets, provider reports and the phishing mailbox.
- Not re-performing classification. Under-classification is the commonest finding and it silently disables escalation, notification and review.
- Ignoring the clocks. Compile the obligation register, define what starts each clock, and test that determinations are made and dated.
- Measuring activity. Alerts blocked is not a metric. Compute dwell, triage, classification, containment and recovery times from the records.
- Counting a technical drill as an executive exercise. Score exercises on scenario, participants, injects, outputs and frequency; observe one.
- Letting root causes be vectors. “Phishing” is how it started; the missing control is the cause.
- Treating ransomware as a technical scenario. Walk the payment, law-enforcement, insurer, sanctions and clean-room decisions through the plan.
- Forgetting third parties. Provider incidents are your incidents; test the clauses and the intake.
- Reporting to the board on volume. Give the committee the lifecycle metrics and the after-action findings.
Related guides
- Auditing cybersecurity programs
- How to audit backups and recovery
- Business continuity and organizational resilience
- The IIA Topical Requirements, including cybersecurity
- Building the IT audit plan
- How to audit IT change management
- How to audit identity and access management
- How to audit privileged access
- Finding severity ratings
- Root cause analysis for audit findings
- The audit issue log template
- The Third-Party Topical Requirement
- Business Continuity & Resilience guides
Leave a Reply