NIS2 security testing

NIS2 security testing: what the regulation requires and what it leaves to your risk assessment

If your entity is in scope for NIS2, the question is not whether you must test your security, but whether you can show a defensible testing program. Commission Implementing Regulation (EU) 2024/2690, Annex point 6.5, requires a security testing policy and procedures, and it ties the need, scope, frequency and type of tests to your risk assessment. It also requires documented results and mitigating actions for critical findings. What it does not do is set a fixed frequency. There is no equivalent of an annual penetration test written into the text, so the interval you choose must be justified by your own risk picture. Confirm first that the regulation applies to your entity type and sector, and confirm the national transposition and any sector-specific expectations with your national competent authority, since application depends on those classifications.

This is the main difference from the frameworks many teams already run. PCI DSS requirement 11.4.2 and DORA Article 24(6) set fixed minimums, such as internal and external penetration tests at least every 12 months under PCI DSS and yearly testing of ICT systems supporting critical or important functions under DORA. Under NIS2 the schedule is yours to set, and you will be asked to defend it. Expect a reviewer to ask why a system was tested every 12 months and another every 24, and whether the answer follows from the risk assessment. A testing calendar that cannot be traced back to identified risks will look arbitrary, even if it is generous.

For that reason, the risk assessment is the first document an auditor or competent authority will read. Check that it names the systems, services and dependencies in scope, records the threats and vulnerabilities considered, and explains how each area was prioritized for testing. Then check that the testing policy, the test plan and the results all trace back to it. Ask your testing provider to map each planned test to a risk entry and to state the test type, such as a web application assessment, an infrastructure test or a code review, so the link is visible on paper. Gaps between the risk assessment and the testing record are the most common weakness to close before any review.

Which systems NIS2 security testing scope should cover

NIS2 does not list the systems you must test. Your risk assessment decides which services, networks and suppliers fall in scope, how deep each test goes and how often it recurs. The cards below are the scoping decisions that most often need a written answer before testing starts.

In-scope services tied to the risk assessment

Start from the services your risk assessment ranks as essential or important, then map each one to the hosts, applications, databases and network segments that deliver it. Record why each system is in or out, because the regulation expects the need, scope, frequency and type of each test to follow from that assessment. A scope list without a risk rationale is hard to defend to a supervisory authority. Check that every system in the list has a named business owner.

Internet-facing applications and APIs

Public websites, customer portals, remote-access gateways and exposed APIs are the most common entry points, so they usually carry the highest testing priority. Confirm the inventory is complete by comparing it against external attack surface discovery, since shadow services and forgotten subdomains are common gaps. Agree whether the test covers authenticated functions as well as anonymous access. Record which environments are production and which are staging copies.

Identity and remote access

Directory services, single sign-on, multifactor authentication and VPN or zero trust access paths decide whether an attacker who gets one foothold can reach everything else. Include the identity providers that issue tokens to in-scope applications, not only the user-facing login pages. Confirm which administrative accounts, service accounts and privileged access workflows are covered. Testing that skips identity often misses the paths that matter most.

Cloud accounts and Kubernetes clusters

Cloud tenants, management planes, container registries and Kubernetes clusters often change faster than the asset register. Decide which accounts, subscriptions, projects and clusters are in scope, and which control planes are managed by your provider and therefore outside your testing rights. Check each provider's published testing rules before any test starts, and confirm who approves changes to network rules during the window. Record the configuration baseline the test will be measured against.

Third-party and supplier connections

Managed service providers, software vendors and integration partners often hold credentials, VPN tunnels or API connections into your environment. Identify which supplier connections fall within your testing scope and which require the supplier's own written consent. Some suppliers will test their own platforms and provide a report, and you should confirm whether that report covers the connection you actually use. Agree in advance how supplier findings are routed and tracked.

Rules of engagement and named contacts

Write down the testing windows, the source addresses the testers will use, the systems that must not be disrupted and the escalation path if a critical finding or outage occurs. Name a technical contact and a decision maker on both sides, and confirm how a stop request is communicated and honored. Agree whether testers may use credentials, and what happens to any data they access. These rules protect operations and provide the written scope record an auditor will ask to see.

How a NIS2 security testing engagement runs, phase by phase

The sequence turns the risk assessment and security testing policy into a scheduled, scoped and documented testing programme, with each finding tracked to closure. Each phase ends with a record an assessor can check.

