NIS Regulations 2018 and Penetration Testing

The detail is where teams get caught out. Because the words “penetration test” never appear in the Regulations, some organisations assume the activity is optional, then struggle to demonstrate their security measures when the Competent Authority reviews them against the NCSC Cyber Assessment Framework. This guide explains where testing sits, what the duty actually asks you to prove, how often you should test, who is allowed to carry the work out, and what to do when findings appear.

Where penetration testing sits in the NIS Regulations

The core security duty for Operators of Essential Services lives in regulation 10. It requires them to take measures to manage risk and to prevent and minimise the impact of incidents affecting their essential services. Relevant Digital Service Providers carry an equivalent security duty under regulation 12. Either way, the Regulations deliberately stay outcome-focused. They describe what good security looks like, not the specific tools you must buy or the tests you must run.

The practical detail is supplied by the sector Competent Authorities, who assess compliance predominantly through the NCSC Cyber Assessment Framework, known as the CAF. The CAF is a set of outcome-based principles, and it is here that testing becomes an expectation. Under objective B, principle B4 covers system security, and the contributing outcome B4.d deals with vulnerability management. Demonstrating B4.d convincingly is difficult without some form of independent security testing, and penetration testing is the recognised way to do it. In other words, the mandate does not flow from the Regulations directly; it flows through the CAF assessment your Competent Authority applies.

For a fuller breakdown of that link, see our guide on how the NCSC CAF treats testing.

What the duty actually asks you to demonstrate

Stripped of the legal language, the security duty (regulation 10 for OES, regulation 12 for RDSPs) and the CAF ask you to show a handful of things in plain terms:

• You understand your attack surface. You know which systems support your essential or digital service and how an attacker could reach them.
• You find weaknesses before attackers do. You actively look for vulnerabilities rather than waiting for an incident to reveal them, which is the heart of the B4.d vulnerability-management outcome.
• Your testing is proportionate. The depth and frequency of testing reflect the importance of the service and the risk it carries, not a token exercise.
• You act on what you find. Findings feed a prioritised remediation programme, and you can evidence that fixes were made and checked.
• You can show your working. You hold reports, scope documents and remediation records that a Competent Authority can review.

A penetration test delivers most of this in a single, defensible package: a scoped assessment, a documented methodology, ranked findings and a report you can put in front of an assessor.

How often should you test under NIS?

The Regulations set no fixed interval, and neither does the CAF. Frequency is a matter of proportionality, but a defensible baseline for most OES and RDSPs is an annual penetration test of the systems that underpin the essential or digital service. Annual testing aligns with how most Competent Authorities expect vulnerability management to operate over a yearly assessment cycle.

Cadence alone is not enough. You should also test when a meaningful trigger occurs, including:

• A significant change to the systems in scope, such as a new platform, migration or major release.
• A new internet-facing service or a substantial change to network architecture.
• A merger, acquisition or onboarding of a new third-party dependency.
• A security incident, or intelligence that a relevant threat has changed.

Treating testing as an annual baseline plus event-driven triggers is far easier to defend than a single date in the calendar.

Who is allowed to carry out the testing?

Neither the Regulations nor the CAF names a specific certification for testers. What they expect is competence and, for credible assurance, a degree of independence from the team that built or runs the system. An assessor wants confidence that the test was carried out to a professional standard by people with no incentive to understate the findings.

This is where CREST accreditation matters. CREST is not a named requirement in the NIS Regulations, and no honest provider should tell you it is. It is, however, widely accepted evidence that a testing provider meets a recognised competence and quality bar. Presenting a report from a CREST-accredited provider is a straightforward way to satisfy a Competent Authority that the “who” behind your testing is sound.

EJN Labs is a CREST-accredited provider, and our testers are UK-based. Because we are independent of your build and operations teams, our assessment carries the objectivity a NIS assessment expects. You can read more about our CREST-accredited penetration testing and how the accreditation supports your evidence pack.

What a NIS-aligned penetration test should cover

Scope should follow the service, not an off-the-shelf checklist. For most OES and RDSPs a NIS-aligned test covers the systems whose compromise would disrupt the essential or digital service, which commonly includes:

• External infrastructure: internet-facing hosts, remote access and the perimeter that exposes the service.
• Web and API layers: the applications and interfaces that deliver or manage the service.
• Internal networks: the segmentation, privilege paths and lateral-movement routes an attacker would use after gaining a foothold.
• Cloud and operational technology where these underpin the service, tested against their specific risks.

