Incident response plan template

The template

Incident response plan outline

1. Purpose, scope and authority

State why the plan exists, which systems, data, locations and business units it covers, and who approved it. Give the incident response lead the authority to make decisions during an incident, such as taking a system offline, and say who can overrule them.

2. Roles and responsibilities

Name the incident response team and a backup for every role. Typical roles are incident lead, technical lead, communications lead, legal counsel, executive sponsor and a note taker. List external parties you would call: your incident response retainer provider, cyber insurance carrier, outside counsel, IT and managed service providers, and law enforcement contacts.

• A RACI table showing who decides, who acts and who is informed
• Escalation paths for nights, weekends and holidays
• Who is authorized to engage outside responders and approve spending

3. Definitions and severity levels

Define what counts as an event and what counts as an incident. Set severity levels, for example low, medium, high and critical, based on the data affected, the number of systems or people involved, operational impact and regulatory exposure. Link each level to who must be notified and how quickly the team assembles.

4. Governance and legal obligations

List the laws, regulations and contracts that affect how you respond, such as HIPAA, PCI DSS, CMMC and DFARS reporting, SEC disclosure rules, state breach notification laws and customer contract terms. Note your cyber insurance requirements, including whether you must notify the carrier before engaging outside responders.

5. Preparation

Describe what’s in place before an incident so the team can act quickly.

• Current inventory of critical systems, data and owners
• Logging, monitoring and alerting coverage, and where logs are kept
• Backups, including immutable or offline copies, and restore testing
• Out-of-band communication, such as phone trees or a separate chat tool
• Retainers and contracts set up in advance with responders and recovery engineers
• Training and a regular schedule of tabletop exercises

6. Detection and analysis

Explain how incidents are reported and detected: alerts from your monitoring or MDR provider, help desk tickets, user reports and third-party notifications. Describe how the team validates an event, assigns a severity, records a timeline and preserves evidence. Include a simple intake form: who reported it, when, what was observed and which systems are involved.

7. Containment and eradication

Set out containment options and who can approve them, such as isolating devices, disabling accounts, blocking addresses or taking systems offline. Describe short-term containment to stop the spread and longer-term containment while you investigate. Then cover eradication: removing malware and attacker access, resetting credentials, fixing the vulnerability that was exploited and confirming the root cause.

• Evidence handling and chain of custody before systems are wiped
• Criteria for when to bring in forensic responders
• How you confirm the attacker no longer has access

8. Communication and notification

Decide who speaks for the organization and what gets said to whom: employees, executives, the board, customers, partners, regulators, insurers, law enforcement and the media. Route external statements through legal counsel. Include pre-approved message templates and a log of every notification made.

9. Recovery

Describe how systems are restored and returned to service: restore order based on business priority, how clean backups are verified, how restored systems are monitored for signs of reinfection and who signs off that operations are back to normal.

10. Post-incident review

Hold a lessons-learned review after every significant incident. Document the timeline, root cause, what worked, what didn’t, and the actions you’ll take, with owners and due dates. Feed the results back into your risk register, controls and this plan.

11. Playbooks

Attach short, step-by-step playbooks for the incidents you’re most likely to face. Each playbook should cover triggers, first steps, containment decisions, who to call and recovery.

• Ransomware
• Business email compromise and wire fraud
• Compromised user or administrator account
• Lost or stolen device
• Data exposure or third-party breach
• Misuse of AI tools or AI agents

12. Testing and maintenance

Name the plan owner. Review the plan at least annually and after major changes to systems, staff or vendors. Test it with a tabletop exercise at least once a year, with both technical and executive participants, and update it based on what you learn.

Appendices

• Contact list for the team, executives, vendors, insurer, counsel and law enforcement
• Critical systems list with owners and recovery priority
• Incident intake form and incident log template
• Evidence handling and chain of custody form
• Communication templates
• Plan revision history