Confirm the risk assessment and testing policy
DeployOpen reviews the current risk assessment, asset inventory and the security testing policy with your security and compliance leads. The policy should state the need for testing, who approves it and how results feed back into risk treatment. The step closes when the risk inputs and policy owner are named in writing, so every later testing decision can be traced to them.
Agree test types and frequency per system group
Systems are grouped by criticality and exposure, such as internet-facing services, identity infrastructure, and internal business applications. For each group, the team agrees the test type (vulnerability assessment, penetration test, code review or configuration review) and the frequency set by the risk assessment. NIS2 Implementing Regulation (EU) 2024/2690 sets no fixed frequency, so the justification must come from your own risk analysis. The step closes with a signed schedule for each group.
Scope and write rules of engagement
The scope document lists in-scope hosts, applications, cloud accounts and third-party components, along with exclusions and any testing windows. Rules of engagement cover testing sources, contact points, emergency stop conditions, handling of production data and what happens if a critical flaw is found mid-test. Your system owners and, where needed, hosting or SaaS providers sign off. The step closes when the scope and rules are approved in writing before any testing starts.
Test with methods matched to each target
Testers use the methods suited to each target: authenticated and unauthenticated testing for applications and APIs, external and internal network testing, configuration review for cloud and platforms, and code review where source is available. The approach follows the testing practice described in ISO/IEC 27002:2022 control A.8.8 and the external and internal penetration test expectations in CIS Controls v8.1 Safeguard 18.2. The step closes with a testing log that records what was tested, when, by whom and with which tools.
Document findings with severity and evidence
Each finding is written up with affected assets, reproduction conditions at a defensive level, evidence, a severity rating and a recommended fix. Severity uses an agreed method so the rating can be compared across test cycles. Findings are reviewed with your technical owners to remove false positives and confirm impact. The step closes when a final report is issued and every finding has an owner and a status.
Track mitigating actions for critical findings
Critical findings receive a documented mitigating action plan with an accountable owner, a target date set by your organization and interim controls where a fix takes time. The plan is linked to the risk register so management can see what remains open. The step closes when each critical finding has an approved action plan recorded in your tracking system.
Retest to confirm closure
Once fixes are applied, the testers repeat the relevant tests against the original finding conditions to verify closure. Retest results state whether each finding is resolved, partly resolved or still open, and any residual risk is accepted formally by the risk owner. The step closes with a retest report that references the original finding IDs.
Retain plans, schedules, reports and audit records
Test plans, schedules, scope documents, final and retest reports, and the record of management decisions are kept in a controlled repository with version history. ENISA's June 2025 NIS2 technical implementation guidance lists test plans and schedules, vulnerability and penetration test reports, code review reports and audit reports as examples of security testing evidence. Confirm the retention period with your regulator or legal team, as no fixed period is set here. The step closes when the evidence set is indexed so it can be produced for a supervisory audit.

Weakness categories that NIS2 testing findings usually point to

This table maps six weakness categories that penetration tests and vulnerability assessments often surface in NIS2 in-scope environments to how they usually appear and why they matter for the risk assessment. Use it to decide which areas deserve testing first, since the risk assessment under Implementing Regulation (EU) 2024/2690 sets the scope and frequency of tests. The main takeaway is that each category should map to a named asset and a documented mitigation, not just a finding count.

Weakness category	How it typically appears in a NIS2 in-scope environment	Why it matters for the risk assessment
Exposed management interfaces	Administrative consoles, remote management ports or vendor portals reachable from the internet or from less-trusted networks	Testing confirms which management functions are reachable from where, so the risk assessment can rate access paths to essential or important services
Weak authentication and identity configuration	Single-factor access to administrative accounts, inconsistent password and session policies, or misconfigured directory and single sign-on settings	Identity is often the route that connects a single foothold to wider impact, so testing results inform the risk rating of privileged access controls
Missing patches in internet-facing services	Outdated versions of web servers, VPN gateways, mail services or self-hosted applications that the vulnerability management process has not yet updated	Findings show whether the patching process reaches systems that the risk assessment classifies as highest exposure, and whether critical findings receive documented mitigating actions
Segmentation gaps between operational and corporate networks	Operational technology or plant networks with routed paths, shared credentials or services that cross into the business network	Testing checks whether a compromise in corporate IT could reach systems that deliver essential services, which directly affects the scope of the risk assessment
Insecure cloud and container configuration	Overly permissive storage or identity roles, exposed cluster management components, or workloads running with unnecessary privileges	Configuration findings show how far the cloud and container estate matches the documented scope of systems covered by the risk assessment
Weak supplier access paths	Third-party remote support accounts, shared vendor credentials, or integration accounts with standing access to production systems	Supplier access is a recurring source of exposure, so testing results help set frequency and scope for supply chain risk and the supplier controls in the policy

