How to Build a Security Incident Response Plan (Without a Full Security Team)

TLDR: An incident response plan (IRP) tells your team exactly what to do when an attack hits — before panic sets in. You don't need a dedicated security team to have one. This guide gives you a practical framework you can implement in a week.

Imagine this: It's Tuesday morning. Your office manager calls — half the company can't log in. Someone from accounting says they received a weird email yesterday and "clicked something." Your IT person is on vacation.

What do you do?

If your answer is "figure it out as we go" — you're not alone. 73% of SMBs have no formal incident response plan, according to the Ponemon Institute. And that's exactly why the average breach costs an SMB $149,000 — not because the attack was sophisticated, but because the response was chaotic.

A plan won't stop every attack. But it cuts your response time, reduces damage, and — critically — keeps you on the right side of NIS2 compliance, which requires documented incident response procedures for covered entities.

What Is an Incident Response Plan?

An incident response plan is a documented set of procedures that defines:

Who is responsible for what during a security incident
How to detect and classify incidents
What steps to take to contain and recover
When and how to notify authorities and affected parties

Think of it like a fire evacuation plan. You hope you never use it. But when the alarm goes off, you're not stopping to discuss who should call the fire department.

The 6 Phases of Incident Response

The industry-standard framework (NIST SP 800-61) breaks incident response into six phases. Here's what each means in practice for an SMB:

Phase 1: Preparation

Before anything happens — this is the work you do now.

Identify your critical assets (customer data, financial records, production systems)
Define your incident response team — even if it's just 3 people
Set up monitoring and alerting (more on this below)
Create communication templates for customers, regulators, and press
Establish relationships with external support (IT vendor, legal, insurance)

The most common mistake: Skipping this phase entirely and jumping straight to Phase 3 during an actual incident.

Phase 2: Detection & Analysis

How do you know something is wrong?

This is where most SMBs fail silently. Without visibility into your systems, you're relying on users to notice something feels "off" — which typically means you find out about a breach weeks or months later.

Signs you may be under attack:

Unusual login times or locations (employee logs in at 3am from Romania)
Mass email sending from internal accounts
Sudden file encryption or access denied errors
Unusual outbound network traffic
Antivirus alerts that keep recurring

A SIEM system like SNYFT automatically flags these patterns and sends alerts, so you don't need someone staring at logs 24/7. Detection time is everything — the longer an attacker dwells in your network, the worse the damage.

Phase 3: Containment

Stop the bleeding.

Short-term containment: Isolate affected systems immediately. Disconnect from the network, don't turn off (you may destroy forensic evidence). This is a decision that needs to happen in minutes, not hours.

Long-term containment: Identify the attack vector. Was it a phishing email? A compromised VPN credential? An unpatched server? You need to close the door the attacker came through before you start cleaning up.

Critical: Do NOT wipe systems or restore from backup before documenting the incident. You'll need evidence for insurance claims, regulatory reporting, and forensics.

Phase 4: Eradication

Remove the threat completely.

Remove malware, backdoors, and unauthorized accounts
Patch the vulnerability that was exploited
Reset all potentially compromised credentials
Verify no persistence mechanisms remain (ransomware gangs often leave backdoors)

This phase requires careful work. Rushing it leads to reinfection — a common and demoralizing mistake.

Phase 5: Recovery

Restore to normal operations — carefully.

Restore systems from clean, verified backups
Monitor closely for 30-90 days after recovery (attackers often wait and re-enter)
Bring systems back online gradually, not all at once
Verify business continuity at each step

The hard question: When were your last clean backups taken? Are they tested? Many companies discover their backups were also compromised — or simply don't restore correctly — only during an actual incident.

Phase 6: Post-Incident Review

Learn from it.

Within two weeks of recovery, conduct a blameless post-mortem:

What happened, and when?
What did we detect, and how?
What did we miss, and why?
What would we do differently?
What changes are needed in our plan?

This is not about assigning blame. It's about making your next incident (and there will be one) less damaging.

Building Your Incident Response Team

You don't need dedicated security staff. You need defined roles.

