The week after a security incident is the worst time to buy security products. It is exactly when most of them get bought. The pressure is high, management wants to see action, and the vendors know both. A security check after the incident sounds almost provocatively unspectacular next to that. Yet this step, not the purchase order, decides your security costs for the next few years.
We regularly get called into companies where the incident is a few weeks in the past. Operations are running again, the forensics team is done, the insurer has been informed. On the table sit three quotes: an EDR platform, a SOC service, an awareness solution. The question we get asked is rarely "What went wrong here?" but "Which of the three should we take?".
The honest answer: maybe none. Not yet.
Why the buying reflex strikes when it is most expensive
After an incident, buying feels like acting. The board of directors wants to show it has responded, not least with a view to its own liability. IT never wants to live through that state again. And the vendor who calls two days after the incident has been handed a sales argument no brochure can deliver: your own experience.
A purchase is also convenient. It is visible, quickly decided, and it can be delegated. A budget approval takes one meeting. The question of why a dismissed employee still had an active account months later takes longer, and it points at nobody anyone likes to point at.
The problem: the decision is based on the shock, not on the findings. The incident becomes a sales argument instead of a data source. In our experience, oversized security stacks are born exactly this way, in the weeks after an incident. Three years later, someone is still renewing licenses whose only justification is the panic of back then.
Add to that: the companies that get hit are rarely the ones without security products. In our mandates we regularly see post-incident environments with half a dozen security tools, each of which could in theory have noticed the attack. They were bought, installed and half configured. The incident happened in the gap between responsibilities, not in a gap in the product catalogue. If that is the starting position, a seventh tool does not solve the problem. It widens it.
The incident is the most honest report you will ever get
An incident is the only moment when someone shows you, without make-up, where your company is vulnerable. No auditor and no questionnaire gets close to this information: the attacker documented the path he took, under real conditions and against your real day-to-day operations.
And in our experience that path rarely runs through missing technology. It runs through things like these: the account without multi-factor authentication that stayed active after someone left. The admin rights that were granted "temporarily" and never revoked. The backup that ran dutifully but whose restore nobody ever rehearsed. The report from an attentive employee that fizzled out because it was not clear who was responsible for it. The service provider's remote access that nobody had needed since the project ended and that nobody closed anyway.
None of these gaps gets closed by a new product. They are organizational: unclear responsibilities, missing routines, configurations nobody took care of. Whoever orders first after an incident buys an answer to a question they have not even asked yet.
Let's be honest: nobody likes hearing that the weakness sits in their own operation and not in the purchasing catalogue. Buying a product feels better than admitting that the offboarding process has run on shouted requests for years. Which is exactly why it pays to establish the findings before the quotes decide what gets talked about at all.
What a security check after the incident does differently
First the distinction, because it gets mixed up often. Forensics and incident response answer the questions "What happened?" and "Is it over?". That is the fire brigade, and it has to come first. The security check answers a different question: "Why could it happen, and what does that mean for our priorities?" That is structural engineering. You need both, in this order, and usually with different people: forensics needs specialists for traces, the check needs someone who can read organization and technology together. (Where the line between an assessment and a pen test runs, we have described here.)
In practice, such a check after an incident runs in four steps:
- Retrace the incident path. Which route did the attack take, station by station? At every station the same question applies: which control was missing, and which was in place but did not bite?
- Take stock. What exists in tools, measures and contracts, and how much of it is configured? A frequent finding from our mandates: the function that would have prevented the incident was already licensed. It was just never activated.
- Prioritize the gaps. Weighted by what the incident has proven, rather than by the completeness of some framework. The incident has done the prioritization for you, that is its only advantage.
- Action plan in sequence. Configuration and responsibilities first, then processes, new purchases last. If a product is genuinely missing at the end, you then buy it with a justification that still holds in three years.
The incident path is the entry point, not the boundary. An attack shows you one route that worked. A good security check then looks at the neighbouring doors: how clean is the lifecycle of accounts and permissions overall? Has a restore from backup ever been rehearsed under realistic conditions? What is reachable from the outside, and does anyone know? And the question that triggers the most in our experience: who notices if something similar starts tomorrow via a different route, and who does that person call?
Such an assessment takes a few weeks. What it costs, we have written up transparently. Compared with a single panic purchase it is almost always the smaller item.
There is one side effect that gets underestimated: the documented findings, together with the decisions that follow from them, are at the same time your proof of due diligence. If someone asks after the incident whether management responded appropriately, "We assessed, prioritized and decided in a structured way" is an answer that holds up. "We bought three products" is not.
What this does to your budget
The security check reverses the usual post-incident logic: first you use what you have. Then you repair what is organizationally broken. And only then do you buy what is still missing after that.
In our experience this sequence ends more often with a shorter tool list than with a longer one, at better coverage. Security loses nothing in the process, it gains: every license that keeps running only because of the panic of back then ties up money and attention that are missing at the weakness the incident has proven. It would be a shame to leave this dearly paid-for information unused.
The effect runs through the following years. What was bought in the panic phase shows up at every renewal, and at renewals hardly anyone decides actively. The contract keeps running because cancelling would need a justification and continuing needs none. A finding from a structured check is exactly that justification, in both directions: it tells you what to keep and configure properly, and it gives you the arguments to let the rest expire.
If it has just happened to you
Three things, in this order:
Park all larger purchasing decisions until findings are in. The exception is what the restart of operations strictly needs. Everything else can wait four weeks, even if it does not feel that way. The quotes will not run away, and a discount that only applies this week is a sales instrument, not an argument. If management or the board of directors demands visible action right away: the decision to assess in a structured way, with a deadline and a responsible person, is visible action. It can be minuted and proven later, which cannot be said of a hasty purchase order.
Document the incident path while the memory is fresh. Who noticed what and when, which systems were affected, which report went to whom, and where things got stuck. That is unspectacular paperwork, but it is the basis for the security check and for every conversation after it, with the insurer as much as with management. In three months, half of it is gone, and with it the chance to make more out of the incident than an invoice.
Set up a structured security check, external or internal. External has one advantage that has nothing to do with competence: whoever investigates internally always also investigates their own work, and that shapes the findings. An outsider can write down what they find without owing anyone in the building anything. This is exactly the kind of check we do as a security assessment, and an initial conversation about it comes with no obligations.
About the quotes that sit on the table after an incident, by the way, we are always interested in the same thing: which of them answers the question of why it could happen?
