NIS2 Compliance: Complete Guide for Essential & Important Entities

NIS2 is the Network and Information Security Directive 2 (Directive (EU) 2022/2555), establishing minimum cybersecurity requirements across essential and important sectors. Directives require member states to transpose their obligations into national law: NIS2 compliance in practice means compliance with the national legislation that implements the directive in each member state where an organisation operates.

The directive establishes a tiered structure. Essential entities face more intensive supervisory oversight, including proactive (ex ante) supervision, and higher financial penalties for non-compliance. Important entities face reactive (ex post) supervision, triggered by evidence of non-compliance or following a significant incident, and lower maximum penalties. Both categories must meet the same substantive obligations under Articles 20 and 21.

NIS2 leaves certification standard selection to each entity's own risk assessment; compliance is assessed by national competent authorities, each determining their own supervisory approach within the framework the directive establishes. ENISA, the EU Agency for Cybersecurity, publishes technical guidance that national competent authorities increasingly reference when assessing entity compliance; those guidelines carry practical weight even where they hold no legal force.

NIS2 applies to entities that meet two criteria: they operate in a sector covered by Annex I or Annex II of the directive, and they meet a size threshold or fall into a category that's in scope regardless of size.

Annex I and Annex II: The 18 Covered Sectors

Annex I — Sectors of High Criticality (11)

• Energy (electricity, oil, gas, hydrogen, district heating/cooling)
• Transport (air, rail, water, road)
• Banking
• Financial market infrastructures
• Health (hospitals, reference laboratories, pharmaceutical, medical device manufacturers)
• Drinking water
• Wastewater
• Digital infrastructure (DNS service providers, TLD name registries, cloud computing, data centres, content delivery networks, trust service providers, electronic communications networks and services)
• ICT service management, B2B (managed service providers, managed security service providers)
• Public administration (central and regional government)
• Space (operators of ground-based infrastructure supporting space-based services)

Annex II — Other Critical Sectors (7)

• Postal and courier services
• Waste management
• Manufacture, production and distribution of chemicals
• Food production, processing and distribution
• Manufacturing (medical devices, computers/electronics/optical products, electrical equipment, machinery, motor vehicles, other transport equipment)
• Digital providers (online marketplaces, online search engines, social networking platforms)
• Research organisations

Annex placement determines the sector, not the entity classification. Whether an organisation is an essential or important entity depends on both its sector and its size — see Size Thresholds below. As a general rule, large entities in Annex I sectors are essential; medium entities in Annex I and all in-scope entities in Annex II are important. Some categories (e.g. DNS providers, TLD registries, qualified trust service providers) are in scope regardless of size.

Size Thresholds

Within those sectors, the general rule is:

1. Essential entities: large enterprises with 250 or more employees, or annual turnover exceeding EUR 50 million and a balance sheet exceeding EUR 43 million, operating in Annex I sectors.
2. Important entities: medium enterprises with 50 to 249 employees, or annual turnover between EUR 10 million and EUR 50 million, operating in Annex I or Annex II sectors.

Several categories are in scope regardless of size: DNS service providers, top-level domain name registries, cloud computing service providers, data centre service providers, content delivery networks, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers. Central government public administration bodies are essential entities regardless of size. Member states may extend NIS2 obligations to additional entities at national level.

Article 21 sets the substantive cybersecurity requirements that all essential and important entities must meet. Ten categories of risk-management measure. Each one proportionate to the risks the entity faces, its size, and the likelihood and impact of incidents. These are functional areas defining what an entity must address; each entity selects controls appropriate to its own risk profile.

Article 21(3) confirms that entities may use European and international standards, including ISO/IEC 27001:2022, when implementing these measures. An ISO 27001:2022-certified information security management system addresses most Article 21 requirements. Three areas need specific NIS2 attention beyond typical ISO 27001 coverage: the supply chain security provisions of Article 21(2)(d), the incident reporting integration requirements of Article 23, and the management accountability obligations under Article 20.

According to the ENISA Threat Landscape 2025, 53.7% of the 4,875 cybersecurity incidents analysed in the year to June 2025 concerned essential entities as defined by the NIS2 Directive. For organisations managing ten Article 21 measures across multiple frameworks, Gracie AI Agents with Personas and Skills automates evidence collection and maps controls across ISO 27001, DORA, and NIS2 simultaneously, cutting manual audit preparation time by 75%.

