Six stages. Each one produces something you can act on.

We build one picture that holds the single-line diagram and the data-flow diagram together, because the interesting risks live where those two views overlap and neither drawing shows it alone. Includes every device that can issue or influence a control action, every path that reaches them, and every party that holds access.

You get: a system and access map that is usually the first complete one the organisation has.

Working from the map, we trace routes from a plausible entry point to a physical or operational consequence. Each path is written as a chain — entry, movement, control action, physical effect — so it can be argued with. A path you can dispute is more useful than a risk score you cannot.

You get: a set of written attack and failure paths specific to your topology.

For each path we ask what would actually stop it, and crucially whether that control is independent of the thing being compromised. Protection logic running on the same controller as the compromised function is one layer wearing two hats. This stage is where defence in depth is either confirmed or found to be depth on paper.

You get: a control-effectiveness view showing which defences are genuinely independent.

Testing is scoped to the highest-consequence paths and agreed in writing before anything is touched: what will be tested, by what method, during which window, and what the stop conditions are. On energised plant we take the conservative option by default, and we will tell you when a path cannot be tested safely instead of substituting a weaker test and reporting it as clear.

You get: evidence of which modelled paths are real, and which were theoretical.

Findings ordered by consequence and by effort, written for the people who will implement them. An engineering team should be able to read an item and know what to change without a translation layer between the security report and the work order. Where a fix is genuinely expensive we say so, and offer the compensating control alongside it.

You get: a prioritised, costed-by-effort plan, plus a short version for the people approving it.

We re-test what was changed. A finding closes when the path is demonstrably closed, not when a ticket moves. Where remediation changed the architecture, we update the map so the next assessment does not start from zero.

You get: confirmation of what is actually resolved, and an updated system map.