How to Create a Cybersecurity Incident Response Plan

Why Every Business Needs an Incident Response Plan

It’s not a question of if your business will face a cybersecurity incident—it’s when. Even companies with strong defenses experience security events. The difference between a minor disruption and a catastrophic breach often comes down to one thing: whether you had a plan in place before it happened.

A cybersecurity incident response plan (IRP) is a documented set of procedures that tells your team exactly what to do when a security event occurs. It eliminates the confusion, panic, and costly mistakes that happen when people are forced to improvise under pressure.

This guide walks you through building an IRP using the widely adopted six-phase framework, including who should be involved, what templates you need, and how to test the plan so it actually works when you need it.

The Six-Phase Incident Response Framework

The National Institute of Standards and Technology (NIST) and the SANS Institute both recommend a structured approach to incident response. The six-phase framework below draws on both and is practical enough for a business of any size.

Phase 1: Preparation

Preparation is everything you do before an incident occurs. This is the most important phase because it determines how effectively you can execute the other five.

During preparation, you:

• Assemble your incident response team (more on this below)
• Document your critical assets: What systems, data, and applications are essential to your business operations? If your email goes down, how long can you function? What about your ERP, your CRM, your file server?
• Establish communication channels: How will the team communicate during an incident? If email is compromised, do you have an alternative? Consider an out-of-band communication method like a dedicated messaging group on personal phones.
• Set up monitoring and detection tools: You can’t respond to what you can’t see. Endpoint detection and response (EDR), security information and event management (SIEM), and network monitoring tools give you visibility into threats.
• Create and maintain backups: Tested, offline or immutable backups are your safety net. Verify that you can actually restore from them—regularly.
• Develop relationships with external resources: Identify a cybersecurity incident response provider, legal counsel with breach experience, and your cyber insurance carrier’s claims process before you need them.
• Train your staff: Everyone in the organization should know the basics—how to recognize a potential incident and who to contact. Your response team needs deeper training and regular practice.

Phase 2: Identification

Identification is the process of detecting that a security event has occurred, determining its scope, and classifying its severity.

Not every alert is an incident. Your team needs clear criteria for what constitutes a security event versus a false alarm. Define severity levels:

• Low: Suspicious activity that needs investigation but hasn’t resulted in confirmed compromise (e.g., a single failed phishing attempt)
• Medium: Confirmed security event with limited impact (e.g., a single compromised user account with MFA preventing further access)
• High: Active breach affecting multiple systems or sensitive data (e.g., ransomware spreading across the network)
• Critical: Business operations are significantly disrupted or sensitive data has been exfiltrated (e.g., confirmed data theft, widespread encryption)

Key activities during identification:

• Gather and preserve evidence (logs, screenshots, affected system details)
• Determine what systems, data, and users are affected
• Document the timeline: When did the event start? When was it detected? What’s the gap?
• Assign a severity level based on your predefined criteria
• Notify the incident response team based on the severity level

Phase 3: Containment

Once you’ve confirmed an incident, the immediate priority is stopping it from getting worse. Containment has two components:

Short-term containment: Immediate actions to limit the damage. This might include disconnecting affected machines from the network, disabling compromised user accounts, blocking malicious IP addresses, or isolating affected network segments. The goal is to stop the spread without destroying evidence.

Long-term containment: Temporary measures that let you continue operating while you work on full remediation. This could mean rebuilding affected systems on a clean network segment, applying emergency patches, or routing traffic through additional monitoring. Long-term containment buys you time to do eradication properly.

Critical rule: document every action taken during containment. What was done, when, by whom, and why. This record is essential for the investigation, for insurance claims, and for legal proceedings.

Phase 4: Eradication

Eradication means removing the threat from your environment entirely. This is where you eliminate the root cause—not just the symptoms.

Eradication activities include:

• Removing malware from all affected systems
• Closing the vulnerability or access point the attacker used to get in
• Resetting compromised credentials (all of them, not just the ones you know about)
• Scanning the entire environment to confirm no backdoors or persistence mechanisms remain
• Reviewing account creation logs—attackers often create new accounts to maintain access

Don’t rush this phase. Incomplete eradication is the number-one reason organizations get reinfected. If the attacker left a backdoor you didn’t find, they’ll be back—sometimes within hours.

Phase 5: Recovery

Recovery is the process of restoring normal business operations. This includes:

• Restoring systems from clean backups
• Rebuilding compromised machines from known-good images
• Gradually bringing systems back online with increased monitoring
• Verifying that restored systems are functioning correctly and are free of compromise
• Monitoring closely for signs of reinfection or continued attacker activity

