What a NIS2 gap analysis is and who it is for
When a regulator, customer or contract asks for NIS2 readiness, a NIS2 gap analysis is the exercise that shows how far current controls fall short. It maps what the organization does today against the Article 21(2) measures, the management body duties in Article 20, the reporting duties in Article 23 and, for in-scope digital providers, the 13 Annex sections of Commission Implementing Regulation (EU) 2024/2690. The output is a ranked list of gaps, each with an owner and a remediation plan, because an entity that finds it does not comply must take corrective measures without undue delay under Article 21(4). The analysis itself is internal work, and its quality depends on whether it is run against the right obligations for the right entity.
The starting point is classification, not controls. Whether an entity is *essential* or *important* under Article 3 determines how its supervisor will act (ex ante for essential entities, ex post for important ones), and the sector in Annex I or II determines which rules and supervisors apply. A digital provider in one of the covered categories must also assess itself against the implementing regulation, while a manufacturer in an Annex II sector generally does not. Confirm the classification and the national law of the Member State with jurisdiction before scoping the gap analysis, because the national transposition law, not the Directive alone, sets the obligations that apply.
Be clear about roles. The organization owns its controls, its risk decisions and its management body approvals. An implementation partner can prepare systems, document policies and assemble evidence against each requirement, but NIS2 creates no certificate of compliance, and only an independent auditor or assessor issues a report. Ask any partner for a fixed scope listing the entities, sectors, systems and requirement areas covered, the evidence to be produced, and who signs off the findings. Ask your auditor or supervisor in advance which evidence they expect, since ENISA's June 2025 guidance gives examples but states that following it does not by itself establish compliance.
How to run a NIS2 gap analysis in six phases
The sequence moves from confirming who is in scope to a prioritized remediation plan, so each phase builds the evidence base the next one needs. Each phase closes with a named output that management can review and approve.
Confirm scope and entity classification
Start by establishing whether the organization is in scope, under which Annex I or Annex II sector, and whether it is classified as essential or important under Article 3. Check the national law of each Member State where the entity operates, because the transposed law sets the actual obligations. Essential and important entities share the same Article 21 and Article 23 duties, but they face different supervision and fine ceilings, so classification determines how much evidence a supervisor may request. The output is a written scope statement, approved by the management body, that names the entity type, sector, supervising authority and the group entities covered.
Build the inventory of systems and suppliers
Compile an inventory of the network and information systems, the services they support, the data they hold and the suppliers that operate or host them. Include cloud accounts, data center locations, managed service arrangements and open-source components in production. Assign each asset an owner and a criticality rating that reflects its role in the entity's services. Without this inventory, later phases cannot show which controls apply to which systems. The output is a current asset and supplier register that the team can reconcile against change records and procurement data.
Map existing controls to Article 21(2)(a) to (j) and the governance duties
Map each existing policy, control and procedure to the ten minimum measures in Article 21(2)(a) to (j). Add the management body duties in Article 20, including approval of the measures, oversight and training, and the reporting duties in Article 23, including the early warning, notification and final report. Record each mapping as met, partly met or not in place, and note the owner and the evidence that supports it. Where a control serves several measures, record it once and reference it under each. The output is a gap register at the level of the Article 21 measures, governance and reporting duties.
Map requirements to the 13 sections of Implementing Regulation 2024/2690 where applicable
If the entity is a DNS, TLD, cloud, data center, CDN, managed or managed security service provider, online platform or trust service provider, assess it against the 13 sections of the Annex to Implementing Regulation (EU) 2024/2690. Entities outside those categories should confirm that the Annex does not apply to them. For each requirement, record whether it is met, and where the regulation uses wording such as 'where appropriate', 'where applicable' or 'to the extent feasible' and the entity does not apply a requirement, write down the reasoning, as Article 2(2) of the regulation requires. Note the fixed review cycles, such as annual review of the security policy and risk assessments and quarterly assessment of recurring incidents. The output is a section-by-section assessment with documented justifications for each non-applied requirement.
Review evidence against ENISA's June 2025 examples
For each requirement marked as met, test whether the evidence would satisfy a supervisor. Use the examples of evidence in ENISA's June 2025 technical implementation guidance as a reference point, and check that each policy covers the ten topic-specific policies the implementing regulation requires. Confirm that records are dated, approved, current and tied to a named owner, and that the evidence shows the control operating, not only that a document exists. ENISA states that following its guidance does not by itself establish compliance, so treat its examples as a benchmark for the entity's own proof. The output is an evidence matrix that marks each requirement as evidenced, weakly evidenced or missing.
Prioritize gaps and set a remediation plan
Rank the gaps by the risk they leave to the entity's services, by their regulatory exposure and by the effort required to close them. Assign an accountable owner, a planned action and a verification step to each item. Under Article 21(4), an entity that finds it does not comply with the Article 21(2) measures must take corrective measures without undue delay, so the plan should be approved by the management body and tracked to closure. Where a gap depends on a supplier, record the contractual lever. The output is an approved remediation plan with owners, actions and verification criteria, which becomes the baseline for the next assessment cycle.
Which Article 21 measures to score first
Article 21(2) sets ten minimum measures, and a gap analysis scores each one as a separate component with its own evidence. The cards below name each area and the record a reviewer would ask for, using ENISA's June 2025 examples as the reference. Score the measures that depend on written policy and management decisions first, because the others draw on them.
Risk analysis and information system security policies
This is the foundation: a documented policy on risk analysis and security for network and information systems. Reviewers ask for the current risk assessment, its scope, the owner who approved it, and the date of the last review. Under Implementing Regulation 2024/2690, the security policy and risk assessment must be reviewed at least annually, so check that the review dates are recorded. Score this first, since most other components cite it.
Incident handling procedures
Check whether a documented incident handling policy exists, with detection, analysis, containment, recovery and post-incident review steps. Reviewers ask for the incident register, the criteria used to call an incident significant, and records of past drills or real events. Confirm that the register feeds the quarterly review of recurring incidents the implementing regulation requires, and that it can support the Article 23 reporting deadlines.
Business continuity and crisis management
Score whether backup management, disaster recovery and crisis management plans exist and have been tested. Reviewers ask for recovery objectives agreed by management, backup restore test records, and a crisis team roster with decision rights. A plan that has never been exercised is a common gap, so look for test reports, not only plan documents.
Supply chain security
Map every supplier that touches systems or data and check whether security requirements are set for each. Reviewers ask for supplier risk assessments, contract security clauses, and records showing how suppliers were assessed against the entity's own requirements. Open-source components and cloud providers belong in this inventory too, so record which versions and sources are used.
Security in acquisition, development and maintenance
Check how security is built into system acquisition, development and maintenance, including vulnerability handling and disclosure. Reviewers ask for secure development requirements, change records, vulnerability scan results, and the process for patching or retiring unsupported software. Confirm that the entity can show who approves changes to production systems.
Effectiveness assessment of measures
This component asks whether the entity tests that its other measures work. Reviewers look for an assessment plan, results of internal audits, penetration tests or security scans, and documented follow-up on findings. Schedule these checks so their results can feed the management review of the security policy, which is also an annual cycle.
Basic cyber hygiene and training
Check whether asset inventories, patch management, configuration baselines and staff awareness training are in place and recorded. Reviewers ask for training attendance records, patch compliance reports, and the list of approved configurations. Training also matters for management body members, so keep their records separate in the file.
Cryptography and encryption
Review the policy and procedures for cryptography, including which algorithms and key lengths are approved, and how keys are generated, stored and rotated. Reviewers ask for an inventory of encrypted systems, key management records, and the approval of any exception. Where encryption is not applied, the reasoning must be documented.
HR security and access control
Check pre-employment screening, role-based access rules and the process for removing access when staff leave or change roles. Reviewers ask for access review records, privileged account lists, and joiner, mover and leaver logs. Access reviews are often the weakest evidence, so sample real accounts against HR records during the gap analysis.
MFA and secured communications
Confirm where multi-factor or continuous authentication is required, and how emergency communications and secured voice, video and text channels are protected. Reviewers ask for the authentication configuration of critical systems, exception approvals, and the communication tools used during an incident. Test these in practice, since a policy that names MFA without configuration records does not show coverage.
Gap analysis for digital providers under Implementing Regulation 2024/2690
Implementing Regulation (EU) 2024/2690 applies to a defined list of digital providers: DNS service providers, TLD name registries, cloud computing service providers, data center service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking platforms, and trust service providers. A digital provider should first confirm that it falls in one of these categories, because the regulation sets its technical requirements for those entities and not for every in-scope company in the same sector. Map each service line to the category it fits, since a group may run several services with different obligations.
- Service-by-service mapping: Record which service line falls under which category, rather than classifying the whole company once.
- Entity-type evidence: Keep the reasoning and the source of each classification so an authority can trace it.
- Group structure: Confirm which legal entity provides each service, because the obligations attach to the provider of the service.
- Overlap with other rules: Note where a service also falls under a sector-specific law, such as DORA for certain financial entities.
- Scope changes: Re-check the mapping when services are added, sold or moved to another provider.
Check that the classification and the entity list agree with the entity's own registration with its national authority.
The implementing regulation sets its technical and methodological requirements in an Annex of 13 sections. Covered providers must assess themselves against each section, and the assessment should cover the policies, processes, technical controls and evidence that each section requires. A useful gap analysis records, for each section, what exists today, what is partly in place and what is missing, with a named owner for each line. ENISA's June 2025 guidance gives examples of evidence for these requirements, which is the most practical starting point for the evidence list.
- Section-level register: Create one row per Annex section with its status, owner, evidence location and open actions.
- Evidence examples: Use ENISA's examples to define what counts as proof for each requirement, then check your own records against them.
- Technical controls: Test the controls in production, not only in the design documents.
- Partial coverage: Mark sections that an existing ISO/IEC 27001:2022 or NIST CSF 2.0 program covers, and check the gaps that the mapping does not close.
- Ownership: Assign each section to a person who can produce the evidence, since accountability for the outcome stays with the provider.
Confirm the current text of the Annex against EUR-Lex before you freeze the register, because the working copy of the requirements must match the official text.
ENISA identifies ten topic-specific policies that the implementing regulation requires providers to document. They cover areas such as risk management, incident handling and the handling of removable media. Providers often have some of these policies in a broader security manual, but supervisors look for each topic as a separate, approved and current document. The gap analysis should therefore check each policy for existence, scope, approval and whether staff follow it. A policy that exists only in draft is a gap, even when the practice is sound.
- Policy inventory: List all ten topics and the document that covers each one, including the version and the approver.
- Approval record: Show that the management body or the designated owner approved each policy.
- Practice check: Compare what the policy says with what staff do, and log the differences as gaps.
- Cross-references: Where one document serves two topics, make the mapping explicit so an auditor can find each topic.
- Retirement: Remove or archive superseded versions so only current policies are in circulation.
Ask your legal or compliance lead to confirm that the policy set matches the list in ENISA's guidance and the current implementing regulation.
Some requirements in the implementing regulation use qualifying phrases such as 'where appropriate', 'where applicable' or 'to the extent feasible'. These phrases do not allow a provider to skip a requirement silently. If the provider decides that a requirement does not apply, or that it cannot apply it in full, it must document its reasoning. Article 2(2) of the implementing regulation sets this duty. A gap analysis should therefore flag every qualified requirement and record a decision for each one, with the facts that support it.
- Qualifier register: Find every use of the qualifying phrases in the Annex and list each one as a separate item.
- Decision record: For each item, state whether it applies, the reasoning, the date and the approver.
- Evidence of reasoning: Keep the facts behind the decision, such as the architecture, the service model or the risk assessment result.
- Review trigger: Reopen the decision when the architecture, the customer base or the threat picture changes.
- Compensating measures: Where a requirement does not apply in full, document the alternative control that addresses the same risk.
Have legal counsel or the national authority's guidance confirm that a documented exclusion is defensible in your jurisdiction.
Several requirements in the implementing regulation set fixed cycles. The security policy must be reviewed by management at least once a year, risk assessments must be reviewed at least annually, and recurring incidents must be assessed each quarter. These cycles are easy to miss in a one-time gap analysis, yet a supervisor will test whether they happen and whether the records show it. The gap analysis should therefore list each cycle with its trigger, its owner and the record that proves each occurrence.
- Cycle calendar: Record each annual and quarterly obligation with its due date and the person responsible.
- Meeting minutes: Keep dated management review minutes that show the policy was examined and what changed.
- Risk assessment history: Retain each annual review as a dated version, so the sequence can be shown.
- Recurring incident analysis: Produce a quarterly summary that groups incidents by cause and records the actions taken.
- Missed cycles: Treat a missed review as a finding with a remediation date, not as a silent gap.
Before relying on any cycle in your calendar, confirm the exact wording and points in the Annex against the official text on EUR-Lex.
Test governance and reporting duties alongside the technical controls
Governance and reporting are where many NIS2 gap analyses find the most urgent gaps, and they rarely have a technical fix. The management body must approve the Article 21 measures and oversee their implementation, and under Article 20 its members must follow training. Ask the board or its delegated committee for the minutes where the measures were approved, the most recent review of the risk management approach, and a record of attendance at cybersecurity training. If those records do not exist or are dated before the measures were adopted, that is a gap no firewall rule can close. Confirm with counsel which personal liability rules apply under your national transposition law, because the exposure differs by Member State.
Reporting readiness is the second test, and it depends on process as much as tooling. Under Article 23(4), an entity must be able to identify a significant incident and meet three deadlines: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month. A reviewer will not accept a policy that describes these deadlines. They will ask who decides that an event is significant, how the clock is started and recorded, which named people approve each submission, and which competent authority or CSIRT receives it. Run a tabletop exercise with a realistic scenario, time each step, and keep the timestamps, decision log and drafts as evidence. Where the exercise shows that the decision owner is unavailable on weekends, the fix is a documented on-call rota and a delegation rule.
Plan remediation for these items as carefully as for technical findings. Article 21(4) requires corrective measures without undue delay once an entity finds it does not comply, so each governance gap needs an owner, a target date approved by the management body, and a minute recording that decision. Deployment teams can build the logging, ticketing and notification workflows that feed the report, but the approval records and policy sign-off must come from the organization itself. An independent assessor will test whether those records were produced in practice, not only whether the documents exist.
What evidence closes a gap and what does not
A gap closes only when the organization can show a document, record or export that proves the measure operates in practice. The five evidence types below are the ones that most often decide whether a gap analysis holds up under supervisory questions. ENISA's examples are non-binding, so confirm with your national competent authority how much detail it expects.
Approved policies
A policy shows intent and ownership, not operation. Check that each policy has a named owner, a version history, a review date and approval by the management body, which the governance duties under Article 20 require. Ten topic-specific policies must be documented under the implementing regulation, so map each one to a gap and confirm the scope statement matches the systems actually in use. A policy that nobody has reviewed on the required cycle is a gap, not evidence.
Risk assessment records
Risk assessment records show that the entity identified its risks and chose measures in proportion to them, as Article 21(1) requires. Look for the asset inventory, threat and vulnerability inputs, risk ratings, treatment decisions and the date of the last review. The implementing regulation expects risk assessments to be reviewed at least annually, so a record older than that cycle leaves an open gap. Keep the risk owner's sign-off with the record.
Configuration exports
Configuration exports prove that a technical control is set as the policy says. Examples include identity provider settings, MFA enforcement, firewall rule sets, logging and retention settings and patch baselines, captured with a timestamp and the system name. Screenshots alone are weak because they cannot be reproduced. Pair each export with a check that shows the setting holds over time, not only on the day it was taken.
Test and exercise records
Test and exercise records show that a control or process works when used. Relevant records include backup restore tests, incident response tabletop exercises, vulnerability scan results with remediation tickets and penetration test reports with retest evidence. The reporting duties in Article 23 are a common gap here, so record whether the 24-hour, 72-hour and one-month steps were rehearsed. Note the date, participants, findings and the corrective actions opened.
Supplier assessments
Supplier assessments show that third parties who affect the entity's systems are checked against security requirements. Keep the due diligence questionnaire, the security clauses in the contract, incident notification commitments, audit rights and the most recent review of each critical supplier. Where a supplier provides its own certificate or report, record its scope, period and any exceptions, since a certificate that does not cover the service in use leaves a gap open.
In-house gap analysis or outside support
This table compares running the NIS2 gap analysis internally, buying a fixed-scope assessment from a consultant, and bringing in an implementation partner after the gap list is agreed. Read each row to see who owns the decisions and sign-off, and what you pay for in each model.
| Option | When it fits | What the internal team keeps | What is paid for |
|---|---|---|---|
| In-house analysis | Entity has security staff who know Article 21 and Implementing Regulation 2024/2690, and time to work through the evidence examples | Scope, method, scoring, gap ownership, remediation priorities and management sign-off | Internal staff time, plus any tools or training the team needs. No outside fee, but the work competes with operational duties |
| Consultant fixed-scope assessment | Entity needs an independent view of its current state, or lacks in-house NIS2 depth for the 13 sections of the implementing regulation | Final decisions, the remediation plan, control ownership and the board briefing | A written assessment of agreed scope and deliverables. Ask whether the gap list maps to Article 21(2)(a) to (j) and the digital provider sections where they apply |
| Implementation partner after the gap list is agreed | Gap list is approved and the entity needs systems, configurations, policies and evidence prepared | Control ownership, technical decisions, approval of every policy and evidence record, and attestation of what the organization actually operates | Preparing systems and evidence under a written scope. The partner does not issue compliance reports; supervisors and independent auditors assess the result |
| Who gives the verdict | Applies to all three options | The organization states its own compliance position | Only the national competent authority or an independent auditor provides assessment results. No option produces a NIS2 certificate |
Who owns the gap analysis, the remediation and the evidence
Your organization owns the entity's compliance position. The management body remains accountable for approving and overseeing the Article 21 measures, and a gap analysis is only useful if the people who carry that accountability make the decisions it raises. Your team sets the scope and classification, decides how each risk is treated, accepts residual risk and approves the remediation plan. Under Article 21(4), the entity must take corrective measures without undue delay once it finds non-compliance, so the owner of each gap must be named inside your organization.
- Scope and classification: confirm which entities, systems and services fall in scope and whether the entity is essential or important.
- Risk decisions: decide how each gap is treated, and document any requirement the entity does not apply, with reasoning, where the implementing regulation allows it.
- Management approval: the management body approves the measures and the remediation plan and records its oversight.
- Owners and deadlines: assign a named person to each corrective action and track progress to closure.
- Evidence custody: keep the policies, records and logs that supervisors may request.
Confirm that your management body has its training and approval records in place before any partner work starts.
An implementation partner such as DeployOpen helps prepare the systems, controls and evidence that the gap analysis examines. The partner's work is set out in a written, fixed scope, and it covers only the tasks that scope names. Typical contracted work includes helping define the assessment method, mapping existing controls to the Article 21 measures and the implementing regulation, preparing the documents and records that show each control, and carrying out the remediation the client has agreed to fund. The partner does not decide the entity's risk appetite, accept residual risk or sign off the entity's compliance position.
- Scoping support: help structure the assessment against the ten Article 21(2) measures and any applicable implementing regulation sections.
- Evidence preparation: prepare configurations, runbooks, policy drafts and logs in line with the examples ENISA gives.
- Remediation work: build or harden systems, such as self-hosted platforms in your own infrastructure, where the contract says so.
- Gap reporting: provide a gap list and remediation plan, clearly marked as the partner's working document.
- Handover: transfer documentation, configurations and ownership so your team can operate the controls.
Check that the statement of work separates assessment support from remediation and names the deliverables in writing.
An independent auditor or assessor provides the external test of the entity's controls. Only an independent party issues an audit report, attestation or certificate. NIS2 creates no certificate of compliance, and national competent authorities may request evidence such as the results of security audits by a qualified auditor under Articles 32(2) and 33(2). Whether an audit is required, and how it is structured, depends on the national transposition law and the supervisor, so confirm those requirements before you engage anyone.
- Independent testing: the auditor tests design and operation of controls against the requirements, using its own procedures.
- Report or opinion: only the auditor issues a report, and only it can state a conclusion about compliance.
- Independence: the auditor should not design or implement the controls it tests, to keep its opinion credible.
- Scope agreement: the auditor agrees its scope and sampling approach with your organization in advance.
- Supervisor expectations: confirm with your national authority which audit form and qualifications it accepts.
A partner's gap list is not an audit opinion. Ask any party that offers a "NIS2 certificate" to show the legal basis for it.
Common reasons gap analyses stall or miss gaps
Most NIS2 gap analyses fail in predictable ways: the scope is set too narrowly, existing frameworks are treated as proof, and nobody owns the result. The cards below cover five pitfalls that recur across the Article 21 measures and the implementing regulation, each with one check to run before the analysis is signed off.
Scope drawn too narrowly
Teams often assess only the production environment or the IT department, then discover that the entity's services, subsidiaries, managed providers and cloud tenants fall within the systems that NIS2 covers. Start from the entity's classification under Articles 2 and 3, then list every network and information system that supports the services in scope, including those run by third parties. Confirm the boundary with management in writing, because essential and important entities carry the same obligations but face different supervision and fine ceilings.
ISO 27001 mapping treated as proof
A control mapping shows where an existing ISO/IEC 27001:2022 control might serve a NIS2 requirement, but ENISA's mapping states that it does not establish equivalence. Teams that mark a measure as met because a matching Annex A control exists skip the NIS2-specific detail, such as the implementing regulation's cycles and documentation rules. Check each mapped requirement against the implementing regulation text and ENISA's evidence examples, and record any requirement the existing control does not cover.
No named owner per measure
A gap register with no accountable owner usually stays open. Each Article 21(2) measure and each topic-specific policy needs one named person who can approve the evidence, fund the fix and report progress to the management body. Shared ownership between IT, legal and operations tends to produce no decision at all. Before the analysis closes, confirm that every row in the register has a single owner, a due date agreed with that owner and a line to the management body that approved the Article 20 oversight.
Evidence without dates or approval
Policies and risk assessments that exist as drafts, or that carry no version history and no approval record, do not show that a measure runs. Several implementing regulation requirements set fixed cycles, such as at least annual review of risk assessments and quarterly assessment of recurring incidents, and a supervisor will check that these reviews happened on time. Collect each item with its owner, approval date, version and the date of the most recent review, and flag any artifact whose review cycle has lapsed.
Missing supplier and reporting paths
Gap analyses often cover internal controls and skip the paths that carry an incident or a supplier problem out of the organization. Check whether the entity can identify a significant incident fast enough to meet the 24-hour early warning, the 72-hour notification and the one-month final report under Article 23(4), and whether contracts with managed and cloud providers let it receive that information in time. Test the path with a tabletop exercise, not only a document review.
NIS2 gap analysis questions buyers ask
How long does a NIS2 gap analysis take?
The duration depends on scope and what you already have, so no fixed timeline applies to every entity. The main drivers are how many sites, systems and suppliers fall in scope, whether you are a digital provider that must also assess itself against the 13 sections of Implementing Regulation (EU) 2024/2690, how many policies already exist, and how quickly your staff can produce evidence. Ask any provider to state the phases, deliverables and dependencies in a written scope before work starts, and confirm which of those depend on your own people's availability.
What does a NIS2 gap analysis cost, and what drives the price?
Cost depends on the size of the environment, the number of in-scope services, the state of existing documentation and whether the analysis is done internally, by a consultant or by a technical implementation partner. The most useful quote separates the work into the Article 21 measures, the Article 20 governance and Article 23 reporting duties, and any Implementing Regulation sections that apply to you, with each item tied to evidence to be reviewed. Ask whether the price is fixed to a written scope, what is excluded (remediation, policy writing, training, testing) and whether any follow-on work recurs. No supplied fact gives a reliable figure, so treat any number without a defined scope with caution.
Does an ISO 27001 certificate cover NIS2?
No. An ISO/IEC 27001:2022 certificate does not demonstrate NIS2 compliance on its own. ENISA's mapping links the Implementing Regulation's requirements to ISO/IEC 27001:2022 and other frameworks so you can reuse existing controls, but ENISA states that the mapping does not establish equivalence. NIS2 also adds legal duties that a management system does not cover, including management body approval and training, the 24-hour, 72-hour and one-month reporting deadlines, and registration with the national authority. Use your ISO 27001 evidence as a starting point, then test each gap against the NIS2 text and the Implementing Regulation.
Can we run a NIS2 gap analysis in-house?
Yes, many organizations do the first pass internally, provided someone understands both the Article 21 measures and the technical expectations in ENISA's June 2025 guidance. The work is mostly reading your current controls, gathering evidence and comparing both against the requirements, which requires security, IT operations and legal input. Internal teams often struggle with objectivity, with the policy cycles that the Implementing Regulation sets (such as at least annual review of risk assessments) and with judging whether a 'where appropriate' exception is properly reasoned and documented. An outside reviewer can test those points, but the organization still owns its conclusions.
What does management need to do for a NIS2 gap analysis?
Management must own the outcome, because Article 20 places approval and oversight of the Article 21 measures with the management body, and members must follow training. In practice, leadership should name an accountable owner, approve the scope and the entity's classification, agree which gaps are accepted or remediated, and sign off the corrective measures required under Article 21(4) without undue delay. Management also needs to review results in a documented meeting so the record shows oversight. An implementation partner can prepare the analysis and draft material, but it cannot make these decisions for the board.
Is a NIS2 gap analysis the same as an audit?
No. A gap analysis is an internal or advisory review that compares your current state with the requirements and produces a remediation plan. An audit is an independent assessment whose result carries weight with a regulator. NIS2 creates no certificate of compliance, and national competent authorities oversee compliance through inspections, security audits, security scans, information requests and fines. Supervisors may ask for results of security audits by a qualified auditor, so a gap analysis is a preparation step. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or certifications; those come from independent auditors or certification bodies.
How DeployOpen scopes and prepares NIS2 evidence
DeployOpen's part in a NIS2 gap analysis is to plan and implement the self-hosted open-source platforms that produce the evidence, inside your own cloud accounts, data centers or air-gapped networks. Before any work starts, the scope is agreed in writing. That document should name the entity classification you are working from, the Article 21 measures and any Implementing Regulation 2024/2690 sections in play, the systems in and out of scope, the deliverables and the timeline. Most engagements are fixed-scope, so the decisions that drive cost, such as which systems count as in scope and which Annex sections apply to your entity type, are made up front rather than discovered mid-project. Ask for a written statement of which requirements you are treating as applicable and which you are documenting as not applied with reasoning.
Within that scope, DeployOpen prepares the systems, controls and evidence that an assessor or a national competent authority would ask to see: configured logging, access records, backup and restore tests, patch and vulnerability records, incident handling runbooks and the topic-specific policies that ENISA identifies. Where you agree it, DeployOpen also runs security testing against the in-scope applications, APIs, cloud and infrastructure, so that identified gaps are tested rather than assumed. Every gap found should feed a remediation plan with owners and dates, because Article 21(4) expects corrective measures without undue delay. Your management body still owns the decisions, approves the measures and oversees the remediation, and your staff own the day-to-day operation of the controls after handover.
DeployOpen does not issue audit reports, attestations or certificates. NIS2 creates no certificate of compliance, and any independent security audit or assessment must come from a qualified auditor you engage yourself. Hiring DeployOpen does not guarantee a regulator's outcome, and it does not transfer your legal responsibility for compliance. Before you sign, confirm three things in writing: who on your side owns each control, which evidence the scope commits to producing, and how handover to your own team will be done. Those answers will tell you more about the engagement's value than any general claim about readiness.
