What Should Be in Your Incident Response Plan? A Practical Template

The plan must define specific roles and the responsibilities associated with each. At minimum, the plan should define the incident commander, who has overall authority and decision-making responsibility during an incident. The lead investigator, who directs the technical investigation and forensic analysis. The communications lead, who manages internal and external messaging. And the legal lead, who advises on regulatory obligations, evidence preservation, and notification requirements. Each role should have a primary assignee, at least one alternate, and contact information that includes personal cell phones and alternative communication methods independent of corporate infrastructure.

The escalation matrix defines when and how incidents escalate based on severity. Not every security event is a crisis, and the plan must provide clear criteria for determining severity levels and the corresponding response posture for each. A severity classification system might include four levels: Level 1 events are investigated by the security operations team during normal business hours. Level 2 events activate the core incident response team and may require after-hours response. Level 3 events engage executive leadership and external resources. Level 4 events are existential threats that activate the full crisis management team, including the board and external communications. Each severity level should define specific triggers, the roles activated, the communication cadence, and the expected response timeline.

The escalation matrix must also address authority boundaries. Who can authorize shutting down a production system? Who can approve engaging outside counsel or a forensics firm? Who can authorize a public statement? Who can approve a ransom payment? These decisions cannot wait for ad hoc authorization during an incident. The plan should pre-authorize specific roles to make specific categories of decisions up to defined thresholds, with clear escalation paths for decisions that exceed those thresholds.

The plan should include containment procedures for the threat scenarios most likely to affect the organization. These are not generic instructions to 'isolate affected systems.' They are specific, step-by-step procedures tailored to the organization's environment. A containment procedure for ransomware might specify: isolate affected network segments using specific firewall rules, disable affected user accounts in Active Directory, block identified indicators of compromise at the proxy and DNS layers, and preserve affected endpoint images before any remediation. Each procedure should reference the specific tools and platforms the organization uses, because 'isolate the endpoint' is not actionable if the responder does not know whether to use the EDR console, a network access control system, or a physical cable disconnect.

Evidence preservation procedures are a critical companion to containment. The plan should specify what evidence to collect, in what order (prioritizing volatile data), using what tools, and with what chain-of-custody documentation. For each common incident type, the plan should list the specific log sources, system artifacts, and network data that investigators will need. It should also specify retention requirements: how long evidence should be preserved, where it should be stored, and who has access. These procedures must account for legal hold requirements, since litigation may follow any significant breach and evidence destroyed after the organization was on notice of a potential claim creates serious legal exposure.

Both containment and evidence preservation procedures should be tested regularly through technical exercises. A written procedure that has never been executed may contain errors, reference tools that have been decommissioned, or assume access that no longer exists. Testing converts theoretical procedures into validated, reliable capabilities.

Communication during an incident is difficult, time-sensitive, and consequential. Pre-drafted communication templates dramatically reduce the time required to issue notifications and ensure that messaging is consistent, accurate, and legally appropriate. The plan should include templates for several distinct audiences and purposes.

Internal communication templates should cover incident team activation messages, executive briefing formats, employee notification messages (what to do and what not to do), and status update templates at defined intervals. These templates should use clear, non-technical language appropriate for each audience. The executive briefing template should be structured to convey the essential information a senior leader needs: what happened, what is affected, what are we doing about it, what do we need from you, and when will we know more. Status update templates should follow a consistent format so recipients can quickly identify what has changed since the last update.

External communication templates are higher stakes and should be developed in consultation with legal counsel. The plan should include templates for regulatory notifications under each applicable framework (state breach notification laws, GDPR, HIPAA, SEC, etc.), customer notification messages, partner and vendor notifications, media holding statements, and law enforcement referral communications. Each template should identify the legal triggers that require its use, the timeline for issuance, the approval chain before sending, and the specific information that must be included to satisfy regulatory requirements. These templates will need customization for each incident, but having a vetted starting point saves hours during a response and reduces the risk of legally problematic statements.

One of the most overlooked components of an IR plan is the out-of-band communication strategy. During a serious incident, you must assume that the adversary has access to corporate email, messaging platforms, and potentially VoIP systems. Discussing response strategies through compromised channels gives the attacker advance notice of containment actions, legal strategy, and investigation findings. The plan must establish communication channels that are completely independent of corporate infrastructure: a dedicated messaging platform with separately managed accounts, personal cell phones for voice communication, and physical meeting locations if needed.

The out-of-band communication plan should specify which platform will be used, who has accounts, how the platform is administered (it should not be managed through the same identity infrastructure as corporate systems), and how it will be tested. Testing is critical because an out-of-band channel that nobody has used before will cause confusion and delays when it is activated for the first time during an actual incident. The plan should also address how sensitive information shared through out-of-band channels will be preserved for the incident record while maintaining appropriate confidentiality.

Finally, the plan must clearly identify legal triggers: specific conditions that activate legal obligations. These include data breach notification thresholds under applicable state, federal, and international laws; cyber insurance notification requirements and timelines; contractual notification obligations to customers and partners; SEC disclosure requirements for public companies; and law enforcement referral criteria. For each trigger, the plan should specify the condition, the timeline, the responsible role, the required content, and the recipient. Legal triggers should be reviewed by qualified counsel at least annually, as regulatory requirements change frequently and failure to meet notification timelines creates significant liability.