Recovery should be phased. Don’t bring everything back online at once. Start with the most critical systems, verify they’re clean, monitor them closely, then move to the next tier. Increased monitoring should continue for weeks or months after the incident—attackers sometimes wait and try again once they think you’ve let your guard down.

Phase 6: Lessons Learned

This is the phase most organizations skip, and it’s arguably the most valuable. Within two weeks of resolving the incident, hold a formal lessons-learned meeting with everyone involved in the response.

The meeting should answer:

• What happened, and what was the root cause?
• When did the incident start, and when did we detect it? Can we close that gap?
• What worked well in our response?
• What didn’t work? Where did we scramble, hesitate, or make mistakes?
• Were our tools and processes adequate?
• What specific changes will we make to prevent this type of incident in the future?

Document the findings and update your incident response plan accordingly. Every incident is an opportunity to strengthen your defenses. Don’t waste it.

Who Should Be on the Incident Response Team

An incident response team isn’t just IT people. A complete team includes:

• Incident Response Lead: The person who coordinates the response and makes decisions. This is typically your IT director, CISO, or your managed security provider’s designated lead.
• IT/Security Staff: The technical team performing investigation, containment, eradication, and recovery.
• Executive Sponsor: A C-level leader (CEO, COO, or CFO) with authority to make business decisions during the incident—like approving emergency spending, authorizing system shutdowns, or deciding on public communication.
• Legal Counsel: An attorney experienced in data breach law. They’ll advise on notification requirements, regulatory obligations, and communications that may be subject to legal discovery.
• Communications Lead: Someone responsible for internal and external messaging. This could be your marketing director, PR contact, or an executive. Inconsistent or delayed communication during a breach erodes trust fast.
• HR Representative: Needed if the incident involves an insider threat, employee negligence, or if the response requires staff to work unusual hours.
• External Partners: Your managed security provider, cyber insurance carrier, and forensic investigators if needed. Have their contact information—including emergency after-hours numbers—documented and accessible.

Every team member should know their role before an incident happens. Print contact cards. Store them somewhere accessible even if your network is down—a physical binder in the office and a document on personal phones.

Communication Templates You Should Prepare Now

During an incident, you won’t have time to craft careful messages from scratch. Prepare templates for:

• Internal notification to staff: A brief message telling employees there’s a security event, what they should and shouldn’t do, and who to contact with questions. Keep it simple and avoid technical jargon.
• Executive briefing: A structured update for leadership covering what happened, current status, business impact, actions taken, and next steps.
• Customer/partner notification: Required by law in many states and industries if personal data is compromised. Legal counsel should review this template. It should be factual, transparent, and include what you’re doing to protect affected individuals.
• Law enforcement report: The FBI’s IC3 (Internet Crime Complaint Center) and your local FBI field office. Have their contact information ready and a template for the initial report.
• Insurance carrier notification: Most cyber insurance policies require notification within a specific timeframe (often 24-72 hours). Know your policy’s requirements and have the claims line ready.

Testing Your Plan

An untested plan is barely better than no plan at all. Test yours regularly using these methods:

Tabletop Exercises

Gather your response team and walk through a realistic scenario. “It’s Tuesday at 3 PM. An employee reports they can’t open their files. IT discovers ransomware on the network. Walk me through what happens next.” Each team member describes their actions. You identify gaps, confusion, and bottlenecks without any real risk. Run tabletop exercises at least twice a year.

Technical Drills

Test specific technical capabilities: Can you actually restore from your backups? How long does it take? Can your team isolate a network segment quickly? Do your detection tools alert the right people? These hands-on drills verify that your tools and processes work as expected.

Full Simulations

For mature organizations, conduct a full simulation where a simulated attack is executed against your environment (by your security provider, with appropriate controls). This tests everything—detection, response, communication, and recovery—under realistic conditions.

Common Mistakes to Avoid

• No plan at all: Improvising during a breach is the most expensive approach.
• Plan exists but nobody’s read it: A plan gathering dust in a SharePoint folder doesn’t help anyone.
• No external contacts documented: Scrambling to find a forensic investigator’s phone number during an active breach wastes critical time.
• Skipping the lessons-learned phase: You’ll face the same problems again.
• Over-reliance on technology: Tools detect threats, but people respond to them. Your team needs training and practice.

Start Building Your Plan Today

A cybersecurity incident response plan isn’t a luxury—it’s a necessity. The businesses that recover quickly from security events are the ones that prepared for them. The ones that suffer the most are the ones that assumed it wouldn’t happen to them.

You don’t have to build this plan alone. Schedule a free assessment with BrightWorks IT. We’ll evaluate your current readiness, help you build or refine your incident response plan, and make sure your team knows how to execute it when it counts.