Home › Blog › Incident Response Plan
Incident Response June 3, 2026 · 7 min read

How to Create an Incident Response Plan (Step-by-Step)

When a security incident hits, the last thing you want is your team figuring out the process in real time. An Incident Response Plan tells everyone exactly what to do, in what order, and who's responsible, before the chaos starts.

What Is an Incident Response Plan?

An Incident Response Plan (IRP) is a documented, step-by-step process your organization follows when a security incident occurs. That includes ransomware attacks, data breaches, phishing compromises, insider threats, DDoS attacks, and any other event that threatens your systems or data.

The goal isn't just to recover, it's to recover faster, limit damage, preserve evidence, and meet notification obligations. A well-tested IRP can be the difference between a bad week and a business-ending event.

The hard truth: Most organizations don't discover they need an IRP until they're in the middle of an incident. By then, every minute without a plan costs time, money, and data.

The 6 Phases of Incident Response

The NIST incident response framework (SP 800-61) defines six phases that your IRP should follow:

Phase 1

Preparation

Build your response capability before an incident happens. Define roles, assemble your response team, set up logging and monitoring, and make sure this document exists and people know where it is.

Phase 2

Detection & Analysis

Identify that an incident has occurred. Define what triggers a response (alert thresholds, user reports, vendor notifications), how to triage severity, and who gets notified first.

Phase 3

Containment

Stop the bleeding. Short-term containment (isolate affected systems) and long-term containment (patching, blocking, credential resets) happen here. Document everything as evidence.

Phase 4

Eradication

Remove the threat. Delete malware, close vulnerabilities, eliminate unauthorized access. Verify the environment is clean before moving to recovery.

Phase 5

Recovery

Restore systems to normal operation. Validate functionality, monitor for reinfection, and define what "back to normal" actually means with specific criteria.

Phase 6

Post-Incident Activity

The lessons learned phase. Document what happened, what worked, what didn't, and what needs to change. Update the IRP based on what you learned.

What Your IRP Must Include

Roles and Responsibilities

Every IRP needs a named Incident Response Team with defined roles, Incident Commander, Technical Lead, Communications Lead, Legal/Compliance contact, and Executive Sponsor at minimum. People need to know their job before the incident, not during it.

Severity Classification

Not every incident is a five-alarm fire. Define severity levels (Critical, High, Medium, Low) with clear criteria for each. This determines response speed, escalation paths, and notification requirements.

Communication Templates

Pre-write your communications. Internal notifications, customer breach notifications, regulatory notices, and press statements should all have templates ready. Under stress, people say the wrong things, templates prevent that.

Notification Obligations

Know your legal requirements before you need them. GDPR requires breach notification within 72 hours. Most US state laws require notification within 30–90 days. HIPAA has its own timeline. Your IRP should spell out exactly who gets notified, when, and how.

Evidence Preservation

Define how to collect and preserve forensic evidence during an incident. This matters both for investigation and potential legal proceedings. Log retention policies, chain of custody procedures, and forensic tools should all be documented.

Contact List

Include a current contact list for your response team, your cyber insurance provider, legal counsel, law enforcement contacts (FBI IC3, local field office), and any external forensics vendors you have on retainer.

Common IRP Mistakes

How Long Does It Take to Write?

A thorough IRP written from scratch takes 8–15 hours, researching requirements, drafting the document, getting legal review, and getting sign-off from leadership. Starting from a professionally written template cuts that to 1–2 hours of customization.

Don't wait until an incident to start writing.

Our Incident Response Plan template covers all 6 NIST phases, includes pre-written communication templates, severity classification criteria, and a full contact sheet. Fill in the blanks and you're ready.

Browse Templates at SecReadyNow →

Final Thoughts

The value of an Incident Response Plan isn't measured in the incidents you handle smoothly, it's measured in the ones that don't spiral out of control. Even a basic, well-practiced IRP dramatically reduces damage, recovery time, and the likelihood of regulatory penalties.

Start simple. Get the core phases documented, define your team, write your notification templates. You can refine over time. The worst IRP is the one that doesn't exist yet.

📬

Get CMMC tips and template updates

No spam. Just practical guidance on CMMC compliance and new resources when we publish them.

Frequently Asked Questions

NIST SP 800-61 Rev 2 defines four phases: (1) Preparation, establishing policies, procedures, communication plans, and tools before an incident; (2) Detection and Analysis, identifying and characterizing the incident; (3) Containment, Eradication, and Recovery, stopping the spread, removing the threat, and restoring operations; and (4) Post-Incident Activity, conducting a lessons-learned review and updating documentation. NIST emphasizes these phases are iterative, not strictly sequential.
Multiple regulations require documented incident response capabilities. HIPAA (45 CFR § 164.308(a)(6)) requires covered entities to implement incident response procedures. DFARS 252.204-7012 requires DoD contractors to report cyber incidents within 72 hours. The FTC Safeguards Rule (16 CFR § 314.4(h)) requires qualifying financial businesses to have an incident response plan. CMMC Level 2 Practice 3.6.1 explicitly requires an operational incident-handling capability and must be evidenced during assessment.
Under DFARS 252.204-7012(c), contractors must report cyber incidents on covered systems to DoD via the DIBNet portal (dibnet.dod.mil) within 72 hours of discovery. The report must include the company's CAGE code, relevant contract numbers, description of the technique used, a description of CUI involved, and forensic indicators. System images must be preserved for at least 90 days and made available to DoD upon request.
NIST SP 800-61 recommends defining IRT roles even for small organizations, with individuals playing multiple roles. At minimum: an incident commander (decision authority), a technical lead (investigation and containment), a communications coordinator (notifications and regulatory reporting), and an executive sponsor (authority for major business decisions). Small organizations can supplement with a third-party IR retainer service to fill gaps during an active incident.
NIST SP 800-86 and DFARS 252.204-7012(e) both require preserving forensic evidence from affected systems. Best practice includes: full disk images of compromised systems before remediation, memory captures where possible, network flow logs, authentication logs, and any malware samples. Under DFARS, these must be preserved for at least 90 days and made available to DoD upon request. Premature remediation that destroys evidence can create contractual liability and undermine insurance claims.