What drives the cost of NIS2 security testing

This table compares the main cost drivers for NIS2 security testing, why each one moves the price, and how to scope it efficiently. Read it before requesting a quote, since the written scope is what determines the fee. DeployOpen does not publish a price list, so a quote follows from the scope you agree in writing.

Cost driver	Why it moves the price	How to scope efficiently
Number and type of in-scope systems	Each additional system, network segment or service adds test planning, execution and reporting. Systems that support essential or important services in your risk assessment usually carry more depth.	Start from the risk assessment and list only the systems in the NIS2 scope. Group similar hosts and document why the rest are excluded.
Internal versus external testing	External tests cover internet-facing addresses. Internal tests require access to internal networks and more time for discovery, so they generally cost more per address.	Confirm which exposures are reachable from outside. Test internal segments in a single, clearly bounded window.
Application and API depth	Authenticated testing of applications and APIs, including business logic and access control checks, takes more time than unauthenticated scanning of the same endpoints.	Name the applications and API versions in scope, state the roles to be tested and provide accounts and documentation before work starts.
Cloud and Kubernetes review	Configuration review across cloud accounts and clusters adds effort for each account, region, identity policy and workload. Provider testing rules and shared responsibility limits also shape the work.	List accounts, clusters and namespaces explicitly. Agree which provider-managed components are excluded and why.
Segmentation and OT boundary checks	Verifying that network segments and operational technology boundaries actually separate systems requires testing from both sides, and any safety constraints add planning time.	Define the boundaries to be verified and the expected separation rules. Agree in advance which OT assets are tested only through documentation review.
Number of retest rounds	Each retest verifies remediation of findings and adds effort. Retests are needed to show that mitigating actions for critical findings were effective.	Ask for the number of retest rounds in the quote and agree a finding severity threshold that triggers retesting.
Whether the policy and evidence package is included	Drafting a security testing policy, procedures and an evidence register is separate work from running the test. Including it adds design and document review effort.	Decide whether you need a policy draft, a procedure set or only the test reports. Ask which artifacts from the ENISA evidence list the quote covers.
One-time work: scoping, policy design and baseline test	Initial scoping, policy and procedure design and the first full test establish the baseline. This work is typically paid once, though later cycles reuse it.	Ask for the one-time items separately in the quote so you can see what is set up once and what repeats.
Recurring work: periodic tests, retests and retainers	Periodic tests follow the frequency set by your risk assessment, since NIS2 sets no fixed frequency. Retainers for ongoing support and continuous testing recur on the agreed term.	Ask for the recurring items and their frequency in writing. Confirm which retainer services are included and how changes to scope are priced.

How authority audits and scans differ from your own security testing

A competent authority can supervise your entity through audits and inspections. The form, timing and powers depend on how your member state transposed NIS2, so confirm them with your authority. The reviewer examines the paper and the practice: whether a security testing policy and procedures exist, whether the need, scope, frequency and type of tests trace back to your risk assessment, and whether results and mitigating actions for critical findings are documented.

Who performs it: staff of the competent authority or an auditor it appoints, depending on national law.
What it covers: the policy and procedures required by point 6.5 of Implementing Regulation (EU) 2024/2690, the link between the risk assessment and the test programme, and the records of past tests.
What it asks you to produce: test plans and schedules, vulnerability assessment and penetration test reports, code review reports and audit reports. The ENISA NIS2 technical implementation guidance lists these as examples of evidence.
How it relates to your program: the reviewer tests whether your program works, not whether a single test was passed.
What it does not do: a clean audit does not remove the need to keep testing as your risk picture changes.

Ask your authority which powers, notice arrangements and reporting channels apply to your sector before an inspection is announced.

What evidence to keep for NIS2 security testing reviews

ENISA's June 2025 NIS2 technical implementation guidance lists the kinds of evidence a reviewer expects to see for security testing. The cards below connect each item to what it must show, so the record holds together when a supervisor, auditor or customer asks how testing was planned, performed and acted on.

Test plans and schedules

The test plan shows what was tested, why, and how often, linked to the risk assessment that Implementing Regulation (EU) 2024/2690 requires to set the need, scope, frequency and type of tests. A reviewer checks that the schedule matches the entities and systems in the risk assessment, that the reasons for any gap are written down, and that the approved policy and procedures are the ones the plan follows. Confirm the plan names owners and dates, since it is the first document a supervisor asks for.

