Fix the thing that broke
The exploited path gets closed, a tool gets bought, and the incident is declared handled. Nothing looked for the other instances of the same weakness, so the next one arrives by a route that was always there.
You had an incident. Recovering is one job. Knowing what else is exposed is another.
The breach you found is rarely the only way in.
Ransomware, a wire fraud attempt, or a near miss that got everybody's attention. The immediate work is containment and recovery, and somebody is already doing it. The work that does not have an owner is the harder question: the thing that was exploited was one instance of a pattern, and the same pattern almost always exists elsewhere in the estate. Right now, briefly, you have the attention and the budget to go and look.
Underneath
What is actually going on
The visible problem is rarely the one that decides how this goes. These are the parts that are true whether or not anybody has said them out loud.
The incident was a symptom
An account without a second factor, a server nobody patched, a backup that had been failing quietly. Whatever it was, it is a category, and the category has other members.
Nobody can state the blast radius
What that account could reach, what that machine could see, what was on the share. The answer exists in five systems and has never been assembled.
The clock belongs to other people now
Insurers, regulators and customers all have notification windows, and they run whether or not the technical work is finished.
The team is exhausted and the board wants a plan
The people who know most about what happened are the ones with the least capacity to write the account of it that leadership needs.
The fork
Two ways this usually goes
Treat it as evidence about the whole estate
Take the shape of what happened and go looking for it everywhere else, from the exports the systems already produce. That turns one incident into a map, and a map is something a board can fund.
The order
What to do, in sequence
The order matters more than the individual steps. Most of the cost in these situations comes from doing the right things in the wrong sequence.
- First
Establish what else looks like that
Every account without a second factor, every machine no tool has seen, every backup job that has been failing. Counted from evidence rather than assumed.
- Then
Give every exposure an owner and a date
An exposure with no name against it is a note. The register is short, ranked, and each line belongs to somebody by name.
- Then
Write the account leadership can read
What happened, what it reached, what it would have cost, and what is different now. In language a board can act on rather than a timeline of alerts.
- After
Decide what changes permanently
Which controls, which owner, which review cadence. The difference between a company that had an incident and one that keeps having them is entirely in this step.
The questions
What you will be asked
Each of these has a real answer and a plausible one. Knowing which you are giving is most of the job.
Could this happen again tomorrow by a slightly different route?
What did the account or machine involved actually have access to?
What would this have cost if it had run for another week?
What is materially different now, and who owns keeping it that way?
The result
What you end up with
- An evidence-backed picture of what else carries the same exposure
- A ranked risk register with named owners and dates
- A board-ready account of the incident and the response
- A short list of permanent changes, sized to your business
Also happening