Incident Response Plan Template (Free, With Cloud Runbook)

An incident response plan is the document a company follows from the moment a security event is reported until the incident is closed and reviewed. This incident response plan template opens with a First Hour Checklist, then has the response stages, a severity matrix, a contact list, incident record fields, a breach notification table and first-hour evidence and containment steps for AWS, Azure and Google Cloud. Truvo Cyber generalized the template from incident response plans in use in client security programs.

What does an incident response plan template contain?

An incident response plan template contains the procedure the response team follows, the people the team calls and the records the team keeps. The Truvo template has these parts:

• First Hour Checklist: the page to open when something is happening now, from reporting the incident and opening the record to containment, calling the right people and keeping details within the response team.
• Purpose, scope and definitions: the systems, networks and data in scope, including company data held by vendors, and terms such as Security Event, Information Security Incident, Incident Lead, Security Response Team, Out-of-Band Channel and Indicator of Compromise.
• Response team and contacts: the default and backup Incident Lead, the executive sponsor who names an Incident Lead when neither answers, and a contact list with phone numbers and the situation for each call.
• Reporting an incident: what staff report and where, an out-of-band route for a suspected insider or compromised email, and where reports from customers, vendors and researchers go.
• Severity matrix and response stages: the response goal at each severity and the actions at each stage.
• Incident record and evidence: the fields every record holds and how evidence is collected, stored and handed over.
• Notification, communication rules, retention and testing: the breach notification table, who speaks for the company, how long records are kept and how the plan is tested.
• Roles and responsibilities: the Incident Lead, the Security Response Team, the Privacy Officer, management and all Personnel.
• Appendices: first-hour steps for AWS, Microsoft Azure and Entra ID, and Google Cloud, and a mapping to SOC 2, ISO/IEC 27001:2022 and NIST CSF 2.0.

What are the five stages of an incident response plan?

The five stages of an incident response plan in the Truvo template are Verify, Assess, Contain and eradicate, Recover, and Review. The stages often overlap, and the response team records every action in the incident record, with the time and who acted.

1. Verify. The Security Response Team identifies the affected systems, devices, accounts and data. The Incident Lead declares the incident and records the time, because some notification deadlines start from awareness.
2. Assess. The team works out who is affected (Personnel, customers or others), what data was accessed, stolen, changed, deleted or encrypted, whether personal information is involved and whether the company is the controller or a processor for that data, and which laws, contracts and insurance terms require notice. For a Critical incident, management decides whether to engage legal counsel, and once counsel is engaged, the team handles incident communications as counsel directs.
3. Contain and eradicate. The team preserves evidence first where doing so does not increase harm, then isolates affected systems, disables compromised accounts, revokes sessions and tokens, rotates exposed passwords, API keys and other secrets, and blocks malicious IP addresses and domains. Eradication removes the cause, such as malware or an attacker's account, and fixes the root cause. The team records these changes under the Change Management Policy, as emergency changes where needed.
4. Recover. The team restores compromised systems to a known-good state by rebuild or by restoring a backup taken before the compromise, after checking that the backup is free of the incident's indicators of compromise. Restored systems stay under monitoring for [30 days], and for High and Critical incidents the Incident Lead holds a check-in [at least daily] until resolution.
5. Review. Within [10 business days] of resolving a High or Critical incident, management and the Security Response Team meet and document the timeline from first signal to closure, the root cause, what worked and what slowed the response, and actions with an owner and a due date. The results feed the risk assessment, and the team tracks each action to completion. Low and Medium incidents are reviewed together [quarterly] for trends.

For these stages applied to one incident type, see the ransomware response guide.

Incident severity matrix for an incident response plan

With an incident severity matrix, every responder applies the same rule for how fast to act and who to involve. The matrix below is the one in the template, generalized from a plan in use at a client. Values in brackets are defaults to change to what the team can meet.

Who belongs on an incident response contact list?

An incident response contact list holds everyone the response team calls in the first hours, with phone numbers that work when company email is down. The template has a row for each party below, with the name and organization, phone and email, and when to call. The default Incident Lead and a backup are named, and if neither answers within [30 minutes], the executive sponsor names an Incident Lead.