The right scope is a conversation, and defining it well is half the value of the engagement. We agree scope with you before any testing begins so the assessment maps cleanly to the systems your Competent Authority cares about.

What happens when the test finds problems?

Findings are the point of the exercise, not a failure of it. A NIS-aligned report should rank issues by risk so you can prioritise the work that reduces real exposure first, and it should give your engineers enough technical detail to reproduce and fix each issue. That prioritised remediation is exactly the behaviour B4.d and the underlying security duty want to see.

Retesting closes the loop. Once you have remediated, a retest confirms the fixes hold and gives you clean evidence that the weaknesses were resolved, which is far more persuasive to an assessor than a list of open findings. EJN Labs includes retesting of the issues we report, so you can evidence a complete find-fix-verify cycle rather than a single snapshot in time.

A note on the Cyber Security and Resilience Bill

Scope is set to widen. The Cyber Security and Resilience Bill was introduced to Parliament in November 2025 and is expected to broaden the range of organisations in scope and strengthen the duties around resilience and reporting. It is important to be precise: this Bill is coming, not yet law, so your obligations today still rest on the NIS Regulations 2018 as assessed through the CAF. It is also separate from the EU NIS2 Directive, which is European law and does not apply in the United Kingdom. The sensible move is to build a testing programme that already meets the current expectation, because organisations that test well now will have little to change when the Bill takes effect.

How EJN Labs delivers NIS-aligned penetration testing

We keep the engagement predictable so you can plan and budget with confidence:

• CREST-accredited and independent: your report comes from a provider whose competence a Competent Authority will accept as evidence.
• UK-based testers: your testing is delivered by our own UK team, which matters for services that carry national significance.
• Fixed-price, fast quotes: a flat day rate and a clear scope, with no surprises, and a fixed-price quote turned around quickly.
• A report an assessor accepts: ranked findings, a documented methodology and a remediation-ready format that maps to the CAF outcomes.
• Retesting included: we verify the fixes so you can evidence a complete cycle.

If you need to demonstrate the vulnerability-management outcome behind your NIS duties, the fastest route is a scoped, CREST-accredited test with a report built for assessment. Get a fixed-price quote in 24 hours and we will help you define a scope that maps to your essential or digital service.

Frequently asked questions

Do the NIS Regulations 2018 legally require penetration testing?

No, not by name. The Regulations place a duty to take appropriate and proportionate security measures (regulation 10 for Operators of Essential Services, regulation 12 for Relevant Digital Service Providers), but they do not mention penetration testing. The expectation arises because Competent Authorities assess that duty through the NCSC CAF, and the vulnerability-management outcome (B4.d) is very hard to evidence convincingly without independent testing.

Which organisations do the NIS Regulations apply to?

They apply to Operators of Essential Services (OES) in sectors such as energy, transport, health, water and digital infrastructure, and to Relevant Digital Service Providers (RDSPs) such as online marketplaces, search engines and cloud computing services. Sector Competent Authorities determine and assess which organisations fall in scope.

How is NIS compliance actually assessed?

Compliance is assessed by your sector’s Competent Authority, predominantly using the NCSC Cyber Assessment Framework. The CAF sets out outcome-based principles rather than a checklist, and penetration testing is a recognised way to demonstrate the system-security and vulnerability-management outcomes.

How often should we run a penetration test for NIS?

There is no fixed legal interval. A defensible baseline for most in-scope organisations is an annual test of the systems supporting the essential or digital service, supplemented by testing after significant changes, new internet-facing services, or a security incident. Frequency should be proportionate to the risk the service carries.

Do our testers need to be CREST-accredited for NIS?

CREST accreditation is not a named requirement in the NIS Regulations. It is, however, widely accepted evidence that your testing provider meets a recognised competence and quality standard, which helps satisfy a Competent Authority on the independence and rigour of your testing. EJN Labs is CREST-accredited and our testers are UK-based.

Will the Cyber Security and Resilience Bill change these testing requirements?

The Cyber Security and Resilience Bill was introduced in November 2025 and is expected to widen scope and strengthen resilience duties, but it is coming, not yet law, so your current obligations still rest on the NIS Regulations 2018. It is also separate from the EU NIS2 Directive, which does not apply in the United Kingdom. Building a strong testing programme now is the best preparation.