The Maturity Staircase: Which Security Assessment Fits Your Maturity Level?
In Part 2 I drew the map of security assessments: which type of assessment answers which question. What was still missing there is the second dimension – and it matters at least as much as the first: your maturity level.
The same assessment that is exactly right for one company is wasted money for another. Not because the assessment is bad – but because it starts two steps too high. And an assessment that starts too high will, in the end, only find what one step below would have made visible at a fraction of the cost.
Maturity Is Not a Technology Question
The most important point first, because it is the most commonly misunderstood: maturity does not mean how many security tools you have in place. It means how reliably your processes run.
A company with an expensive vulnerability scanner that never acts on the results is not more mature than one without – it just has more ignored reports. Maturity shows not in the tool stack but in whether findings reliably turn into action. That is exactly why the staircase is built organizationally, not technically.
The Staircase
Picture the following stages. Each one builds on the one below – skip a step and you are standing on shaky ground.
Stage 1: Basic Hygiene and Overview
Before anything gets tested, the fundamentals need to be in place: Do you actually know which systems you have? Is there a working patch management process? Have default passwords been changed, admin rights restricted, backups set up and tested?
Three things help on this stage: Threat modeling makes systems, data flows and relevant threats systematically visible – the foundation for planning everything that follows deliberately. A gap analysis shows where you stand against a security baseline. And implementing that baseline is the actual core of this stage.
Because otherwise, the rule here is: you do not need an assessment, you need to clean up. If fundamentals are missing here, any assessment will only confirm what you already suspect – at a multiple of the price.
Stage 2: Knowing Where the Gaps Are
Once the fundamentals are in place, the next step is making potential weaknesses systematically visible. This is where vulnerability scans and vulnerability assessments are the tools of choice – complemented by attack surface management for the outside-in view.
What matters is not the scan itself but what happens afterwards: are the findings prioritized and worked off? A company does not reach this stage by scanning, but by reliably turning scan results into action.
Stage 3: Testing in Depth
Only once known gaps are being closed systematically does it pay to look deeper: What can an attacker achieve that an automated scan will not show? That is the territory of penetration testing and source code review.
This is where the groundwork pays off. A pentester who does not have to wade through trivial, long-known vulnerabilities finds the genuinely interesting attack paths – logic flaws, chained exploits, privilege escalations. Exactly what a pentest is for.
Stage 4: Testing Your Defense as a Whole
At the top sits the question of whether your defense works as a system: Would you notice a real attack and respond to it? That is what red teaming – and, collaboratively, purple teaming – puts to the test.
This stage requires all the ones below it. A red team engagement against a company without working patch and vulnerability management does not test your detection – it simply finds the next open printer. The printer story from Part 1 sends its regards: the red team found the easiest way in because the network was full of trivial gaps. Its actual strength – testing detection and response under realistic pressure – never came into play.
Why Skipping Stages Is So Expensive
The most common expensive mistake is jumping from stage 1 straight to stage 3 or 4. The appeal is understandable: red teaming sounds more impressive than a vulnerability scan, and a pentest feels more thorough than "cleaning up first".
But an assessment that starts too high does not deliver a better result – it delivers a more expensive one. It finds the same fundamental problems that would have surfaced one stage below at a fraction of the cost, and it burns the very budget that fixing them would have needed. In the end, you have a thick report and the same unsolved underlying problem.
The AD assessment from Part 1 is exactly this case: the insight "this was never hardened" did not need a deep assessment. It was already established before the actual assessment began.
How to Tell Where You Stand
A few honest questions help – and the answers are often uncomfortable:
- Do you have a current, complete overview of your systems and externally reachable services?
- Do you have a security baseline defined – and do you enforce it?
- Are known vulnerabilities closed within a defined timeframe – or do they pile up in a report?
- Do you know who does what in an emergency – and have you ever rehearsed it?
- Would you even notice an attack?
If you hesitate at the first questions, you are further down the staircase – no matter how many security tools you run. And that is not bad news: it is the cheapest insight you can get before putting budget into the wrong assessment.
The Right Stage Beats the Highest Stage
At its core, the maturity mindset is a promise: the most effective assessment is not the most impressive one, but the one that matches where you actually stand. It builds on what you already have and moves you up one stage – instead of expensively confirming that you skipped the bottom one.
This is exactly where I support companies: figuring out where you stand, which assessment genuinely moves you forward, and in what order – whether as part of your SSDLC or in security consulting aimed at increasing your resilience. Often the cheapest first step is the most valuable one.
Next week, the series concludes with Part 4: Regulation and Motivation – what NIS2, CRA and DORA actually require, and why compliance is the minimum, not the goal.