NIS2 Security Assessment: Scope, Testing and Evidence That Holds Up

In spring, the board of a hypothetical managed hosting provider approved a budget for an "NIS2 pentest". The company has roughly four hundred staff, data centres in two EU countries, banks and telecom operators among its customers. The vendor moved fast: three weeks later a report of about a hundred and fifty pages arrived — a scanner export sorted into OWASP Top 10 categories with an upbeat "verified" stamp. The report went into the archive.

In autumn, a large customer that is itself subject to NIS2 sent a supply-chain security questionnaire. The questions were uncomfortable. Which services were in scope, and why those? Who authorised active testing, and within what limits? Which findings have been fixed, and what proves it? And above all, how does the company assess whether its security measures actually work? The hundred and fifty pages answered none of them. The money was spent, and there was no evidence anyone could point to.

The example is invented, but it pinpoints the real task. An NIS2 security assessment is not a one-off test and not a "compliant" label. It is work that produces verifiable evidence: which controls genuinely operate, where they fail under pressure, what has been fixed and how that fix was confirmed. Compliance, legal and leadership then rely on that evidence. Below we look at how to scope such an assessment, what each method shows, how to prioritise findings, review suppliers and choose a provider so the result survives the first awkward question.

What NIS2 requires of an organisation — and what it does not require of a pentest

Directive (EU) 2022/2555, known as NIS2, does not say "run a penetration test once a year". Its Article 21 requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage cybersecurity risk, and lists the minimum areas those measures must cover. They include incident handling, supply-chain security, security in the acquisition, development and maintenance of systems including vulnerability handling and disclosure, cryptography, and policies and procedures to assess the effectiveness of the risk-management measures themselves.

That last area is where a technical security assessment earns its place. A penetration test, a configuration review or an application verification answers the question "does this measure work?", but none of them replaces the risk-management system as a whole. Reducing NIS2 compliance to a single pentest confuses the measuring instrument with the thing being measured.

Applicability is settled before testing

NIS2 is a directive, not a regulation. Member States had until 17 October 2024 to transpose it into national law, and the original NIS Directive was repealed from 18 October 2024. Concrete obligations, competent authorities, procedures and sanctions therefore have to be read in the applicable national law, taking account of the jurisdiction rules for the relevant entity type, not only in the directive's text.

Not every company in the EU falls under NIS2. The European Commission explains that the directive widened sector coverage and applies a size-cap rule: as a general rule, medium and large organisations in the listed sectors come into scope, while the directive itself covers certain categories regardless of size, and Member States may identify additional entities under its risk criteria. Entities are divided into essential and important categories, with different supervisory regimes. So the first question is not "what should we test?" but "does NIS2 apply to us, in which category and under which national law?" A lawyer working from the official texts should answer it, not a testing vendor.

One caveat on changes. In January 2026 the Commission proposed targeted amendments to NIS2. Until the legislative process is complete, that is a proposal rather than law in force, and building an assessment plan on it would be premature.

Regular audits, targeted audits and scans are not the same thing

Article 32 sets out competent authorities' powers over essential entities: on-site and off-site supervision, regular and targeted audits carried out by an independent body or the authority itself, ad hoc audits, security scans, information requests and requests for evidence of audits performed. An important detail: targeted audits are based on risk assessments or other risk-related information. The directive does not create one universal "annual independent audit for everyone" rule. The frequency and form of checks depend on national law and the authority's decisions.

For whoever commissions the assessment, the practical conclusion follows. The report has to be something you can present as evidence: clear scope, a date, methodology versions, confirmed findings and retest results. An authority asking for audit evidence is precisely the situation where a context-free scanner export is useless.

Three layers of evidence: governance, technical, supply chain

A defensible NIS2 compliance assessment gathers evidence at three levels, and each answers its own question.

The governance layer asks: is cyber risk understood, does it have an owner, is it managed, and can the current state be compared with a target state? Without it, technical findings float in the air: it is unclear which risk they confirm and whose decision is needed to fix them.

The technical layer checks whether implemented controls withstand examination by an authorised team following a documented methodology. This is where penetration tests, configuration reviews and application verification live.

The supply-chain layer asks whether acquired products and services are designed and delivered securely, and whether suppliers can show it. For the provider in our example this layer runs both ways: it is a supplier to its customers and at the same time a consumer of other vendors' services.

Weakness in any layer undermines conclusions drawn from the others: a perfect pentest is worthless if nobody owns remediation, and a flawless policy counts for nothing if the default admin password is still on the control panel.

Linking to risk management: current and target profiles with NIST CSF 2.0

