Incident Response Plan Template: Free Excel Download for SaaS Teams

Photo: Unsplash

Related guides:

• insider threats
• incident postmortem template
• bcp disaster recovery plan template
• incident response plan vs disaster recovery plan
• SOC 2 compliance checklist

Key takeaways

• An incident response plan defines who does what when a security event hits your SaaS platform.
• This workbook includes a team roster, 4-tier severity matrix, 7-phase playbook, and communications plan.
• Maps to SOC 2 CC7.3, ISO 27001 controls 5.24 to 5.28, and common NIST IR practices.
• The plan is only worth what you have tested. Auditors ask for a tabletop exercise record, not just the document.
• SecureSlate helps connect IR controls to evidence and post-incident follow-up.

---

Overview

When an incident happens, teams without a written plan lose hours deciding who leads, who notifies customers, and what gets preserved for forensics. A practical IR plan turns chaos into a checklist.

The cost of not having one is rarely the technical response. It is the decisions nobody is authorised to make at 2am: whether to take production down, whether this is legally a breach, who talks to the customer who just emailed asking.

What goes in an incident response plan

A plan that works in an actual incident has these eight parts. Anything less and someone will be improvising under pressure.

1. Scope and definitions. What counts as an event, what counts as an incident, what counts as a breach. These are three different things with three different sets of obligations, and conflating them is how teams either over-escalate or miss a notification deadline.
2. Roles with named people. An Incident Commander with authority to make calls, plus technical lead, communications, legal and executive sponsor. Every role needs a named backup with a phone number.
3. Severity definitions. Tied to concrete response times and escalation paths.
4. Detection and reporting channels. How an incident gets raised, including by an employee who is not on the security team and by an external researcher.
5. Phase-by-phase actions. What to do, in order, with the tools named.
6. Evidence preservation rules. What to capture before you remediate. Rebuilding the compromised host destroys the evidence you need for the investigation and, if it becomes one, the legal case.
7. Communications plan. Internal, customer, regulator and, if relevant, media. With who approves each message.
8. Post-incident process. Postmortem, corrective actions, and tracking those actions to closure.

Two things to decide in advance, not during: who has authority to declare a breach for notification purposes, and who can authorise taking production offline. Both decisions get made badly when the person who owns them is asleep and nobody knows who deputises.

The incident response lifecycle

Most frameworks describe the same cycle with different labels. NIST's guidance is commonly summarised as four phases, SANS uses six, and this template uses seven for operational granularity. The substance is identical:

Phase	Goal	Where teams go wrong
Preparation	Plan, tooling, training, contacts current	Contact list last updated two reorgs ago
Detection and analysis	Confirm something real is happening, assess scope	No triage criteria, so everything is either ignored or SEV-1
Containment	Stop the spread without destroying evidence	Wiping the host before capturing memory and logs
Eradication	Remove the root cause, not just the symptom	Rotating one credential when the whole key set was exposed
Recovery	Restore service, verify integrity, monitor for recurrence	Declaring recovery before confirming the attacker is out
Post-incident	Root cause, lessons, corrective actions	Postmortem written, actions never assigned
Improvement	Feed findings back into controls and the plan	Same root cause recurs six months later

Containment deserves particular attention because it is where the biggest irreversible mistakes happen. Decide beforehand what you preserve: memory capture, disk image, full log export with timestamps, network flow data. Write it into the plan so nobody has to make that call while an attacker is active.

Defining severity levels that actually work

The most common flaw in IR plans is a severity matrix nobody uses, because the definitions are abstract. Tie each level to something observable.

Level	Trigger examples	Response time	Who leads	Who gets told
SEV-1	Confirmed unauthorised access to production data, ransomware, full outage of a customer-facing system	15 minutes, all hands	Incident Commander, executive sponsor engaged	Exec team immediately, legal on the first call, customers within contractual window
SEV-2	Suspected compromise, exposure of a credential with production access, partial outage	1 hour	Security lead	Exec summary same day, legal if data may be involved
SEV-3	Single endpoint malware contained by EDR, policy violation with no data exposure	Same business day	On-call engineer	Security team, tracked in ticket
SEV-4	Phishing reported and blocked, low-risk misconfiguration	Next business day	On-call engineer	Logged only

Then check the definitions against reality: pull your last ten incidents and classify them retrospectively. If most land in a level whose response time you never actually met, the matrix is wrong, not the team.

Breach notification timelines you cannot miss

Your communications plan needs the clocks written into it, because they start running before the investigation is finished. These are the ones most SaaS companies are exposed to:

• GDPR: notify the supervisory authority within 72 hours of becoming aware of a personal data breach, where it poses a risk to individuals. Affected individuals without undue delay where risk is high.
• HIPAA: notify affected individuals without unreasonable delay and within 60 days. Breaches affecting 500 or more residents of a state or jurisdiction require notice to HHS and media without unreasonable delay and within 60 days; smaller breaches can be logged and reported annually.
• US state laws: vary widely, with some specifying 30 or 45 days. You are generally subject to the law of the resident's state, not your own.
• Contractual commitments to customers: frequently 24 to 72 hours, and often stricter than any statute. Check your own DPAs and MSAs, since this is the deadline most companies actually breach first.
• Sector and regional regimes: financial services, critical infrastructure and public sector customers often carry additional duties.

