How to Build a Cybersecurity Incident Response Plan for Your Business

The first question most businesses ask after a security incident is: "What do we do now?" The second question is usually: "Why don't we have a plan for this?" These questions should not be asked at the same time.

A cybersecurity incident response plan is the document that answers the "what do we do now" question before you need to ask it. Having a plan does not prevent incidents. It determines the difference between an incident that is contained in hours and one that compounds over days, costs ten times as much, and becomes a public breach notification.

What an Incident Response Plan Needs to Cover

Effective incident response plans are operational documents, not policy statements. They tell specific people what to do, in what order, using which tools, in the first hours after a suspected incident.

The elements:

Incident classification. Not every security alert is the same severity. A plan that treats a phishing email opened by one employee the same as active ransomware encryption is not useful. Define severity levels (P1 through P3 or similar) and the response protocols for each.

Roles and responsibilities. Who is the incident commander for a P1 incident? Who is the technical lead? Who handles external communications? Who has authority to take systems offline? Who calls the lawyers? Every role should have a named primary and a named backup, because incidents do not wait for the primary to be available.

Detection and triage. How does an incident become known? What are the first responder steps to confirm whether something is an incident and to classify its severity?

Containment procedures. What specific steps are taken to stop the spread of an incident? Isolating affected systems, revoking compromised credentials, blocking attacker IP ranges, taking services offline temporarily.

Eradication and recovery. How do you remove the threat from your environment and restore normal operations? In what order do you restore systems? How do you confirm the threat is fully removed before restoring?

Communication protocols. Who is notified at what point in the incident? Internal (leadership, board, relevant teams), external (customers, regulators, law enforcement, press). Regulatory notifications have strict timelines — 72 hours under GDPR, for example.

Evidence preservation. How do you preserve the forensic evidence needed to understand what happened, where it came from, and what was accessed — without destroying that evidence by the way you respond?

Post-incident review. What is the process for reviewing what happened, why, what worked in the response, and what needs to change?

Step 1: Define What an Incident Is

The first thing your plan needs is a shared definition of what constitutes a security incident, so people know when to activate the plan rather than hoping someone else handles it.

An incident is any event that compromises or is suspected to compromise the confidentiality, integrity, or availability of your systems or data. This includes:

• Confirmed or suspected unauthorised access to systems or data
• Malware detected on any device
• Ransomware encryption of any files
• Unusual login activity from unknown locations or at unusual times
• Data exfiltration alerts
• A colleague receiving convincing phishing emails that appear to come from a trusted source
• A vendor notifying you that they have experienced a breach that may involve your data

Anything that could be in this list should trigger at least triage, even if it does not ultimately result in a full incident response activation.

Step 2: Build Your Severity Matrix

Define severity levels based on business impact. A practical three-level model:

P1 (Critical): Active compromise with confirmed or suspected data access or data exfiltration. Ransomware active in the environment. Production systems unavailable due to a security incident. Incident commander must be notified immediately, response team activated within 30 minutes.

P2 (Serious): Malware detected and contained to one system. Compromised credentials with no confirmed access to sensitive data. Phishing attack that captured credentials for internal systems. Response within 2 hours, investigation within same business day.

P3 (Minor): Phishing email opened but no credentials entered. Single user account locked due to failed authentication attempts. Suspicious but unconfirmed activity. Investigation within 24-48 hours during business hours.

Step 3: Map Your Contact List

Your incident response plan is only as useful as the contact information in it, and that contact information must be accessible when your systems are potentially compromised.

Your contact list should be printed and stored offline (not only in systems that might be offline during an incident) and should include:

• All members of your incident response team with mobile numbers and personal email addresses
• Your hosting provider's emergency support line
• Your cyber insurance provider's claims line
• Your legal counsel or outside privacy counsel
• A cybersecurity incident response firm (either retained or identified in advance — having a retainer agreement means you get priority service during a breach)
• Relevant regulatory bodies (ICO for UK, relevant EU supervisory authority, sector-specific regulators)
• Your bank's fraud line if financial accounts could be involved

Step 4: Document Your Containment Playbooks

General principles are not enough in the first hours of an incident. You need specific, step-by-step containment procedures for the most likely incident types.

Ransomware containment:

1. Immediately disconnect affected devices from the network — pull the ethernet cable or disable wi-fi, do not power down
2. Do not try to decrypt, delete, or otherwise interact with encrypted files
3. Identify the scope of encryption — what file servers, cloud storage, or databases are affected
4. Activate the incident response team and engage external expertise
5. Preserve the ransom note and any indicators of compromise for forensic analysis
6. Do not pay the ransom without legal and insurance consultation

Credential compromise:

1. Identify what systems the compromised credentials had access to
2. Immediately revoke and reset the compromised credentials
3. Review access logs for the compromised account for the past 30 days
4. Identify any sessions still active and terminate them
5. Check for any changes made using the compromised credentials (email rules created, data exported, new accounts created)
6. Determine whether MFA was in place and bypassed — if so, escalate severity

Data exfiltration:

1. Identify the mechanism of exfiltration (email, API, file upload, database export)
2. Block the exfiltration mechanism immediately
3. Determine the scope of data exfiltrated (what data, how much, what time period)
4. Assess regulatory notification obligations based on data type and jurisdiction
5. Preserve logs and evidence before taking remediation steps that would overwrite them

Step 5: Define Your Communication Plan

What you say, to whom, and when during a security incident has legal, regulatory, and reputational implications. Define this in advance.

Internal communications: Use out-of-band channels (personal mobile, personal email) if internal systems may be compromised. Do not communicate incident details over potentially compromised channels.

Customer notifications: If customer data was affected, define when and how you will notify customers. Legal counsel should approve the language. A premature notification containing inaccurate information is worse than a slightly delayed notification containing confirmed facts.

Regulatory notifications: Under GDPR, 72 hours from awareness. Under various sector-specific regulations (financial services, health information), timelines vary. Know your obligations before an incident occurs.

Press: Do not communicate to media without legal counsel involved. A single spokesperson should be designated in advance. "No comment" is sometimes the correct short-term response until you understand the full scope.

Step 6: Maintain and Test the Plan

A plan that has never been tested is a plan you do not know will work.

Run a tabletop exercise — a facilitated discussion where your incident response team walks through a simulated incident scenario — at least annually. The exercise reveals gaps in the plan, conflicting assumptions about who does what, and steps that look clear on paper but are ambiguous in practice.

Test specific components separately: confirm that the offline contact list is current, test that your backup restoration procedure actually works, confirm that you can actually isolate a system without taking down other critical services.

The cybersecurity for small business guide covers the proactive controls that reduce the frequency of incidents you need to respond to. The penetration testing guide covers how to identify vulnerabilities before attackers do. Both are relevant to building a complete security programme around your incident response capability.

Building or reviewing your incident response plan is the kind of work where an outside perspective from people who have responded to real incidents is genuinely valuable. Our cybersecurity team works with businesses on exactly this. Contact us to discuss your current preparedness and what gaps need to be addressed.