The NIST Cybersecurity Framework 2.0 is a US framework, not a European legal act. But its outcome-based structure gives an assessment team a neutral vocabulary for two key ideas: what the organisation does today and what it wants to achieve. Separating current and target state underpins any gap assessment or NIS2 readiness assessment.

Several CSF 2.0 resources are usable straight away. Profiles provide templates for describing current and target state. Informative References show where NIST documents overlap by topic, which helps link governance-level outcomes to technical guidance such as SP 800-115. Quick Start Guides walk through common tasks, and the CSF 2.0 Tool makes the framework's content easier to work with. Together they let you record gaps in a structured, repeatable form rather than free narrative.

There is a line worth not crossing. Mapping CSF outcomes to NIS2 Article 21 obligations is an interpretation, not a fact supplied by either framework. Such a mapping should be written down, its assumptions stated explicitly, and it should be reviewed by legal or compliance.

A word on AI in gap analysis. Any mapping a model produces should be treated as a draft, reviewed before it reaches leadership or a regulator by a person who understands both the framework and your infrastructure.

Scope: which services and assets to include

Scope is where an assessment is won or lost before the first request reaches a system. A sensible starting point is not a list of IP addresses but a list of the services for which the organisation falls under NIS2, and the assets through which those services are delivered. For a hosting provider that might be the customer self-service panel, the virtual-machine management API, the backup system, remote administration channels and the back-office systems support staff connect to.

Next, a method is chosen for each asset group. This decision deserves care, because each method produces a different kind of evidence and each has blind spots.

A scanner without configured roles, test data and authorisation rules, for instance, may not notice that a customer who substitutes another customer's identifier in a request can see the neighbour's backups. Problems like that require checks of business rules and access rights — more on it in our piece on business logic security testing.

Another scope boundary must not be blurred: active testing is permissible only with explicit written authorisation from the parties empowered to permit those actions. If the panel runs on someone else's cloud platform and backups are held by a contractor, you need to establish separately what you may test yourself, what requires additional permission from every empowered party for the affected assets and environment, and what you do not touch at all. No assessment framework grants the right to test systems the organisation does not own or control.

If you are at exactly this stage — you know which services are critical but are unsure how to break them down into testable asset groups and methods — you can discuss the technical side of scope with Pentest.red on the pentest scoping page. NIS2 applicability and the legal mapping remain with your lawyers.

Technical testing with NIST SP 800-115

NIST SP 800-115 is guidance on planning and conducting technical information security tests and examinations, analysing findings and developing mitigation. The document stresses that these processes serve different purposes: finding vulnerabilities in a system or network, and verifying compliance with a policy or other requirements. An NIS2 assessment can pursue one or both purposes within agreed scope: identifying weaknesses for the security team and supplying verifiable evidence for compliance.

Examinations and tests

A useful distinction in SP 800-115 is between examinations and tests. Examinations analyse documentation, configurations and logs without interfering with live systems. Tests actively act on systems: they send requests, attempt to bypass authentication, exploit vulnerabilities. Examinations can reduce interference with live systems; their cost and risk depend on scope, access and technique. Tests add observations of system behaviour. A good assessment plan names the chosen techniques for each asset group and explains the choice, including what each technique cannot detect.

The guide itself is an overview of techniques with their advantages and limitations, not a ready-made testing programme; no single technique is sufficient on its own.

Three phases and a practical extension

Formally, SP 800-115 describes an assessment in three phases. Planning covers scope, asset inventory, authorisations, rules of engagement and success criteria. Execution covers the examinations and tests themselves. Post-execution covers analysing findings, developing mitigation recommendations and reporting. For an NIS2 evidence base it helps to add a practical extension that is not a separate phase in the formal scheme: assigning owners and deadlines, retesting and recording the outcome.

1. Service and scopeIdentify the service that brings the organisation under NIS2, the assets it runs on, and the test boundaries with a rationale.
2. Authorisation and planWritten authorisation from empowered parties, rules of engagement, test windows, emergency contacts, and examinations and tests chosen per group.
3. ExecutionDocument and configuration examinations plus active tests; every action is recorded so it can be reproduced.
4. Post-execution analysisConfirm findings, discard false positives, map to applicable CWE and versioned ASVS requirements, assess impact on the service.
5. Remediation and retestOwners and deadlines, then a repeat check using the same technique; the file records the retest result, not a promise to fix.

The first four steps correspond to the SP 800-115 phases; the last is the practical extension without which an assessment remains a list of problems.

SP 800-115 dates from September 2008, so its catalogue of techniques needs supplementing with current sources on applications and weaknesses. But its structure — from planning through execution to analysis — is tool-independent and still gives an assessment a defensible frame.

Staging and production