Put the specific obligations that apply to you in the plan with the clock start condition for each, and have legal confirm them. "Becoming aware" has a legal meaning worth getting right in advance.

What makes it useful

• Named roles: Incident Commander, CISO, IT Security Lead, IT Ops, Legal, Comms, and backups with contact details.
• Severity matrix: SEV-1 Critical through SEV-4 Low with response times, escalation paths, and notification rules.
• Phase playbook: Detection, Containment, Eradication, Recovery, and Post-Incident with checklists per phase.
• Lessons learned log: Capture improvements after every SEV-1 and SEV-2 event.

Download the template

• Download: Incident Response Plan (XLSX)

Fill team contacts before an incident. Store a printed copy offline for ransomware scenarios.

Tab-by-tab walkthrough

Overview and Version & Approval

Document owner, version, and annual review date. IR plans should be tested at least once per year.

IR Team & Roles

Assign real names, emails, and phone numbers. Include backup contacts for every critical role.

Severity Levels

SEV-1 (15-minute response) through SEV-4 (next business day). Each row defines examples, escalation, and who leads. Align definitions with your on-call runbooks.

IR Playbook

Seven phases from Detection through Post-Incident. Each row lists timeframe, actions, tools, owner, and a checkbox checklist. Customize actions for your SIEM, EDR, and cloud environment.

Communications Plan

Stakeholder notification matrix: executives, legal, DPO, customers, regulators, and media. Includes channel and message templates.

Lessons Learned Log

Post-incident improvements with owner, due date, and status. Link to tickets for audit sampling.

Testing the plan

An untested plan is a document, not a capability. Three levels of testing, in increasing cost and value:

1. Tabletop exercise. Two hours, a scenario, the real response team talking through their actions. Cheapest and highest value, because it surfaces the unanswered authority questions immediately. Run at least annually; twice a year is better.
2. Functional drill. Actually execute part of the response: restore from backup, rotate a credential set, run the forensic capture procedure. Finds the runbook step that no longer matches your infrastructure.
3. Full simulation or red team. Expensive, and worth it once the first two are routine.

Whatever you run, write it up: scenario, participants, what worked, what did not, and corrective actions with owners and dates. That write-up is the artefact auditors ask for, and it is the thing most teams cannot produce.

A good tabletop scenario for a first run: a developer's laptop is compromised and their cloud credentials had production access. It exercises detection, credential rotation, blast radius assessment, customer notification judgement, and evidence preservation all at once.

How to use it as audit evidence

Auditor focus	Template tab
Documented IR process	IR Playbook
Roles and responsibilities	IR Team & Roles
Severity-based response	Severity Levels
Communication procedures	Communications Plan
Continuous improvement	Lessons Learned Log

Pair the plan with tabletop exercise notes and at least one test record per year.

Framework mapping, for the control matrix:

• SOC 2: CC7.3 (evaluating events), CC7.4 (responding to incidents), CC7.5 (recovery), and CC2.3 for external communication
• ISO 27001:2022: A.5.24 (planning and preparation), A.5.25 (assessment and decision), A.5.26 (response), A.5.27 (learning from incidents), A.5.28 (collection of evidence), plus A.6.8 (event reporting)

Common mistakes

• Plan exists but names and phone numbers are blank
• Severity definitions do not match what on-call actually does
• No legal or DPO contact for data breach scenarios
• Lessons learned logged but actions never tracked to completion
• Only stored in the system that the incident has taken offline, or encrypted by ransomware
• No decision rights recorded, so nobody can authorise taking production down
• Notification clocks not written in, so the 72-hour window is discovered on day four

How SecureSlate helps

SecureSlate maps incident response controls to evidence, tracks remediation tasks, and keeps your IR program audit-ready year round.

Get started for free

FAQ

How often should we test the IR plan?
At minimum annually via tabletop exercise. Many teams run two per year plus one technical drill.

Who should be Incident Commander?
Typically a senior security or IT leader trained to coordinate technical, legal, and executive stakeholders. The role needs authority to make containment decisions without waiting for approval, which means it has to be delegated explicitly in advance.

Does this cover regulatory breach notification?
The communications plan includes regulator and customer notification timelines. Confirm requirements with legal counsel for your jurisdictions.

What is the difference between an incident response plan and a disaster recovery plan?
An IR plan handles security events: compromise, unauthorised access, malware. A DR plan handles availability events: outages, data loss, infrastructure failure. They overlap during ransomware, which is why both should reference each other. See incident response plan vs disaster recovery plan.

How many severity levels should we have?
Four is the practical sweet spot. Three tends to overload the middle tier, and five or more produces debates about classification during incidents, which is exactly when you cannot afford them.

Do we need a separate plan per incident type?
No, but you do want playbooks for your two or three most likely scenarios attached to the main plan. For most SaaS companies those are credential compromise, ransomware, and exposure of customer data through a misconfiguration.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory, or professional advice. Breach notification obligations and their triggers vary by framework, industry, and jurisdiction, and the timelines summarised here are general. Consult qualified legal advisors for your specific obligations.