Using ENISA's NIS2 technical guidance: what it is and how to use it

Using ENISA's NIS2 technical implementation guidance: what it costs in effort and who does what

If a customer, contract or regulator now expects NIS2 evidence, the first thing to know is that ENISA's technical implementation guidance is free, non-binding and was published on 26 June 2025. It is a reuse aid that helps you map existing controls to the requirements of Implementing Regulation (EU) 2024/2690, not proof of compliance. The organization owns its controls and the decisions about them. An implementation partner such as DeployOpen can prepare systems, configuration and evidence, and document them in your own environment. Only the national competent authority, or an accredited conformity assessment body or auditor authorized under the national framework where that applies, decides whether you comply. Ask any partner to state this split in the written scope.

The effort is driven by three factors. The first is scope: how many systems, sites and suppliers fall under the requirements, and whether your entity is also covered by the 2024/2690 sector rules, which apply to only certain provider types. The second is existing coverage. If you already run an ISO/IEC 27001:2022 management system or follow NIST CSF 2.0, the ENISA mapping shows which controls you can reuse, and that usually shortens the gap work. Confirm how your current certificate or assessment scope aligns with the NIS2 requirements before assuming the overlap. The third is the Member State framework, because national transposition laws and supervisory expectations differ, so ask your competent authority which evidence it accepts.

Cost has two parts. Internal staff time covers owning policies, approving risk decisions and collecting evidence, and it recurs each review cycle. External spend covers gap analysis, technical hardening, documentation and independent assessment, where the assessor's fee is separate from any partner fee. When requesting a quote, ask the partner to list which requirements of the 2024/2690 annex are in scope, which ENISA evidence examples will be produced, what the organization must still approve, and which deliverables are handed over for the auditor. A fixed written scope makes these boundaries testable.

Who should use the guidance and how it applies to them

If your organization is a DNS service provider, TLD name registry, cloud computing service, data center, content delivery network, managed service provider, managed security service provider, online marketplace, search engine, social network platform or trust service provider in scope of Implementing Regulation (EU) 2024/2690, the technical and methodological requirements in that regulation apply to you directly. ENISA's non-binding guidance explains how to read them and gives examples of evidence for each requirement. It does not change the regulation's obligations, and it does not tell you how your national competent authority will judge your systems.

What the guidance helps with: interpreting each requirement, choosing evidence that a reviewer would expect to see, and identifying where your existing controls already meet a requirement.
What it cannot do: replace the regulation's text, set a higher or lower bar for your sector, or confirm that your implementation is compliant.
Who decides the binding requirement: the regulation applies directly, while the supervisor and the national framework determine how it is enforced and which assessment route applies.
Mapping use: the mapping to ISO/IEC 27001:2022 and NIST CSF 2.0 can reduce duplicate work, but it does not establish equivalence with those frameworks.
Assessment route: ask your national authority whether compliance is shown through an accredited conformity assessment body, an authorized auditor, or another method.

Confirm the exact service category that matches your activity before relying on any evidence example, because the scope of the regulation is defined by service type.

How to reuse ISO 27001 and NIST CSF 2.0 controls without assuming equivalence

ENISA's guidance lets entities build on existing ISO/IEC 27001:2022 and NIST CSF 2.0 work, which can reduce duplication and streamline audits. The mapping is a starting point, not proof of equivalence, so each step below keeps the reuse traceable to the implementing regulation's own requirements.

Inventory existing evidence

List the ISO 27001 or NIST CSF 2.0 controls you already run, along with the artifacts they produce: policy approvals, access review records, backup restore tests, scan reports and incident logs. Record the owner, system scope and last review date for each item. Confirm that the scope of the existing certificate or assessment covers the same entities and systems that NIS2 reaches, because a narrower scope will not carry over.

Match evidence to requirements

For each requirement in Implementing Regulation (EU) 2024/2690, identify the existing control and evidence that address it, and write the link in a single column. Check whether the evidence answers the question the requirement asks, not merely whether a similarly named control exists. Where ENISA gives an example of evidence for a requirement, compare your artifact against that example and note any difference in depth or frequency.

Document gaps explicitly

Where no existing control produces the evidence a requirement needs, record the gap with an owner, the affected systems and a target date agreed by management. Gaps often sit in areas that ISO 27001 or NIST CSF 2.0 treat lightly, such as supplier criteria, incident reporting timelines under Article 23, or documented proportionality decisions. Ask your certification body or assessor how they would treat an open gap before relying on any existing control to close it.

