Most security programs fail because they start in the wrong place. This piece makes the case for why visibility has to come before tooling, detection, or compliance, and what the right sequence actually looks like.
This article was adapted from a conversation on the All Things Cyber podcast, hosted by Robin de Vries and Stephane Konarkowski of ThingsRecon.
I’ve worked on incidents where cyberattacks shut down schools, transport systems, and public services.
When that happens, the impact isn’t theoretical: it’s citizens, disruption, and in some cases, it can be lives.
After 17 years working across governments and critical infrastructure, the pattern behind those failures is always the same.
Most security programs start in the wrong place. They start with tools, or detection, or compliance. But the sequence that actually works is much simpler, as described in this three-step framework.
The Three Step Framework for Securing Critical National Infrastructure
1. Visibility
Before you assess risk, before you buy tooling, before you run a test, you need to understand what actually exists. Not what’s on a network diagram or what procurement says. What’s really there, what it’s connected to, and what it’s doing.
2. Remediation and hardening
Once you can see your state, fix it.
This is where people and process matter. A vulnerability scanner that produces a report nobody acts on hasn’t improved your security posture. The governance around fixing things is the work.
3. Detection and response
Only after the first two steps does detection start to work properly.
If your baseline is incomplete, your alerts are noise. You’ll miss what matters and chase what doesn’t.
It sounds simple. But in practice, most organizations are working from an incomplete picture.
Why This Is Harder Than It Looks
In an enterprise, you usually have one governance model, one infrastructure, one risk framework.
In government, that’s not how it works.
Each ministry operates differently. Different ownership, different legal boundaries, different systems. Some parts of government are deliberately separated from others (police, prosecution, regulatory bodies) for good reason.
So when I arrive in a new country, I don’t start with the IT, I start with the structure:
- Who owns what?
- Who talks to whom?
- Where are the legal boundaries?
Because until you understand that, you can’t understand the technical picture.
Why Compliance Doesn’t Solve This
One of the most common conversations I have is with organizations working toward frameworks like NIS2.
At some point, the requirement comes up: you need to assess your third-party suppliers.
And the response is almost always the same:
“How do we know who our third-party suppliers are?”
That question tells you everything. Most of the tooling we have assumes you know your suppliers, your dependencies, your environment.
In reality, most organizations don’t. Compliance can be a useful starting point, but if it becomes a checklist, it doesn’t produce security.
Tools Don’t Fix Problems; People and Processes Do
There’s a version of this conversation where everyone agrees people and process matter.
And then everyone goes back to buying tools.
The tools give you visibility, but it’s the people and the processes behind them that fix things.
In some of the organizations I work with, we’re still working on basic things like password policies, ownership, accountability. And that’s fine, everyone starts somewhere.
But it means the next step isn’t another advanced platform.
It’s making sure someone is responsible for acting on what the current tools are already showing.
Where To Start
If you’re building or maturing a security program, the sequence matters.
Start here:
- Map what actually exists, not what you think exists
- Fix what you can see, and make it someone’s responsibility
- Then detect and respond, on a foundation that’s real
The organizations that do this well are the ones that understand their environment as it actually is, not as it’s documented.
Those are the ones that are ready when something goes wrong.
David Smith is Regional Lead Consultant for Eastern Europe and the Balkans at BAE Systems Digital Intelligence. He has spent over 17 years working in defense, government, and critical national infrastructure security, including response engagements in Albania and Montenegro and advisory work across multiple national cyber agencies.
This article was extracted from the latest episode of the All Things Cyber podcast.
Watch the full conversation:


.png)


