Incident Response Plan: Phases, Roles and How to Write One

An incident response plan is a written, approved document that tells your organization exactly who does what when a cybersecurity incident happens, from the first alert to the final lessons learned meeting. A good plan covers the phases of response, names the people and decision makers, sets communication rules, and lists the legal and regulatory reporting deadlines you may face.

This article is general information, not legal advice.

Key takeaways

• NIST SP 800-61 Rev. 3, finalized in April 2025, ties incident response to the six functions of the NIST Cybersecurity Framework (CSF) 2.0 and replaces the older Rev. 2 handling guide.
• The classic four phases (preparation, detection and analysis, containment/eradication/recovery, and post-incident activity) still work as a practical outline for your written plan.
• Response is a business effort, not only an IT task: legal, communications, HR, leadership and outside providers all need defined roles.
• Public companies may have to file a Form 8-K within four business days of deciding an incident is material, and every U.S. state has a breach notification law.
• Tabletop exercises are the cheapest way to find gaps in your plan before a real attacker finds them.

What is an incident response plan?

An incident response plan is the playbook your organization follows to detect, contain, recover from and learn from a cybersecurity incident. It turns a stressful, confusing event into a set of known steps, owners and decisions.

NIST defines a cybersecurity incident as an occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity or availability of information or an information system, or that violates law or security policy. That definition matters because it sets the bar for when your plan activates. A single blocked phishing email is an event; a compromised administrator account is an incident.

The plan sits inside a wider set of documents. An incident response policy sets management commitment, scope and authority. The plan explains how the program runs. Playbooks give step-by-step actions for specific scenarios, such as ransomware or a stolen laptop. Your plan should also connect to your business continuity work and your disaster recovery plan with its RTO and RPO targets, because restoring systems after an attack uses the same backups and priorities.

What are the phases of incident response?

The phases are preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. NIST's current guidance reorganizes these around the CSF 2.0 functions, but the classic phases remain a useful way to structure your plan.

The NIST SP 800-61 Rev. 3 model

According to the NIST incident response project page, SP 800-61 Rev. 3 is built on CSF 2.0, the Cybersecurity Framework that groups security outcomes into six functions: Govern, Identify, Protect, Detect, Respond and Recover. The model has three levels:

• Preparation: Govern, Identify and Protect. These are broader risk management activities that support response.
• Incident response: Detect, Respond and Recover. This is the active work during an incident.
• Improvement: a continuous improvement category within Identify, fed by lessons learned from every function.

The practical message is that incident response is not a separate binder on a shelf. It depends on the controls you run every day, such as identity and access management and a zero trust architecture that limits how far an attacker can move.

How the classic phases map to CSF 2.0

Classic phase	Closest CSF 2.0 functions	What happens
Preparation	Govern, Identify, Protect	Policy, roles, tools, logging, training, contracts with outside responders
Detection and analysis	Detect	Spot alerts, confirm an incident, judge scope and severity
Containment, eradication and recovery	Respond, Recover	Isolate systems, remove the attacker, restore clean operations
Post-incident activity	Identify (improvement)	Lessons learned meeting, after-action report, plan updates

Who should be on the incident response team?

Your team should include security responders plus leadership, legal, communications, HR and the technology owners of affected systems. NIST stresses that each role needs clear authority before an incident, not during one.

NIST SP 800-61 Rev. 3 describes these roles:

• Leadership: oversees response, funds it and makes high-impact calls, such as shutting down a critical service.
• Incident handlers: verify incidents, analyze evidence, prioritize work, limit damage and restore operations. They can be staff, contractors or on-call providers.
• Technology professionals: architects, engineers, administrators and developers who carry out fixes.
• Legal: reviews plans and contracts and advises on incidents with legal implications, including notification duties.
• Public affairs and communications: handles media and public statements, ideally from a prepared strategy.
• Human resources: supports onboarding and offboarding and gets involved when an employee may have caused an incident.
• Physical security and facilities: handles physical breaches and gives responders building access.
• Asset owners: set recovery priorities for their business systems.
• Third parties: managed security providers, cloud providers and internet service providers, whose duties should be written into contracts.

The FTC's data breach response guide adds forensic investigators to the list and recommends legal counsel with privacy and data security experience. If you buy cyber coverage, check whether your insurer requires you to use specific firms; our guide to cyber insurance for small businesses covers what to ask.

HR deserves special attention. Insider incidents, compromised employee accounts and leaked personnel records all pull HR into the response, and HR systems often hold the most sensitive data you have. Agree in advance how HR and IT will share access during an investigation without exposing confidential HR files to more people than necessary.

What should a written incident response plan include?

A written plan should include scope, definitions, roles and authority, severity levels, communication rules, response procedures, reporting obligations and a review schedule. NIST notes that plans should be tailored to your size, structure and requirements.

Use this order to draft or audit your plan:

1. Purpose, scope and authority. State which systems, business units and data the plan covers and who approved it.
2. Definitions. Define event, incident, breach and "material" in plain terms so people classify issues the same way.
3. Roles and contacts. List the incident commander, deputies and every function above, with phone numbers that work if email is down.
4. Severity levels and escalation. Set three or four levels with clear triggers, such as "customer data confirmed exposed" or "payroll system offline."
5. Response procedures and playbooks. Cover your most likely scenarios: ransomware, business email compromise, lost devices, cloud account takeover, insider misuse and vendor breaches. Include unusual risks you track, such as preinstalled Android backdoors on company phones.
6. Evidence handling. Explain how to preserve logs and images. The FTC advises taking affected systems offline but leaving machines powered on until forensic experts arrive.
7. Communications plan. Pre-approve holding statements for employees, customers, investors and partners, and name who can speak publicly.
8. Reporting obligations. Map every regulator, contract and law that could require notice, with deadlines and owners.
9. Third-party coordination. List retainers with forensic firms, outside counsel and key vendors, and include the systems in your shadow IT governance inventory so nothing is missed.
10. Testing and maintenance. Set a schedule for exercises and plan reviews, plus triggers for out-of-cycle updates.

