Regulation and Motivation: Why Compliance Is the Minimum – Not the Goal

For three parts, this series was about the what and the how: the right question instead of the wrong one, the map of security assessments and the maturity staircase. What remains for the finale is the question of why – and in practice, there are exactly two answers: "we have to" and "we want to".

Both are legitimate. But they lead to very different results.

"We Have To": Regulation Is Tightening

The third question from Part 1 – "Are we meeting requirements?" – has gained considerable weight in recent months. Three regulations are currently setting the agenda:

NIS2 has been in force in Germany since 6 December 2025 – with no transition period. Around 30,000 companies across 18 sectors have since had to implement risk management measures, report incidents and register with the BSI. What is really new is the personal dimension: top management must approve the measures, oversee their implementation – and is liable for violations.

The Cyber Resilience Act (CRA) affects everyone placing products with digital elements on the EU market – from smart home cameras to B2B software. The first obligation kicks in on 11 September 2026: actively exploited vulnerabilities and severe incidents must then be reported within 24 hours, with a full report within 72 hours. From December 2027, the regulation applies in full – including security by design and vulnerability management across the entire product lifecycle.

DORA has applied to the financial sector since January 2025 and demands digital operational resilience – including regular testing, up to Threat-Led Penetration Testing (TLPT) for significant institutions.

And these are just the three making the most noise right now. Depending on your industry and business model, more join the list: the GDPR with its often forgotten obligation from Article 32 to regularly test and evaluate the effectiveness of your own measures – since 2018, for practically every company. Standards like ISO 27001, BSI IT-Grundschutz, TISAX or IEC 62443, which are not laws but become de facto mandatory through customer contracts and supply chains. And product requirements like the RED provisions for radio equipment or, from 2027, the Machinery Regulation. The list is long – and growing.

For those who need to keep track, there are now specialized tools that map requirements from multiple regulations and standards to concrete measures and make providing evidence easier. The effect: one measure, properly implemented and documented, counts towards several frameworks at once.

What Regulation Actually Demands

Reading the three texts at the assessment level reveals something interesting: none of them demands "one pentest per year". What they demand are working processes – and proof that they are effective.

That maps almost one to one onto the staircase from Part 3: NIS2 risk management starts with taking stock of your own systems – that is stage 1, basic hygiene and overview. The CRA demands lived vulnerability management across the product lifecycle – that is stage 2, making gaps visible, anchored in the development process. And DORA demands tests that match your criticality, up to TLPT – those are stages 3 and 4, testing in depth and testing your defense.

So regulation does not replace the staircase. It does not even question it. It just gives it something many companies never had before: deadlines.

Compliance Is the Minimum

And yet this is where the misunderstanding begins that I encounter most often in projects: compliance gets mistaken for security.

In Part 2, it was already on the map: audit ≠ security. An audit checks whether defined requirements are met – on a given date, against a catalog. That is valuable, but it does not answer whether an attacker gets through. Those who only test for the audit optimize the report instead of the defense. The result is paper security: certified, filed away – and useless when it matters.

Regulation itself, by the way, sees it the same way: it defines minimum requirements, a lower bound. Meeting them does not make you secure – it makes you compliant. And the one who knows the difference best is the attacker. The attestation does not interest them.

"We Want To": The Better Motivation

Hence my plea to close the series: use regulation as a trigger – but not as the goal.

The difference shows in one simple question: are you testing just to pass – or do you also want to get better? Those who just want to pass look for the assessment that finds as little as possible. Those who want to get better look for the assessment that moves the most at their current stage – and work through the results.

The beautiful part: those who climb the staircase out of their own conviction get compliance almost for free. If you know your systems, close vulnerabilities systematically and test your defense, you already have the evidence NIS2, CRA and DORA demand sitting in your drawer. The other way around, it does not work: an attestation builds no resilience.

The Series in Four Sentences

Which brings us full circle:

1. The wrong first question: Do not start with the type of assessment, start with the goal – or you will buy the wrong assessment.
2. The map: Every type of assessment answers a different question. Scan ≠ pentest, pentest ≠ red teaming, audit ≠ security.
3. The maturity staircase: The right assessment depends on where you stand – skipping a stage means expensively confirming what one step below would have shown for a fraction of the cost.
4. Regulation and motivation: Compliance is the minimum. Resilience is the goal.

This kind of orientation is the core of my work: figuring out where you stand, which assessment genuinely moves you forward and how security becomes part of your processes – whether in your SSDLC, in preparing for NIS2, CRA and DORA, or in security consulting aimed at increasing your resilience.