| Role | Responsibility | Who This Might Be | |---|---|---| | Incident Commander | Overall coordination, decisions | CEO, CTO, or IT Manager | | Technical Lead | Containment, forensics, recovery | IT admin or external IT vendor | | Communications Lead | Notifying customers, regulators, press | HR/Legal or Office Manager | | Legal/Compliance | Regulatory obligations, insurance | External lawyer or compliance officer |

Key principle: The Incident Commander should NOT be the same person doing the technical work. Effective incident response requires clear separation between "doing" and "deciding."

For very small businesses (5-20 employees), one person may cover multiple roles — but make sure these are documented and agreed upon in advance.

The Notification Problem: Who Do You Have to Tell?

Under NIS2 (if you're a covered entity), notification is mandatory and time-sensitive:

24 hours: Initial notification to NÚKIB (early warning)
72 hours: Detailed incident notification with technical information
30 days: Final report with full analysis and remediation

Under GDPR (if personal data was affected):

72 hours: Report to ÚOOÚ (Czech data protection authority)
Without undue delay: Notify affected individuals if there's high risk to their rights

Missing these deadlines carries significant penalties — up to CZK 250 million for NIS2 violations.

This is why your Communications Lead role matters. Someone needs to own this task and know the timelines before an incident happens.

Practical tip: Pre-draft your notification templates. In a crisis, you don't want to be writing regulatory communications from scratch.

What Does a Realistic Incident Look Like?

Scenario: Business Email Compromise (BEC)

A Czech logistics company (85 employees) receives a call from their supplier — an invoice for €42,000 went unpaid. Their accounting team had received a legitimate-looking email from what appeared to be the supplier's CFO, requesting payment to a "new bank account."

Without an IRP:

3 days to figure out what happened
Money already transferred and unrecoverable
No documentation for police or insurance
Panic about what else might be compromised
No idea if they need to notify NÚKIB under NIS2

With an IRP:

Accounting flags the unusual payment request immediately (trained to do so)
Incident Commander activated within 1 hour
Technical Lead reviews email headers and logs — confirms spoofed sender
Bank contacted immediately (same-day transaction recall attempted)
Legal reviews NIS2/GDPR notification requirements
Full incident documented for insurance claim
Post-mortem leads to mandatory supplier payment verification process

The money may still be lost. But the chaos — and the regulatory risk — is dramatically reduced.

Your Minimum Viable IRP: A Template

If you're starting from zero, here's what your first incident response plan needs to cover. This doesn't need to be a 50-page document. A 5-page plan that people actually read and follow beats a 50-page one gathering digital dust.

Section 1: Purpose and Scope

What does this plan cover? (all IT systems, specific data types)
Who does it apply to? (all employees, contractors)

Section 2: Incident Classification

Define severity levels so teams know how urgently to respond:

| Level | Description | Response Time | |---|---|---| | Critical | Active attack, data breach, ransomware | Immediate (minutes) | | High | Compromised account, malware detected | Same day | | Medium | Phishing email clicked, suspicious activity | Within 24 hours | | Low | Policy violation, weak password found | Within 1 week |

Section 3: Response Team Contacts

Names, roles, phone numbers, backup contacts
External vendors (IT support, legal, cyber insurance)
Regulatory contacts (NÚKIB hotline: +420 541 110 777)

Section 4: Step-by-Step Response Procedures

Per incident type (ransomware, BEC, data breach, account compromise). Keep these short — 5-10 bullet points per scenario.

Section 5: Notification Requirements

Internal escalation
NÚKIB (NIS2)
ÚOOÚ (GDPR)
Customers
Insurance
Law enforcement

Section 6: Evidence Preservation

Do not turn off infected systems
Take screenshots/photos
Preserve logs (your SIEM should do this automatically)
Document timeline of events

Section 7: Communication Templates

Internal announcement to employees
Customer notification
Regulatory notification (initial and final)
Press statement (if needed)

How SNYFT Fits Into Your IRP

A plan without visibility is just paperwork.

Your IRP assumes you'll detect incidents quickly. Without security monitoring, you're dependent on users self-reporting problems — typically after significant damage has already occurred.

SNYFT provides the detection layer that makes your IRP actually work:

Automated alerting when suspicious activity is detected (unusual logins, mass email sending, known malware signatures)
Centralized log storage that preserves evidence automatically — critical for insurance claims and regulatory reporting
Audit trail for every event, accessible during forensic investigation
Pre-built detection rules covering the most common SMB attack patterns (BEC, ransomware, credential stuffing)

When an incident occurs, your Incident Commander can immediately open SNYFT to see exactly what happened, when, and from where — instead of asking "does anyone have any logs?"

SNYFT covers NIS2 Article 21(2)(j): the requirement for security monitoring and logging — one of 14 mandatory technical measures.

Your 30-Day IRP Quick-Start Plan

You don't need to build a perfect plan. You need a usable plan, fast.

Week 1: Foundation

[ ] Define your incident response team (even if it's 2-3 people)
[ ] List your critical assets and data
[ ] Verify you have backups — and test restoring at least one
[ ] Set up basic security monitoring if you don't have it

Week 2: Build the Plan

[ ] Write your incident classification table
[ ] Document step-by-step procedures for your 3 most likely scenarios (ransomware, phishing, account compromise)
[ ] Confirm your cyber insurance coverage and claims process
[ ] Find your regulatory notification contacts (NÚKIB, ÚOOÚ)

Week 3: Communication Templates

[ ] Draft employee internal alert template
[ ] Draft customer notification template
[ ] Draft NÚKIB 24-hour initial notification template
[ ] Review with legal counsel

Week 4: Test and Validate

[ ] Run a tabletop exercise (30-minute "what would we do if..." discussion)
[ ] Verify everyone knows their role
[ ] Schedule a plan review every 6 months

Frequently Asked Questions

Q: "We're too small for a formal IRP — isn't this overkill?"

A: If you have customer data, employee records, or financial systems, you're a target. Size doesn't determine attractiveness to attackers — opportunity does. A Czech SMB with 30 employees is easier to compromise than a large enterprise with a full security team. A 5-page plan is not overkill. It's minimum viable security.

Q: "We have cyber insurance — doesn't that cover us?"

A: Insurance covers financial losses, not the operational chaos of an incident. More importantly: most cyber insurance policies now require you to have documented security procedures — including an IRP — to be eligible for coverage. Check your policy. Many companies discover this requirement only when filing a claim.

Q: "Who should we call first when an incident happens?"

A: Your Incident Commander. They coordinate everything else. If you don't have one designated in advance, you'll waste critical hours figuring out who's in charge. Designate someone now, not during an incident.

Q: "Do we really need to notify NÚKIB? What if the incident is minor?"

A: Under NIS2, the notification threshold is any incident with "significant impact on the provision of services." This is broader than it sounds — when in doubt, notify. The penalty for failing to notify is far higher than the cost of an unnecessary report. NÚKIB would rather receive an unnecessary notification than a delayed one.

Q: "Can SNYFT replace a security team?"

A: No — and we won't claim it can. SNYFT gives you visibility and automated detection that a security team would use. It surfaces the signals. But your IRP and your team make the decisions and execute the response. Think of SNYFT as your always-on monitoring layer that feeds your IRP, not a replacement for human judgment.

The Bottom Line

Building an incident response plan is not a massive project. It's a week of focused work, a few conversations, and some documentation.

The alternative — figuring it out during an active attack — costs ten times as much in time, money, and damage.

If you're a covered entity under NIS2, documented incident response procedures aren't optional. But even if you're not, it's one of the highest-ROI security investments you can make.

Start with what you have. Document what you'd do. Test it once. Improve it after.

Ready to add the detection layer to your IRP? See how SNYFT handles security monitoring →

About the author: Daniel Paučo is the founder of SNYFT, a cloud-native SIEM platform built for European SMBs. Previously in enterprise security architecture, he started SNYFT after seeing too many small businesses face serious incidents with no visibility into what was happening. Connect on LinkedIn →