Free Incident Response Plan Template (ISO 27001 & SOC 2)

Get a copy

Drop your details, grab the template.

What's inside

Format: DOCX
Category: Policy
Pages: 22
Price: Free

Asurvo customers get this template preloaded in their workspace, along with hundreds of other starter documents.

See Asurvo in action Browse all templates

Incident readiness

Building an incident response plan people can use under pressure

An incident response plan is read in two very different settings: calmly, by an auditor checking it exists, and frantically, at 2 a.m., by an engineer who has just found something wrong. Plans written only for the first reader fail the second. The test of a good plan is whether someone who has never opened it can declare an incident, reach the right people, and know what to do in the first hour. This template gives you a starting structure; the tiers, contacts, and decision rights have to be yours.

Start with severity tiers

Severity drives everything else: who gets paged, how fast, who can approve customer communication, and whether legal counsel is involved. Define tiers by observable impact rather than by attack type, so the on-call responder can classify quickly without a full investigation. The example below is a common four-level model to adapt.

Example severity model

Example severity model
Tier	Typical criteria	Response expectation	Escalation
SEV 1 Critical	Confirmed exfiltration of customer or regulated data; ransomware; production-wide outage caused by an attack	Incident commander assigned immediately; continuous response	Executive team, legal counsel, communications; assess regulatory notification
SEV 2 High	Compromised privileged account; malware on a server; suspected but unconfirmed data exposure	Response starts within the hour	Security lead and system owner; executives informed
SEV 3 Medium	Single compromised user account contained quickly; policy violation with limited exposure	Same business day	Security team and line manager
SEV 4 Low	Blocked phishing attempt; suspicious event with no evidence of compromise	Tracked in ticket queue	None beyond security team

Response phases and what each produces

Most plans follow the lifecycle popularized by NIST SP 800-61: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. NIST published Revision 3 in 2025, which reorganizes the guidance around the CSF 2.0 functions, but the working phases remain a sound skeleton for a plan.

Phase, Key activities, Record produced comparison
Phase	Key activities	Record produced
Preparation	Contact lists, on-call rota, logging coverage, forensic tooling, retainer with an external IR firm if used	Current plan, tested contact list, tabletop reports
Detection and analysis	Triage alerts and reports, declare an incident, assign severity and an incident commander	Incident ticket with timestamps and initial classification
Containment	Isolate hosts, revoke credentials, block indicators; preserve evidence before wiping	Action log with who did what and when
Eradication and recovery	Remove root cause, restore from known-good sources, monitor for recurrence	Recovery sign-off by system owner
Post-incident	Blameless review, root cause, corrective actions with owners and dates	Post-incident report and tracked corrective actions

Roles to name before you need them

Incident commander: owns decisions and coordination, not hands-on investigation.
Technical lead: directs investigation and containment.
Scribe: keeps the timeline; this role is routinely skipped and routinely missed afterwards.
Communications lead: drafts internal, customer, and public statements for approval.
Legal and privacy counsel: decides on regulatory and contractual notification and preserves privilege where relevant.
Executive sponsor: approves decisions with business impact, such as taking a service offline or paying for outside help.

Notification clocks to build in

Several regimes start a clock at the moment of awareness or determination, so the plan should record those moments precisely and route decisions to counsel early. The table lists widely cited examples; your obligations depend on jurisdiction, sector, and contracts, and many US state breach laws add their own requirements.

Regime, Obligation comparison
Regime	Obligation
GDPR Article 33	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 risk
HIPAA Breach Notification Rule	Notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery; breaches affecting 500 or more people also require notice to HHS within that window
SEC Form 8-K Item 1.05	US public companies disclose a material cybersecurity incident within four business days of determining it is material
Customer contracts	Many agreements and data processing addenda set their own notification windows; list them in the plan

Framework coverage

In ISO/IEC 27001:2022, Annex A 5.24 through 5.28 cover incident management planning, assessment of events, response, learning from incidents, and collection of evidence, with 6.8 covering event reporting by staff. SOC 2 addresses the same ground in CC7.3 (evaluating security events), CC7.4 (responding to incidents), and CC7.5 (recovery). NIST CSF 2.0 places it in the Respond function (RS.MA, RS.AN, RS.CO, RS.MI) and Recover function. HIPAA requires security incident procedures under §164.308(a)(6), and PCI DSS 4.0.1 Requirement 12.10 requires a plan that is reviewed and tested at least once every 12 months. See the SOC 2 framework page and HIPAA page for broader context.

Testing and what auditors inspect

An untested plan is a hypothesis. Run at least one tabletop exercise a year using a scenario relevant to your environment, such as a leaked cloud access key or ransomware on a file server, and invite the executives who would really make decisions. Record attendees, the scenario, gaps found, and follow-up actions. Auditors will usually ask for the plan, the last test record, a list of incidents in the period, and a sample of incident tickets showing classification, timeline, and a post-incident review. If there were no incidents, expect questions about how you know.

Before you call the plan done

Contact list tested by actually calling the numbers
Out-of-band communication channel defined in case email or chat is compromised
Evidence preservation steps written before containment steps
Links to the business continuity plan for prolonged outages
Corrective actions from reviews tracked to closure, ideally in a CAPA process
Plan owner, approver, and next review date recorded

Post-incident corrective actions are where many programs lose the thread. Asurvo's Audit product tracks findings through remediation and CAPA, so lessons learned from incidents and exercises have owners and deadlines rather than living in a meeting note.

FAQ

Frequently asked questions

What is the difference between an incident response plan and a playbook?

The plan sets governance: severity definitions, roles, escalation, decision rights, communications, and review. Playbooks are step-by-step procedures for specific scenarios such as phishing, lost devices, or cloud credential exposure. The plan should reference playbooks, and playbooks can change more often without re-approving the plan.

How often should an incident response plan be tested?

At least annually is the widely accepted baseline, and PCI DSS 4.0.1 Requirement 12.10.2 makes annual review and testing mandatory for in-scope entities. Many organizations run tabletop exercises more often and test again after major changes to infrastructure, staff, or the plan itself.

Which ISO 27001 controls relate to incident response?

ISO/IEC 27001:2022 Annex A 5.24 covers incident management planning and preparation, 5.25 assessment and decision on events, 5.26 response to incidents, 5.27 learning from incidents, and 5.28 collection of evidence. Control 6.8 covers how personnel report observed or suspected security events.

Does a small company need a formal incident response plan?

If it pursues SOC 2 or ISO 27001, handles health or card data, or signs enterprise contracts, yes. The plan can be short: a few severity levels, named roles even if one person holds several, a contact list, notification decision points, and a commitment to review after incidents. Proportionate and tested beats long and unread.

Who should approve the incident response plan?

Typically the security lead owns it and an executive approves it, because the plan grants decision rights such as taking systems offline or engaging outside counsel. Legal and communications should review the notification and disclosure sections before approval.

Keep exploring

Incident Response Plan