On 8 July 2026, the European Commission decided to refer Ireland, Spain, France, and the Netherlands to the Court of Justice of the European Union for failing to notify national laws transposing the NIS2 Directive. The deadline had been 17 October 2024. The Commission sent letters of formal notice in November 2024 and reasoned opinions in May 2025, and the referrals ask the Court to impose a lump sum plus daily penalties until transposition is complete. The pattern matters for any business with European exposure. Enforcement of NIS2 is real, it runs through national law, and it is arriving unevenly, which makes the question of when to start less about legal certainty and more about operational readiness.
The rules are also still moving. On 20 January 2026 the Commission proposed targeted amendments to NIS2 as part of a wider cybersecurity package. They would add a "small mid-cap" category for companies with fewer than 750 employees and less than €150 million in turnover, harmonize how ransomware attacks are reported, and clarify jurisdiction and scope. The proposal is still working through Parliament and the Council. Compliance teams are therefore planning against a Directive that is in force, national laws that differ, and an amendment that has not yet been adopted.
Here is the point most NIS2 summaries skip. NIS2 is a legal duty to manage cybersecurity risk and report significant incidents. It is not a certification, and no certificate makes an organization compliant. ISO/IEC 27001 and NIST frameworks supply useful evidence and structure, but the obligation sits in national law, and supervisors judge outcomes: whether the measures are proportionate to the risk, whether management approved them, and whether an incident was reported on time. An organization can hold an ISO 27001 certificate and still miss the reporting clock.
This guide covers who NIS2 covers, including how it reaches Indian providers and suppliers, what the ten minimum measures require, how the 24-hour, 72-hour, and one-month reporting sequence works, where the NIST Risk Management Framework and the NIST AI Risk Management Framework fit alongside it, a phased roadmap, and what non-compliance costs. It is written for CISOs, compliance leads, and the technology and procurement teams at organizations that serve or operate in the European Union.
What the NIS2 Directive Is and Who It Covers
NIS2 is Directive (EU) 2022/2555, which replaced the original 2016 Network and Information Security Directive. It sets a common baseline for cybersecurity risk management and incident reporting across what the Commission describes as 18 critical sectors, including energy, transport, banking, health, digital infrastructure, ICT service management, public administration, manufacturing of key products, and digital providers. Because it is a directive, each Member State writes its own national law, so the obligations an organization faces depend on where it operates and which national authority supervises it.
Coverage generally turns on sector and size. Medium-sized and larger organizations in the listed sectors fall in scope, and certain providers, such as DNS service providers and top-level domain registries, are covered regardless of size. The Directive then splits covered organizations into two categories.
| Category | Typical members | Supervision | Maximum administrative fines Member States must provide |
|---|---|---|---|
| Essential entities | Large organizations in the highest-criticality sectors, such as energy, transport, banking, health, digital infrastructure, ICT service management, and public administration | Proactive and reactive, including audits and inspections | At least €10 million or 2% of total worldwide annual turnover, whichever is higher |
| Important entities | Other medium and large organizations in the listed sectors, including manufacturing, food, chemicals, postal services, waste management, and digital providers | Reactive, after evidence or indication of non-compliance | At least €7 million or 1.4% of total worldwide annual turnover, whichever is higher |
The fine figures are floors for the maximum, so a Member State may set higher ceilings. The full legal text is on EUR-Lex.
How NIS2 Reaches Indian Providers and Suppliers
An organization does not need an office in Frankfurt to feel NIS2. Three routes bring Indian companies into the picture.
| Indian organization type | How NIS2 reaches it | What to expect |
|---|---|---|
| Cloud, data centre, content delivery, managed service, or managed security service provider offering services in the EU | Directly, as a covered digital infrastructure or ICT service management provider. Article 26 requires such providers that are not established in the Union to designate a representative there | Full risk-management and reporting duties, the technical requirements in Implementing Regulation (EU) 2024/2690, and supervision through the Member State of the representative |
| Subsidiary or establishment of an Indian group in an EU Member State, in a covered sector | Directly, through the establishment | The same duties as any local entity under that country's law |
| Supplier to an EU essential or important entity, such as a software vendor, outsourcer, or support provider | Indirectly, through contracts. Article 21 requires covered entities to manage supply chain risk | Security clauses, audit rights, evidence requests, and incident notification timelines flowed down into agreements |
| No EU customers or operations | Not directly | Useful as a benchmark, with no legal duty |
The third row affects the most Indian companies, because the Implementing Regulation expects covered entities to write adequate security clauses into contracts with their direct suppliers and service providers. For an Indian IT services firm, the first sign of NIS2 is often a revised security addendum or a detailed questionnaire from a European client, well before any regulator makes contact. The January 2026 proposal would also oblige non-EU entities in scope to designate an EU-based representative, which tightens the existing rule, though it is a proposal and not yet law.
What Article 21 Requires: The Ten Minimum Measures
Article 21 requires covered entities to take appropriate and proportionate technical, operational, and organizational measures, using an all-hazards approach, and lists ten minimum areas. Proportionality is part of the test: the measures should reflect the entity's exposure, size, the likelihood and severity of incidents, and their societal and economic impact.
| Measure under Article 21(2) | What it means in practice | Typical evidence |
|---|---|---|
| (a) Risk analysis and information system security policies | A documented, current risk assessment and policy set approved by management | Risk register, approved policies, review records |
| (b) Incident handling | Detection, triage, response, and recovery processes | Incident response plan, exercise records, ticket history |
| (c) Business continuity and crisis management | Backup management, disaster recovery, and crisis procedures that are tested | Test results, recovery time evidence, crisis plan |
| (d) Supply chain security | Assessment and contractual control of direct suppliers and service providers | Supplier inventory, security clauses, assessment outcomes |
| (e) Security in acquisition, development, and maintenance | Secure development and procurement, including vulnerability handling and disclosure | Secure development procedures, patch records, disclosure policy |
| (f) Assessing the effectiveness of measures | Policies and procedures that test whether controls work | Vulnerability assessments, penetration tests, audit reports |
| (g) Cyber hygiene and training | Baseline practices and security training | Training records, awareness metrics |
| (h) Cryptography and encryption | Policies governing the use of cryptography | Encryption standards, key management procedures |
| (i) Human resources security, access control, and asset management | Joiner, mover, and leaver controls, access policies, and an asset inventory | Access reviews, asset register, onboarding procedures |
| (j) Multi-factor authentication and secured communications | Multi-factor or continuous authentication and secured emergency communications where appropriate | Authentication configuration, coverage reports |
ENISA's Technical Implementation Guidance, published in June 2025, translates these measures into practical expectations and examples of evidence, and maps them to ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST Cybersecurity Framework 2.0, ETSI EN 319 401, and CEN/TS 18026:2024. It was written around the Implementing Regulation for digital infrastructure and service providers, and other entity types can use it as a reference point as well.
Incident Reporting Under Article 23
The reporting duty applies to significant incidents, broadly those causing severe operational disruption or financial loss, or considerable damage to other people. The clock starts when the entity becomes aware of the incident, not when the investigation concludes.
| Deadline | Report | What it contains |
|---|---|---|
| Within 24 hours of becoming aware | Early warning | Whether the incident is suspected of being caused by unlawful or malicious acts, and whether it could have cross-border impact |
| Within 72 hours of becoming aware | Incident notification | An initial assessment, including severity and impact, and indicators of compromise where available |
| On request of the CSIRT or authority | Intermediate report | Relevant status updates |
| Within one month of the incident notification | Final report | A detailed description, the type of threat or root cause, mitigation applied and ongoing, and cross-border impact where relevant |
Organizations with both Indian and European operations face parallel clocks. India's CERT-In requires cyber incidents to be reported within six hours of detection, a rule in force since 2022, which is shorter than NIS2's 24-hour early warning. A single triage process built to satisfy the shortest clock first, with templates ready for each regulator, avoids discovering the mismatch during a live incident. The Commission's Digital Omnibus proposal envisages a single entry point for incident reporting, but until it is adopted, separate national channels remain.
Governance: Management Accountability Under Article 20
Article 20 makes cybersecurity a board-level duty. Management bodies of essential and important entities must approve the risk-management measures taken to comply with Article 21, oversee their implementation, and can be held liable for infringements. Members of management are also required to follow cybersecurity training. This is the provision that turns NIS2 from an IT project into a governance obligation, and it is where many programmes are thinnest: policies exist, but there is no record that the right people reviewed and approved them.
Where the NIST Frameworks Fit: RMF and AI RMF
One clarification comes first. NIS2 does not require or reference the NIST Risk Management Framework or the NIST AI Risk Management Framework, and ENISA's official mapping runs to ISO/IEC 27001, ISO/IEC 27002, NIST Cybersecurity Framework 2.0, ETSI, and CEN/TS 18026, not to the RMF or the AI RMF. Both NIST frameworks are voluntary and are best treated as process scaffolds an organization can use to run the risk cycle that NIS2 demands. They are particularly relevant to organizations that also serve United States federal or regulated customers, or that operate AI systems.
The NIST Risk Management Framework (SP 800-37 Rev. 2)
Revision 2 of NIST SP 800-37, published in December 2018 (NIST's announcement), defines a seven-step lifecycle for managing security and privacy risk: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor. Prepare was added in that revision, and the framework works with SP 800-53 for controls, SP 800-53A for assessment, and SP 800-137 for continuous monitoring. Its steps line up well with what NIS2 asks of an entity.
| RMF step | What it does | Related NIS2 activity |
|---|---|---|
| Prepare | Sets roles, risk strategy, risk tolerance, and approach to common controls and supply chain risk | Article 20 governance, Article 21(2)(a) risk policies, and (d) supply chain security |
| Categorize | Analyses the impact of losing confidentiality, integrity, or availability of each system | Identifying critical services, asset management under (i), and judging what counts as a significant incident |
| Select | Chooses and tailors controls proportionate to risk | Selecting measures that are proportionate under Article 21(1), mapped to ISO 27002 or CSF 2.0 |
| Implement | Deploys controls and documents how they were configured | Putting measures (b) to (j) into operation |
| Assess | Tests whether controls are implemented correctly and produce the intended outcome | Article 21(2)(f) effectiveness assessment, including vulnerability assessment and penetration testing |
| Authorize | A senior official accepts the residual risk | Management approval and accountability under Article 20 |
| Monitor | Maintains ongoing awareness of control effectiveness and risk | Detection readiness for Article 23 reporting and continuing risk review |
The fit has limits. The RMF is system-centric and grew out of United States federal practice, whereas NIS2 works at the level of the entity, adds supply chain duties, and attaches a reporting clock the RMF does not have. It supplies a disciplined way to categorize, select, assess, and authorize, and it does not supply the national-law mapping or the notification workflow.
The NIST AI Risk Management Framework
NIST's AI Risk Management Framework, released in January 2023, is organized around four functions: Govern, Map, Measure, and Manage. A Generative AI Profile (NIST AI 600-1) followed in July 2024. NIST's AI Resource Center notes that AI RMF 1.0 is being revised and that the Playbook will be updated after the revision, so organizations should anchor on version 1.0 and the Generative AI Profile for now. NIST has also released a preliminary draft of a Cyber AI Profile, NIST IR 8596, which extends Cybersecurity Framework 2.0 to AI-specific risks and is intended to be used alongside the AI RMF.
NIS2 contains no AI-specific measures, but Article 21 is technology-neutral and covers the network and information systems an entity relies on. An AI-enabled security operations tool, a customer-facing language model application, or an agent with access to internal systems is part of that estate, and its risks belong in the same risk analysis.
| AI RMF function | What it covers | Related NIS2 activity |
|---|---|---|
| Govern | Policies, accountability, and culture for AI use | Article 20 oversight and Article 21(2)(a) policies, including an inventory that exposes unapproved AI tools |
| Map | Context and risk identification for each AI system | Risk analysis, asset management under (i), and supply chain review of third-party models under (d) |
| Measure | Testing, evaluation, and verification of AI behavior and security | Effectiveness assessment under (f), including adversarial testing of AI applications |
| Manage | Prioritizing and responding to AI risks | Incident handling under (b) and Article 23 reporting when an AI-related incident is significant |
The EU AI Act runs on a separate timetable. The EU's Digital Omnibus on AI moved the application date for stand-alone high-risk AI obligations to 2 December 2027, but NIS2 duties already apply wherever national transposition is in force, so an AI system that supports a covered service falls under those risk duties today regardless of the AI Act schedule.
A Phased Compliance Roadmap
The timings below are indicative and depend on size, existing maturity, and the national law that applies.
| Phase | Indicative window | Key outputs |
|---|---|---|
| 1. Scope and applicability | Weeks 1 to 4 | Entity status in each Member State, sector and size analysis, national authority identified, representative need assessed |
| 2. Governance setup | Weeks 2 to 8 | Management approval path, named accountability, training for management, and RMF-style Prepare activities |
| 3. Gap assessment | Weeks 4 to 12 | Existing controls mapped against Article 21 and ENISA guidance, with a scored gap register |
| 4. Remediation and implementation | Months 3 to 9 | The ten measures implemented, supplier contracts updated, multi-factor authentication and cryptography policy in place |
| 5. Reporting readiness | Months 3 to 6 | A 24-hour and 72-hour workflow, templates for each authority, and a tabletop exercise aligned with CERT-In timelines |
| 6. Testing and verification | Months 6 to 12 | Vulnerability assessment, penetration testing, red or purple team exercises, and AI security testing where AI is in scope |
| 7. Operate and monitor | Ongoing | Continuous monitoring, management review, and re-baselining as national laws and amendments change |
What Non-Compliance Costs
| Gap | Consequence |
|---|---|
| Measures that are not proportionate to the risk or not documented | Supervisory orders to bring measures into compliance, and fines up to the national ceiling |
| Management has not approved or overseen the measures | Personal liability exposure under Article 20 and weaker standing with the supervisor |
| Late or missing incident reports | Breach of Article 23, separate from any penalty for the incident itself |
| Supply chain duties ignored | Failed customer audits, contract loss, and exposure when a supplier incident spreads |
| Reliance on a certificate alone | An ISO 27001 certificate does not confer NIS2 compliance, and gaps surface during supervision |
| Waiting for the 2026 amendment before acting | Lost time, since the core Article 21 and 23 duties are unchanged by the proposal |
A Maturity Model for NIS2 Readiness
Level 1: Applicability has not been assessed, and security work is driven by customer questionnaires ↓ Level 2: Applicability is determined and policies are written, but incident reporting exists only on paper ↓ Level 3: Article 21 measures are mapped to ISO 27001 or CSF 2.0, supplier clauses are updated, and the 24-hour and 72-hour workflow has been tested ↓ Level 4: An RMF-style lifecycle of categorize, select, assess, authorize, and monitor runs across systems, AI systems are inventoried and assessed under the AI RMF functions, and management approval is recorded ↓ Level 5: Evidence is collected continuously and cross-mapped to NIS2 national laws, CERT-In, and DPDP obligations, with regular reporting to management
A Readiness Playbook
- Determine applicability in each country of operation. Sector, size, and establishment decide whether an organization is essential, important, or out of scope, and the answer can differ by Member State.
- Identify the national authority and law for each exposure. Track national variations against the Directive baseline instead of assuming one uniform rule.
- Get management approval and training on the record. Article 20 liability makes documented oversight a priority, not a formality.
- Run a gap assessment against Article 21 and the ENISA guidance. Map existing ISO 27001 or CSF 2.0 controls to the ten measures and score the gaps.
- Update supplier contracts and the supplier inventory. Flow security clauses, audit rights, and incident notification timelines down to direct suppliers.
- Build the reporting workflow before an incident. Define who decides that an incident is significant, who files, and which clock governs each regulator, including CERT-In.
- Test the measures and keep the evidence. Vulnerability assessment, penetration testing, and purple team exercises show that controls work, which supervisors treat as the real measure.
- Review on a fixed schedule. National laws, the pending amendment, and the organization's own systems and AI use will all change.
Common Mistakes and Edge Cases
Treating NIS2 as one law. It is a Directive implemented through national laws that differ in scope details, authorities, and timing, so a single EU-wide checklist hides real variation.
Assuming an ISO 27001 certificate equals compliance. The certificate is helpful evidence of a management system. It does not address the reporting clock, management liability, or national requirements.
Updating policies but not supplier contracts. The supply chain measure is where Indian vendors often meet NIS2 first, and where unprepared customers fail audits.
Starting the reporting clock too late. Awareness, not confirmation, starts the 24 hours, so a process that waits for full certainty will be late.
Using the NIST frameworks as if they were the NIS2 mapping. The official mapping targets ISO and CSF 2.0. The RMF and AI RMF are useful scaffolds, not substitutes for the Article 21 and 23 analysis.
Waiting for the amendment outcome. The proposal adjusts scope and adds ransomware reporting detail. It does not remove the core measures or the reporting sequence.
Overlooking the shorter CERT-In clock. A group process that targets 24 hours will miss India's six-hour requirement.
When to Use What: A Few Decision Points
ISO/IEC 27001 versus NIST CSF 2.0 as the primary control framework. ENISA maps to both, so the choice follows existing practice. An organization with a certified management system can extend it, while one with United States customers may lean toward CSF 2.0.
Adopting the NIST RMF or not. The RMF suits organizations that need formal system authorization discipline or serve United States federal customers. Others may find an ISO 27001 management system simpler, while borrowing the Categorize and Authorize ideas.
Adopting the AI RMF now or later. Organizations that already operate customer-facing AI or agents benefit from structuring that risk today. Those with minimal AI use can start with an AI inventory and revisit when NIST publishes its revision.
A single EU programme versus per-country tracking. A baseline built to the Directive and the strictest applicable national law, plus a tracker for local deviations, usually costs less than parallel programmes.
In-house versus external gap assessment and testing. Internal teams know the estate, while an independent party adds credibility with customers and supervisors.
How SecNinjaz Fits Into This
NIS2 readiness draws on two of SecNinjaz's practices. The GRC and DPDP practice covers Regulatory Compliance, ISO Certification and Compliance, Audit and Gap Assessment, Risk Management, and AI Governance, with vCISO support for organizations that need senior security leadership guiding the programme. The Cybersecurity practice covers Vulnerability Assessment, Penetration Testing, Red Teaming, Purple Teaming, Breach and Attack Simulation, AI and LLM Security Testing, and AI SOC Automation, which supply the effectiveness evidence Article 21(2)(f) expects.
SecNinjaz holds ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 42001:2023, and ISO/IEC 20000-1:2018, a combination that supports the control mapping, privacy, AI governance, and managed service discipline described above. Legal interpretation of national transposition laws remains a matter for qualified counsel in the relevant Member State, and SecNinjaz's role is the technical and governance readiness behind it. For organizations that need to turn a Directive into a working programme, that pairing of gap assessment and testing evidence is the one worth looking for, whether the organization works with SecNinjaz or anyone else.
Frequently Asked Questions
What is the NIS2 Directive and who must comply?
NIS2 is Directive (EU) 2022/2555, which sets cybersecurity risk-management and incident reporting duties for medium-sized and larger organizations across 18 critical sectors, plus certain providers regardless of size. Covered organizations are classed as essential or important entities, and each Member State applies the rules through its own national law.
Does NIS2 apply to Indian companies?
It can, in three ways. Indian cloud, data centre, managed service, and managed security service providers offering services in the EU are covered directly and must designate an EU representative. Indian subsidiaries in covered EU sectors fall under local law, and Indian suppliers to EU essential or important entities meet NIS2 through contract clauses. Companies with no EU customers or operations are not covered.
What are the NIS2 incident reporting deadlines?
Significant incidents require an early warning within 24 hours of becoming aware, an incident notification within 72 hours, an intermediate report on request, and a final report within one month of the incident notification. Organizations also subject to India's CERT-In rules must report within six hours of detection, so a shared process should target the shorter clock.
What are the penalties for NIS2 non-compliance?
Member States must provide maximum fines of at least €10 million or 2% of worldwide annual turnover for essential entities, and at least €7 million or 1.4% for important entities, whichever is higher. Supervisors can also order entities to comply and to stop infringing conduct, and Article 20 allows management bodies to be held liable.
Is ISO 27001 certification enough for NIS2 compliance?
No. ISO/IEC 27001 controls map closely to Article 21 and ENISA's guidance maps to the standard, so certification is useful evidence. NIS2 is a legal duty enforced through national law, and it adds management liability, supply chain requirements, and the incident reporting sequence that a management system certificate does not by itself address.
Where do the NIST RMF and AI RMF fit with NIS2?
NIS2 does not require either framework, and ENISA's mapping uses ISO standards and NIST CSF 2.0. The NIST Risk Management Framework (SP 800-37 Rev. 2) offers a seven-step lifecycle that mirrors the risk cycle NIS2 expects, with its Authorize step resembling management approval under Article 20. The AI RMF's Govern, Map, Measure, and Manage functions help structure the risk of AI systems that sit within an entity's network and information systems.
What is the status of the 2026 NIS2 amendment proposal?
The Commission proposed targeted amendments on 20 January 2026, including a small mid-cap category, harmonized ransomware reporting, and clearer jurisdiction and scope rules. The proposal is moving through the ordinary legislative procedure in Parliament and the Council, so it is not yet law, and the core Article 21 and Article 23 duties remain in force in the meantime.
Where should an organization start with NIS2 compliance?
Start by determining whether the organization is in scope in each country it serves and which national authority supervises it. Then get management approval on the record, run a gap assessment against Article 21 and the ENISA guidance, update supplier contracts, and build and test the 24-hour and 72-hour reporting workflow before an incident forces the question.