A separate question is where to test. A staging environment is safer, but results obtained there do not carry over to production automatically: versions, settings, integrations, service-account privileges and even the set of enabled protections may differ. If testing ran on staging, the report should say so plainly and describe how staging differs from the live system. Production testing — with its own limits, windows and rollback plan — is agreed in the rules of engagement before work begins.

The application layer: OWASP ASVS, WSTG and HTTP mechanisms

The services of essential and important entities often reach customers through web applications and APIs, so the application layer deserves depth rather than a quick glance. The buyer has three different instruments here, and it matters not to confuse them.

ASVS as a shared yardstick

The OWASP Application Security Verification Standard provides a basis for testing technical security controls and a list of requirements for secure development. Its stated aim is to normalise the range of coverage and rigour the market offers under the name "web application security verification", using an open standard fit for commercial use. For a buyer it is arguably the most useful document in the whole set: it lets you compare what different providers actually check.

In ASVS 5.0.0, each requirement has a numeric identifier. Identifiers can change between versions, so OWASP recommends citing them with a version prefix, for example v5.0.0-1.2.5. Requirements are published in machine-readable formats including CSV and JSON. If you require versioned identifiers in reports, applicable application-control findings can be traced to a specific requirement. This preserves the comparison criterion; comparability of retest environments and preconditions must still be checked separately. How to build an application audit around such a yardstick is covered in detail in our piece on application security audits.

WSTG and the Top 10: procedures and awareness

The OWASP Web Security Testing Guide is a collection of testing procedures: exactly how to test authentication, session management and input handling. The published edition the source material relied on is 4.2. If ASVS answers "what must hold", WSTG answers "how to check it".

The OWASP Top 10, 2025 edition, is an awareness document reflecting broad consensus on the most critical web application risks. OWASP itself calls it a first step towards a secure development culture. So the phrase "the application was tested against the OWASP Top 10" should be read as describing awareness-level coverage, not verification depth. That is exactly what the report in our hypothetical example looked like.

HTTP mechanisms that are cheap to check

MDN documentation describes several protocol-level mechanisms that are inexpensive to verify. Content Security Policy lets you define which resources a page may load and helps detect and mitigate attacks such as cross-site scripting and data injection. CORS determines when a browser lets a script read another origin’s response; it does not replace server-side authorisation. Cross-Origin Resource Policy restricts use of a response in cross-origin no-cors requests and helps reduce some cross-site reading risks, including those related to speculative execution. For a quick first check of settings, MDN points to Mozilla's HTTP Observatory.

Sessions deserve their own line in the plan. HTTP itself does not keep state between requests, but that does not stop applications from building full sessions on top of it — for example, storing them server-side and linking them to the browser via a cookie, or passing a token in a header. So what you test is the specific implementation: cookie attributes, session lifetime and revocation, binding to the user, and behaviour on logout and password change.

Prioritising findings: CWE Top 25 and exploitation signals

An assessment that produces hundreds of findings with no justified order of remediation helps hardly anyone. MITRE's 2025 CWE Top 25 identifies the most dangerous weaknesses behind vulnerabilities published as CVE records. MITRE notes that these weaknesses are often easy to find and exploit and can lead to full system takeover, data theft or disruption of applications.

Two companion lists sharpen the picture. The 2025 CWE Top 10 KEV Weaknesses ranks the weaknesses behind vulnerabilities in CISA's Known Exploited Vulnerabilities (KEV) catalogue — the ones attackers actually use. MITRE also publishes weaknesses on the cusp of the Top 25 and specifically notes that some classes, such as command injection, draw particular attacker attention.

The practical method looks like this. Map technical weaknesses to CWE where applicable; record an appropriate criterion and explain non-applicability for other findings. Then rank along two axes: exploitation signals and impact on the specific in-scope service. With comparable reachability, a vulnerability in a virtual-machine management API may be more urgent than one in an internal wiki if its service impact is greater. Secrets and privileges exposed through the wiki can reverse that order; membership in a CWE class appearing in the KEV weaknesses list does not establish exploitation of a particular finding. Root-cause analysis has a second benefit: it shows where in the development lifecycle a whole class of defects can be eliminated — injection or memory-safety errors, for instance — instead of patching each instance. More on building that order in our article on risk-based vulnerability prioritisation.

CISA confirms the same classes: its Secure by Design Alerts address eliminating cross-site scripting, OS command injection and directory traversal, and a joint CISA and FBI alert covers exploitation of buffer overflows. Include these categories in the test plan and report taxonomy where they apply to the tested technology.

Suppliers and products: Secure by Design and Secure by Demand

NIS2 explicitly names supply-chain security as one of the risk-management areas, and an assessment that stops at your own perimeter misses this layer. CISA's material offers useful support here.

