Most incident response plans are written for the auditor and read for the first time during an incident. They run to 30 pages, name people who have since left, and describe a security operations center the company does not have. When something goes wrong, the team improvises, and the plan sits in a folder.
A plan that works is shorter and more specific. It says who is in charge, how to decide how serious something is, who must be told and by when, and what to record. The detailed technical steps for particular scenarios live in separate playbooks that can change without re-approving the plan.
This article covers what the frameworks expect, how to structure the plan, how to define incidents and severity, which roles to assign, how to handle notification deadlines, what to preserve, and what an auditor will check.
What the frameworks expect
SOC 2 CC7.3 covers evaluating security events to determine whether they are incidents, CC7.4 covers responding through a defined incident response program, and CC7.5 covers recovery.
ISO 27001:2022 Annex A 5.24 to 5.28 cover planning and preparation, assessing events, responding, learning from incidents, and collecting evidence.
PCI DSS v4.0 Requirement 12.10.1 requires a plan ready to activate, covering roles, communication (including notifying payment brands and acquirers), response procedures, business recovery, and legal reporting requirements. Requirement 12.10.2 requires it to be reviewed and tested at least once every 12 months.
The HIPAA Security Rule requires security incident procedures at 45 CFR 164.308(a)(6), including identifying, responding to, mitigating, and documenting incidents.
NIST SP 800-61 is a widely used guide to incident handling, and its current revision aligns incident response with the NIST Cybersecurity Framework 2.0.
The plan itself is a policy document, so it needs an owner, an approver, a version, and a review date like any other.
Keep the plan and the playbooks separate
The plan is the stable part. It should fit in a few pages and change rarely:
Scope and definitions
Severity levels and how to assign them
Roles and how to reach them
The response phases and who decides at each one
Communication and notification
Evidence and record-keeping
Post-incident review
Playbooks are the operational part. One per likely scenario: a compromised user account, a leaked credential, a lost laptop, malware on an endpoint, exposure of customer data, a ransomware event, a compromised vendor. Each lists the first technical steps, the systems to check, and the people to involve. They should be easy to update as your environment changes.
Define incidents and severity
Not every alert is an incident. The plan should define the difference so nobody has to debate it under pressure. A security event is something observed that might matter. A security incident is an event that has compromised, or is likely to compromise, the confidentiality, integrity, or availability of systems or data. Triage of events is part of monitoring; security monitoring and alerting covers that step and the record it should leave.
Then define severity in terms anyone on call can apply:
| Severity | Description | Response |
|---|---|---|
| Critical | Confirmed exposure of customer or regulated data, or a production outage caused by an attack | Full response team, executive notified at once, notification assessment starts |
| High | Confirmed compromise of an account or system, no confirmed data exposure yet | Incident lead and technical lead engaged at once |
| Medium | Suspicious activity with limited scope, contained or containable | Handled by on-call within business hours |
| Low | Policy violation or minor event with no evident impact | Logged and handled through normal process |
Severity can change as facts emerge. The plan should say who can raise or lower it and that the change is recorded.
Assign roles, not names
The plan names roles. A separate contact list, reviewed every quarter, maps roles to people and deputies.
Incident lead. Runs the response, makes decisions, keeps the timeline. Not necessarily the most senior person.
Technical lead. Directs investigation and containment.
Communications lead. Drafts internal updates and external statements.
Legal and privacy. Assesses notification duties and contractual obligations. External counsel if you have no one in house.
Scribe. Records decisions and actions with timestamps. On a small team the incident lead may do this, but someone must.
Executive sponsor. Approves decisions with business impact, such as taking a service offline or notifying customers.
Keep the contact list somewhere reachable if your primary systems are down. An incident that takes out your identity provider also takes out the plan stored behind it.
Notification: the part with deadlines
Notification obligations are where an incident becomes a compliance event. They come from law, from contracts, and from industry rules, each with its own clock.
GDPR Article 33 requires a controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to individuals. A processor must notify its controller without undue delay. GDPR breach notification and the 72-hour clock covers when the clock starts.
HIPAA requires notice to affected individuals without unreasonable delay and no later than 60 calendar days after discovery of a breach of unsecured PHI, with separate rules for notifying HHS and the media. HIPAA breach notification timelines and thresholds sets these out.
Customer contracts and data processing agreements often set their own notification windows, sometimes shorter than the law's.
US state breach laws vary in definitions and timing.
US public companies must disclose material cybersecurity incidents on Form 8-K within four business days of determining materiality.
Do not try to restate every rule in the plan. Instead, keep a notification register as an appendix: each obligation, its source, what triggers it, when the clock starts, and who sends it. Review it when you sign a contract with a new notification clause. Whether a given incident triggers a given duty is a legal question; confirm with counsel.
Preserve evidence and keep the record
ISO 27001 Annex A 5.28 covers collecting and preserving evidence. In practice:
Export relevant logs before retention rotates them out
Snapshot affected systems before rebuilding them, where feasible
Keep a timeline of observations, decisions, and actions as they happen
Record who had access to the evidence
The incident record is also your audit evidence. It should show detection, triage, severity, actions, notifications made or assessed, and closure.
Learn from it
ISO 27001 Annex A 5.27 asks you to use knowledge gained from incidents to strengthen controls. Hold a post-incident review for every high or critical incident, focused on what happened and what to change rather than who to blame. Track each resulting action to completion, and update the plan or playbooks where the response exposed a gap.
What an auditor will check
- Not done:
The plan, approved, versioned, and reviewed within your stated cycle
- Not done:
A current role and contact list
- Not done:
Evidence the plan was tested, such as a tabletop exercise record
- Not done:
Records for incidents during the period, from detection to closure
- Not done:
Post-incident actions tracked to completion
If you had no incidents, the auditor will still want evidence that the process operated: triage records showing events were assessed, and a test of the plan. Under ISO 27001, the same records support Annex A 5.24 to 5.28.
How TrustLynce helps
TrustLynce policy management provides policy templates with versioning and acceptance tracking, which covers the plan's approval and review cycle. Continuous monitoring routes control failures to owners, leaving a record that events were seen and handled.