Review the incident response contact list [at least quarterly] and after any change in staff or vendors, and keep a printed or offline copy of the plan, because ransomware and email compromise can take out the systems the plan is stored on.

What fields belong in an incident record?

An incident record is the evidence that the response followed the plan, and auditors sample incident records to test SOC 2 CC7.4. Each incident record in the template holds:

• Incident ID, Incident Lead and severity, with each change and the reason
• Time of first report, time of declaration, and who reported
• Affected systems, accounts, data and people, including any personal information
• Indicators of compromise
• A timeline of actions and decisions
• Evidence collected, where the evidence is stored and who handled each item
• Notifications sent: to whom, when and under which obligation
• Root cause, review link and closure date

Evidence handling in the template covers:

• Capturing memory and running processes before shutdown, where tools allow
• Imaging or snapshotting disks before rebuilding or wiping
• Exporting logs before they age out
• Storing evidence in a restricted location, limited to the Security Response Team
• Recording each handover: what, from whom, to whom and when
• Recording a SHA-256 hash of each evidence file

Default retention is at least 3 years for incident records and reviews and at least 15 months for technical evidence, longer when law, contract or a legal hold requires. When the incident tracker itself may be affected, the team keeps the record in a backup location and moves the record back later. For the Jira setup, see the ticketing and SLA guide.

Cloud incident response plan: the first hour in AWS, Azure and Google Cloud

A cloud incident response plan adds provider-specific first-hour steps for incidents such as leaked access keys, an unknown admin user or cryptomining, in this order: preserve evidence, revoke and rotate credentials, isolate, then hunt for persistence. Evidence comes first because default log retention is short and containment changes the systems under investigation.

Responders need five cloud details during the first hour:

• Firewall changes in all three clouds apply to new connections. On AWS, a security group change leaves tracked connections running, and a network ACL deny breaks existing connections for every instance in the subnet, per the EC2 connection tracking documentation. Azure network security group rules apply only to new connections, and Google Cloud VPC firewall rule changes apply to new connections too. To end an open attacker session, capture memory where tools allow, then stop the instance.
• AWS role sessions outlive a key change. Revoke active sessions attaches the AWSRevokeOlderSessions policy, which denies every session of the role issued before that moment, so legitimate users of the role sign in again.
• Microsoft Entra ID access tokens outlive session revocation. Revoking sessions invalidates refresh tokens and browser session cookies within a few minutes, and access tokens already issued can stay valid for 60 to 90 minutes. Blocking sign-in first stops Entra ID from issuing new tokens.
• Microsoft Entra ID Free keeps sign-in logs for seven days, and P1 and P2 keep 30, per Microsoft's retention table. Upgrading later brings no older data back, so set up longer retention before any incident.
• In any cloud, open a support case and record the case number. Rebuild from known-good images or infrastructure code, and check billing for unexpected usage.

Cloud incident recovery depends on snapshots taken before the incident

In one Google Cloud review, a production VM had a snapshot schedule and 15 snapshots, all of the data disk. Snapshot schedules attach to individual disks, and the boot disk holding the operating system and configuration had no snapshot, so a restore would have meant rebuilding the server. Check cloud recovery readiness per disk: every attached disk has a schedule and a snapshot newer than the recovery point objective, and the restore test covers the whole VM. For the recovery evidence auditors ask for, see the SOC 2 CC7.5 guide.

Incident response plan vs incident response policy

An incident response policy holds the rules management approves, and the incident response plan holds the procedure the team follows to keep those rules. The team updates the plan whenever people, tools or contacts change, while the policy changes rarely. The incident response policy template has the policy clauses in full and a side-by-side comparison. For companies running their own hardware, see the on-prem incident response guide.

How to test an incident response plan with a tabletop exercise

A tabletop exercise tests an incident response plan by walking the response team through a simulated incident in a meeting, with production untouched. The kit has a tabletop exercise template with a ransomware-on-a-laptop scenario in four phases: Verify, Assess, Contain and Recover, and Notify and Review. A useful incident response tabletop exercise has four parts:

• Injects: scenario updates revealed one phase at a time (two days later, the attacker emails a generic company inbox with a sample of the customer files as proof) that force decisions.
• Decision points: who sets severity, who decides on the ransom, who calls the insurer.
• Real artifacts: responders open the contact list, the severity matrix and the notification table.
• Recorded results: gaps, actions, owners and due dates, reviewed at the start of the next exercise.

