The second breach is the one that gets you fired

Most organisations survive a first breach. The board is shocked, money appears, consultants arrive, and everyone agrees it was a wake-up call. The second one, twelve months later, through the same door, is different. Nobody's shocked. They're asking what the money bought.

Why it happens

Eradication is harder than containment, and it's done when people are exhausted. Three patterns I'd look for:

1. The attacker kept a key. Credentials reset, but a service account, an API token, or a mailbox rule survived. The first intrusion ends; the access doesn't.
2. The root cause was described, not fixed. The report said "inadequate segmentation" and the project to fix it is still in planning.
3. Nobody tested the fix. The control was deployed and assumed to work. Nobody ran the original attack path against it.

What I'd do differently the first time

Treat eradication as its own project with its own evidence. Before anyone declares the incident over, I'd want to see three things: a list of every credential and token the attacker could have touched, with proof each was rotated; the original attack path replayed against the new controls, by someone who wants it to fail; and a monitoring rule that fires if the same technique recurs.

That last one matters most. The second breach usually announces itself the same way the first one did. If the detection you built after the first one is any good, the second one becomes an alert instead of a headline.

The conversation with the board

Boards ask "are we secure now?" The honest answer is "here's what we've closed, here's what's still open, and here's what we'd see if they came back." That answer survives the second attempt. "Yes" doesn't.

Explore: More on incident response · Work with me