NIS2 Is Already Law — Are You Actually Ready?
The NIS2 Directive — officially Directive (EU) 2022/2555 — entered into force on January 16, 2023, with EU member states required to transpose it into national law by October 17, 2024. Most major economies met that deadline. If you are reading this in 2026 wondering whether NIS2 applies to your organization, the honest answer is: it probably does, and you are already behind.
This is not like GDPR where the scope was fuzzy for years. NIS2 drew explicit lines — sectors, thresholds, roles — and regulators across Germany, France, Italy, the Netherlands, and Romania have been actively issuing guidance and beginning enforcement cycles. Non-compliance is not a theoretical risk anymore. Fines of up to €10 million or 2% of global annual turnover for essential entities are on the table.
What follows is a thorough breakdown of the NIS2 Directive text, the requirements that actually matter operationally, and how to map existing security tooling and processes to satisfy them.
What Is the NIS2 Directive? Context and Background
The original NIS Directive (Directive 2016/1148) was the EU's first horizontal cybersecurity legislation. It required member states to establish Computer Security Incident Response Teams (CSIRTs), designate competent authorities, and impose security and incident notification requirements on operators of essential services and digital service providers. By 2020, the European Commission's evaluation found the original NIS Directive delivered fragmented, inconsistent implementation across member states — some countries applied it narrowly to critical infrastructure, others broadly. The baseline security measures were vague. Incident reporting thresholds were inconsistent. Supervisory powers were weak.
NIS2 is the corrective measure. It is broader in scope, more prescriptive in requirements, and carries significantly heavier enforcement teeth. The full text is available via EUR-Lex under document 32022L2555 — that is the authoritative legal source if you need the NIS2 Directive full text for procurement, legal review, or audit purposes. A NIS2 Directive PDF download is also available directly from the EUR-Lex portal in all official EU languages.
Scope: Who Does NIS2 Actually Cover?
This is where a lot of organizations trip. NIS2 replaced the binary model with a two-tier classification: essential entities and important entities. Both are subject to the same core security requirements, but supervisory intensity and maximum penalties differ.
Essential Entities
Essential entities cover eleven sectors: energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management (B2B), public administration, and space. Organizations in these sectors with more than 250 employees or an annual turnover exceeding €50 million automatically qualify as essential entities. Some categories — DNS providers, TLD registries, cloud computing service providers, data center service providers, CDN providers, and managed security service providers — qualify regardless of size.
Important Entities
Important entities cover six additional sectors: postal and courier services, waste management, manufacture of chemicals, food production and distribution, manufacturing of certain critical products, and digital providers including online marketplaces and search engines. Medium-sized enterprises with 50 or more employees and over €10 million in turnover in these sectors fall under important entity classification. This catches a lot of mid-market B2B software companies that never expected to be in scope for EU cybersecurity regulation.
NIS2 Directive Requirements: The 10 Minimum Measures
Article 21 of the NIS2 Directive text lays out the core security obligation: entities must take appropriate and proportionate technical, operational, and organisational measures to manage cybersecurity risks. The directive then enumerates ten minimum measures that must be implemented. These are not optional — they are the baseline.
1. Risk Analysis and Information Security Policies
You need a documented risk analysis methodology and formal information security policies approved at the management body level. ISO/IEC 27001:2022 or NIST CSF 2.0 map well here. The key is that policies must be board-level approved and periodically reviewed — not just exist in a dusty internal wiki.
2. Incident Handling
This means procedures for detection, containment, investigation, and post-incident review. Article 23 separately addresses incident reporting obligations. Your internal incident handling capability needs to be documented, tested, and aligned with your CSIRT or MSSP if you have outsourced detection and response.
3. Business Continuity and Disaster Recovery
Backup management, disaster recovery, and crisis management. NIS2 is explicit that this includes supply chain disruptions. Your DR runbooks need to account for third-party failure scenarios, not just internal infrastructure outages.
4. Supply Chain Security
Organizations must assess and address cybersecurity risks in their direct suppliers and service providers. That includes reviewing contractual security obligations, evaluating third-party security posture, and maintaining an inventory of critical dependencies. This connects directly to your cloud vendor risk assessment process and your Software Bill of Materials practices. The SAST capabilities in SECRAILS directly address this by identifying security flaws at the code level before they reach production environments.
5. Security in Network and Information Systems Acquisition, Development, and Maintenance
This is effectively a mandate for secure software development lifecycle practices, including vulnerability handling and disclosure. Static application security testing, dependency scanning, and secret detection in your CI/CD pipelines are regulatory baseline now. The Secret Detection capabilities in SECRAILS catch hardcoded credentials and API keys before they are committed to repositories or reach production.
6. Policies and Procedures to Assess the Effectiveness of Cybersecurity Risk-Management Measures
You need to actually measure whether your controls work. Continuous monitoring, metrics, and periodic audits. This is where tools providing ongoing posture visibility become necessary infrastructure. The CSPM platform from SECRAILS gives you continuous visibility across cloud environments, flagging misconfigurations before auditors do and mapping findings directly to compliance frameworks.
7. Basic Cyber Hygiene Practices and Cybersecurity Training
CIS Controls v8 maps tightly to this requirement. Zero trust network access, multi-factor authentication, patch management, and endpoint hardening all fall under cyber hygiene. Training programs need to be role-specific and documented — not just annual security awareness checkbox exercises that nobody remembers.
8. Policies and Procedures Regarding the Use of Cryptography and Encryption
Data at rest and in transit encryption, key management procedures, and cryptographic standards alignment. NIST SP 800-57 Part 1 Rev. 5 is the practical reference for key management. For organizations running in the cloud, this means validating that your cloud providers are using compliant encryption configurations — an area where continuous configuration monitoring delivers direct compliance value.
9. Human Resources Security, Access Control Policies, and Asset Management
Privileged access management, least-privilege principles, joiners/movers/leavers processes, and a maintained asset inventory. NIS2 treats asset visibility as foundational. You cannot protect what you cannot see. The Cloud Inventory tool from SECRAILS provides continuous asset visibility across multi-cloud environments — every resource and every configuration change tracked in real time.
10. Use of Multi-Factor Authentication or Continuous Authentication Solutions
MFA is now an explicit NIS2 requirement, not just a best practice recommendation. This applies to all external-facing systems and privileged internal access paths. Auditing your MFA coverage comprehensively is one of the first practical steps toward NIS2 compliance for most organizations.
Incident Reporting: The 24/72-Hour Clock
Article 23 of the NIS2 Directive establishes a three-stage reporting obligation that is operationally demanding. Stage one: an early warning to the relevant national CSIRT or competent authority within 24 hours of becoming aware of a significant incident. Stage two: an incident notification with initial assessment within 72 hours. Stage three: a final report within one month.
A significant incident is defined as one that has caused or is capable of causing severe operational disruption, financial loss, or material damage to other natural or legal persons. In practice, any ransomware event, significant data breach, or prolonged service disruption will trigger this threshold. Your incident response playbooks need explicit decision trees for NIS2 reporting triggers, and your SOC team needs to understand the 24-hour early warning obligation — not just the 72-hour notification window that gets more attention.
This is tighter than most organizations' current incident management cycles. IBM's Cost of a Data Breach report consistently shows mean time to identify breaches measured in weeks or months for organizations without AI-assisted detection. You cannot meaningfully comply with a 24-hour reporting obligation if your detection capability is measured in weeks.
Management Body Accountability: Personal Liability Is Real
One of the hardest-hitting provisions in NIS2 is Article 20, which places accountability squarely on management bodies. Board members and C-suite executives of essential and important entities can be held personally liable for cybersecurity risk management failures. NIS2 requirements include that management bodies must approve cybersecurity risk-management measures, oversee their implementation, and complete cybersecurity training.
This shifts cybersecurity from a CISO problem to a board-level governance obligation. If your current security governance structure does not have a formal board reporting cadence, a risk register reviewed at the executive level, and documented evidence of management approval for security policies, that gap will be identified during regulatory review.
Penalties: What Non-Compliance Actually Costs
For essential entities: maximum fines of €10 million or 2% of global annual turnover, whichever is higher. For important entities: maximum fines of €7 million or 1.4% of global annual turnover. National competent authorities also have powers to issue binding instructions, mandate security audits, suspend certifications, and — for essential entities — temporarily prohibit individuals from exercising managerial functions.
Germany's BSI, France's ANSSI, and the Netherlands' NCSC have all published detailed implementation guidance. Romania's DNSC has been actively engaging with critical infrastructure operators. The enforcement environment is active and growing.
How to Map NIS2 to Your Existing Security Stack
Most mature security programs will find significant overlap between their existing controls and NIS2 requirements. The gap is usually in documentation, continuous monitoring evidence, and supply chain coverage.
For vulnerability management, NIS2 requires systematic identification and remediation of security risks. This means evidence of continuous scanning, prioritized remediation workflows, and tracked SLAs for critical finding closure. The Vulnerability Management solution from SECRAILS provides the continuous scanning and prioritization layer that satisfies this requirement across cloud and code environments.
For policy enforcement, NIS2's requirement for documented and consistently applied security policies maps directly to infrastructure-as-code security and policy-as-code approaches. When your security policies are codified and enforced automatically in your deployment pipeline, you have both the control and the audit evidence needed for regulatory review.
Reading the Full NIS2 Directive Text
For legal, procurement, or audit purposes, the authoritative NIS2 Directive text is available on EUR-Lex at document identifier 32022L2555. The full text runs to over 80 articles and 40 recitals. Recitals 49 through 90 are particularly useful for understanding the legislative intent behind the security measures in Article 21. If you are building a compliance evidence library, cross-reference Article 21 on security measures, Article 23 on incident reporting, Article 20 on governance, and Articles 32 and 33 on supervisory measures for essential versus important entities.
NIS2 and Your Cloud Security Posture
A significant portion of NIS2 operational compliance work happens in cloud environments. Multi-cloud drift, misconfigured IAM policies, publicly exposed storage buckets, unencrypted data flows — these are exactly the risk categories NIS2's Article 21 measures are designed to address. The challenge is that manual auditing at cloud scale does not work. By the time an audit cycle completes, the environment has changed hundreds of times.
Continuous cloud security posture management — mapping your cloud configuration state to NIS2 requirements in real time — is how modern organizations maintain demonstrable compliance rather than point-in-time compliance theatre. The compliance solutions at SECRAILS are built to deliver exactly this: mapped controls, continuous evidence generation, and drift detection that keeps your NIS2 posture visible and auditable at all times.
NIS2 compliance is not a one-time project. It is an ongoing operational discipline. The organizations that treat it as a checkbox will find themselves scrambling when regulators come. The ones that embed NIS2 requirements into their security architecture and tooling will have the evidence, the posture, and the governance to demonstrate compliance under scrutiny.