Mark partial matches

A control that covers only part of a requirement must be recorded as partial, with a note on what is missing. For example, an ISO 27001 access control may show account reviews without covering privileged access logging to the depth ENISA's evidence examples describe. Marking partial matches stops a green status from hiding work that a supervisor would still ask about during an inspection or security audit.

Keep the mapping as a working document

Store the mapping as an internal, versioned working document owned by the compliance lead, and review it when the ISO 27001 scope, the NIST CSF profile or the NIS2 national law changes. Do not present it to a supervisor as proof of equivalence, and do not rely on it in place of your own assessment. Confirm with your auditor or national authority how they expect the mapping to be presented if they ask for it.

Which ten policies the guidance says must be documented

What should a risk management policy contain for NIS2?

It should set out how the organization identifies, assesses and treats risks to its network and information systems, and who approves the outcome. Expect to document the scope of the assessment, the method and rating scales, asset classification, the criteria for accepting residual risk, and the review cycle. Evidence that the policy is applied includes dated risk registers, treatment plans with named owners and due dates, and management minutes showing that residual risk was reviewed and accepted. Confirm the exact policy title and required elements against ENISA's technical implementation guidance before drafting, because the guidance is the reference for naming and scope.

What must an incident handling policy document for NIS2 reporting?

It must describe how incidents are detected, triaged, classified against significance criteria, escalated and reported. Document the roles and decision makers, the criteria that make an incident significant, the steps for each stage of reporting, and how the reporting clock under Article 23 is tracked. Expect the policy to link to a response plan and to define how lessons learned feed back into controls. Evidence that it is applied includes incident tickets with timestamps, classification decisions, records of the early warning, notification and final report, post-incident reviews, and records of exercises that tested the process end to end.

What does a supply chain security policy need to cover?

It should explain how the organization assesses suppliers and service providers before and during a relationship, which security requirements go into contracts, and how supplier risk is reviewed. Cover criteria for selecting managed service and cloud providers, expectations for vulnerability disclosure and incident notification by suppliers, and how open-source components are vetted and kept up to date. Evidence that it is applied includes a maintained supplier register with risk ratings, completed due diligence questionnaires, signed contract clauses, records of supplier reviews, and documented decisions on suppliers that did not meet the criteria.

How should a security testing policy be written for NIS2?

It should define which systems are tested, which test types apply (such as vulnerability scanning, penetration testing and code review), how often each runs, who may perform tests, and how findings are ranked and remediated within set timelines. Include rules for testing production systems and for retesting after fixes. Evidence that it is applied includes scan and test reports, remediation tickets linked to findings, retest results and records of accepted exceptions. Testing providers such as DeployOpen can run and document tests, but the organization owns the policy and decides on remediation. Only an independent assessor can issue an assessment report.

What does a cryptography policy need to say to satisfy NIS2?

It should state where encryption is required for data in transit and at rest, which algorithms, protocols and key lengths are approved, and who may approve an exception. Cover key generation, storage, rotation, retirement and certificate management, along with the rules for retiring weak configurations. Evidence that it is applied includes an inventory of certificates and keys with expiry dates, TLS and encryption configuration exports from servers and load balancers, key rotation logs, and an exception register with owners and review dates. Confirm the approved algorithm list against current guidance from your national authority and the ENISA publication.

What should an access control policy require for NIS2?

It should require least-privilege access, approval for granting and changing access, prompt removal when people leave or change roles, stronger controls for privileged accounts, and multi-factor authentication where the risk calls for it. Define how often access is reviewed and who performs each review. Evidence that it is applied includes access review records signed by the owners, identity provider exports showing enforced multi-factor authentication, lists of privileged accounts with their approvals, and logs showing that leavers' accounts were disabled on time.

Which other topic policies does the ENISA guidance name?

Beyond the policies on risk management, incident handling, supply chain security, security testing, cryptography and access control, the guidance names further topic-specific policies that the implementing regulation requires to be documented. Read the full list in ENISA's publication and confirm each title, because the exact names and scope must come from that source rather than from secondary summaries. Each topic policy should state its purpose, owner, scope, approval and review cycle, and should point to the procedures and records that show it is applied. Keep these policies under document control with version history, and link them to the overarching information system security policy that management approves.

How to use the guidance step by step in a readiness project

This sequence turns ENISA's non-binding guidance into a readiness file that your organization owns, with each phase closing on a named artifact that can be shown to a competent authority or an independent assessor.