Vulnerability assessment reports

Vulnerability assessment reports show routine scanning of in-scope assets, with dates, tool and coverage recorded. A reviewer looks for asset coverage that matches the scope, a clear triage method, and evidence that findings were assigned to someone. Scans alone do not show exploitability, so keep them separate from the penetration test record and note which findings were verified manually.

Penetration test reports

A penetration test report should state the scope, testing dates, methodology, tester qualifications and independence, and each finding with its severity and evidence. Reviewers check that the scope reflects the risk assessment rather than convenience, and that critical findings carry a recommended fix. Ask the provider to confirm that the report covers the systems the plan names, since gaps between the plan and the report are a common review question.

Code review reports

Code review reports cover security review of application source and build pipelines where the organization develops or customizes software. A reviewer expects the review scope, the standards used, the reviewer's role, and findings tracked to closure in the repository or issue tracker. For self-hosted platforms that DeployOpen customizes, these reports sit alongside configuration and dependency records, so confirm the version reviewed matches the version in production.

Audit reports and records of retests

Audit reports from internal or independent auditors show that testing results were reviewed by people outside the team that performed the work. Keep these with the mitigation log for critical findings: the action taken, the date, the owner, and the retest that confirmed the fix. Supervisors look for records that link each critical finding to a closed action, so a finding without retest evidence reads as open. DeployOpen prepares this evidence but does not issue audit reports or attestations, which independent auditors and certification bodies provide.

Summary letters versus full reports

A summary letter for a customer states the test type, dates, scope in general terms, the number of findings by severity, and whether critical findings were retested. The full report contains technical detail that can expose weaknesses, so it is usually shared only under a confidentiality agreement or with a regulator who asks for it. Agree the letter's content in writing before the test starts, and make sure it never claims more than the full report supports.

What to prepare before NIS2 security testing starts

Before any tester touches a system, the client should assemble the inputs that fix the written scope. The most important is the current risk assessment and security testing policy, because under Implementing Regulation (EU) 2024/2690, point 6.5, the need, scope, frequency and type of tests are set by the risk assessment. A tester who receives a risk assessment that is out of date or silent on certain systems will either test the wrong things or spend time asking which things matter. Alongside it, provide an asset and system inventory that names an owner for each system in scope, plus network and cloud diagrams that show trust boundaries, internet-facing entry points and any segregation between IT and operational networks. Confirm with your own engineering and compliance leads which systems fall under the NIS2 obligations at your entity, since that determination is yours to make, not the tester's.

Next, settle the operational details that prevent wasted tester time and surprise outages. Prepare approved test accounts and roles for each privilege level that the scope requires, along with a named technical contact, an escalation contact who can make a stop decision out of hours, and a list of change freezes and permitted testing windows. Tell the security operations centre in advance which source addresses and dates the testing will use, so that alerts are triaged as expected rather than treated as live incidents, and confirm how backups are scheduled around the test. Decide how production systems will be handled, including whether testing runs against production, a staging copy or a restored snapshot, and who approves any test that could degrade service. Write these decisions into the statement of work before testing starts, because they determine what the final report can honestly say about coverage.

NIS2 security testing questions buyers ask before hiring

Does NIS2 set a fixed security testing frequency?

No. NIS2 does not set a fixed testing frequency. Implementing Regulation (EU) 2024/2690, Annex point 6.5, requires a security testing policy and procedures, with the need, scope, frequency and type of tests set by your risk assessment. Your risk assessment should therefore justify how often you test each system, and that justification is what a supervisor will read first. Systems that change often, face the internet or support critical services usually warrant tighter cycles than stable internal tools, but the right interval is yours to document. Confirm with your national competent authority whether it expects a specific cadence in its guidance, since national rules can add detail on top of the EU regulation. Keep the reasoning, the schedule and the results together so the frequency decision can be defended.

What drives the cost and duration of a NIS2 security test?

The main drivers are the number of systems in scope, how many applications and APIs are involved, the test types chosen (external, internal, application, cloud, code review), and how much access the tester is given. Authentication complexity, the number of user roles and integrations also add effort, as does the depth of retesting after fixes. Costs are typically one-time for each test cycle, with recurring costs when you run tests on a schedule or retain a provider for continuous testing. When requesting a quote, ask for the scope in writing, the systems and environments included, the test types, the access model, the report format, and whether retesting is priced separately. DeployOpen does not publish a price list. A quote follows from the agreed written scope, and scope is what moves cost up or down most.

