What NIS2 point 6.5 security testing requires in practice
Point 6.5 of the Annex to Implementing Regulation (EU) 2024/2690 asks an in-scope entity for a policy and procedures for security testing. The entity must set the need, scope, frequency and type of its tests from its risk assessment, test against a documented methodology that covers the components relevant to secure operation, document the type, scope, time and results of each test, rate the criticality of every finding with mitigating actions, and apply mitigating actions for critical findings. The regulation sets no fixed testing frequency, so the policy has to be reviewed at planned intervals and justified by the entity's own risk picture.
That absence of a fixed frequency makes the risk assessment the hard part. A supervisor or customer will not accept "we test annually" unless the file shows why annual testing matches the entity's exposure, which systems are internet-facing, how often they change, and which threats the entity considers likely. Confirm that your risk assessment names each system in scope for testing, records the test types chosen for each (for example, vulnerability assessment, penetration testing or code review), and gives a reason for the chosen cadence. Ask whether the risk assessment is reviewed when a major change lands, because a stale risk file weakens every testing decision built on it.
Point 6.2.2(d) also requires security testing within the secure development life cycle, so the testing policy must reach the software your teams build, not only the production estate. In practice, this means defining which code reviews, dependency checks and pipeline scans run before release, and who may waive a failed check. For example, an illustrative team could require a Semgrep Community Edition scan in its CI/CD pipeline and record each blocked or accepted finding in the same register used for infrastructure results. Confirm that the policy names owners for both tracks and that one register holds the criticality rating and mitigation status for every finding.
Which systems, teams and suppliers fall under security testing scope
Scope under point 6.5 is not a fixed list. It follows from the entity's risk assessment, so each category below needs a documented reason for being tested, a documented reason for being excluded, or a decision to test it differently. Confirm the entity type first, because the sector-specific obligations that apply to a DNS provider, a cloud provider or a managed service provider change what must be covered.
Internet-facing and internal systems
Start with the exposure map. Internet-facing services such as remote access gateways, public web endpoints and mail gateways carry the most immediate external risk, while internal systems matter when an attacker has already gained a foothold. Record which hosts, addresses and network segments are in scope, and document who approved each boundary. Any system left out needs a written justification tied to the risk assessment, such as an isolated environment with no path to production data.
Applications and APIs
Applications and APIs are where authentication, authorization and input handling flaws usually appear. Inventory every production application, every API version still reachable, and any internal service exposed to partners. Check whether test coverage follows the business criticality recorded in the risk assessment, not only the size of the codebase. Ask your team to confirm which interfaces handle personal data or control transactions, since these typically warrant deeper test types.
Cloud and infrastructure
Cloud accounts, infrastructure as code, identity configurations and container platforms change faster than traditional networks, so scope must cover the configuration as well as the workloads. Include management planes, storage buckets, network policies and the administrative paths into each account. Confirm with the platform team which accounts, regions and clusters exist, because shadow accounts are a common gap in scoping exercises.
CI/CD pipelines and code repositories
Build systems, code repositories and deployment pipelines can alter production without passing through a human review. Scope should include the repositories that feed production, the runners that build them, and the secrets and credentials they hold. Protected branches and restricted push rights reduce the risk of unreviewed changes, and their settings belong in scope too. Check whether pipelines run code scanning on each change, since point 6.2.2(d) links testing to the secure development life cycle.
Endpoints and administrator workstations
Endpoints are scoped by role and access, not by count alone. Administrator workstations, jump hosts and engineering laptops with production credentials deserve priority because they provide a direct route to privileged systems. Verify that each in-scope endpoint has an agent or an inventory record that lets the team match installed software against known vulnerabilities. Excluded device classes, such as kiosks with no network path to sensitive systems, should be recorded with the reason for exclusion.
Third-party and managed components
Managed service providers, hosted platforms and open-source components can be in scope even when the entity does not operate them directly. Decide which of these the entity tests itself, which it requires its supplier to test, and what evidence the supplier must return. Contracts should specify the test types, reporting timelines and right to review results. Confirm this split with each supplier before the schedule is fixed, because gaps here are usually discovered only during an audit.
How an assessor tests security testing under point 6.5
The assessor starts with the written security testing policy and asks whether it explains why testing happens, what it covers and how often it runs. Because point 6.5 sets no fixed frequency, the assessor does not look for a particular number of tests per year. Instead, they trace each scheduled test back to the risk assessment and ask why the scope and test types were chosen for those risks. A plan that lists tests without a link to risk is the most common finding at this stage. The assessor also checks that the policy has been reviewed at planned intervals and that the review changed something when the risk picture changed.
- Risk traceability: each system or service in the test plan maps to a risk entry, and high-risk assets receive deeper or more frequent testing.
- Test type rationale: the plan explains why a given test type (for example, an authenticated scan, a penetration test or a code review) fits the asset.
- Dated schedule: the test plan and schedule are current, with owners and dates.
- Review record: the policy shows a review date, the reviewer and the changes made after the last review.
Confirm that the policy names the people who approve the plan and that the plan matches the risk assessment you would show the same assessor.
Once the plan is accepted, the assessor samples executed tests and checks whether each one followed a documented methodology. They want to see the method written before the test ran, the components it covered and the tools used. A test that exists only as a scan export with no scope statement cannot be shown to cover what the plan promised. The assessor compares the planned scope with the actual scope and asks why any difference exists. Gaps between plan and execution are acceptable when they are recorded and explained, and unexplained gaps are not.
- Methodology document: a written procedure for each test type, including the components relevant to secure operation.
- Scope and timing record: the systems tested, the dates and the testers, compared with the plan.
- Tool list: the scanners and test tools used, with versions where the tool output depends on them.
- Results archive: raw output, reports and the tester's summary kept together and retrievable.
- Independence statement: who ran the test and whether they were internal or external.
Confirm that a sampled test can be traced from the plan entry to the methodology, the raw results and the final report without manual reconstruction.
The assessor then reads the findings, looking for a consistent rating process rather than a list of severities copied from a tool. Each finding should record what was found, where, the type and scope of the test that produced it, and a criticality rating with the reasoning behind it. The assessor checks whether the rating method is documented and applied the same way across tests. They also look for a mitigating action attached to each finding, because a finding without an action is an open question rather than a record of security testing.
- Rating method: a documented scale for criticality, applied consistently across scanners, penetration tests and code reviews.
- Finding record: asset, location, test source, date and evidence for each finding.
- Action per finding: a planned mitigation, owner and target for every finding that is not closed on discovery.
- Deduplication: the same vulnerability reported by two tools or two tests appears as one tracked item.
- Tool severity override: where a team changed a scanner's rating, the change and its justification are on record.
Confirm that a reader can see how a finding moved from discovery to rating to action without consulting the tester.
The last check is whether critical findings were mitigated and whether the closure can be verified. The assessor selects critical findings and follows each one to its end state. They want evidence that the fix was applied, or that a compensating control reduced the risk, and that a retest or verification confirmed the result. A critical item marked closed with no retest or no link to a change record is a weak result. The assessor also checks timing against the entity's own internal target for critical findings, since the regulation requires action but leaves the deadline to the entity's risk assessment.
- Change linkage: each closed critical finding links to the change or configuration record that fixed it.
- Verification: a retest, rescan or review confirms the finding no longer appears.
- Compensating controls: where a fix was deferred, the record shows the interim control and its approval.
- Overdue report: the list of open critical findings with age and escalation history.
- Management visibility: reports on critical findings reached the people who own the risk.
Confirm your own internal deadline for critical findings and check that recent closures meet it, because an assessor will compare the two.
How to build a security testing program that follows the risk assessment
This sequence turns the risk assessment into a documented testing policy, a test plan per asset class and a findings register that shows critical issues were fixed. Each step produces an artifact an assessor or supervisor can inspect.
Confirm the risk assessment inputs
Start from the current risk assessment and list the systems, applications, interfaces and supplier connections it rates as relevant to secure operation. Record the threats, business impact and exposure (internet-facing, internal, third-party hosted) for each asset group, since these determine what needs testing. Confirm with the risk owner that the register is current. The output is a scoped asset list linked to risk ratings, and the step is done when every rated asset group maps to at least one owner.
Write the security testing policy and procedures
Draft a policy that states why security testing is performed, who approves it, and how it connects to the risk assessment and the secure development life cycle. Add procedures for scheduling tests, handling out-of-scope findings, protecting test data and communicating results. Management should approve the policy, since the implementing regulation makes the policy a documented obligation. The output is an approved policy and a set of procedures that name accountable roles.
Define test types and frequency per asset class
For each asset class, decide which test types apply, such as vulnerability assessment, penetration testing, code review or configuration review, and how often each runs. The regulation sets no fixed frequency, so the justification must trace back to the risk rating and to changes in the environment. Record the rationale for each choice, because an assessor will ask why a frequency was selected. The output is a test plan and schedule that a reviewer can check against the risk register.
Set the documented testing methodology
Write the methodology each test type follows, covering the components relevant to secure operation such as operating systems, applications, network services and cloud configurations. Define entry criteria, tooling, evidence to capture and the point at which a test is considered complete. Confirm the methodology covers the secure development life cycle for code-level testing. The output is a methodology document per test type that testers can repeat and a reviewer can audit.
Run and record each test
Execute the tests under the approved plan, using internal staff, an implementation partner or an independent tester depending on the skills and independence the policy requires. Record the type, scope, date and result of every test, including tools and versions used. Keep raw outputs such as scanner reports and code review notes alongside the summary. The output is a dated test record for each run, which becomes the core evidence for the testing obligation.
Rate each finding by criticality
Assess each finding against a documented rating scale that combines severity, exploitability and the business impact recorded in the risk assessment. Enter every finding in a findings register with its rating, owner, affected asset and the mitigating action proposed. Ask testers to justify ratings that differ from scanner severity labels. The output is a findings register where every entry has a criticality rating and a mitigating action.
Track mitigation of critical findings
Assign each critical finding to a named owner and apply the mitigating action before the item is closed. Where a fix cannot be applied, record a documented risk acceptance approved by the accountable manager, along with compensating controls. Retest critical items to confirm the fix worked. The output is a closed-loop register showing each critical finding, its fix or accepted risk, and the retest result.
Schedule the policy review
Review the policy, procedures and test plan at planned intervals and after significant changes to the environment, threat picture or risk assessment. Compare test results over time to decide whether frequencies and test types still match the risk. Record the review outcome, changes approved and the date of the next review. The output is a revision history for the policy and an updated test plan that management has approved.
Which evidence shows security testing is governed and working
Point 6.5 is judged on what an entity can show, not on what its policy says. The artifacts below are the examples ENISA lists in its June 2025 guidance, and each one should trace back to the risk assessment that sets the testing scope and frequency.
Versioned security testing policy
The policy sets the need, scope, frequency and test types for security testing, and it must follow the risk assessment rather than a fixed calendar. Keep it under version control with an owner, an approval record and a dated review at planned intervals. Check that each revision states what changed and why, and that the current version matches what the team actually runs.
Test plans and schedules
A test plan records which systems are tested, with which method, by whom, and when. The schedule should show how each entry traces back to a risk rating, so an assessor can see why a high-risk system is tested more often than a low-risk one. Confirm that planned tests were executed, and record the reasons for any that slipped.
Vulnerability and penetration test reports
Each report should state the type, scope, dates and results of the test, plus the methodology used. For scanning, retain the tool configuration and the scan scope so the result can be reproduced. Penetration test reports should show what was attempted, what succeeded and which findings were reproducible, so the findings can be checked later.
Code review and pipeline scan records
Code review records show who reviewed a change, what they checked and what they found, and they support the secure development requirement in point 6.2.2(d). Pipeline scan output, such as Semgrep results from CI/CD runs, adds a continuous record. Confirm that protected branches prevent merges that bypass review, so the record cannot be skipped.
Internal and external audit reports
Internal audit reports test whether the security testing process itself works, not only whether the systems passed. External audit or assessor reports give independent evidence, and they must be issued by an independent auditor or assessor. Ask for the scope, date and findings of each report, and check whether the entity closed the actions agreed in response.
Testing tools register and findings log
Maintain a list of testing tools with their versions, configurations and the scope each one covers, so the methodology can be verified. Link the findings register to remediation tickets, recording each finding's criticality rating, its mitigating action, the owner, and the closure date. Critical findings must show a completed mitigation, so the register should make open critical items visible to management.
What security testing costs to meet and what drives it up
This table breaks down the cost components of meeting point 6.5 by who is paid, whether the cost is one-time or recurring, and what drives it. Use it to build a quote request and to see where self-hosted open-source tools remove license spend while labor remains.
| Cost component | Who is paid and for what | One-time or recurring | What drives it up |
|---|---|---|---|
| Tooling and licenses | Tool vendors or hosting providers. Self-hosted open-source scanners such as Wazuh, Fleet and Semgrep Community Edition have no license fee, but hosting and upkeep still cost money. | Recurring for commercial licenses. Open-source tools carry recurring infrastructure and maintenance cost. | Number of endpoints, repositories and cloud accounts in scope. Confirm each tool's license terms and feature limits before relying on them. |
| Setup and integration | Implementation partner or internal platform engineers who deploy scanners, connect them to asset inventory and CI/CD, and set up evidence storage. | One-time, with later changes when scope or tooling changes. | Number of environments, heterogeneity of operating systems and languages, and whether scanning is wired into existing pipelines. |
| Test execution and triage | Internal security engineers or a testing provider who run scans and penetration tests, then review and deduplicate findings. | Recurring, at the frequency set by the risk assessment. | Change rate of systems, number of findings, false-positive volume, and how often new components are added. |
| Penetration testing and code review | External testers or a security testing firm, paid per engagement under a written scope. | Recurring per test cycle, plus one-time scoping for new systems. | Risk rating of the system, size of the attack surface, depth of testing methodology, and third-party components in scope. |
| Criticality rating and mitigation | Engineers and system owners who assess each finding, assign criticality, and fix critical findings. | Recurring. Effort rises with each release or patch cycle. | Number of critical findings, complexity of fixes, and whether mitigation requires changes to shared platforms or suppliers. |
| Evidence upkeep | Compliance or security staff who keep test plans, reports, methodology, tool lists and results current and retrievable. | Recurring, and grows with the number of test cycles retained. | Number of test cycles, need to show results over time, and how well evidence is generated automatically rather than assembled by hand. |
| Policy review | Management and security owners who review the testing policy at planned intervals and after significant change. | Recurring, usually tied to the review cycle and to material changes in risk. | Frequency of architecture changes, new regulatory requirements, and the number of teams that must approve the policy. |
| Assessor sampling effort | Independent auditors or assessors who sample test records, reports and remediation evidence. The organization pays for the auditor and for staff time to support sampling. | Recurring at each assessment cycle. | Size of the sample drawn, gaps in documented methodology, and how quickly staff can produce requested records. Ask the auditor for its sampling approach in writing. |
Who does what: your team, a partner and the auditor
Your organization owns the security testing policy and everything the policy decides. Point 6.5 of the Annex to Implementing Regulation 2024/2690 requires you to set the need, scope, frequency and type of security tests from your risk assessment, so the decisions about what gets tested, how often, and by which test types sit with management and the security function. Those same people accept residual risk, approve the mitigation plan for each finding, and make sure critical findings are fixed.
- Policy ownership: Approve the security testing policy, its procedures and its review interval, and assign an accountable owner.
- Risk-based scope: Decide which systems, applications, APIs and cloud environments fall in scope, and link each choice to the risk assessment.
- Risk acceptance: Record who accepts any finding left open, the reason, and the review date.
- Mitigation decisions: Assign owners and deadlines for each finding, and confirm that critical findings receive mitigating actions.
- Evidence retention: Keep test plans, reports, tool lists and remediation records in a location the auditor and supervisor can reach.
Before engaging any partner, confirm internally who signs off the policy and who can accept risk on the organization's behalf.
An implementation partner such as DeployOpen prepares the systems, tooling, methodology and evidence that the testing program depends on, and can run fixed-scope security testing against the scope you have approved. The partner does not set your risk appetite, decide which findings you accept, or certify that your program meets the regulation. Those remain with you and with the independent assessor.
- Tooling and pipelines: Set up scanning and test pipelines in your own environment, such as vulnerability detection on endpoints or code scanning in CI/CD, with configuration you can inspect.
- Methodology documents: Draft a documented testing methodology covering the components relevant to secure operation, for your review and approval.
- Evidence preparation: Produce test plans, schedules, reports, tool inventories and remediation tracking in a form an assessor can test.
- Fixed-scope testing: Carry out penetration tests, application and API testing, or cloud and infrastructure testing against a written scope, deliverables and timeline.
- Limits of the role: DeployOpen does not issue audit reports, attestations or certifications.
Before signing, ask the partner to state in writing which deliverables you receive, who owns the evidence, and which parts you must still perform yourselves.
The independent auditor, or the national competent authority that supervises your entity, tests whether the evidence shows that the security testing policy exists, is applied and is reviewed. NIS2 creates no certificate of compliance, so any formal outcome comes from an independent assessment or from supervisory action such as inspections, security audits, security scans and information requests. Only these parties issue findings or reports on your compliance.
- Policy and scope review: The assessor checks that the scope and frequency trace back to the risk assessment and that the policy has been reviewed at planned intervals.
- Methodology testing: The assessor tests whether testing followed the documented methodology and covered the relevant components.
- Evidence sampling: The assessor samples reports, test plans and remediation records to confirm that test type, scope, time and results were documented.
- Criticality and mitigation: The assessor checks that each finding was rated and that critical findings were mitigated.
- Findings: The assessor issues the observations or findings, which you then respond to.
Ask your auditor early which evidence they expect and whether they will accept reports produced by a partner.
Where security testing programs usually fall short
Most security testing programs run tests, but few can show why those tests happen, how they were performed, or what was fixed afterward. The gaps below are the ones supervisors and assessors tend to find first, and each one breaks a link between the risk assessment, the test and the evidence of remediation.
Test frequency disconnected from risk
Many programs run a penetration test once a year because that is what they have always done, with no record of how the risk assessment set that rhythm. Point 6.5 sets no fixed frequency, so the frequency must trace back to identified risks, such as internet-facing services, recent architecture changes or high-value data. Check that the risk register names the systems tested, and that the testing calendar can be explained against it.
Testing without a written methodology
Teams often run scanners and manual tests with no documented method, so two tests of the same system produce results that cannot be compared. The point 6.5 expectation is a documented methodology that covers the components relevant to secure operation. Check that each test type has a written procedure, defined tools, and a stated scope, and that testers follow it.
Findings recorded without criticality ratings
A scanner export with hundreds of unranked lines gives management nothing to act on, and it cannot show that critical issues were handled first. Each finding needs a documented criticality rating and a mitigating action or accepted risk with an owner. Check that every finding in the report carries a rating and a linked ticket.
Critical findings closed without evidence
Tickets are often marked resolved on the word of the engineer, with no retest, no change record and no proof the fix reached production. Point 6.5 requires mitigating actions to be applied for critical findings, so the record must show what changed and that the issue no longer reproduces. Check that each critical item links to a retest result and a deployment or configuration change.
No testing inside the development life cycle
Security testing often starts after a release is built, which leaves defects in code and infrastructure definitions to reach production. Point 6.2.2(d) expects security testing processes within the secure development life cycle, so testing should run at code review, build and deployment stages. Check whether pipelines block merges or releases when scans report unresolved high-severity issues, and whether the results are retained.
Security testing under NIS2: questions buyers ask
How often does NIS2 require security testing?
NIS2 and Implementing Regulation (EU) 2024/2690 do not set a fixed testing frequency. Under point 6.5, your entity sets the need, scope, frequency and type of security tests from its risk assessment, and the testing policy is reviewed at planned intervals. A supervisor will ask why you chose your frequency, so the answer should trace back to the risk assessment: systems with higher exposure or criticality, and systems that change often, usually justify more frequent testing. Keep the schedule, the rationale and the results together as evidence.
Is penetration testing mandatory under NIS2?
No supplied requirement names penetration testing specifically. Point 6.5 asks for security tests of a type chosen from your risk assessment, tested under a documented methodology that covers the components relevant to secure operation. Penetration tests are a common choice, and ENISA's June 2025 guidance lists penetration test reports among example evidence, but other test types such as vulnerability assessments, code reviews and internal or external audits can also fit. Confirm the exact test types your supervisor expects in your sector and national transposition law.
What drives the cost and effort of a NIS2 security testing program?
The cost depends on the number and complexity of systems in scope, how often each system is tested, the test types the risk assessment selects, and whether testing is one-time or recurring. Costs usually fall into three groups: the initial policy and methodology work, the test execution, and the remediation and retest work that follows critical findings. Ongoing testing recurs, so the total effort is mostly a function of how many systems you test and how often. DeployOpen does not publish a price list. Ask for a written scope that lists systems, test types, frequency and deliverables, and a quote follows from that scope.
What does the work need from our internal staff?
Internal staff must own the decisions that NIS2 places on the management body and the organization: the risk assessment that sets test scope and frequency, approval of the testing policy, acceptance of residual risk, and the assignment of owners for mitigating actions on critical findings. Engineers from IT and development teams need to provide system access, asset information, change windows and remediation capacity. Expect a named owner for the testing program and a clear escalation path for critical findings, because the regulation requires those findings to be fixed, not just reported.
Can our own team run NIS2 security testing in-house?
Yes, an in-house team can run security testing if it has the skills, tools and independence the methodology requires. The regulation requires a documented methodology, documented results, criticality ratings and mitigation of critical findings, and it does not require an external tester. Many organizations test internally for routine scanning and use external specialists for deeper tests, so the testers can check each other's work. Where an external party performs tests, the organization still owns the policy, the decisions and the evidence. Confirm with your supervisor whether they expect independent testing for any system.
How do open-source tools help produce the testing evidence?
Open-source tools can generate much of the operational evidence point 6.5 asks for, but they do not replace the methodology or the decisions. For example, Wazuh vulnerability detection correlates software inventories from monitored endpoints with a vulnerability repository, and Fleet matches installed software on enrolled hosts against sources including the NVD and OSV. Semgrep Community Edition can scan repositories continuously in CI/CD pipelines, and GitLab protected branches help show that code changes follow review. Your evidence set should combine tool output with test plans, reports and records of how each critical finding was mitigated. Confirm each tool's coverage against your own systems before relying on it.
What should we ask a partner for in a quote?
Ask for a written scope that names the systems and environments to be tested, the test types and methodology, the test frequency and how it was derived from your risk assessment, and the deliverables. Also ask which tasks the partner performs and which remain with your staff, how critical findings are rated and communicated, how mitigation support and retesting are handled, and what evidence is delivered to your files. Confirm the timeline, the conditions for changes to scope, and who will hold the final test reports. Remember that a partner prepares systems and evidence, while only an independent auditor or the supervisor assesses compliance.
How DeployOpen scopes and prepares security testing evidence
DeployOpen works under fixed-scope engagements, where the systems to be tested, the test types, the deliverables and the timeline are agreed in writing before any work starts. For point 6.5 this matters because the scope has to trace back to your own risk assessment. Before signing, ask the provider to show how each target (applications, APIs, cloud accounts, infrastructure and any AI systems or agents) was selected from the risk assessment, and who in your organization approved that selection. DeployOpen's security testing covers applications and APIs, cloud and infrastructure, AI systems and agents, and red teaming, so the written scope should state which of these are in and which are deliberately out.
DeployOpen prepares the testing policy, the documented methodology, test records and evidence packs that your organization adopts and owns. In practice that means a test plan and schedule, the type, scope, date and results of each test, a severity rating for each finding with its mitigating action, and proof that critical findings were fixed or formally accepted. These records are the kind of evidence ENISA's June 2025 guidance lists for this point. DeployOpen does not issue audit reports, attestations or certificates. An independent assessor or auditor reviews the evidence and issues any conclusion, so confirm early which assessor your competent authority or customers will accept.
Testing is not a one-off exercise under point 6.5, because frequency follows the risk assessment and changes as systems change. DeployOpen offers ongoing testing and support as a retainer, which can keep scope, schedule and evidence current between major engagements. Ask for the retainer terms in writing, including how new systems are added to scope, how critical findings are escalated, and how retest results are recorded. Whichever model you choose, the decision on frequency and test types remains with your management, and the policy should record that decision and when it is next reviewed.
