Incident Response Policy Template (and How It Differs From the Plan)

An incident response policy is the set of management-approved rules for security incidents: who must report a suspected incident, how severity is set, what must be recorded and kept, and how often the response plan is tested. The incident response plan is a separate document with the steps, contacts and severity matrix that the response team follows.

What is the difference between an incident response policy and an incident response plan?

An incident response policy states the rules that hold for every incident, and an incident response plan states how the response team carries out a response. The same split appears in SOC 2 CC5.3, where control activities are deployed through policies that establish what is expected and in procedures that put policies into action.

For the plan side, see the incident response plan template: the First Hour Checklist, the response stages, the severity matrix, the contact list, the incident record fields and the first-hour steps for AWS, Azure and Google Cloud.

Why Truvo keeps the incident response policy and plan as separate documents

Truvo keeps the incident response policy and the plan apart so the team can update the plan and the policy on separate schedules. A new on-call phone number belongs in the plan the same day. A change to who may declare an incident is a management decision and belongs in the policy.

Truvo follows three house policy style rules to keep the incident response policy stable:

• Roles appear only in the header and the Roles and Responsibilities section. Clauses use Personnel or [Short Name] as the subject, so a reorganization changes one section and leaves the rules untouched.
• Roles in place of people's names. The header names the Policy Owner role, so the policy stays the same through staff changes.
• Tools and evidence tables go in the Security Program Manual. The SIEM, the ticketing system and the evidence list go in the Security Program Manual and the GRC platform, which change as the stack changes.

Security Incident Response is one of around 19 security capabilities, and Truvo builds each one in the same order: a capability assessment, then the Security Program Manual that describes how the capability works, then the policies, controls and evidence. Writing the incident response policy last means every rule is one the team can meet. For that sequence in practice, see the post on operationalizing security policies.

What does an incident response policy template contain?

An incident response policy template in Truvo's house style has these sections, in this order:

1. Header block: Policy Owner (role), Approved by, Version, Effective date, Next review.
2. Purpose: one sentence.
3. Defined Terms: Information Security Incident (confirmed or reasonably suspected, including outages), Security Incident Response Plan, Out-of-Band Channel, Personnel.
4. Scope: all Personnel, all company systems, networks and data, and company data that vendors hold or process.
5. Related Policies: the Security Incident Response Plan, the Privacy Policy, the Change Management Policy and the Business Continuity and Disaster Recovery Policy.
6. Policy: short lettered clauses, (a) to (m), each with a bold label.
7. Roles and Responsibilities: Policy Owner, Incident Lead, Privacy Officer, Management and All Personnel, each as a bold line with bullets.
8. Exceptions.
9. Enforcement.
10. Review.

Incident response policy clauses, written in house style

The clauses below come from the downloadable incident response policy template, with the same clause letters. Values in brackets are defaults to change to what the team can meet.

(b) Reporting. Personnel report a suspected Information Security Incident immediately, through the channel in the Security Incident Response Plan. Personnel learn how to report when they join and [at least annually].

(c) Out-of-Band Reporting. Personnel use an Out-of-Band Channel when they suspect another employee or contractor is involved, or when [Short Name]'s email or chat may be compromised.

(d) External Reports. Reports from customers, vendors, researchers and other outside parties go to the reporting channel. Only Personnel authorized under the Security Incident Response Plan reply to the outside party.

(e) Severity. Every Information Security Incident is assigned a severity level under the Security Incident Response Plan. An incident with an unclear severity is treated as High until more is known.

(f) Records. Every confirmed or suspected Information Security Incident is recorded from first report to closure, with each action and decision.

(g) Evidence. Evidence is preserved before systems are changed, wherever preserving it does not increase harm.

(i) Notification. [Short Name] notifies regulators, customers, affected individuals, insurers and law enforcement as law and contracts require. Notifications involving personal information follow the Privacy Policy.

(k) Post-Incident Review. Every Critical and High Information Security Incident gets a documented review [within 10 business days] of resolution. Each resulting action has an owner and a due date and is tracked to completion.

(l) Record Retention. [Short Name] keeps incident records and reviews for [at least 3 years], and technical evidence for [at least 15 months]. Records are kept longer when law, contract or a legal hold requires.

(m) Testing. The Security Incident Response Plan is tested [at least annually], by tabletop exercise or walkthrough. Each test is documented, and gaps are tracked to completion. The plan is updated after each test and after each Critical or High Information Security Incident.

The other clauses in the template are (a) Response Plan, (h) Emergency Changes and (j) External Communications.

Design notes on the Notification and Severity clauses:

