Incident Response Planning: What to Do Before a Breach Happens

Why You Need an Incident Response Plan Before the Incident

The worst time to figure out who to call, what to shut down, and what to say publicly is while your systems are encrypted and your customers are calling. An incident response plan for your business is the document that answers those questions before the pressure hits — so your team can execute under stress instead of improvise.

Most growing companies do not have one. They assume their IT team will figure it out, or that it will not happen to them. Both assumptions are wrong. Incidents happen to companies of every size, and the organizations that recover fastest are the ones that planned their response in advance.

An incident response plan does not need to be a hundred-page document. It needs to be clear, actionable, and tested. Here is how to build one.

The Six Phases of Incident Response

Effective incident response follows a structured lifecycle. Each phase has specific objectives and actions.

1. Preparation

This is everything you do before an incident occurs. Preparation includes:

• Documenting the plan itself. Roles, responsibilities, contact lists, procedures, and decision trees.
• Establishing the incident response team. Identify who is on the team and what each person is responsible for. Include IT, legal, communications, and executive leadership.
• Pre-engaging external resources. Identify and establish relationships with forensics firms, legal counsel specializing in data breaches, public relations support, and your cyber insurance carrier’s incident response hotline. Having contracts in place before an incident eliminates delays when time matters most.
• Deploying detection capabilities. Endpoint detection and response tools, log monitoring, and alerting systems that give you the ability to identify incidents quickly.
• Training the team. Everyone on the incident response team needs to know the plan and their role in it. Annual tabletop exercises test the plan and identify gaps.

2. Identification

Detection is the trigger. When something abnormal is identified — a security alert, unusual network activity, a report from an employee, or notification from a third party — the identification phase determines whether it is a real incident and how severe it is.

Key actions during identification:

• Gather initial evidence without modifying or destroying data
• Classify the incident by type (ransomware, data breach, business email compromise, insider threat, denial of service)
• Assess initial scope — what systems, data, and users appear affected
• Assign a severity level that triggers the appropriate response procedures
• Notify the incident response team lead

Speed matters here. The average time between initial compromise and detection is measured in weeks, not hours. The longer an attacker has access, the more damage they do. Investing in detection capabilities during the preparation phase directly reduces this window.

3. Containment

Once an incident is confirmed, containment limits the damage. There are two stages:

Short-term containment stops the immediate bleeding. Actions may include:

• Isolating affected systems from the network
• Blocking malicious IP addresses or domains
• Disabling compromised user accounts
• Preserving forensic evidence before making changes

Long-term containment stabilizes the environment while you prepare for full remediation. This may involve:

• Building clean systems to replace compromised ones
• Applying temporary fixes that allow limited operations to continue
• Enhancing monitoring on potentially affected systems
• Implementing additional access controls

The key principle: contain the incident without destroying the evidence you need to understand what happened. Rushing to wipe and rebuild systems before forensic analysis is complete can mean you miss the root cause — and the attacker gets back in.

4. Eradication

With the incident contained, eradication removes the threat from your environment completely. This includes:

• Removing malware, backdoors, and unauthorized access mechanisms
• Patching the vulnerabilities that were exploited
• Resetting credentials for all potentially compromised accounts
• Verifying that no persistence mechanisms remain

Eradication must be thorough. Attackers commonly establish multiple access points so they can return if one is discovered. A forensic investigation identifies all points of compromise, not just the obvious ones.

5. Recovery

Recovery restores normal operations. This phase requires careful planning to avoid reintroducing the threat:

• Restore systems from clean backups (verified as uncompromised)
• Rebuild systems that cannot be cleaned with confidence
• Monitor restored systems closely for signs of reinfection
• Gradually return to normal operations with enhanced monitoring
• Verify data integrity before resuming business processes

Recovery is not flipping a switch. It is a staged process where you bring systems back online methodically, validate each one, and confirm that normal operations can resume safely.

6. Post-Incident Review

After the incident is resolved, conduct a thorough review. This is the step most organizations skip — and it is one of the most valuable.

The post-incident review should answer:

• What happened, and what was the root cause?
• How was the incident detected, and could it have been detected sooner?
• Did the incident response plan work? Where did it break down?
• What changes are needed to prevent a similar incident?
• What improvements should be made to the response process?

Document the findings and update the incident response plan accordingly. Every incident is a learning opportunity. Organizations that skip the review are likely to repeat the same mistakes.

What Your Incident Response Plan Document Should Include

Keep the plan concise and actionable. It should include:

• Incident response team roster with names, roles, and contact information (work, personal, and after-hours). Include alternates for each role.
• Escalation procedures with clear criteria for when to escalate to executive leadership, legal counsel, and external resources.
• Communication templates for internal notifications, customer communications, regulatory notifications, and media statements. Drafting these under pressure leads to mistakes.
• External resource contact list including forensics firms, legal counsel, insurance carrier hotline, law enforcement contacts, and regulatory reporting portals.
• Technical procedures for common incident types — isolation procedures, evidence preservation steps, and system recovery processes.
• Decision authority matrix documenting who can authorize system shutdowns, ransom payments, public communications, and regulatory notifications.
• Regulatory requirements with timelines for mandatory breach notifications by jurisdiction and industry.

Store the plan where the team can access it during an incident. If the plan lives only on a server that gets encrypted by ransomware, it is useless when you need it most. Maintain copies offline and ensure the incident response team knows where to find them.

Testing the Plan: Tabletop Exercises

A plan that has never been tested is a plan that will fail under pressure. Tabletop exercises are the most practical way to test incident response for growing companies.

A tabletop exercise walks the incident response team through a realistic scenario. The facilitator presents the scenario in stages, and the team discusses what they would do at each point. No systems are actually affected — it is a discussion-based exercise.

Effective tabletop exercises:

• Use scenarios relevant to your business (ransomware targeting your industry, business email compromise using your vendors, data breach involving your customer data)
• Include all members of the incident response team, including non-technical participants
• Test communication procedures and decision-making, not just technical response
• Identify gaps in the plan, unclear responsibilities, and missing resources
• Result in specific action items to improve the plan

Run tabletop exercises at least twice a year. Vary the scenarios. Include executives in at least one exercise annually so they understand their role and the decisions they may need to make.

Building the Plan When You Do Not Have a Security Team

Most growing companies do not have a dedicated security team to build and maintain an incident response plan. The plan still needs to exist. The reality is that incident response planning requires experience — specifically, experience with how incidents actually unfold, what goes wrong, and what decisions matter most.

A cybersecurity engagement can deliver a tested incident response plan tailored to your business, your systems, and your regulatory requirements. A fractional CIO provides ongoing oversight to keep the plan current, run tabletop exercises, and ensure your team is prepared when an incident occurs.

The cost of building an incident response plan is negligible compared to the cost of responding to a breach without one. Companies that plan their response in advance contain incidents faster, lose less money, and recover more quickly. The companies that do not plan pay the premium in chaos, delays, and avoidable damage.

Build the plan now. Test it regularly. Update it as your business changes. When the incident comes — and it will — your preparation determines the outcome.