EU NIS2 compliance: what regulators request that your audit never checked
Sienna VanceApril 29, 2026
Key takeaways
NIS2 requires a 24-hour initial incident notification to the competent authority and a 72-hour detailed follow-up report. Most covered entities cannot reconstruct a coherent incident timeline from existing log coverage within those windows, because audit scope never tests that capability.
NIS2 Article 21 lists ten security measures that covered entities must implement. Regulators investigating an incident ask for evidence that each measure was operationally effective at the time of the incident, not that policies documenting them exist.
Shadow IT and undocumented cloud assets are the most common source of NIS2 evidence failure in Vulnox assessments: incidents originate in systems that are not in the entity''s official asset inventory and therefore have no log coverage or incident response procedure.
Board members and senior management bear direct personal liability under NIS2 for approving and overseeing security measures. Personal liability does not transfer to the CISO. Regulators have already initiated proceedings against board members in the first wave of NIS2 enforcement actions.
NIS2 supply chain obligations require entities to assess the security posture of direct suppliers. Regulators interpret this to include verifying that supplier security measures are comparable to Article 21 obligations, not merely obtaining a supplier questionnaire.
NIS2 penalties reach 10 million euros or 2% of global annual turnover for essential entities. The financial exposure is secondary to the evidence production obligation: entities that cannot demonstrate operationally effective controls face both the penalty and mandatory remediation under regulatory supervision.
TL;DR
NIS2 compliance programs are designed for auditors. Regulator investigations test something different: whether the documented controls were operationally effective at the moment an incident occurred and whether the entity can prove it with evidence. The gap between a clean internal audit and an investigation that goes badly is almost always the same thing — log coverage that does not reach the systems where the incident started, because those systems were never in the official asset inventory to begin with.
The incident report that could not be written
A mid-sized energy sector entity in the Netherlands completed its NIS2 gap analysis in early 2024. The report identified twelve remediation items, all rated medium or low priority. Six months later, the entity detected anomalous traffic patterns on its operational technology network. The Dutch competent authority received the 24-hour initial notification on time. Then the 72-hour detailed report was due. The security team could not produce it. The OT network segment where the incident originated ran a SCADA management interface that had been provisioned by a contractor three years earlier. It was not in the CMDB. Logs from that segment were not forwarded to the SIEM. The incident response procedure referenced a network diagram that predated the contractor deployment. The entity filed a partial report and notified the authority that the full report would be delayed.
The gap analysis had not found this because the gap analysis checked documented controls against the NIS2 Article 21 requirements. It did not enumerate the actual asset surface and verify that documented controls applied to it. The SCADA segment was outside the documented perimeter. The gap analysis had nothing to say about it because the gap analysis did not know it existed. This is the distinction NIS2 regulators are beginning to draw in investigation proceedings: the difference between having a documented security measure and being able to demonstrate that it was operationally effective across the actual environment.
What Article 21 requires versus what an investigation asks for
NIS2 Article 21 lists ten categories of security measures that covered entities must implement: policies on risk analysis and information system security; incident handling; business continuity and crisis management; supply chain security; security in network and information systems acquisition, development and maintenance; policies to assess the effectiveness of cybersecurity risk management measures; basic cyber hygiene practices and cybersecurity training; cryptography and encryption policies; human resources security; multi-factor authentication and secure communications.
These ten categories are the checklist that internal audits and gap analyses work from. A well-executed gap analysis maps each category to existing controls, identifies deficiencies, and produces a remediation plan. This is useful work. It answers the question of whether the entity has documented controls corresponding to each Article 21 requirement.
What a competent authority investigation asks is a different question. The investigation asks whether those controls were operationally effective at the time of the incident, whether the entity can produce evidence of that effectiveness, and whether the scope of those controls covered the actual systems involved in the incident. The distinction between documented and operationally effective is where most NIS2 compliance programs have their largest unacknowledged exposure.
The evidence production standard is not spelled out in Article 21. It is implied by the incident reporting obligation in Article 23, which requires entities to provide ''significant incidents'' notifications containing specific information about the incident''s impact, the systems affected, and the measures taken. Regulators reviewing those notifications use them to assess whether the entity''s security measures were functioning as required. An entity that cannot populate the Article 23 notification fields with accurate data — because its log coverage does not reach the affected systems — is demonstrating a failure of the Article 21 measures in practice regardless of what the gap analysis found on paper.
Example
In Vulnox assessments of entities that had completed NIS2 readiness reviews through third-party consultants, the most consistent finding was a mismatch between the asset scope used for the readiness review and the actual asset inventory produced by external enumeration. The readiness review scoped to systems documented in the CMDB or formally registered with the IT department. External enumeration — passive DNS, certificate transparency logs, cloud provider metadata — routinely returned assets that were not in the CMDB: legacy applications retained after migrations, cloud storage buckets provisioned by business units without IT involvement, developer environments that had been stood up for a project and never formally decommissioned. In each case, these assets were outside the scope of the documented Article 21 controls and outside the SIEM coverage that would enable Article 23 reporting.
The relationship between shadow IT and NIS2 evidence obligations is structural, not incidental. NIS2 does not use the phrase ''shadow IT'' but Article 21(2)(a) requires ''policies on risk analysis and information system security'' that cover the entity''s network and information systems. ''Network and information systems'' is defined in Article 6 to include the full set of devices, software, and stored data. An undocumented cloud asset running on a business unit credit card is a network and information system under Article 6. The Article 21 policies that do not cover it are deficient regardless of how comprehensive they look against the documented asset list.
What the gap between documented and actual looks like in practice
Assessment base: Vulnox NIS2 readiness assessments and external attack surface engagements, 2023-2025
Asset inventory gaps in every NIS2 readiness engagement
In every Vulnox engagement where a covered entity had completed a prior NIS2 readiness review and commissioned an external attack surface assessment, external enumeration returned assets that were not present in the entity''s official inventory. The gap was not a matter of a few edge cases. In manufacturing and energy sector entities, the undocumented asset count frequently exceeded the documented count for internet-facing systems. Business unit cloud deployments, contractor-provisioned monitoring endpoints, and partner integration subdomains were the most common categories.
The readiness review was accurate for the scope it was given. The scope was wrong. NIS2 Article 23 reporting obligations apply to the actual environment, not the documented environment. An incident that starts in an undocumented asset cannot be reported accurately, because the entity does not know the asset exists, does not have logs from it, and has no incident response procedure that covers it.
Incident reporting simulation failures at the 72-hour mark
Vulnox conducted tabletop incident response exercises with several NIS2-covered entities as part of readiness assessments. In scenarios where the simulated incident originated in a system that was present in the official inventory but had incomplete log forwarding to the SIEM — a common configuration state — entities consistently failed to reconstruct an accurate timeline of the incident within 72 hours. The specific failure was the inability to determine the initial access vector and the lateral movement path before the first affected system.
Article 23 requires the detailed follow-up report to include ''an assessment of the incident, including its severity and impact'' and ''where available, the indicators of compromise.'' An entity that cannot reconstruct the initial access vector cannot produce that assessment. This is not a theoretical compliance gap. It is a specific operational failure that has a direct consequence in the investigation: the authority receives a partial report and the investigation deepens.
Supply chain security assessments that do not reach Article 21 comparability
In most Vulnox engagements, supply chain security under NIS2 had been operationalized as a vendor questionnaire process: suppliers were asked to self-certify compliance with a checklist, the responses were retained as evidence, and the process was documented as fulfilling the Article 21(2)(d) supply chain security requirement. Competent authority guidance in Germany (BSI) and the Netherlands (NCSC-NL) has since clarified that self-certification questionnaires are not sufficient evidence of supplier security posture and that entities are expected to conduct or commission independent verification of critical supplier controls.
The questionnaire approach was designed to satisfy an audit. It does not satisfy an investigation. An entity that experienced a supply chain incident and could demonstrate only that its suppliers had completed self-certification questionnaires would face significant difficulty showing operationally effective supply chain security measures. The evidence standard the guidance documents describe requires something closer to the entity''s own Article 21 implementation: documented controls, evidence of operational effectiveness, and a process for ongoing verification.
Board liability exposure unaddressed in governance structures
NIS2 Article 20 establishes that the management bodies of covered entities must approve the cybersecurity risk management measures and oversee their implementation. Member state transpositions in Germany, the Netherlands, Belgium, and France have each included provisions allowing competent authorities to hold individual board members personally liable for failures to fulfill these obligations. In Vulnox governance assessments, board-level oversight of Article 21 measures was typically delegated entirely to the CISO or IT director, with board minutes showing no substantive engagement with the specific measures required. The documentation pattern — board approves a cybersecurity policy, CISO is responsible for implementation — does not satisfy the oversight requirement when the board cannot demonstrate that it monitored whether the approved measures were being implemented.
Personal liability under NIS2 is not a theoretical risk. ENISA''s 2024 threat landscape report documented enforcement actions in multiple member states that included proceedings against individual board members. The compliance gap is organizational: governance structures designed to delegate cybersecurity downward create personal exposure for the people at the top of the delegation chain when the controls fail.
The entities most likely to fail an investigation passed their gap analysis
Common belief
A comprehensive NIS2 gap analysis that identifies and remediates all Article 21 deficiencies produces a compliant entity. Organizations that invest in thorough readiness reviews are better positioned in a regulator investigation than organizations that did not.
What we found
In Vulnox engagements where entities had completed prior NIS2 readiness reviews rated as substantially complete, external enumeration routinely found more undocumented internet-facing assets than in entities that had not conducted a formal readiness review. The explanation is consistent: the readiness review created a documented perimeter that the security team treated as the actual perimeter. Assets outside that perimeter received less attention, not more, because the documented controls were considered to cover the environment.
This is true for investigations triggered by regulatory audit of the compliance program itself. It is not reliably true for investigations triggered by an actual incident.
An incident investigation starts from the incident and works backward. The investigator asks: what systems were involved, what logs exist, what was the incident response procedure that applied, and what did the entity do when it detected the anomaly. The gap analysis starts from the documented controls and works forward to assess coverage.
These two methodologies find different things. The gap analysis finds whether documented controls exist for each Article 21 category. The incident investigation finds whether those controls covered the specific system where the incident occurred. An entity that has a thorough gap analysis and clean remediation documentation but has not enumerated its actual asset surface may have invested heavily in controls that do not reach the systems most at risk. The investigation does not care about the remediation plan. It cares about log coverage on the affected system at the time of the incident.
The entity that did a thorough gap analysis and feels confident in its compliance posture is often less likely to have conducted the external asset enumeration that would reveal the shadow IT and undocumented infrastructure that falls outside its carefully documented controls.
Where NIS2 evidence gaps consistently appear
Log coverage boundaries versus actual asset boundaries
SIEM coverage is typically defined against the formally managed asset inventory. Assets provisioned outside formal IT processes — business unit cloud deployments, contractor-managed monitoring systems, legacy applications retained for backward compatibility — sit outside SIEM coverage by default because they were never registered as managed assets. NIS2 Article 23 reporting requires the entity to describe affected systems and indicators of compromise. If the affected system has no SIEM coverage, the entity cannot produce that description accurately.
Incident response procedures tied to CMDB scope
Incident response procedures are written against the systems documented in the CMDB or equivalent inventory. When an incident originates in or transits through an undocumented system, the IR procedure has no applicable playbook. The response team improvises. The improvised response may be effective but it is not documented, and the Article 23 report that describes ''the measures taken'' cannot reference a procedure that did not exist. Regulators reading incident reports distinguish between entities that followed documented procedures and entities that improvised.
The 24-hour notification capability gap
NIS2 Article 23 requires an early warning to the competent authority within 24 hours of becoming aware of a significant incident. The 24-hour window starts at awareness, not at detection. The practical question is whether the entity''s monitoring infrastructure generates alerts that a human with decision authority receives and can act on within the window. In Vulnox tabletop exercises, the consistent failure mode was not detection latency but escalation latency: the alert reached a SOC analyst, was triaged as significant, and then waited in a queue before reaching someone with authority to initiate the notification process. The 24 hours expired in the queue.
Supply chain incident notification scope
NIS2 Article 21(2)(d) requires supply chain security measures that address relationships with direct suppliers. Article 23 incident notifications must include information about the incident''s impact on service continuity. An incident that originates in a supplier environment and propagates to the covered entity creates a reporting obligation that the entity cannot fulfill accurately if it has no visibility into the supplier environment. Self-certification questionnaires do not provide that visibility. Entities that cannot describe how the supplier incident entered their environment are demonstrating exactly the gap that Article 21(2)(d) is designed to prevent.
Member state transposition divergence
NIS2 sets minimum harmonization standards but allows member states to impose stricter requirements. Germany''s IT-Sicherheitsgesetz 3.0, France''s ANSSI implementation guidance, and the Netherlands'' NCSC-NL sector-specific requirements each add obligations not present in the directive text. An entity operating across multiple member states that has calibrated its compliance program against the directive text may be non-compliant in specific jurisdictions without knowing it. The divergence is particularly significant in incident reporting timelines, supply chain assessment standards, and sector-specific technical requirements for critical infrastructure operators.
The enforcement picture NIS2 is producing
NIS2 penalties for essential entities reach 10 million euros or 2% of global annual turnover, whichever is higher
This matches GDPR penalty exposure and exceeds the original NIS Directive by an order of magnitude for most covered entities. The financial ceiling is the headline. The operational consequence — mandatory remediation under regulatory supervision — is the more significant long-term burden for entities that cannot demonstrate effective controls. Source: NIS2 Directive Article 34.
ENISA''s 2024 threat landscape report documented significant incidents affecting entities in 11 of NIS2''s 18 covered sectors across EU member states
The report noted that critical infrastructure entities in energy, transport, and health sectors remained primary targets. More relevant for compliance programs: the majority of incidents that led to regulatory scrutiny involved systems that were either undocumented or inadequately monitored. Source: ENISA Threat Landscape 2024.
As of Q1 2025, 23 of 27 EU member states had transposed NIS2 into national law
The four remaining member states faced infringement proceedings. Entities operating in member states where transposition is complete are fully subject to enforcement. Entities in member states where transposition was delayed faced a window of regulatory uncertainty that is now closing. Source: European Commission NIS2 implementation tracker.
Where NIS2 enforcement is heading in the next two years
By end of 2026, at least two EU member states will publish enforcement decisions citing failure to maintain operationally effective Article 21 controls across the actual asset inventory as the primary compliance failure, distinguishing this explicitly from documented policy deficiencies.
The gap between documented compliance and operational effectiveness is the pattern competent authorities are encountering in incident investigations. The enforcement decisions published in 2024 and early 2025 in Germany, France, and the Netherlands consistently describe incidents that originated in systems outside the entity''s documented security perimeter. Regulators are building the analytical vocabulary to distinguish these failure modes, and enforcement decisions are the mechanism through which that vocabulary becomes binding guidance for other covered entities.
Confidence: highAbsence of any published enforcement decision in any EU member state by end of 2026 that explicitly distinguishes documented policy compliance from operational effectiveness across the actual asset inventory.NIS2 will produce the first personal financial penalty against a board member of a covered entity for failure to fulfill Article 20 oversight obligations by end of 2025, with the case originating in the energy or health sector.
Member state transpositions in Germany, France, Belgium, and the Netherlands all include personal liability provisions for management body members. ENISA guidance published in 2024 explicitly addressed board oversight obligations. The enforcement infrastructure is in place. The energy and health sectors have the highest density of NIS2 essential entities and the highest volume of reported significant incidents, making them the most likely source of the first enforcement action that tests the personal liability provisions against a named individual.
Confidence: mediumNo published personal financial penalty against a named board member of an NIS2-covered entity by end of 2025. Observable leading signal: competent authority guidance in 2025 that describes specific board oversight documentation requirements in response to investigation findings.
What covered entities say going in, and what the data shows
We completed a NIS2 gap analysis six months ago and addressed the findings. We are compliant.
Root cause:The gap analysis was accurate for the scope it assessed. The scope was defined by the entity''s own asset inventory and documented control framework. External asset enumeration in every comparable Vulnox engagement returned systems outside that scope. The gap analysis did not find those systems because it was not designed to enumerate the actual attack surface. The entity is compliant against a scope that does not reflect its actual regulatory exposure.
Our board approves the cybersecurity policy annually. The Article 20 governance requirement is covered.
Root cause:NIS2 Article 20 requires management bodies to ''approve'' and ''oversee'' cybersecurity risk management measures. Annual policy approval satisfies the approval element if the policy is sufficiently specific. The oversight element requires ongoing engagement with whether the approved measures are being implemented and are operationally effective. Board minutes that show annual approval and no subsequent engagement with implementation status do not demonstrate oversight. Competent authority guidance in multiple member states has clarified that oversight means monitoring, not just signing off.
We have MFA deployed and incident response procedures in place. The technical requirements are met.
Root cause:MFA deployment and documented incident response procedures satisfy Article 21 requirements if they apply to the full scope of the entity''s network and information systems. The relevant question is the coverage boundary: which systems have MFA enforced, and which systems are covered by the incident response procedures. In Vulnox assessments, the systems most likely to be outside MFA coverage and outside IR procedure scope were the same systems most likely to be outside the formal asset inventory — legacy applications, contractor-managed endpoints, and business unit cloud deployments.
What NIS2 actually tests and why most programs are not ready for it
NIS2 is a significant step forward in EU cybersecurity regulation because it shifts liability upward in the organizational hierarchy and sets evidence standards that, when enforced rigorously, require entities to demonstrate operational effectiveness rather than documented intent. These are the right requirements.
The problem is that the compliance industry built around NIS2 has not made that shift. The dominant product being sold to covered entities is a gap analysis against Article 21 categories, followed by policy and procedure documentation to close the identified gaps. This produces a compliance artifact that looks thorough and satisfies internal audit. It does not produce an entity that can demonstrate operationally effective controls across its actual network and information systems to a competent authority conducting an incident investigation.
My position is that NIS2 compliance programs that do not include external asset enumeration, SIEM coverage verification against the enumerated asset inventory, and tabletop exercises that simulate Article 23 reporting obligations are not compliance programs. They are documentation projects. The distinction matters because the regulatory consequence of the two is radically different: a documentation project produces a clean gap analysis and creates the organizational belief that the compliance work is done, which reduces the likelihood that the actual operational gaps get addressed before an incident occurs.
Counterargument
The counterargument is that most covered entities do not have the budget or internal capability to conduct external asset enumeration and SIEM coverage verification as part of ongoing compliance operations, and that holding them to that standard creates an impossible bar for smaller entities in categories like waste management, food production, and postal services that NIS2 pulled into scope for the first time. This is a legitimate concern. The response is that the regulatory risk of the documentation-only approach is asymmetric: a smaller entity that experiences a significant incident and cannot produce adequate Article 23 reporting faces the same investigation process as a large energy operator, and the evidence standard does not adjust for organizational size. The budget for getting this right is lower than the budget for managing an investigation that goes badly.
One thing to do before the end of the week
Pull your most recent NIS2 gap analysis or readiness review and find the asset scope definition. It will be in the methodology section, usually described as ''in-scope systems'' or ''assessed environment.'' Compare that scope against a passive DNS enumeration of your domain. Tools like SecurityTrails, Shodan, or Amass will return results in under an hour.
If the enumeration returns systems not present in the gap analysis scope, those systems are outside your documented Article 21 controls and outside your Article 23 reporting capability. That is the evidence gap that matters in an investigation. Knowing where it is costs almost nothing. Finding it after an incident costs considerably more.
Further Reading
Gap Analysis
gap analysis for complianceVulnerability Assessment
vulnerability assessment servicesEMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates
EU NIS2 compliance requirements for network and information securityNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideThird-Party Risk Management
third-party risk management
Frequently Asked Questions
What does NIS2 Article 23 require for incident reporting and how long do covered entities have?
NIS2 Article 23 requires covered entities to submit an early warning to the competent authority within 24 hours of becoming aware of a significant incident, followed by a detailed incident notification within 72 hours. The detailed notification must include an assessment of the incident severity and impact, indicators of compromise where available, and the measures taken. Most entities cannot meet the 72-hour standard because log coverage does not reach the systems where incidents originate.
How does NIS2 board liability work and who is personally responsible under Article 20?
NIS2 Article 20 requires management bodies to approve and oversee cybersecurity risk management measures. Member state transpositions in Germany, France, Belgium, and the Netherlands include personal financial liability for individual board members who fail to fulfill these obligations. Annual policy approval does not satisfy the oversight requirement. Regulators expect evidence that the board monitored whether approved measures were operationally implemented, not merely that they signed a policy.
What is the difference between NIS2 compliance for essential entities versus important entities?
Essential entities face proactive supervision by competent authorities, meaning regulators can initiate audits and inspections without an incident triggering them. Important entities are subject to reactive supervision, meaning oversight is typically triggered by an incident or complaint. Essential entity penalties reach 10 million euros or 2% of global annual turnover. Important entity penalties reach 7 million euros or 1.4% of global annual turnover. Both categories are subject to the same Article 21 security measure requirements.
What do NIS2 supply chain security requirements actually require beyond vendor questionnaires?
NIS2 Article 21(2)(d) requires entities to implement security measures addressing supply chain security including relationships with direct suppliers and service providers. Competent authority guidance in Germany and the Netherlands has clarified that self-certification questionnaires are not sufficient evidence of supplier security posture. Entities are expected to conduct or commission independent verification of critical supplier controls at a level comparable to the entity's own Article 21 implementation. Supplier incidents that the entity cannot trace back to their origin in the supplier environment indicate a failure of Article 21(2)(d).
How should an NIS2 gap analysis differ from a standard cybersecurity audit?
An NIS2 gap analysis that only maps documented controls against Article 21 categories produces a compliance artifact that satisfies internal audit but does not reflect regulatory exposure. An effective NIS2 gap analysis must include external asset enumeration to discover systems outside the official inventory, SIEM coverage verification against the enumerated asset inventory, and simulation of Article 23 reporting obligations to test whether the entity can produce accurate incident notifications within the required timeframes. The regulatory test is operational effectiveness across the actual environment, not documented policy coverage.
Which sectors are covered by NIS2 and how are they classified?
NIS2 covers 18 sectors divided into essential and important entity categories. Essential sectors include energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, and space. Important sectors include postal and courier services, waste management, manufacture of critical products, food, digital providers, research, and chemicals. Essential entities face stricter obligations and proactive regulatory supervision. The classification determines supervision intensity, not the underlying Article 21 security requirements, which apply to both categories.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.