Do the Risk Assessment Before You Buy Security Tools
Most security budgets are spent on the threats that were easiest to imagine. A risk assessment tells you which ones would actually hurt.
Security spending tends to follow attention rather than risk. A breach makes the news, a vendor sends a well-timed email, and a tool gets purchased to address a threat that was never particularly likely to affect your business.
Meanwhile the thing that would genuinely stop you trading for three days has no owner and no budget.
A risk assessment is the unglamorous exercise that fixes this. It is also frequently skipped, because buying a tool feels like progress and thinking does not.
What a risk assessment actually is
Not a scan. A conversation, structured, that produces a short ordered list.
You are trying to answer four questions:
- What would genuinely damage this business?
- How could that plausibly happen?
- How likely is each path, honestly?
- What would it cost to make each one meaningfully less likely?
Everything else in security follows from that list. Without it, you are buying protection against whichever threat had the best marketing.
Start with impact, not threats
The common mistake is starting from a catalogue of attack types and working towards your business. That produces a generic list where everything looks equally alarming.
Start from the other end. What are the three or four things that would actually hurt?
For a company holding customer data, it is exposure. For a company whose revenue stops when the system stops, it is availability. For a company in a regulated sector, it might be a reportable incident regardless of actual harm. For a company whose value sits in a design or a dataset, it is theft of that specific thing.
Those lead to genuinely different priorities. A business whose main risk is downtime should be spending on resilience and recovery, not on data loss prevention, however good the demo was.
Be honest about likelihood
This is where assessments go soft, because everything feels possible once you start listing threats.
Ask instead: has this happened to companies like us, at our size, in our sector, recently? Would it require an attacker to specifically target us, or would it happen to whoever was scannable that week?
The second category is where most real incidents come from. Unpatched software, exposed services, credentials reused from a breach elsewhere. Nobody chose you. You were reachable.
That is a useful filter, because it means the highest value spending is usually on ordinary hygiene rather than on defences against sophisticated adversaries.
The output is a budget conversation
A risk assessment that produces a document nobody acts on has failed.
The useful output is short: here are the four things most likely to hurt us, here is roughly what each would cost if it happened, here is what reducing each one costs, and here is the order.
That fits on a page and it is something a non-technical decision maker can actually engage with. A forty page report with a heat map is usually a sign that the exercise became an end in itself.
Reassess when something changes
Not annually out of habit. When the business changes.
A new product, a new market, a significant new customer with different expectations, a system moved to a new environment, or a large change in headcount. Each of those changes the shape of the list. A calendar reminder does not.
The order that saves money
If you do this properly, the sequence that follows is almost always the same: fix the ordinary hygiene first, then add monitoring so you find out about problems quickly, then bring in specialists to test the things that matter most.
Buying tools first, which is the common order, means paying for capability you cannot yet use against risks you have not yet ranked.
The assessment itself is the cheapest step and it is where our cybersecurity engagements start. It also tends to reveal that a portion of the risk is not a security problem at all, but an infrastructure one, where recovery and monitoring do more good than any tool.