Can our internal security team run the NIS2 testing ourselves?

Internal teams can run some testing, and NIS2 does not prohibit it, but the policy you adopt must address who performs the work, their skills and their independence from the systems they test. A team that builds or operates a system has a hard time objectively finding its own flaws, and an independent tester is usually easier to defend to a supervisor. Internal staff need current, demonstrable skills in the test types you claim, along with tools, time and a method that produces comparable reports. An external provider adds independence, a documented methodology, experience across many environments and a report structured for auditors and management. A common model is internal teams running routine scanning and an external provider performing deeper, independent tests. Document the split in your policy so the evidence matches what you say you do.

How long does a NIS2 penetration test take from start to report?

Duration depends mainly on scope and system count. A single external perimeter with a small number of hosts takes far less time than an estate of applications, APIs, cloud accounts and internal networks, each with its own authentication roles and integrations. Scheduling also matters: access windows, change freezes, test environment availability and the time needed to answer tester questions all add calendar time. Ask the provider to break the timeline into scoping, testing, reporting and a review meeting, and to state what the client must have ready at each step. Retesting runs on its own timeline after the client fixes findings. Confirm the expected timeline in the written scope rather than relying on general estimates, because the scope document is what sets it.

What must our organization provide before a security test starts?

The client's role is essential to a useful test. Before work begins, you should provide an accurate asset inventory for the systems in scope, network ranges and domain names, architecture or data flow diagrams, and a named technical contact with authority to approve testing. You also need written authorization that covers the specific systems and test types, and a clear list of out-of-scope assets, including third-party hosted services whose owners must consent. Provide test accounts with the roles and permissions you want assessed, test environments where testing may be intrusive, and agreed change and incident handling procedures. Tell the provider about known issues and recent changes. Gaps in these inputs are a common reason tests take longer or miss areas that matter.

How does retesting close critical findings for NIS2?

NIS2 Implementing Regulation (EU) 2024/2690 expects documented results and mitigating actions for critical findings, so each critical finding needs a recorded fix and a verification step. The usual flow is that the client remediates, records the change and the owner, and the tester retests the specific issue to confirm it is resolved. The retest report should state, for each finding, whether it is closed, partially addressed or still open, with the evidence used to decide. Keep the original finding, the remediation record and the retest result together. If a finding cannot be fixed quickly, document a risk acceptance or compensating measure with an owner and review date. Retesting is usually scoped separately, so ask for it explicitly in the quote.

Is a penetration test report enough to satisfy a supervisor or customer?

A report alone is rarely enough. ENISA's June 2025 NIS2 technical implementation guidance lists test plans and schedules, reports of vulnerability assessments, penetration tests and code reviews, and audit reports as examples of evidence. The report is one piece of that set. A supervisor or customer will also look for the security testing policy, the risk assessment that set scope and frequency, the schedule, evidence of remediation and retesting, and records showing management reviewed the results. The report should state its scope, methodology, dates, tester qualifications and limitations so it can be checked. Supervisory audits and security scans by authorities are separate activities from your own testing, so do not assume an authority's scan replaces your evidence. Confirm the exact format your authority or customer expects before the test is commissioned.

How DeployOpen scopes and runs NIS2 security testing

DeployOpen plans and runs security testing against NIS2 obligations as part of its wider work on self-hosted open-source platforms inside the client's own infrastructure. Each engagement starts from a written scope, and the deliverables are documented so your team can show how testing follows from your risk assessment.

How we scope

Engagements are fixed-scope, with systems, test types and deliverables agreed in writing before work starts.
We help you map which systems fall under your risk assessment and which test types and frequency that assessment supports.
Scope records the testing policy reference, the test window and who on your side approves findings and remediation priorities.

How we build

We prepare a test plan and schedule that lists each system, test type, tester and planned date.
Testing combines vulnerability assessment, penetration testing and code review where the agreed scope includes them.
Testers record their method, tools and limits so the results can be reproduced and reviewed later.

How we hand over

Reports separate confirmed findings, their business impact and the mitigating actions recommended for critical issues.
We deliver the test plan, schedule, reports and remediation tracking as documents your team can file as evidence.
Retest is scoped in writing so corrected findings can be verified and closed with dated records.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement.
Your team owns the policy and decisions, and we advise on how testing evidence will look to your competent authority or auditor.
Confirm with us which regulator, sector guidance or customer requirement applies to your organization before scoping.