Cybersecurity Incident Response Plan Template

A cyber incident is the wrong time to decide who can shut down access, call a vendor, speak to customers, or authorize recovery. The pressure is real, the facts are incomplete, and a well-meaning shortcut can make a difficult situation much worse. A usable incident response plan gives people a calm starting point before the situation becomes urgent.

This template is designed for organizations that need a practical first version, not a binder full of generic language. It follows the core idea in NIST’s current incident response guidance: response works best when it is connected to ongoing risk management, recovery planning, leadership decisions, and lessons learned. Adapt it to your environment, have counsel review notification obligations, and test it with the people who would actually use it.

Start with the decisions people need to make

An incident response plan is not a list of technical commands. It is a decision guide. Before writing procedures, identify the business services that cannot be unavailable for long, the information that needs special protection, the vendors who may need to act quickly, and the people authorized to accept disruption in order to contain a threat.

CISA describes an incident response plan as a leadership-approved document that clarifies roles, responsibilities, and key actions before, during, and after a suspected or confirmed incident. Its Incident Response Plan Basics makes an important point: the plan should be a living document. A contact list that belongs to former employees or a recovery procedure for a system you no longer use will not help when it matters.

Cybersecurity incident response plan template

1. Purpose, scope, and approval

Purpose: This plan guides the organization’s response to suspected or confirmed cybersecurity incidents that could affect systems, information, customers, employees, vendors, or operations.

Scope: List the systems, locations, cloud services, devices, accounts, and third parties covered. Include remote staff, managed service providers, critical applications, backups, and communication tools. If a vendor holds your data or controls your access, it belongs in the plan.

Approval and review: Name the executive who approves the plan, the owner who keeps it current, the secure location where it is stored, and the next review date. Keep an offline copy with the most important contacts and authorities in case email or file sharing is unavailable.

2. Roles and decision authority

For each role, write a primary name, backup name, phone number, and out-of-band contact method. One person can cover more than one role in a smaller organization, but the responsibility should never be vague.

• Executive sponsor: accepts major operational, financial, and customer-impact decisions.
• Incident coordinator: runs the response, maintains the timeline, assigns actions, and keeps decisions visible.
• Technology lead: investigates, contains, preserves evidence, and coordinates recovery with staff and providers.
• Business operations lead: identifies priorities, service impact, workarounds, and recovery order.
• Legal and communications lead: advises on notification, insurance, customer, regulator, and public communications.

State who can disable an account, isolate a device, take a service offline, engage outside responders, approve emergency spending, or restore a system. Without that clarity, teams lose time seeking approval or, just as risky, act beyond their authority.

3. Incident declaration and first-hour checklist

Define the events that activate the plan. Examples include suspected ransomware, unusual administrator activity, confirmed account takeover, exposed sensitive information, a lost device with protected data, a material vendor incident, or an outage that may be caused by malicious activity. A report does not need to be perfect before it is escalated. It needs to reach the right person quickly.

In the first hour, record who reported the issue, when it was noticed, the systems and people involved, what has already changed, and the evidence available. Preserve logs, screenshots, alert details, emails, and relevant device information. Avoid casually rebooting, deleting, or altering a potentially affected system before the technology lead decides what must be retained.

First-hour handoff: give the incident coordinator one short, timestamped record of the report, affected services, containment decisions, evidence location, responsible people, and the time of the next update. That record keeps the response aligned when new facts arrive and different teams need to act quickly.

Copy-and-use incident record

Keep this short record with the plan so the coordinator can create one reliable handoff while information is still changing. It is a practical starting point, not a substitute for legal, insurance, or regulatory advice.

• Incident: Record the date and time, who reported it, what was observed, and the systems, accounts, locations, vendors, or people that may be affected.
• Business impact: Name the services at risk, the immediate operational consequence, the current workaround, and the business owner who can set recovery priority.
• Containment: Note each action, its time, the person who approved it, the disruption it may cause, and the evidence or recovery option it could affect.
• Evidence: List the logs, screenshots, alert details, emails, device details, and case numbers collected, plus the protected location where they are stored.
• Decisions and updates: Record the current incident lead, next update time, approved audience, vendor or insurer contacts, and any decision that still needs an owner.
• Recovery: State what must be true before a service returns, who validates the result, and who accepts the return to normal operation.

A completed record gives leadership, technical responders, and outside partners the same facts to work from. After the incident, it becomes the basis for the review, corrective actions, and next tabletop exercise.

Contain without destroying the evidence you need

Containment stops the incident from becoming larger. It might mean disabling an account, revoking sessions, isolating a device, blocking a malicious domain, restricting vendor access, or pausing a risky integration. The correct action depends on the incident, so write the authority and the trigger into the plan rather than pretending there is one universal command.

Ask three questions before taking a major action: What risk does this stop now? What business service will it interrupt? What evidence or recovery option could it affect? That short pause helps the team choose a controlled action instead of an automatic one. It also creates a useful record for leadership, customers, insurers, or regulators later.

Identity incidents deserve special attention because one compromised account can reach email, cloud files, financial tools, remote access, and administrator consoles. The guide to multi-factor authentication for business explains how stronger sign-in controls reduce the chance that a stolen password becomes a larger event.

Write communications before you need them

Your plan should identify the internal update channel, a fallback if normal collaboration tools are unavailable, who speaks to employees, who works with vendors, and who approves external statements. Keep the early message simple: what is known, what the team is doing, what people should avoid doing, and when they can expect the next update.

Do not promise a cause, scope, or recovery time before it is verified. If the incident could involve personal, regulated, or contractual information, bring counsel and the relevant insurance contact into the process early. Notification requirements depend on the facts and the organization, so the plan should assign that decision rather than guessing.

Recover in a deliberate order

Recovery is more than turning systems back on. Before restoring, confirm that the entry point has been addressed, credentials have been reset where appropriate, affected devices are understood, and backups are usable. Then restore according to business priority. Payroll, customer service, line-of-business software, communications, and file access may have different urgency for each organization.

Document the criteria that make a service safe to restore. For example: the affected account is disabled or re-secured, the device is rebuilt or validated, relevant monitoring is active, the application owner approves a functional check, and the business owner accepts the restoration. This avoids a fast but fragile return to operations. The companion IT disaster recovery plan template helps teams document the recovery targets, dependencies, and testing behind that decision.

Close the loop after the immediate pressure passes

Within a reasonable window after recovery, hold a short review. Capture the timeline, decisions, business impact, what worked, what delayed the response, and the safeguards or process changes that need an owner. This is not a blame session. It is where an organization turns a difficult event, or a near miss, into a stronger operating routine.

Update the plan, contact list, vendor details, and related playbooks. Then schedule a tabletop exercise with a realistic scenario such as a fraudulent sign-in, a ransomware alert, or a compromised social account. The practical steps in Rebnetik’s guide to protecting business social media from hijacking are a useful reminder that high-visibility accounts need the same defined ownership and escalation path as core technology.