Confirm scope and applicable national law
Start by establishing whether NIS2 applies to the organization or group, which Annex I or Annex II sector it falls under, and whether it is classed as essential or important. Because NIS2 is a directive, the national transposition law of the Member State with jurisdiction decides the detail, so identify that law and its competent authority. Ask the authority which assessment or certification route the national framework accepts. Output: a signed scope and jurisdiction memo, approved by management, that names the competent authority and the applicable national law. Confirm timing with that authority, since no timeline is fixed by the guidance itself.
Read the implementing regulation requirements
Read Implementing Regulation (EU) 2024/2690 alongside the ENISA guidance, requirement by requirement, but only if the organization falls within one of the entity types it binds. Other entities should still read the Article 21 measures and use the guidance as a reference. Record which requirements apply to the systems in scope. Output: a requirements register listing each applicable requirement, its owner, and whether it is in scope for each system or service. Your legal or compliance lead should sign off on the register before any gap work starts.
Map existing controls to the requirements
Compare the requirements register against controls the organization already runs. If it holds an ISO/IEC 27001:2022 certificate or follows NIST CSF 2.0, use ENISA's mapping to find reusable controls. Treat the mapping as a starting point, because ENISA warns that it does not establish equivalence. Each control must be checked against the requirement it claims to meet. Output: a control mapping workbook that links each requirement to an existing control, its documented procedure, and the reviewer who confirmed the match.
Collect evidence examples for each requirement
For each mapped control, gather the evidence that would demonstrate it in operation. ENISA's guidance gives evidence examples per requirement, such as records of logging, backups, configuration, testing and privileged access. Pull real samples from the systems, not screenshots prepared for the exercise. Note the date range each sample covers and where it is stored. Output: an evidence index that lists each sample, its source system, the period it covers and the requirement it supports. Requirements with no usable evidence move to the gap list.
Close gaps and assign owners
Review the gap list with system owners and management. For each gap, decide whether to implement a control, accept the residual risk with a documented decision, or defer it under a dated plan. Assign a named owner and a completion check to every action. Where external help is needed, define the work in a written scope before it starts. Output: a remediation register with an owner, status and closure evidence for each item, approved by the management body.
Prepare the documented policies
Write or update the policies that ENISA identifies as required, including risk management, incident handling, supply chain security, security testing, cryptography and access control. Keep them specific to the systems in scope and avoid copying generic templates. Each policy should name its owner, approval date and review cycle, and it should be approved by management. Output: an approved policy set with version history, which the evidence index can cite directly.
Run an internal review
Before any external assessment, have someone independent of the implementation team test the file. Sample a few controls, ask for the underlying evidence, and check that the policies match how the systems actually behave. Record each finding with its severity, owner and due date. Retest the findings after correction. Output: an internal review report with findings, corrective actions and retest results, signed by the reviewer and presented to management.
Request the independent assessment
Once the internal review is closed, request the assessment route the national framework allows, whether that is an accredited conformity assessment body or an auditor authorized by the national authority. An implementation partner can prepare systems and evidence, but only that independent body issues a report or certificate. Ask the assessor for a written scope, the evidence it will request, and the expected output format. Output: a signed engagement letter and a readiness file that the assessor can review, with the assessor's final report as the eventual outcome.

Why following the guidance does not prove compliance

ENISA's June 2025 guidance helps entities read Implementing Regulation (EU) 2024/2690, but it carries no legal force on its own. The cards below separate what the guidance offers from what a competent authority or an accredited assessor will actually accept as proof.

The guidance is non-binding

ENISA's technical implementation guidance is a set of recommendations, not a legal requirement. The binding obligations come from Implementing Regulation (EU) 2024/2690 and from national laws that transpose NIS2. Check which text your national authority cites in inspections, and treat ENISA's examples as a reading aid for those binding requirements.

Partial use does not establish compliance

ENISA states that implementing its guidance, in part or in full, does not by itself establish compliance. Adopting the evidence examples for logging or backups does not close a requirement if the underlying control is missing or untested. Record which requirements you adopted, which you adapted, and which you did not use, with the reason for each.

Mapping is not equivalence

ENISA maps the implementing regulation to ISO/IEC 27001:2022 and NIST CSF 2.0 so you can reuse existing controls, but the mapping does not establish equivalence. An ISO 27001 certificate or a NIST CSF profile does not automatically satisfy a NIS2 requirement. Check each mapped control against the requirement text and note any gap in your own register.

Assessment by accredited bodies

