Business Incident Response: A Starter Guide

Most small and mid-sized businesses don't have a dedicated security team, which makes "incident response" sound like something only large companies need. In practice, the businesses most likely to be hurt badly by an incident are the ones with no plan at all — and a basic plan doesn't require a large budget.

Before anything happens: the preparation checklist

• Know your critical systems. If email, payment processing, or your primary database went down right now, what would actually stop working? You can't protect what you haven't identified.
• Maintain backups that are actually isolated from your main network — offline, versioned, or otherwise unreachable if your primary systems are compromised — and periodically test that they restore correctly.
• Write down who gets called, in order, with current contact information: internal decision-makers, legal counsel, cyber insurance (if you have it), and any outside incident response help.
• Know your disclosure obligations in advance — what you're legally required to report, to whom, and within what timeframe, varies by industry and by what data was involved.

The first hour of an actual incident

1. Don't panic-fix. The instinct to immediately wipe, reinstall, or "clean up" a compromised system destroys the evidence needed to understand what happened — and risks missing that the attacker still has access elsewhere.
2. Contain, don't necessarily shut down everything. Isolating an affected system from the network is usually more useful than a full shutdown, which can also destroy evidence in memory.
3. Start a timeline immediately. What was first noticed, when, by whom — write it down as it happens rather than reconstructing it later from memory.
4. Loop in the right people early, per your pre-written contact list — waiting until you're certain of the full scope before notifying anyone usually costs more time than it saves.
5. Preserve before you investigate. If you're not sure whether something should be touched, don't touch it until someone who does know has weighed in.

Common early mistakes

• Assuming the incident is contained because the obvious symptom stopped — attackers who had time to establish persistence often leave more than one way back in.
• Communicating internally over the same channel that may be compromised (e.g., discussing a suspected email compromise over email).
• Treating the first ransom note or alert as the start of the incident, when it's frequently the end of a much longer unnoticed intrusion.

After the immediate response

A short post-incident review — what was missed, what worked, what the plan didn't account for — is what actually improves your position for next time. Skipping this step is the most common reason similar incidents recur.

If you're building this from nothing, GhostTrace's Incident Documentation service can help structure both the preparation and, if needed, the actual response.