IT Incident Response Plan: Complete Guide for SMBs (Template + Checklist)

Daniel Sarica

Published: December 3, 2025

A security incident handled correctly in the first hours costs you days of recovery. One handled chaotically costs weeks, sometimes months - plus penalties, reputation damage, and lost customers.

This guide gives SMBs a concrete plan: what to do, in what order, who is responsible, and how to communicate.

What is a security incident (and what isn’t)

Not every IT problem is a security incident. The difference matters because it determines who needs to be involved and what legal obligations you have.

It is a security incident:

Ransomware or malware active in the network
Unauthorized access to systems or data
A data leak (intentional or accidental)
Successful phishing (someone handed over credentials)
Unauthorized changes to systems or data
Downtime caused by an attack (DDoS, sabotage)

It is not a security incident:

A server down because of failed hardware
A software error or bug
A configuration problem affecting performance
A forgotten password

The distinction matters: a security incident can trigger legal reporting obligations - state breach notification laws, HIPAA if you handle health data, or your sector regulator’s rules. An ordinary technical problem does not.

If you are not sure which category the situation falls into, treat it as a security incident until you have evidence to the contrary.

Why the first 24 hours are critical

Three concrete reasons:

1. Evidence disappears fast. Logs in RAM are lost on restart. Temporary files get overwritten. Network connections close. Every hour that passes reduces your chances of understanding what happened and how.

2. Attackers move fast. In an active attack, the first hours are when the attacker tries to spread through the network, exfiltrate data, or install backdoors for later access. A slow response means more damage.

3. Legal deadlines don’t wait. Depending on your sector, the clock can be brutally short: financial firms regulated by NYDFS must notify the regulator within 72 hours, public companies must disclose material incidents within four business days, HIPAA sets a hard 60-day outer limit for breach notification, and some state breach laws require notice in as little as 30 days. The deadlines start running from the moment you become aware of the incident, not from the moment you finish the investigation.

The 5 steps in order

Before triggering the full plan, quickly verify that the situation is what it seems to be. An employee reporting “something weird” can mean anything from an active attack to a Windows update that changed the interface.

Clarifying questions:

What exactly did you notice? (concrete symptoms)
When did it start?
Is anyone else affected?
Did you do anything in the meantime? (restart, clicked links, etc.)

Time allocated for verification: 15-30 minutes maximum. If after the initial check the situation is still unclear or confirms an incident, move to the steps below.

Step 1: Isolate, don’t shut down

The instinct is to turn everything off. Resist it.

What you do:

Disconnect the affected equipment from the network (pull the cable or disable WiFi)
Do NOT shut it down, do NOT restart it
Isolate the affected network segment if possible
Keep systems running for forensic analysis

Why it matters: a restart destroys evidence in RAM that may be the only way to understand the attack vector.

Exception: if you can actively see data being encrypted or exfiltrated and have no other way to stop it, a forced shutdown can be justified. But it is the last resort, not the first option.

Step 2: Document everything

Start an incident log. Simple format - the form doesn’t matter, what matters is that it exists.

What you record:

The exact time of every observation and action
Who reported it and what they observed
Which equipment is affected (names, IPs, location)
What actions were taken and by whom
Screenshots of error messages, ransom notes, suspicious behavior

This log will be essential for: the technical investigation, reports to authorities, conversations with your insurer, and any legal proceedings.

Step 3: Establish who coordinates

Who needs to be involved:

The incident coordinator (a single person with decision-making authority)
The IT lead (in-house or external provider)
Management (CEO or equivalent)
Communications lead (if one exists)
Legal counsel (for major incidents)
Your security services provider (if you have a contract)

The essential rule: one person coordinates. Everyone else receives clear instructions and reports back to the coordinator. Without this structure, chaos is guaranteed.

Step 4: Assess before you communicate

Before communicating or reporting, you need to understand what happened. Not completely, but enough.

Key questions:

Which systems are affected?
What data was accessed/compromised/encrypted?
Is personal information involved? (this triggers state breach notification laws)
Is the attack still active, or has it been contained?
What is the operational impact? (what no longer works)
Are there unaffected backups?

The answers to these questions determine: what you report, who you notify, and what the recovery priority is.

Step 5: Report according to your legal obligations

If you are in a regulated sector:

Healthcare (HIPAA): notify affected individuals without unreasonable delay, no later than 60 days; breaches affecting 500+ people also go to HHS
Financial services: NYDFS-regulated firms notify the regulator within 72 hours; non-bank financial institutions under the FTC Safeguards Rule report breaches affecting 500+ consumers within 30 days
Public companies: disclose material incidents to the SEC on Form 8-K within four business days of determining materiality
Critical infrastructure: once CIRCIA reporting rules take effect, covered entities must report significant incidents to CISA within 72 hours - and ransom payments within 24 hours

Under state breach notification laws (if personal information is involved):

Deadline: varies by state - “without unreasonable delay” in most, hard deadlines as short as 30 days in some
To whom: affected residents and, in many states, the state attorney general
What you report: the nature of the breach, categories of data affected, approximate number of people, likely consequences, measures taken

To the affected individuals:

Required when their personal information is compromised (the exact trigger varies by state)
Without unjustified delay
Clear language, not legal jargon

How to report to the FBI and CISA: step-by-step instructions

For most private companies in the US, reporting a cyber incident to federal authorities is voluntary - but it is strongly recommended, and your insurer, your lawyer, and your enterprise customers will expect it. If you are in a regulated sector, the mandatory reports above come on top of this, not instead of it.