Test the plan at least annually with a tabletop exercise or a walkthrough, document each test and track the gaps to completion. Update the plan after each test and each High or Critical incident. For where AI tools help during analysis, see the AI for incident response guide.

How an incident response plan maps to SOC 2, ISO 27001 and NIST SP 800-61 Rev. 3

One incident response plan can serve SOC 2, ISO 27001 and NIST at once, because each plan section maps to a requirement in all three. The mapping below is Truvo Cyber's interpretation, and auditors may map controls differently.

The SOC 2 CC7.4 criterion reads: The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate. NIST published SP 800-61 Rev. 3 in April 2025 to supersede Rev. 2, with incident response recommendations organized by CSF 2.0 Functions and Categories. For what auditors sample, see the CC7.4 guide and the ISO 27001 A.5.24 guide.

Breach notification deadlines to put in an incident response plan

Breach notification deadlines start at a defined moment, usually awareness or a determination, so the incident record needs that timestamp. In the template, the Privacy Officer leads notifications involving personal information, management approves every external notification, with legal counsel where warranted, and management decides whether to report to law enforcement or the Canadian Centre for Cyber Security. Confirm each row with counsel. The table has common obligations only and is general information, not legal advice.

The customer contract and cyber insurance rows take their terms from each contract and from the policy notice clause, so fill them in from those documents. For incidents involving personal information, Truvo's data breach response service supports scoping and notification.

When to start somewhere other than an incident response plan template

An incident response plan template becomes a working capability once the plan has named owners, a tested contact list and an exercise on record. Some fast-track compliance packages insert the company name into templates and collect signatures within a week. The audit can pass on that paperwork, and the gap appears at the first real incident, when responders look for who sets severity and whom to call.

Start somewhere other than the incident response plan template in these situations:

• An incident is in progress now. Call legal counsel and the cyber insurer's breach hotline first, then an outside incident responder, and write the plan afterwards.
• The plan needs an owner first. An Incident Lead needs time to test the plan and keep the contacts current.
• The environment is undocumented. The cloud steps assume an asset list and working logs. Start with a capability assessment.

Building incident response as a security capability

Incident response is one of the security capabilities an effective program is built from. The build order is a capability assessment of how the team detects and responds today, then a Security Program Manual that names owners and tools, then the policies, controls and evidence auditors test. A team that writes the incident response plan in that order ends up with a plan that matches the systems the team operates.

Truvo Cyber builds incident response capabilities for companies with SOC 2, ISO 27001 and customer security requirements, and responds to live incidents. See incident response services for the scope.

Frequently asked questions

Is there a free incident response plan template?

Yes. The incident response kit on this page is free and includes an incident response plan template, an incident response policy template and a tabletop exercise template as Google Docs. The plan template opens with a First Hour Checklist and has the response stages, a severity matrix, a contact list, incident record fields, a notification table and first-hour cloud steps.

What is an example of an incident response plan?

An incident response plan example rates incidents from Low (unapproved software on a work laptop, no data compromised) to Critical (access to customer data, data theft, ransomware or an extended outage). Each level has a reporting route and a response goal, from five business days to resolve to the full response team within an hour. Unclear incidents count as High.

What should a cybersecurity incident response plan template include?

A cybersecurity incident response plan template should include a first-hour checklist, scope, definitions, the response team and Incident Lead, reporting routes, the response stages, a severity matrix, a contact list with external parties, incident record fields, evidence handling, notification duties, record retention and a testing schedule. A cloud section adds evidence and credential steps for each provider.

What is an incident severity matrix?

An incident severity matrix is a table of incident levels, typically Low, Medium, High and Critical, with a description, examples, a reporting route and a response goal for each level. Responders use the matrix to decide how fast to act and who to involve. Many plans treat an incident of unclear severity as High.

How often should an incident response plan be tested?

Test an incident response plan at least once a year, and again after major changes such as a new cloud provider, a new Incident Lead or a merger. A tabletop exercise is the usual method. SOC 2 and ISO 27001 auditors typically ask for the most recent exercise results and evidence that the team fixed the gaps found.