• Notification deadlines go in the plan. Deadlines differ by law and contract and change over time, so Truvo keeps them in the plan's notification table and the Notification clause states the duty only. Two examples: GDPR Article 33 requires notice to the supervisory authority without undue delay and, where feasible, within 72 hours of awareness, and PIPEDA section 10.3 with section 6 of the Breach of Security Safeguards Regulations requires a record of every breach of security safeguards, kept for 24 months. Confirm both with counsel. The examples are general information, not legal advice.
• Under the Severity clause, an unclear incident is treated as High. A responder who is unsure escalates instead of waiting, and the plan's severity matrix has the criteria for each level.

What auditors look for in an incident response policy: SOC 2 and ISO 27001

Auditors read an incident response policy as a list of commitments, then ask for the records that prove the team kept each commitment. The SOC 2 criteria and ISO 27001 controls auditors test an incident response policy against:

SOC 2 criterion text is from the AICPA Trust Services Criteria (2017, revised 2022), via Cloudaware's CC7 reference. ISO titles are from ISO/IEC 27001:2022 Annex A.

The common audit gap: tested annually with no tabletop record

A gap Truvo often sees in an incident response policy is a Testing clause with no tabletop exercise on record. In a SOC 2 Type 2 audit, the auditor uses the frequency in the policy as the test step. Truvo's own control catalog for the capability has the control The Incident Response Plan is tested at least annually via tabletop exercises or equivalents, and the matching evidence request is the results of the latest tabletop exercise, with the corrective actions. When the policy says tested at least annually and the team has no dated exercise record, auditors typically record an exception, even when the team has handled real incidents well.

In Truvo's engagements, we often see template policies with a frequency and no named owner for the work, and the same gap appears in other clauses. In one SOC 2 discovery for an established B2B SaaS company, the technical controls were strong, yet incidents were handled ad hoc by whoever owned the affected area, with no classification, no tracking and no post-incident review. At another SaaS company, the team cleared SIEM alerts from the dashboard without opening cases, which left monitoring evidence and no response evidence for CC7.3. For the same mechanism in ISO 27001, see the post on the ISO 27001 policy evidence gap.

The fix is to schedule the first tabletop exercise when management approves the policy, and to set every frequency to a cadence the team will keep.

When to start somewhere other than an incident response policy template

Start somewhere other than an incident response policy template in these cases:

• The plan and the responder come first. Most incident response policy clauses refer to the Security Incident Response Plan. Management approval of the policy commits the company to rules that need a plan, a reporting channel and a named Incident Lead in place. Start with the plan and the contact list.
• Detection needs work first. The Reporting and Severity clauses depend on alerts reaching a person. When a capability assessment finds logs and alerts routed nowhere central, build detection first, so incident reports come from alerts as well as from staff noticing incidents manually.
• Prescribed content. When a regulator, a government contract or a customer agreement prescribes incident content or deadlines, start from that text and fit the house style around the required wording.

An incident response policy template adopted in a week with only the company name changed carries the same audit risk. Each bracketed frequency becomes an audit commitment, so read and adjust every number, then book the first tabletop exercise on the day of approval.

Building the incident response capability around the policy

The incident response policy is one part of the Security Incident Response capability, next to the plan, the tabletop record and the incident records an auditor samples. Truvo Cyber builds and operates that capability through incident response services. In a security capability assessment, Truvo scores incident response alongside the other capabilities before anyone writes a policy.

Frequently asked questions

What is the difference between an incident response policy and an incident response plan?

An incident response policy holds the approved rules: who reports, how severity is set, what is recorded, how evidence is preserved and how often the plan is tested. An incident response plan holds the procedure: a first-hour checklist, response stages, contacts and the severity matrix. The plan changes often, while the policy stays stable and needs management approval.

Who approves an incident response policy?

Management approves the incident response policy, and a Policy Owner role, typically the head of security or the CTO, maintains the policy. Under ISO 27001:2022 A.5.1, management approves topic-specific policies, and the company publishes and communicates them and has relevant personnel acknowledge them. Record the approver and date in the policy header.

How often should an incident response policy be reviewed?

Review the incident response policy at least annually and whenever the company's environment, risks or legal obligations change, such as a new regulated data type or a major vendor change. Test the incident response plan at least annually through a tabletop exercise, and update the plan after each test and each Critical or High incident.

Does SOC 2 require an incident response policy?

Under SOC 2 CC7.4, the entity executes a defined incident response program, with evaluation of security events under CC7.3 and recovery under CC7.5. Under CC5.3, control activities are deployed through policies and procedures. In practice, auditors ask for an approved incident response policy or plan, the incident population for the period and sample incident records.

What should an incident response policy include?

An incident response policy includes Purpose, Defined Terms, Scope, Related Policies, lettered policy clauses, Roles and Responsibilities, Exceptions, Enforcement and Review. The clauses cover reporting, out-of-band reporting, severity, records, evidence, emergency changes, notification, external communications, post-incident review, record retention and plan testing. Steps and contacts go in the plan.