What you prepare beforehand:

Basic company details (legal name, location, industry)
Contact details for the person responsible for cybersecurity
A description of the incident (what happened, when, which systems)
A preliminary impact assessment
The measures taken up to the moment of reporting

The concrete steps:

File a report with the FBI’s Internet Crime Complaint Center at https://www.ic3.gov
For an active or significant incident, call your local FBI field office directly
Report the incident to CISA at https://www.cisa.gov/report or report@cisa.gov
If ransomware is involved, say so explicitly - the FBI sometimes holds decryption keys for known ransomware families

What follows after the initial report:

The FBI or CISA may follow up for technical indicators (logs, malware samples, attacker infrastructure)
Neither agency will fine you - they are not regulators; their role is to help you and to track the threat actors
The official record of your report is exactly what insurers, courts, and enterprise customers will ask for later

Important: the initial report does not need to be complete. Its purpose is to get the incident on record and get help moving. The details come in later updates. Don’t wait until you have all the answers to report - with wire fraud in particular, fast reporting is sometimes what makes it possible to freeze and recover the funds.

Who does what: the responsibility matrix

This matrix needs to be established before the incident, not during it.

CEO: Final decisions, approval of external communication, contact with authorities

Incident coordinator: Overall coordination, maintains the log, makes sure the steps are followed

IT lead: Technical isolation, investigation, system restoration

HR: Internal communication to employees

Legal counsel: Verifying legal obligations, drafting required notifications

Communications/Marketing: Messages to customers, press (if needed)

Internal communication template

Subject: IT security issue - what you need to know

Team,

We have identified a security issue affecting [describe generally - e.g., the file server / the email system / etc.].

What we are doing:

The IT team is working on resolving it
We have isolated the affected systems
We will send updates every [X hours]

What we ask you to do:

Do not access [the affected systems]
Do not discuss the situation with anyone outside the company
Report any suspicious behavior to [contact]
Continue normal work on the unaffected systems

What NOT to do:

Do not post on social media about this situation
Do not answer questions from the press (direct them to [contact])
Do not try to “fix” anything yourself

We will follow up with more information. Thank you for your understanding.

[Name, role]

External communication template (customers/partners)

Subject: Notice regarding a security incident

Dear partners,

We are writing to inform you that we have identified a security incident affecting [describe generally, without technical details].

What we have done:

We isolated the affected systems
We initiated an investigation with [external experts, if applicable]
We notified the competent authorities as required by applicable law

The impact on you: [Describe concretely - e.g., your data was not affected / the following categories of data may be involved: … ]

The measures we recommend: [If applicable - e.g., changing passwords, monitoring accounts, etc.]

Contact for questions: [Dedicated person, email, phone]

We apologize for any inconvenience and want to assure you that we are treating this situation with maximum seriousness.

[Official signature]

Mistakes that make the situation worse

1. Shutting everything down instead of isolating. You lose evidence and you don’t solve the problem.

2. Paying the ransom without consulting anyone. Beyond the fact that you are financing criminals, you have no guarantee you will get your data back - a significant share of companies that pay never receive a working decryption key. And if the payment goes to a sanctioned group, you can face OFAC penalties on top of everything else. Talk to your insurer, your lawyer, and the FBI first.

3. Communicating prematurely. Announcing “we’ve been attacked” before you know what happened creates panic and can be used against you.

4. Staying silent when you were required to communicate. If customer data is compromised and you don’t notify, you are breaking the law - and you lose trust permanently when it comes out.

5. Deleting the “evidence”. The instinct to “clean up” the systems destroys exactly the information needed for the investigation and for preventing a recurrence.

6. Investigating without expertise. If you don’t have IT forensics skills in-house, don’t improvise. Hire someone - or accept that you will never know exactly what happened.

How to prepare before it happens

An incident response plan does not guarantee you won’t be attacked. It guarantees you won’t lose precious time wondering what to do.

The necessary minimum:

A written document with the steps to follow (it can be one page)
An emergency contact list: IT provider, security firm, lawyer, insurer
The responsibility matrix - who coordinates, who decides what
Communication templates prepared in advance (internal and external)
Tested backups - it is not enough that they exist; you need to have verified that restoration works
An annual simulation - at least once a year, walk through the scenario without the pressure of a real incident

First 24 hours checklist

☐ Verify whether it is a real incident or an ordinary technical problem
☐ Isolate the affected equipment (no restart/shutdown)
☐ Start the incident log (time, observations, actions)
☐ Contact the designated incident coordinator
☐ Notify management
☐ Contact your IT provider / security firm
☐ Assess: which systems, what data, what impact
☐ Check whether personal information is involved (state breach notification laws)
☐ Check whether sector reporting rules apply to you (HIPAA, NYDFS, SEC, CIRCIA)
☐ Notify your cyber insurer - most policies require prompt notice
☐ Prepare reports to the FBI (IC3) and CISA, plus any regulator notifications with deadlines
☐ Prepare the internal communication
☐ Decide whether/when to communicate externally
☐ Document every decision and the reasons behind it

Additional resources

Conclusion

Security incidents cannot be prevented 100%. They are managed. The difference between a company that recovers quickly and one that loses months lies in preparation and in the execution of the first hours.

This document is a starting point. Adapt it to the structure and needs of your company.

If you need help implementing an incident response plan or preparing your team, contact us.