Article 23 establishes the incident reporting obligations for essential and important entities. Where a significant incident occurs, entities must notify their national CSIRT (Computer Security Incident Response Team) or competent authority in three stages. A significant incident is one that has caused or is capable of causing substantial operational disruption or financial loss to the entity, or material harm to other natural or legal persons.

In addition to notifying the competent authority, entities must notify service recipients where a significant incident is likely to affect them. Where the incident may affect individuals or other organisations beyond those using the entity's services, entities should consider whether broader notification is appropriate under applicable data protection law.

The 24-hour early warning is the tightest timeline and the one most organisations find challenging without a pre-planned incident response process. Entities without a documented, tested incident classification and escalation process will struggle to meet the early warning obligation. The incident handling measure under Article 21(2)(b) and the reporting obligation under Article 23 should be designed and tested together.

NIS2 establishes a penalty framework with maximum fines that national competent authorities can impose, and expressly provides for personal accountability of management body members.

Article 20 goes further than most comparable EU directives by placing accountability directly on the management body. Management body members are required to follow training on NIS2 risk-management measures and to ensure their organisation complies with the directive. Article 20(4) provides that member states shall ensure management body members can be held liable under national law for infringements of national measures transposing NIS2. The specific form of personal liability varies by member state but may include personal fines, temporary bans from management roles, or other sanctions.

Supervisory powers available to competent authorities include on-site inspections, security audits, requests for evidence of policy and procedure implementation, and, for essential entities, binding instructions requiring specific remedial action. For essential entities, competent authorities can apply supervisory measures proactively: the authority can audit before an incident occurs.

NIS2 is an EU directive. UK organisations fall outside its direct jurisdiction as a result of UK withdrawal from the European Union. The UK implemented the original NIS Directive via the Network and Information Systems (NIS) Regulations 2018, and those regulations remain the primary UK legal framework for operators of essential services and relevant digital service providers.

NIS2 is directly relevant to UK organisations in four circumstances:

1. EU-established entities: UK-based groups that operate through EU-established subsidiaries, branches, or entities meeting the NIS2 in-scope criteria must ensure those EU entities comply with the national NIS2 transposition legislation in the relevant member states.
2. Supply chain obligations: UK organisations that supply ICT services, managed services, or other services to EU essential or important entities will face indirect NIS2 requirements through their customers' supply chain security programmes under Article 21(2)(d). This includes software vendors, cloud providers, and managed service providers with EU financial services, health, or critical infrastructure clients.
3. DORA overlap: UK financial services firms with EU-authorised entities must comply with DORA, which operates alongside NIS2 in the financial sector. Recital 16 of DORA confirms that DORA takes precedence over NIS2 where both apply to the same subject matter for financial entities, though NIS2 still governs in areas outside DORA's scope.
4. The UK Cyber Security and Resilience Bill: Announced in the King's Speech in July 2024, the Bill is expected to expand the scope of the NIS Regulations to align more closely with NIS2, including broader sector coverage, extended obligations for ICT service providers in the supply chain, and strengthened incident reporting requirements. UK organisations building NIS2-aligned programmes now will be better positioned for the UK legislative changes ahead.

UK organisations managing Cyber Essentials alongside their NIS2 programme will find the two frameworks share a common hygiene baseline; SureCloud's Cyber Essentials resource hub maps the alignment and identifies where NIS2 imposes additional obligations.

Article 21(2)(d) requires essential and important entities to address supply chain security as part of their risk-management programme. The supply chain security requirement covers security in relationships with direct suppliers and service providers, including the security practices of those suppliers, their contractual arrangements with sub-suppliers, and the security posture of the supply chain as a whole.

ENISA has published guidance on what Article 21(2)(d) means in practice. Entities should assess the security practices of their direct suppliers, implement appropriate contractual protections including audit rights and incident notification obligations, tier their suppliers by risk and criticality, and maintain a process for responding to supply chain security events. For organisations managing large supplier portfolios, this requires a systematic third-party risk management (TPRM) programme rather than ad hoc supplier assessments.

