Expert Insights

How to Secure Critical Infrastructure Systems

A 17-year practitioner’s approach to managing real-world cyber risk, from national infrastructure to enterprise.

ThingsRecon company logo with stylized wing icon on a dark blue background.

David Smith

Regional Lead Consultant

May 15, 2026

May 18, 2026

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:

Share on Linkedin
Follow us on LinkedIn to get the latest insights.
ThingsRecon logo
get a personalized demo
What’s connected to you right now?
ThingsRecon logo
Thank you! You are now susbribed to The Recon Log
Oops! Something went wrong while submitting the form.
ALL THINGS
CYBER
A ThingsRecon podcast
from the edges of
the internet.
Share on LinkedinShare on XShare on Facebook