CISA's position is that the burden of cybersecurity has fallen disproportionately on consumers and small organisations rather than on technology manufacturers. The Secure by Design principles ask manufacturers to treat customer security as a core business requirement: products should be secure by default, and features such as multi-factor authentication, logging and single sign-on should be provided at no extra cost.

Manufacturers that sign the Secure by Design Pledge commit to making a good-faith effort towards seven key goals, and CISA publishes their progress reports. That gives supplier review concrete material to request. But a signed pledge is a promise, not independent verification. It shapes which questions to ask; it does not replace the answers.

For buyers, CISA has issued Secure by Demand guidance on negotiating software procurement, a separate Secure by Demand guide for owners and operators of operational technology, and a joint guide with Australia's ASD's ACSC on choosing secure and verifiable technologies. They translate well into questionnaires and contract requirements. Ask the supplier whether MFA, logging and single sign-on are included in the base product or sold separately. Whether it has signed the Pledge and what its latest progress report shows. Whether it has a memory-safety roadmap covering its own code and open-source dependencies. Which vulnerability classes, such as injection or directory traversal, it has eliminated architecturally rather than fixing one by one. How it tests and stages updates so they do not break customer systems.

A method for assessing third-party suppliers, including SaaS, is described in detail in our piece on third-party risk security assessment.

Accepting results and retesting

Acceptance connects assessment results to the buyer’s decision. This is where it is decided whether the organisation receives evidence or merely a document. It helps to agree in advance which artefacts the provider delivers and by what criteria you accept them.

Retesting deserves particular attention. A fix nobody verified remains a claim: it may have closed one entry point while leaving a neighbouring one, or regressed in the next release. A retest of the original case and agreed variants, recording environment, date and outcome, provides evidence within the tested scope. How such a check works and what counts as confirmation is covered in our article on penetration test remediation validation.

The file should record the version of every source used and the date of the assessment. Standards change, systems change, and a year later you need to compare like with like.

Trade-offs worth agreeing up front

Every assessment design sacrifices something. Breadth of coverage competes with depth on the most critical services: for the same budget you can run a scanner across the whole perimeter or manually dissect two key systems. Checklist review helps systematise coverage but can miss chained weaknesses unless interactions are analysed; comparative cost depends on depth and access. A one-off test is easier to procure but goes stale as systems change. The evidence base does not resolve these dilemmas for the organisation, but it makes them explicit — and then the choice can be justified to leadership.

Each framework has its own job, and none provides complete coverage: SP 800-115 sets the testing cycle, ASVS sets verifiable application requirements, CSF 2.0 provides the governance vocabulary, and the Top 10 marks the awareness level.

How to choose a provider for an NIS2 assessment

Comparing providers offering NIS2 compliance or readiness assessments makes sense only once scope and evidence requirements are defined. What you are buying is evidence quality, not a label.

Ask each candidate to name the sources and versions their methodology rests on: for example, the NIST SP 800-115 lifecycle, application verification against ASVS 5.0.0, classification by the 2025 CWE Top 25. Request an anonymised sample report and check whether applicable findings carry versioned ASVS identifiers and CWE mapping, with explicit criteria for other findings, whether examinations and tests are separated, whether technique limits and the test environment are disclosed, and whether retesting is part of the recommendations. Ask how the provider documents authorisation and rules of engagement and how it handles production systems.

Be wary of a promise that one test will make the organisation NIS2-compliant. Compliance is determined by applicable legal obligations and by competent authorities' assessment. A pentest can inform that, but it is not certification, attestation or an assurance opinion. Verify any provider claims about certifications, customers and capabilities independently.

If you want to discuss what the technical part of such an assessment — testing in-scope services, application verification, retesting — could look like for your infrastructure, see the description of our penetration testing service and outline the task on the pentest scoping page. Legal applicability, certification and work on industrial systems should be discussed separately with appropriately qualified specialists.

Bottom line: an assessment that withstands questions

Back to the provider from the opening. What it needed was not a thicker report but answers to the customer's four questions: what was tested and why, who authorised it, what was fixed and what proves it, and how the effectiveness of measures is assessed. Each answer is a separate artefact that can be kept and re-checked.

The sequence of work follows naturally: applicability under national law, current and target profiles, scope derived from services, examinations and tests along the SP 800-115 phases with written authorisation, application verification against ASVS 5.0.0, prioritisation by CWE and exploitation signals, retesting, and questions for key suppliers.

What technical sources cannot do is determine legal applicability. That is a question for the directive's official text, national law and lawyers. Organisations that keep these two questions apart, demand versioned and traceable findings, and choose providers by methodology rather than labels get from an NIS2 assessment not a folder in the archive but a foundation for real risk reduction.