Nobody is ready the first time it happens. No matter how many tabletops you’ve run, how detailed your playbook is, or how experienced your team is, the first 24 hours of a breach feel different than anything you’ve prepared for.
I’ve been through it. What I can tell you is that the textbook version and the reality don’t match.
The First 24 Hours of a Breach Start With Confusion
The first indication is rarely clear. You don’t get an alert that says “breach in progress.” You get something ambiguous.
A strange login from a location that might be a VPN. An endpoint behaving oddly. A vendor calling to ask why your server is scanning their network. A report from an employee that something feels off.
The first 24 hours of a breach almost always begin with someone asking: Is this actually something?
That question takes longer to answer than you’d expect. And while you’re answering it, the clock is already running.
Triage Is Messier Than the Playbook Suggests
Your incident response plan probably has a nice flowchart. Detect, contain, eradicate, recover. Neat boxes with arrows.
Reality is messier.
You’re trying to figure out what happened while it might still be happening. You’re pulling people off other work. You’re making calls about what to shut down and what to leave running for forensic value. You’re arguing about whether to kill a server that’s critical to operations.
And you’re doing all of this with incomplete information, because the attacker knows more about what they did than you do.
The first few hours are about establishing basic facts. What systems are affected? How did they get in? Are they still in? What data could they have accessed?
You won’t have complete answers for most of these. You have to act anyway.
Communication Becomes the Hardest Part
Technical response is actually the easier half. The harder half is communication.
Within hours, you’re fielding questions from executives who want to know how bad it is. Legal wants to know about notification obligations. PR wants to know what to say if it leaks. HR wants to know if an employee was involved. The board wants a briefing.
Everyone wants certainty. You don’t have any yet.
The first 24 hours of a breach force you to say “I don’t know” repeatedly while still projecting that the situation is under control. That’s a difficult balance.
I’ve learned to give updates on a fixed schedule rather than when asked. It reduces the interruptions and sets expectations. Even if the update is “no significant change, still investigating,” it’s better than silence.
The Team Dynamic Changes
Stress reveals things about your team you didn’t know.
Some people step up. They work calmly, communicate clearly, and make good decisions under pressure. Others freeze, panic, or disappear into rabbit holes that don’t matter.
You’ll also find out quickly whether your relationships with other departments are solid. Legal, PR, IT, HR — if you haven’t built trust with those teams before the incident, you’re going to struggle during it.
The first 24 hours are not the time to introduce yourself to the general counsel. This is one of the reasons building relationships before you need them is essential to surviving the CISO role.
Decisions Get Made With Bad Information
You will make decisions during a breach that you later question. That’s unavoidable.
Do you take systems offline and halt business operations, or keep them running and risk further damage? Do you notify law enforcement now or wait until you understand what happened? Do you tell customers before you have complete information?
Every choice has tradeoffs. You rarely have time to fully evaluate them.
What matters is documenting why you made each decision with the information you had at the time. If you’re later asked to justify your actions — by regulators, by lawyers, by the board — that documentation is your defense.
Outside Help Takes Time to Spin Up
If you’re calling a forensics firm or incident response retainer, know that they’re not walking in the door in an hour.
Even with a retainer in place, there’s scoping, contracting, and logistics. They need access to your environment. They need context on your architecture. They need to coordinate with your team without stepping on the investigation.
Budget a few hours minimum before outside help is actually contributing. In a serious incident, it might be the next day before they’re fully engaged.
This is why relationships with IR firms matter before you need them. A cold call during an active breach is the worst time to start that conversation. CISA’s incident response resources can help organizations prepare before an incident occurs.
The Log Problem
You’ll wish you had better logging. Everyone does.
The questions that matter during a breach — what did the attacker access, how long were they in, what did they take — depend on logs that may not exist or may not be retained long enough.
The first 24 hours often include a scramble to preserve whatever logging you do have before it rotates out. And a painful realization of what you’re not capturing.
This is why logging and retention decisions made during normal operations matter so much. You’re not making those decisions for compliance. You’re making them so that when something goes wrong, you can actually understand what happened.
The First 24 Hours Set the Tone
How you handle the first day shapes everything that follows.
If you communicate clearly, maintain coordination, and make defensible decisions, you build credibility for the longer response process. If you panic, go silent, or point fingers, you lose trust that’s hard to regain.
The goal isn’t perfection. It’s controlled, deliberate action in the face of uncertainty.
You won’t know everything. You’ll make mistakes. Some things will take longer than they should.
What matters is that the organization sees leadership that’s engaged, honest about what’s known and unknown, and working the problem systematically.
The first 24 hours of a breach are about buying time and building confidence — internally and externally — that you can manage what comes next. And once the immediate crisis passes, how you review what happened determines whether your team learns from it or just survives it.