Your first 24 hours after a breach: an incident response plan for SMBs

Most small businesses have a fire evacuation plan but no plan for a cyber incident — even though a breach is far more likely than a fire. When ransomware locks your files or an attacker is loose in your email, the worst moment to start deciding who to call and what to disconnect is while it is happening, under pressure, with the clock running. An incident response plan is simply a set of decisions made in advance, written down, so that when something goes wrong your team acts quickly and calmly instead of freezing. For an Israeli SMB it does not need to be a thick document — it needs to be clear, short, and actually rehearsed.

Why a Plan Matters More for Small Businesses

Large companies have dedicated security teams who handle incidents for a living. A small business usually has a few people wearing many hats, none of whom may have ever managed a breach. That makes the first hours chaotic precisely when speed matters most: the faster you contain an incident, the less data is stolen, the fewer systems are encrypted, and the lower the eventual cost. A plan compensates for not having a full-time security team by making the right first moves obvious to whoever is on hand. It also reduces panic-driven mistakes — like wiping a machine that holds the only evidence of how the attacker got in, or paying a ransom before exploring alternatives.

Detecting an Incident Early

You cannot respond to what you have not noticed, and the uncomfortable truth is that attackers often sit inside a network for days or weeks before they strike. The earlier you detect them, the less damage they can do — which is why detection belongs in any response plan, not just prevention. Train your team to treat the warning signs as worth reporting: unexpected password-reset emails, colleagues receiving odd messages supposedly from you, files suddenly renamed or inaccessible, accounts logging in at strange hours or from unfamiliar countries, and security software being disabled. Endpoint detection and response (EDR) tools surface much of this automatically and can alert you while there is still time to act. The businesses that come through incidents best are usually the ones that spotted something early and took it seriously rather than explaining it away.

The Phases of Incident Response

It helps to think of response in stages. Preparation is everything you do beforehand — the plan, the contacts, the backups, the training. Detection is recognising that something is wrong. Containment is stopping the spread: isolating affected machines so the damage does not grow. Eradication is removing the attacker's foothold — closing the entry point, resetting compromised credentials, cleaning infected systems. Recovery is restoring operations from clean backups and confirming the threat is gone. Finally, lessons learned is the review afterwards that stops the same thing happening again. A good plan walks your team through each of these in plain language, so nobody has to invent the process during the crisis.

The First Hour: Contain, Don't Panic

The instinct to immediately delete everything or rebuild a machine is understandable but often harmful. The priority in the first hour is containment: disconnect affected devices from the network — unplug the network cable or disable Wi-Fi — to stop ransomware or an attacker spreading to other systems, but do not switch the machine off, because powering down can destroy evidence needed to understand the attack. Resist the urge to start cleaning up. Instead, isolate, then escalate to whoever owns your incident plan. If credentials may be compromised, begin resetting passwords for affected accounts and revoking active sessions, starting with email and administrator accounts, which are the keys to everything else.

Who to Call: Your Contact List

A surprising amount of damage in the first hours comes simply from not knowing who to call. Your plan should contain a current contact list: your IT or managed security provider, key internal decision-makers, and where relevant your legal advisor and insurer. If you hold a cyber insurance policy, calling the insurer early matters — many policies require prompt notification and provide access to incident response specialists as part of the cover, and acting outside that process can jeopardise a claim. Keep this list somewhere reachable even if your systems are down — a printed copy or a phone note — because a contact list trapped inside the encrypted server is no use at all.

Legal and Regulatory Obligations in Israel

A breach is not only a technical event; it can carry legal duties. Under Israel's privacy regulations, a business that suffers a serious security incident affecting personal data may be required to notify the Privacy Protection Authority, and in some cases the affected individuals. Knowing in advance whether and when you must report — and who in your business is responsible for that decision — prevents a scramble at the worst possible time, and avoids the secondary damage of a regulatory failure on top of the breach itself. Your plan should name who assesses notification obligations and keep the relevant thresholds and contacts written down, so the legal response moves in parallel with the technical one.

Recovery: Where Backups Prove Their Worth

Recovery is the moment your backup strategy is tested for real. If you have isolated, tested, offline or immutable backups, you can rebuild from a clean point and refuse to depend on an attacker for your own data. If your backups were connected to the network, ransomware may have encrypted them too — which is why the time to verify backups is long before an incident, not during one. Recovery is also where patience pays: restoring onto systems that still contain the attacker's foothold simply re-infects you. Confirm the entry point is closed and compromised credentials are reset before you bring systems back, and bring them back in a deliberate order rather than all at once.

After the Incident: Learn and Improve

Once operations are restored, the temptation is to move on and never speak of it again. That wastes the most valuable thing a breach produces: a precise map of where your defenses failed. A short, blameless review should answer how the attacker got in, what allowed them to spread, how quickly you detected and contained it, and what would have made each step faster. The output is a concrete list of fixes — a missing MFA enforcement, an unpatched system, a backup that was not truly isolated, a gap in staff awareness. An incident that leads to those fixes makes you genuinely harder to hit next time; one that is quietly buried leaves you exposed to a repeat.

Keep the Plan Simple — and Practise It

An incident response plan that nobody has read is barely better than no plan at all. The most effective plans for small businesses are short enough to be useful under stress: a one-page summary of the first steps, the contact list, and where the backups are, backed by a little more detail behind it. Just as important is rehearsal. A simple tabletop exercise — talking through 'ransomware just locked the main server, what do we each do?' over an hour — surfaces gaps cheaply: a contact who has left, a backup nobody is sure works, an unclear decision-maker. Practising once or twice a year turns a document into genuine readiness.

Where to Start

If your business does not have a written incident response plan, the time to build one is now — calmly, before you need it. NetFortress helps Israeli SMBs prepare for and respond to security incidents: building a practical response plan, putting detection and tested backups in place, and standing alongside you with hands-on expertise if an incident does occur. Book a free consultation and we will help you put a clear plan in place, so that if the worst happens, your team knows exactly what to do in the first 24 hours.