Depending on the national framework, compliance may be shown through assessment or certification by accredited conformity assessment bodies, or by auditors authorized by national authorities. Confirm with your competent authority whether it accepts self-assessment, an authorized auditor, or a certification scheme, and who pays for and issues each form of evidence.

Evidence must match actual systems

Examples in the guidance describe what evidence can look like, not what your environment produces. A log sample from a lab tenant or a backup policy with no restore test will not reflect production. Pull evidence from the systems in your scope, dated and attributable, and confirm that it covers the assets your risk assessment identified.

Document your own reasoning

Keep a dated record that links each requirement to the risk it addresses, the measure you chose, the evidence you hold, and the decision owner. Where you departed from ENISA's examples, state why your context justifies it. This record, approved by the management body, is what shows a supervisor that the choices were deliberate rather than copied.

Who owns the controls, who prepares evidence and who decides

Your organization remains accountable for NIS2 compliance under the national transposition law. Management bodies must approve and oversee the Article 21 measures, and nobody outside the organization can accept residual risk or sign off the proportionality decisions that justify which measures apply. These are governance acts, and they must be recorded by people inside the entity.

Control ownership: Named owners for each measure, policy and technical control, with authority to change the configuration they run.
Risk decisions: Approval of the risk assessment, the treatment plan and the acceptance of residual risk by the appropriate level of management.
Management approval: Sign-off of the information system security policy and the annual management review, plus records of management training.
Operational evidence: Logs, tickets, access reviews and test results generated by daily operation, which only your staff can produce at the source.
Supplier decisions: Choice of vendors and managed providers, and accountability for their contract terms.

Before engaging any partner, confirm in writing which of these items you will keep in-house and which named person signs each one.

How to choose an assessor or implementation partner for NIS2 evidence

ENISA's guidance says compliance may be demonstrated through conformity assessment bodies or auditors authorized by national authorities, depending on the Member State. Your choice of outside help should follow from that, because the partner who prepares your evidence and the body that checks it play different roles and should not be the same firm.

Confirm the national route

Start by asking which route your national competent authority accepts for demonstrating compliance: accredited conformity assessment bodies, authorized auditors, or no formal assessment at all. The route depends on your Member State's transposition law, so check it against the national rules rather than the ENISA guidance alone. Get the answer in writing before you agree on scope, because it decides which firm can issue a document your supervisor will accept.

Keep advisor and assessor independent

A firm that designed your controls and then certifies them has a conflict of interest that supervisors may question. Ask whether the firm preparing your evidence will also perform any assessment, and whether any person on the assessment team helped build the measures. Where the same organization is on both sides, ask how it documents its independence and whether an unrelated reviewer checks the final results.

Check Annex sector experience

NIS2 applies differently across the Annex I and Annex II sectors, and the entity types inside each sector carry different obligations. Ask for examples of work with organizations in your sector, described without client names, such as how they handled a hospital's clinical networks or a managed service provider's customer data. Experience with the sector's regulator matters as much as general security skill.

Ask for the evidence method

Ask how the firm collects, labels, stores and hashes evidence, who can change it, and how it keeps records of what was reviewed and when. Evidence should come from systems such as logs, configuration exports and backup restore records, not from screenshots assembled for the review. Ask to see a sample evidence index for one ENISA evidence example before you commit.

Require a written fixed scope

Ask for a written statement of which entities, sites, systems, suppliers and measures are in scope, what deliverables will be produced, and what will be excluded. Compare the scope with your risk assessment and your registered entity list. Ambiguous scope is the most common source of cost growth, so agree on the change process for adding systems before work begins.

Ask what they will not do

Before signing, ask which ENISA mapping they use for ISO/IEC 27001:2022 and NIST CSF 2.0, and whether they treat the mapping as proof of equivalence. Ask them to name the tasks they will not perform, such as issuing an attestation, deciding residual risk acceptance, or signing incident reports for your management. A reliable firm answers both questions plainly and in writing.

Questions buyers ask about the ENISA guidance before hiring help

Is ENISA's NIS2 technical implementation guidance mandatory?

No. ENISA published its June 2025 technical implementation guidance as non-binding material. It explains how to think about the requirements of Implementing Regulation (EU) 2024/2690 and gives examples of evidence for each requirement. Binding obligations come from the NIS2 Directive, the implementing regulation where it applies, and your national transposition law. ENISA also states that implementing its guidance, in part or in full, does not by itself establish compliance. Your national competent authority decides what it accepts, so confirm the expected approach with them before you rely on the guidance as your structure.