Keep the plan short enough to use under pressure, and keep an offline copy.

How do tabletop exercises test your plan?

A tabletop exercise is a discussion-based session where your team walks through a realistic scenario and talks through each decision. It tests the plan, the people and the communication paths without touching production systems.

You do not need to build scenarios from scratch. The CISA Tabletop Exercise Package (CTEP) provides pre-built templates and vetted scenarios that organizations can combine to design their own exercises. CISA describes them as a way to test and update information sharing, emergency plans and related policies.

To get the most from a tabletop:

• Invite executives, legal, communications and HR, not only the security team.
• Inject surprises, such as a reporter calling or the backup server also being encrypted.
• Force real decisions: who approves taking the website offline, and who decides whether an incident is material?
• Capture gaps in an after-action report and assign each fix an owner and a date.

NIST recommends exercising procedures periodically to confirm they are accurate and to train new staff.

What reporting obligations should your plan cover?

Your plan should cover SEC rules if you are a public company, state breach notification laws if personal data is involved, sector rules such as HIPAA, and the upcoming CIRCIA requirements for critical infrastructure. Your legal team should confirm which apply to you.

SEC Form 8-K Item 1.05

Under rules the SEC adopted on July 26, 2023, public companies must disclose a cybersecurity incident they determine to be material on Form 8-K Item 1.05. The filing is generally due four business days after the company determines the incident is material. It must describe the material aspects of the incident's nature, scope and timing, and its material or reasonably likely material impact. Disclosure can be delayed only if the U.S. Attorney General determines immediate disclosure poses a substantial risk to national security or public safety and notifies the SEC in writing. Companies also describe their cybersecurity risk management and board oversight annually under Regulation S-K Item 106.

State breach notification laws

The FTC notes that all 50 states, the District of Columbia, Puerto Rico and the U.S. Virgin Islands have laws requiring notice of security breaches involving personal information. Deadlines and content rules differ, so keep a state-by-state summary with your plan. The FTC also points to the HIPAA Breach Notification Rule and its own Health Breach Notification Rule for health data, and advises reporting to law enforcement promptly.

CIRCIA

The Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) will require covered entities to report covered cyber incidents to CISA within 72 hours of reasonably believing one occurred, and to report ransom payments within 24 hours. CISA states these requirements take effect only when its final rule does. Until then, CISA encourages voluntary reporting. If you operate in a critical infrastructure sector, build these deadlines into your plan now so you are ready when the rule lands.

Obligation	Who it applies to	Timing
SEC Form 8-K Item 1.05	SEC registrants (public companies)	Generally four business days after determining materiality
State breach notification laws	Organizations holding residents' personal information	Varies by state
CIRCIA incident report	Covered critical infrastructure entities	72 hours, once the final rule takes effect
CIRCIA ransom payment report	Covered critical infrastructure entities	24 hours, once the final rule takes effect

Common mistakes in incident response planning

• Writing the plan for IT only. If legal, communications and HR first see the plan during an attack, decisions stall.
• No decision owner for materiality. Public companies lose time debating who decides, while the four-day clock waits to start and pressure builds.
• Storing the plan only on the network. Ransomware can lock the file share that holds your contacts and procedures.
• Wiping systems too fast. Rebuilding before preserving evidence can destroy what you need to find the root cause and meet reporting duties.
• Ignoring vendors. Many incidents start at a supplier. Contracts should define notice duties and cooperation, as covered in our guide to third-party risk management.
• Never updating the plan. Staff, systems and laws change, and stale contact lists fail when you need them.

Frequently asked questions

How often should you update an incident response plan?

Review it at least once a year and after every significant incident, exercise, reorganization or major system change. NIST recommends periodic reviews and updates whenever significant improvements are needed.

Is an incident response plan the same as a disaster recovery plan?

No. An incident response plan handles security incidents from detection to lessons learned, while a disaster recovery plan focuses on restoring systems and data after any disruption. The two should reference each other and share recovery priorities.

Do small businesses need a formal incident response plan?

Yes, though it can be short. Even a few pages naming who to call, how to isolate systems, which outside firms to contact and which notification laws apply will save time and reduce harm.

What is the difference between a plan and a playbook?

The plan describes the overall program: roles, authority, severity levels and reporting. A playbook gives step-by-step actions for one scenario, such as ransomware or a compromised email account.

What to do next

Start by finding your current plan, if one exists, and checking it against the ten elements listed above. Confirm who holds authority to declare an incident and to decide materiality. Ask legal counsel to map your notification obligations by state, sector and regulator. Then schedule a tabletop exercise within the next quarter using a CISA scenario, invite your leadership team, and turn the gaps you find into dated action items. Repeat the cycle every year.

Sources

• NIST CSRC: Incident Response project (SP 800-61 Rev. 3 and CSF 2.0)
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• SEC: SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure
• CISA: Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA)
• CISA: Tabletop Exercise Package (CTEP)
• FTC: Data Breach Response, A Guide for Business

Last reviewed: November 2026.