Incident Response Policy and Plan
An incident response policy states an organisation's commitment to managing security incidents and assigns authority, while an IR plan translates that commitment into specific procedures, roles, and communication channels. Together they define scope, escalation paths, and how IR activities connect to business continuity and disaster recovery.
Last updated:
An incident response policy is a short governance document signed by senior management that states the organisation's commitment to handling security incidents, defines what falls within the IR programme's scope, and grants authority to the teams that will act. An IR plan is the operational companion: it translates the policy into specific procedures, defines roles and responsibilities, establishes severity tiers, specifies communication channels, and prescribes the steps from initial detection through post-incident review. Without the policy, an IR plan lacks the authority and resources to function; without the plan, the policy is an unfulfilled promise. Regulators in most jurisdictions treat both documents as mandatory evidence of a functioning information security programme.
The distinction matters in practice because the two documents have different audiences and different update cycles. A policy rarely needs to change unless organisational strategy or regulatory context shifts. A plan changes whenever technology, staffing, or threat conditions change, and it should be tested at least annually so those changes are caught before a real incident exposes them. Many organisations maintain the policy as a single-page board-level commitment and the plan as a versioned operational manual that cross-references playbooks, contact lists, and tool inventories.
International standards provide structure for both documents. NIST SP 800-61 (Revision 2) from the US National Institute of Standards and Technology outlines the four-phase lifecycle and describes what a plan should contain. ISO/IEC 27035 provides a five-stage model used in many European and Asia-Pacific jurisdictions. The UK National Cyber Security Centre and the EU Agency for Cybersecurity (ENISA) publish complementary guidance. India's CERT-In Directions of 2022 impose specific notification timelines and mandatory reporting obligations that IR plans operating in India must accommodate. Regardless of jurisdiction, the structural logic of an IR policy and plan remains consistent.
By the end of this topic you will be able to:
- Distinguish the purpose and audience of an IR policy from those of an IR plan, and explain why both are required.
- List the mandatory sections of an IR plan and describe what each section must contain.
- Explain how scope, authority, and communication channels are defined in each document.
- Describe how an IR plan relates to business continuity plans and disaster recovery plans, and identify where the handoff between them occurs.
- Identify the review and testing requirements that keep an IR policy and plan current.
- IR policy
- A management-approved governance statement that commits the organisation to an incident response programme, defines its scope, and grants authority to designated teams. Typically one to three pages; rarely changes unless organisational strategy or legal obligations shift.
- IR plan
- The operational document that translates the policy into specific procedures, roles, severity tiers, communication chains, and recovery criteria. Versioned and reviewed at least annually; may reference separate playbooks for specific incident types.
- Scope statement
- The section of a policy or plan that defines which systems, data types, locations, and third parties fall within the IR programme's coverage. A narrow scope is a governance gap; an overly broad scope creates resource problems. Both must be explicit.
- Business continuity plan (BCP)
- A document that specifies how an organisation keeps critical business functions operating during a significant disruption. The IR plan and BCP must cross-reference each other because a severe security incident may trigger BCP activation.
- Disaster recovery plan (DRP)
- A plan focused on restoring IT systems and data after a major failure or destructive event. Often a subset of BCP. The IR plan's recovery phase should specify when a DRP is invoked and who authorises the invocation.
- Communication matrix
- A structured table in an IR plan that maps incident severity tiers to mandatory notification recipients, timelines, and communication channels. It removes ambiguity about who must be told, in what timeframe, and through which channel during an active incident.
The IR policy: purpose, authority, and scope
A policy exists to express management intent and confer authority. An IR policy tells staff, auditors, and regulators that the organisation has made a formal commitment to responding to security incidents, that specific people are empowered to act, and that resources have been allocated. Without this commitment documented at the board or executive level, an IR team can be overruled by business managers who want to avoid disruption, denied budget when incidents are active, or exposed to legal liability when they take containment actions that affect business operations.
The scope section is the most consequential part of any IR policy. It defines which information assets, systems, geographic locations, and third-party relationships fall within the programme. A cloud environment that is out of scope is an unmanaged risk. A subsidiary that is out of scope is a potential entry point for attackers. Scope decisions require legal input because they interact with contractual obligations, data protection law, and jurisdictional rules. India's Digital Personal Data Protection Act 2023, the EU's GDPR, and the UK's Data Protection Act 2018 all create specific obligations when personal data is involved in an incident. The policy should name the applicable regulatory frameworks and confirm that the programme covers incidents involving regulated data.
Authority is the other critical element. The policy should name the role (not the individual) that holds authority to: declare a major incident, authorise containment actions that affect business operations (such as isolating a production system), engage external parties such as law enforcement or forensic vendors, and approve external communications including regulatory notifications. Naming a role rather than a person means the authority survives personnel changes.
Mandatory sections of an IR plan
An IR plan must be specific enough that a competent person unfamiliar with the organisation could follow it during a stressful incident. Vague language ("notify relevant stakeholders") is not a procedure. The following sections are the minimum required in a plan that will satisfy major frameworks including NIST SP 800-61, ISO/IEC 27035, and the NCSC Cyber Incident Response guidance.
| Section | What it must specify |
|---|---|
| Purpose and scope | What the plan covers; how it relates to the policy; which systems and data types are in scope |
| Roles and responsibilities | Who is on the Computer Security Incident Response Team (CSIRT), their alternates, and which decisions they are authorised to make |
| Incident classification | Severity tiers (typically three to five), the criteria for each tier, and examples |
| Detection and reporting | How incidents reach the IR team: monitoring alerts, staff reports, third-party notifications; initial triage steps; the single point of contact for reporting |
| Containment and eradication | Short-term containment options by incident type; authorisation required; evidence preservation requirements |
| Communication and notification | Internal escalation chain; external notification obligations with timelines; approved spokesperson; out-of-band communication channel if primary systems are compromised |
| Recovery | Criteria for returning systems to production; validation steps; who authorises the return; when the DRP is invoked |
| Post-incident review | When the review occurs, who participates, what is documented, and how lessons are fed back into the plan |
Appendices typically include: a current contact list for all CSIRT members and their alternates, a list of external contacts (law enforcement liaisons, forensic vendors, legal counsel, cyber insurance carrier), a tool and access inventory listing credentials or access methods needed during an incident, and a separate set of playbooks for the most common incident types (ransomware, data breach, insider threat, DDoS). Playbooks are not part of the base plan; they are referenced from it so they can be updated independently.
Defining scope and authority in the plan
The scope section of an IR plan is more detailed than the equivalent section in the policy. The policy says what is in scope in general terms. The plan specifies precisely: which network segments, cloud accounts, and SaaS environments are covered; how incidents involving third-party systems are handled; and what happens when an incident crosses organisational or jurisdictional boundaries.
Authority in the plan is mapped to specific decisions and severity tiers. A Tier 1 (low severity) incident might be handled entirely by the SOC team lead without escalation. A Tier 3 (critical) incident requires CISO involvement, notification of the board, and potentially engagement with law enforcement or regulators. The plan should include a decision matrix that shows who has authority at each tier, what actions they are empowered to take, and who they must notify. This removes ambiguity under pressure.
Cross-border incidents require particular care. An organisation with operations in multiple jurisdictions may have different notification timelines in each: GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach; India's CERT-In Directions 2022 require notification within six hours; the US has a patchwork of state-level breach notification laws with varying timelines. The plan must list each applicable jurisdiction and its requirement so that the team is not reconstructing this under time pressure during a live incident.
Communication channels and notification obligations
Communication failures are among the most common causes of poor incident outcomes. The IR plan must establish communication channels before an incident, not during one. This includes both internal channels (from the SOC to the CISO, from the CISO to the board) and external channels (to regulators, law enforcement, affected customers, and the media). See Key Terms and Stakeholders in IR for a full breakdown of the stakeholder map.
The communication matrix in the plan maps severity tiers to mandatory recipients and timelines. At Tier 1, notification may be limited to the SOC team lead. At Tier 3, the matrix should specify: CISO notified within one hour, legal counsel engaged within two hours, board chair notified within four hours, affected customers notified within 24 hours, regulator notified within 72 hours (or six hours under CERT-In). These timelines must be achievable with the organisation's actual staffing and tool set; aspirational timelines that cannot be met make the plan unreliable.
Out-of-band communication is a frequently overlooked requirement. If an attacker has compromised the organisation's email server or internal messaging platform, the IR team cannot communicate through those channels. The plan must specify an out-of-band channel: a separate email domain, personal mobile numbers for key staff, a pre-arranged secure messaging application, or a physically separate communication system. This channel should be tested as part of annual exercises.
External notifications to regulators should be treated as legal obligations, not optional communications. In the EU, failure to notify under GDPR can result in fines up to four percent of annual global turnover. Under the UK's Data Protection Act 2018, the ICO can impose fines up to £17.5 million or four percent of global turnover. Under India's DPDPA 2023, penalties for failing to notify breaches can reach INR 250 crore. The IR plan should identify which legal counsel role is responsible for approving regulatory notifications and confirm that the timeline in the matrix is compatible with the legal deadline.
Relationship to business continuity and disaster recovery
IR plans, business continuity plans, and disaster recovery plans address overlapping but distinct problems. An IR plan is focused on a security event: identifying it, limiting damage, preserving evidence, and restoring the affected system to a known-good state. A BCP is focused on operational continuity: keeping essential business functions running regardless of the type of disruption, whether a security incident, a natural disaster, or a key-person loss. A DRP is focused on IT system recovery: restoring systems and data after a major failure.
| Document | Primary focus | Triggered when |
|---|---|---|
| IR plan | Identify, contain, and resolve a security incident | A security event is detected or reported |
| Business continuity plan | Keep critical business functions operational | A disruption threatens business operations regardless of cause |
| Disaster recovery plan | Restore IT systems and data after major failure | Systems are destroyed, corrupted, or unavailable beyond IR remediation scope |
The handoff between an IR plan and a BCP is a specific, documented trigger. A ransomware attack that encrypts production databases may start as an IR incident but quickly reach a point where business operations are at risk. The IR plan should specify: at what point (defined by impact criteria, not elapsed time) the BCP is activated alongside the IR plan, who authorises BCP activation, and how the two teams coordinate. Both plans should reference each other so there is no gap in authority or confusion about who is in charge of which workstream.
DRP invocation criteria should appear in the IR plan's recovery section. Common triggers include: data loss that exceeds the organisation's Recovery Point Objective (RPO), system unavailability that exceeds the Recovery Time Objective (RTO), or evidence that systems cannot be restored from a clean backup without a full rebuild. The IR plan should name the role that authorises DRP invocation and confirm that the DRP's contact lists and resource assumptions are consistent with what the IR plan expects to be available.
Review, testing, and maintenance
An IR policy and plan that is not regularly reviewed and tested is a liability, not an asset. Plans that refer to tools the organisation no longer uses, contact lists with departed staff, or procedures that contradict current infrastructure are worse than no plan: they create false confidence and waste time during a real incident. The maintenance schedule should be embedded in the plan itself, not left to informal agreement.
Review triggers should include: a significant change in IT infrastructure or architecture, a major regulatory change (such as a new breach notification law), a significant incident in the organisation or a widely publicised incident in the same sector that reveals a gap, and the annual scheduled review. Each review should produce a dated, version-controlled document with a change log and a signature from the policy owner confirming approval.
Testing takes several forms. A tabletop exercise walks key personnel through a simulated scenario to test decision-making and communication flows without touching live systems. A functional exercise tests specific procedures such as activating the out-of-band communication channel or restoring a system from backup. A full-scale exercise tests end-to-end IR capability including external notifications. Regulators in several jurisdictions now expect evidence of testing: the US SEC's cybersecurity disclosure rules, DORA (Digital Operational Resilience Act) in the EU, and the UK FCA's operational resilience framework all include testing requirements.
What is the primary difference between an IR policy and an IR plan?
Key Takeaways
- An IR policy is a short, management-approved governance statement that commits the organisation, defines scope, and grants authority; an IR plan is the operational document that translates the policy into specific procedures, roles, and communication chains.
- Every IR plan must include purpose and scope, roles and responsibilities, incident classification criteria, detection and reporting procedures, containment and eradication steps, a communication matrix, recovery criteria, and a post-incident review process.
- The communication matrix must map severity tiers to mandatory notification recipients and timelines, including regulatory obligations that differ by jurisdiction: six hours under India's CERT-In Directions 2022, 72 hours under GDPR, and varying timelines under US state breach notification laws.
- IR plans, business continuity plans, and disaster recovery plans address related but distinct problems; the IR plan must specify the objective criteria that trigger BCP or DRP activation so the handoff is clear before an incident occurs.
- Both the policy and plan must be reviewed at least annually, after every significant incident, and after major infrastructure or regulatory changes; testing through tabletop and functional exercises is expected by regulators in multiple jurisdictions.
What is the difference between an IR policy and an IR plan?
What sections must an incident response plan contain?
How does an IR plan relate to a business continuity plan?
Who owns the incident response policy?
How often should an IR policy and plan be reviewed?
Test yourself on Incident Response and Management with free, timed mocks.
Practice Incident Response and Management questionsSpotted an error in this page? Report a correction or read our editorial standards.