Is the ENISA guidance free to use, and under what license?

Yes. ENISA's technical implementation guidance and its mapping to ISO/IEC 27001:2022 and NIST CSF 2.0 are free to use under the Creative Commons Attribution 4.0 license (CC BY 4.0). That license lets you copy, adapt and reuse the material in your own internal documents, including policies and evidence templates, provided you give appropriate credit. The license covers the document, not the requirements themselves. Reading the guidance costs nothing, so the paid work is in applying it to your systems, which is where the cost of a NIS2 program sits.

Does the ENISA guidance cover every NIS2 entity?

It targets the entity types covered by Implementing Regulation (EU) 2024/2690: DNS service providers, TLD name registries, cloud computing providers, data center service providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers. Those entities must apply the implementing regulation directly. Other essential and important entities are not bound by it, but they can use the guidance as a reference for the Article 21 measures. Check with your competent authority how it expects your sector to be assessed, because the sector-specific rules and supervisor expectations still apply.

Does ISO 27001 certification satisfy NIS2?

No. ENISA maps the implementing regulation to ISO/IEC 27001:2022 and NIST CSF 2.0 so that entities can reuse controls they already run, and it warns that the mapping does not establish equivalence. A valid ISO 27001 certificate can show that an information security management system exists and is audited, which helps with several NIS2 measures and reduces duplicated work. It does not cover every NIS2 requirement, such as the Article 23 reporting timelines, management body duties under Article 20 or the registration obligations. NIS2 also creates no certificate of compliance, so ask your authority what evidence it accepts. The mapping is a starting point for a gap analysis, not a substitute for one.

How much effort does applying the ENISA guidance take, and what drives it?

The guidance does not supply a figure for effort, and the honest answer depends on your starting point. The main drivers are the number of systems in scope, how much of your existing ISO 27001, NIST CSF or similar program you can reuse, how many of the ten required topic-specific policies you already have, and how well your logging, backup, configuration and access records are kept today. A gap analysis against the requirements usually sets the size of the rest of the work. Ask any consultant or implementation partner for a written scope that lists the systems, requirements, policies and evidence items they will cover, and for the assumptions behind their estimate.

What does the work need from our internal team?

The internal team owns the controls, the decisions and the evidence. Management must approve the risk management measures and take the required training, as Article 20 requires. Someone in IT or platform engineering must know the systems well enough to explain configuration, logging, backups and access, because those are the items an assessor or supervisor will ask about. A security or compliance lead needs time to own the policy set and the risk assessment. An external partner can prepare systems, draft documents and collect evidence, but it cannot accept risk or sign off on behalf of your organization. Plan internal time for reviews and interviews from the start.

Can we apply the ENISA guidance ourselves without outside help?

Yes, if you have the skills and capacity in house. The guidance is free, written for practitioners, and organized by requirement with examples of evidence, so a capable security team can work through it without a consultant. Outside help makes most sense when the team lacks time, when the systems are complex or hybrid, when the gap analysis is unclear, or when you need hands-on work on logging, backups, hardening or testing. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure and prepares evidence for assessments, but it does not issue audit reports or certifications. An independent auditor or the authority you report to makes that determination.

How DeployOpen maps your systems to the guidance and prepares evidence

DeployOpen works from the written scope to the evidence a reviewer would ask for, using ENISA's June 2025 guidance as a reference for how each requirement can be shown. We deploy and harden self-hosted open-source platforms inside your own infrastructure, and we prepare systems and evidence for your assessment. Only your competent authority or an authorized assessor can judge compliance.

How we scope

We agree a written scope covering which systems, networks and suppliers fall under your NIS2 program.
We map each in-scope system to the relevant requirements of Implementing Regulation (EU) 2024/2690 and ENISA's examples of evidence.
Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before work starts.

How we build

We deploy self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks, under your control.
We configure logging, access control, backups and vulnerability handling so they produce records a reviewer can inspect.
Where you already use ISO/IEC 27001:2022 or NIST CSF 2.0 controls, we reuse them and document where ENISA's mapping does not establish equivalence.

How we hand over

We document the topic-specific policies the implementing regulation expects, drafted for your management body to review and approve.
We deliver an evidence index that links each requirement to its system configuration, logs and test results.
We run security testing on the in-scope systems and hand over findings and remediation records for your own review.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We help you prepare for supervisory requests, but your organization owns its controls and its responses to authorities.
Independent auditors and conformity assessment bodies issue any assessment reports or certifications, not DeployOpen.