Supply chain risk management was identified as a key area of difficulty by 37% of organisations surveyed in the ENISA NIS Investments 2024 Report, making it the implementation gap most likely to surface in a regulatory audit. The supply chain security measure under NIS2 also intersects with the ICT third-party risk requirements under DORA Article 28 for financial entities; organisations in scope of both frameworks should design their TPRM programme to address both simultaneously; SureCloud's third-party risk resource hub sets out a practical approach to doing this at scale.

For financial services entities, NIS2 and DORA (the Digital Operational Resilience Act, Regulation (EU) 2022/2554) apply simultaneously. Recital 16 of DORA establishes DORA as lex specialis: where DORA and NIS2 impose overlapping requirements, DORA's incident reporting and ICT risk-management requirements take precedence for financial entities. Financial entities that comply with DORA are therefore considered to have met the corresponding NIS2 requirements.

In practice, a DORA-compliant financial entity's ICT incident reporting satisfies the NIS2 Article 23 obligation for those same incidents. But NIS2 continues to apply in areas outside DORA's scope, and competent authorities may require demonstration of NIS2 compliance in those areas. Organisations subject to both frameworks should map their obligations by area so they're addressing each requirement under the right framework.

For organisations in critical infrastructure sectors outside financial services, NIS2 governs exclusively; the SureCloud DORA compliance framework maps the boundary between the two for organisations assessing their cross-framework exposure.

Building NIS2 compliance means building a programme that can be evidenced on demand. The steps below reflect what competent authorities expect to see.

Step 1: Confirm In-Scope Status

Determine whether the organisation meets the sector and size criteria for essential or important entity status. For groups with entities across multiple EU member states, this analysis must be done per-entity and per-member-state, as national transposition legislation may vary in scope and definitions. Document the conclusion and the basis for it.

Step 2: Identify the Competent Authority and National Requirements

Identify the national competent authority responsible for NIS2 supervision in each relevant member state. Review the national transposition legislation for any requirements that go beyond the directive's minimum, particularly on incident reporting channels, registration obligations, and sector-specific guidance. Registration obligations vary by member state: national transposition legislation determines whether formal registration with the competent authority is required.

Transposition is still in progress across the EU: as of June 2025, fewer than ten member states had fully transposed NIS2, with the majority in advanced stages of implementation according to the ENISA Advisory Group. This means national requirements and the supervisory expectations that follow continue to evolve. Checking for updates from the relevant national authority belongs in every organisation's ongoing compliance calendar.

Step 3: Conduct a Gap Assessment Against Article 21

Map existing information security and risk management controls against the ten Article 21 measures. If the organisation holds an ISO 27001:2022 certification or equivalent, use the certified scope and controls as the starting point but conduct a specific NIS2 gap analysis. Pay particular attention to supply chain security, incident detection and reporting integration, and the completeness of business continuity and disaster recovery provisions.

The ENISA NIS Investments 2024 Report found that almost one in three organisations hadn't conducted a cybersecurity assessment in the past 12 months, and that supply chain risk management (37%), business continuity (49%), and patching (50%) were the most widely cited implementation gaps. These are three of the ten Article 21 measures: organisations starting compliance work should address these first.

Step 4: Address Management Body Accountability

NIS2 Article 20 requires management body members to oversee and approve cybersecurity risk-management measures. In practice this requires a governance structure where cybersecurity risk is a standing agenda item at board or equivalent level, management body members have completed or can evidence NIS2-relevant training, and accountability for compliance is formally assigned at senior management level. Competent authorities reviewing Article 20 compliance will look for an accountability structure established before any incident and evidenced through board minutes, training records, and formal sign-off.

Step 5: Implement Incident Detection and Reporting Workflows

The 24-hour early warning requirement is operationally demanding. It's the obligation most organisations find challenging to meet without a pre-planned, tested response process. Organisations that haven't rehearsed the classification and escalation steps tend to discover the gaps during an active incident; this process must be documented and integrated with the wider incident response programme before one occurs.

Step 6: Establish Ongoing Assurance and Review

Article 21(2)(f) requires policies and procedures to assess the effectiveness of risk-management measures. Build a schedule of internal audits, penetration testing, tabletop exercises, and management reviews that provides continuous assurance over the programme. Competent authorities will expect evidence of ongoing assurance rather than a single point-in-time assessment.

SureCloud helps essential and important entities build NIS2-compliant programmes using Gracie AI Agents with Personas and Skills: Article 21 control mapping, incident workflow integration, supply chain risk management, and Article 20 board reporting.