A security engineer notices something odd at 4:47 on a Friday — a service account signing in from a region where the company has no staff, no servers, and no reason to be. Within the hour, they'll face a choice most playbooks never mention and most teams get wrong: act, or watch. The instinct is to slam the door shut immediately, reset the password, pull the box offline, and breathe. That instinct is often the single most expensive mistake a company makes during a breach.

The Setup

Every organization eventually discovers something it wasn't supposed to find. A login that shouldn't exist. A file moving somewhere it shouldn't go. A vendor calling to ask why your data is sitting on a forum. The breach itself is rarely the interesting part — intrusions are now a statistical certainty, not a moral failing. What's interesting is the seventy-two hours that follow, because that window is where regulators start their clock, where attackers decide whether to escalate, and where a company quietly reveals whether it actually understands its own environment.

These hours don't get discussed because they're uncomfortable. Disclosure timelines and notification templates make for clean policy documents. The messy, high-pressure judgment calls made at 5 p.m. on a Friday — with half the team unreachable and no one entirely sure how bad it is — don't fit neatly into a compliance binder. But that's exactly where security maturity lives or dies.

What Everyone Assumed

The assumption is simple and almost universally held: the responsible move is to eject the attacker the moment you find them. Speed equals diligence. The faster you reset the credential, isolate the host, and restore service, the more seriously you're taking the incident. Slowness looks like negligence; decisive action looks like control.

This belief feels obviously correct, which is precisely why it's dangerous. It treats a breach as a fixing problem — something broke, so you repair it as quickly as possible and move on. It assumes the thing you found is the thing that happened. And it quietly assumes that the attacker is passive, waiting to be removed, rather than an adversary actively watching how you respond.

What Actually Happened

Here's the reality that turns the assumption inside out. By the time anyone detects an intrusion, the attacker has usually been inside for weeks — sometimes months. Dwell time is measured in that range for a reason. And a competent attacker who has had weeks of quiet access does not rely on a single foothold. They've established redundancy: a second set of stolen credentials, a scheduled task that re-establishes access, an OAuth token granting persistent reach into your cloud, a web shell buried in an application no one looks at anymore. The compromised service account your engineer spotted is the one they were willing to let you see.

So when the team rushes in and resets that one account, isolates that one server, and declares the incident contained, two things happen at once. First, the attacker — who is watching — learns that they've been detected, and now decides how to spend the access they have left. That decision frequently means accelerating data exfiltration, detonating ransomware they were holding in reserve, or burning their loud foothold while retreating to the quiet ones you never found. You didn't close the door. You knocked on it.

Second, and just as costly, the act of "fixing" destroys the evidence you need to understand what actually happened. Rebuilding a server wipes the memory, the logs, and the timeline artifacts that would have told you which accounts were touched, what data left, and where else the attacker went. Now you can't determine scope. And without scope, everything downstream becomes a guess — your remediation is incomplete because you're evicting one intruder from a house with several exits, and your disclosure to customers and regulators is built on a story you can't actually verify. Mature teams invert the order entirely: they map every foothold first, watch carefully while resisting the urge to swing, and then evict everything in one coordinated action — so the attacker loses all access at the same moment, with nowhere to fall back to.

Decoded

The shift is this: the first seventy-two hours are not a fixing problem. They are an understanding problem. Containment without comprehension is theater — it produces the feeling of control while leaving the attacker a way back in. The mature question isn't "how fast can we kick them out?" It's "do we understand enough to kick them out completely, and can we prove it?" Speed still matters, but it's speed of comprehension, not speed of reaction.

This is why the first hours reveal more than any policy ever could. A team that improvises — resetting credentials in a panic, rebuilding boxes before imaging them, telling the whole company before they understand the blast radius — is showing you that they've never thought past the discovery moment. A team that calmly preserves evidence, restricts the circle of who knows, maps the full scope before acting, and then moves decisively is showing you something a maturity audit never could: that they decided how they'd respond long before the alert fired. The breach doesn't expose how good your tools are. It exposes whether you ever rehearsed the decision.

Most companies will never publish what they did in those seventy-two hours, which is exactly why so few people learn from them. I'd rather we talk about it openly. So here's what I want to know: if you found a confirmed intruder in your environment right now, today, would your team's first move be to remove them — or to understand them? Hit reply and tell me honestly. I read every response, and the gap between those two answers is the most revealing thing I know.

Think clearly,
— DJ Brar
SKBSEC | SKB Decoded
www.skbsec.com