The First 24 Hours: What to Do Immediately After a Breach

If your systems are compromised right now, stop reading and act: isolate the affected machines from the network, then call your incident response provider’s emergency line. DYOPATH’s is staffed 24/7 at 1-866-609-PATH. Everything below still applies — read it while you wait for a callback, or hand it to whoever’s driving the response. Below is the full playbook for the first 24 hours after a breach, hour by hour.

Key Takeaways

• The first 60 minutes decide how much worse this gets. Isolate affected systems from the network — don’t panic-shutdown everything, and don’t do nothing while you figure out what happened.
• Don’t wipe, reimage, or “just fix it” before evidence is preserved. You may need those logs for your insurer, law enforcement, and your own legal defense weeks from now.
• Legal counsel and your cyber insurance carrier usually get called before customers do, in that order — some policies require it, and counsel affects what you can say publicly.
• Employees hear it from you first, in plain language, before they hear it from a headline or a customer.
• Recovery starts once containment is confirmed, not before. Restoring systems too early, before you’ve closed the door the attacker used, is how the same incident happens twice in one week.
• This is a general framework, not a substitute for your own incident response plan or legal counsel. Every breach is different, and regulatory notification timelines vary by state and industry.

Minute 0–60: Contain It

The instinct is to fix everything at once. Resist it. Your only job in the first hour is to stop the bleeding without destroying evidence you’ll need later.

Pull the network cable, or disable Wi-Fi, on any machine you know or suspect is compromised. Isolating a system is almost always better than shutting it off completely — powering a machine down erases the data in its memory, and that memory is often exactly what a forensic investigator needs to figure out how the attacker got in and where else they went. If a machine is actively encrypting files and you genuinely can’t isolate it fast enough any other way, powering it off is still better than watching it spread. But isolate first when you can.

Change passwords on accounts you know were involved, starting with anything with admin rights. If you use multi-factor authentication, don’t disable it to “make troubleshooting easier” — that’s exactly what an attacker wants. Lock down remote access tools (RDP, VPN, any remote desktop software) if you’re not certain they’re clean.

Don’t announce anything company-wide yet. A vague “we’re having IT issues” message that leaks before you understand the scope tends to cause more confusion than it prevents.

Hour 1–4: Preserve the Evidence

Before anyone touches a keyboard to “clean up,” document what’s in front of you. Take photos of ransom notes, error messages, or anything on-screen with a phone camera — screenshots can be altered later, questioned, or simply lost if the machine reboots. Note exact timestamps: when you first noticed something wrong, and when each action after that happened.

If you have logging in place — firewall logs, endpoint detection, server logs — don’t let anyone clear or overwrite them. This is also the point where system images and forensic copies matter more than a quick restore. NIST’s Computer Security Incident Handling Guide, SP 800-61 lays out the standard for this kind of evidence handling, including chain-of-custody basics that matter if this ever becomes a legal or insurance question — worth a read if you don’t already have an internal playbook.

This is also when most organizations realize they need outside help. If you don’t have a forensics team on retainer, this is the moment to call one — trying to run a full forensic investigation with an internal IT team that’s never done one before usually costs more time than it saves.

Hour 4–12: Make the Calls

Three calls matter most in this window, and the order matters: legal counsel, your cyber insurance carrier, and then your incident response provider if you haven’t already engaged one.

Counsel first, because attorney-client privilege can affect what gets written down and how, and because notification laws vary significantly by state and by what kind of data was involved — health records, financial data, and general PII often carry different clocks and different regulators. Your insurer second, because most cyber policies require notification within a specific window (often 24 to 72 hours) and may require you to use their approved vendors for forensics or negotiation — call after you’ve engaged your own provider and you could find the costs aren’t covered.

Depending on what happened, you may also need to report to federal authorities. CISA’s incident response resources outline what’s reportable and to whom — the FBI’s Internet Crime Complaint Center (IC3) and CISA itself both take reports, and involvement from law enforcement is sometimes an added protection, not a complication, particularly with ransomware.

Don’t skip this step because you’re worried about how it looks. Regulators and insurers generally respond far worse to a late or hidden notification than to a prompt, honest one.

Hour 12–24: Communicate, Carefully

Now you tell people — internally first, then externally if warranted, with legal input on the wording of anything that leaves the building.

For employees, a short, factual message beats silence or speculation: what you know, what you’re doing about it, and what they should (and shouldn’t) do in the meantime — don’t click unfamiliar links, don’t discuss it on social media, report anything unusual immediately. Don’t promise “no data was affected” or “this won’t happen again” before you actually know that. Those sentences tend to age badly, and they’re the kind of statement that gets quoted back at you later.

If customers or partners need to be notified, that message usually goes through legal review before it goes anywhere, and it’s fine for it to be short. A factual holding statement — we detected an incident, we’re investigating, here’s how to reach us with questions — buys time to get the details right without leaving people in the dark.

Your board or leadership team should get a real update, not a summary that makes things sound more settled than they are. This is also the point where a written timeline of decisions starts to matter — for the board, for your insurer, and for whoever eventually asks “who knew what, and when.”

Beyond 24 Hours: Recover, Don’t Rush

Once containment is confirmed — not assumed, confirmed — recovery can start. Restore from clean backups where possible, watch closely for signs of reinfection, and patch whatever vulnerability let the attacker in before you consider the incident closed. A system that gets restored and reconnected before the entry point is fixed is often compromised again within days.

This is also when the real remediation work happens: rotating every credential the attacker may have touched, reviewing what data actually left the network (not just what you assume left), and closing the gaps a forensic review turns up. Expect this phase to run days to weeks, not hours — anyone who tells you a serious incident wraps up by end of day is either dealing with something small or skipping steps.

Once things are stable, do the step most companies skip: a lessons-learned review. What let the attacker in. How long it took to notice. Where the response plan held up and where it didn’t. This is the last phase in most formal incident handling frameworks for a reason — skip it, and the same gap tends to get exploited again, sometimes within the same year.

What Not to Do in the First 24 Hours After a Breach

A few habits show up again and again in the worst outcomes:

• Don’t pay a ransomware demand as a first move. Talk to counsel, your insurer, and law enforcement first — payment doesn’t guarantee you get usable data back, and it can carry its own legal exposure depending on who’s on the other end.
• Don’t post about it publicly before legal review, even internally in a company Slack that “isn’t really public.” Screenshots travel.
• Don’t let one person quietly fix it and move on without documenting what they did. That well-meaning IT admin who reimages a server at 2 a.m. to “get us back up” may be erasing the only evidence of how the attacker got in.
• Don’t assume it’s over because the visible symptoms stopped. Attackers who’ve been inside a network for a while often leave more than one way back in.

When You’ve Been Through This Before

Organizations that have a written incident response plan before something happens move through these hours noticeably faster and calmer than those improvising for the first time — not because the situation is any less serious, but because nobody’s arguing about who calls the insurer while the clock runs. If you don’t have a plan yet, CISA’s Incident Response Plan Basics factsheet is a reasonable starting point for building one, and that’s worth doing before the next incident, not during it.

DYOPATH’s incident response team works these hours for clients every week — containing active incidents, coordinating with law enforcement and insurance, and getting operations back to normal without cutting corners that cause a repeat. If you’re in the middle of something right now, the team is reachable 24/7 at 1-866-609-PATH. If you’re reading this to get ahead of the next one, DYOPATH’s incident response services page covers what that ongoing readiness looks like.