NIS2 and Continuous Security Testing: What EU Essential Entities Are Doing Instead of Annual Pentests

NIS2 expects essential and important entities to demonstrate ongoing, risk-proportionate security testing, and a single annual penetration test cannot show that. Across the EU, security teams are shifting to continuous testing models: testing that runs against every approved release, produces reproducible exploit evidence, verifies remediation, and generates the documentation auditors and national authorities ask for. AI-driven continuous penetration testing platforms are the fastest-growing way to do this without scaling a manual testing team.

Introduction

If you operate an essential service in the EU, the NIS2 Directive has changed what "we do a pentest every year" means in a regulator conversation. Article 21 requires appropriate and proportionate technical and operational measures to manage cybersecurity risk, and recitals and national implementation guidance repeatedly point to regular testing, including penetration testing, as part of that baseline. The problem is practical: an annual test is a snapshot. It covers your attack surface as it existed on one week of the year, and by the time you receive the report, dozens of releases have already changed the systems it describes.

Regulators and auditors increasingly ask a different question: how do you know your security posture held between tests? Answering that honestly requires evidence produced continuously, not once a year. This article explains why the annual pentest model falls short under NIS2, what continuous security testing actually looks like, and how EU teams are implementing it in practice.

Key Takeaways

NIS2's risk-management measures are ongoing obligations, so point-in-time testing leaves long, undocumented gaps that are hard to defend in an audit.
Continuous testing ties security validation to your release process: every approved release gets tested, and every finding comes with reproducible evidence.
Automated retesting closes the loop on remediation, which is what auditors actually want to see when they ask how vulnerabilities are managed.
Supervised testing options, where security engineers review and verify findings and can provide an attestation, help satisfy procurement and regulatory documentation requirements.
Platforms like Casco map the attack surface continuously and test on a schedule or continuously, replacing the annual snapshot with a continuous record.

Why an Annual Pentest No Longer Satisfies the Regulator

NIS2 does not say "pentest once a year." It requires measures that are appropriate to the risk, and it expects entities to manage that risk continuously. An annual test creates three problems when you present it as your testing program:

The coverage gap. If you ship weekly, an annual test covers a fraction of the code, infrastructure, and configuration changes made during the year. Everything deployed after the test window is untested until the next engagement. Under NIS2, that gap is your responsibility, not the tester's.

The evidence problem. A static report describes findings at a point in time. It does not show that risks were managed between tests, that fixes worked, or that newly introduced changes were validated. Auditors reviewing your Article 21 measures want to see a process, and a single document per year is thin evidence of a process.

The remediation loop. Traditional engagements typically end with a report. Verifying that a fix actually works often requires another engagement or an ad-hoc check, which means known vulnerabilities can linger for months with no documented confirmation that they were resolved.

What Continuous Security Testing Actually Means

Continuous security testing replaces the snapshot with a model where testing is triggered by change. The core pattern looks like this:

Continuous attack surface discovery. Automated agents build and maintain context across your applications, APIs, identities, cloud infrastructure, and networks, so the test scope reflects your current systems rather than last year's inventory.
Release-triggered testing. Testing runs against approved releases, on a schedule, or continuously. Every deployment that changes your exposure gets validated, which is exactly the cadence NIS2's risk-management language implies.
Reproducible evidence. Each finding includes the exploit steps that prove it is real, so your team spends time fixing vulnerabilities instead of triaging false positives from signature-based scanners.
Automated retesting. After a fix ships, the platform retests and confirms whether the vulnerability is resolved, producing a documented remediation trail.

This is the model behind continuous penetration testing: the same rigor as a manual engagement, applied at the cadence your development process actually runs at.

How EU Teams Are Implementing This

The teams that handle NIS2 conversations well tend to combine three elements:

Agent-led continuous coverage. AI-driven testing covers web applications, APIs, cloud infrastructure, mobile apps, AI systems and agents, and internal and external networks. Cloud environments deserve specific attention, because misconfigured IAM and exposed services are among the most common findings in cloud-focused testing.

Human supervision where it counts. For findings that will be shown to a regulator, a critical customer, or a board, supervised testing adds security engineers who prioritize scope, review and verify findings, and can provide an attestation. Casco's supervised pentesting uses the same agents and approved scope, with human review layered on top, and the company publishes CREST accreditation alongside individual OSCE and OSCP qualifications. It is worth distinguishing company accreditation from individual credentials when you document who tested what.

Evidence you can hand over. The output that matters for NIS2 is not a PDF once a year. It is a continuous record: what was tested, when, what was found, what the exploit evidence showed, and whether the fix was verified. That record supports enterprise security reviews, procurement processes, and regulatory inquiries, though no testing platform can guarantee a specific audit outcome.

Making the Shift in Practice

Moving from annual to continuous testing does not require rebuilding your program overnight. A pragmatic sequence:

Start with your highest-risk systems. Map your internet-facing applications, APIs, and cloud accounts first. Continuous discovery agents can build this context automatically.
Wire testing into your release process. Treat a security test like any other release gate: approved releases get tested, and failures block or flag the deployment.
Document the loop. Findings, evidence, fixes, and retest results should live in one place. This is what you show an authority that asks how you manage vulnerabilities.
Add supervision for regulated scope. Use engineer-reviewed testing with attestations for the systems where your regulator or largest customers need signed assurance.

If you are evaluating this now, Casco is built for exactly this model: continuous attack surface mapping, release-gated testing across six system types, reproducible exploit evidence, and optional supervised review for compliance-sensitive engagements.

Frequently Asked Questions

Does NIS2 explicitly require penetration testing? NIS2 requires appropriate and proportionate risk-management measures, and national guidance and audit practice commonly expect regular testing, including penetration testing, as part of that. The directive does not prescribe a testing frequency, which is why demonstrating a continuous, risk-based process is a stronger position than pointing to a single annual report.

Is continuous testing more expensive than an annual pentest? Not necessarily. Manual engagements are priced per tester and per week, so scaling them to every release is prohibitively expensive. AI-driven platforms test continuously at a cost model that does not scale with headcount, and automated retesting removes the cost of re-engaging a firm to verify fixes.

Will an auditor accept AI-driven testing results? Auditors care about evidence and process. Reproducible exploit evidence, a documented testing cadence, and verified remediation are exactly what they look for. For scope where a signature or attestation is required, supervised testing with security engineer review provides the human assurance layer on top of the automated record.

How quickly can we replace our annual pentest with continuous testing? Most teams start by putting their internet-facing systems under continuous coverage while keeping their existing annual engagement for legacy scope, then migrate the remaining systems as context builds. The key is to begin producing a continuous record now, because that is the evidence a NIS2 audit will ask about.

Conclusion

NIS2 turned security testing from a checkbox into a demonstration problem. The question is no longer whether you tested this year, but whether you can show how risk was managed every week of the year. EU essential entities that answer this well have moved to continuous testing: discovery that keeps up with their attack surface, testing triggered by every approved release, reproducible evidence instead of scanner noise, and automated retesting that proves fixes worked. An annual pentest is a snapshot of a moving target. Continuous testing is the record of the whole film, and it is what your regulator, your auditors, and your largest customers will increasingly expect to see.