NIS2 Compliance | Who Must Comply and What It Requires

What Is NIS2 Compliance?

NIS2 compliance means meeting the legal duties the EU's NIS2 Directive places on organizations in critical sectors. Those duties cover managing cybersecurity risk, reporting significant incidents to authorities, and making senior management answerable for both. In practice, being compliant means you can show a regulator that your security measures, reporting process, and governance are in place and working. A policy document alone does not show that.

NIS2 Directive in plain language

The NIS2 Directive, formally Directive (EU) 2022/2555, is the EU's baseline cybersecurity law for sectors society depends on. It replaced the original Network and Information Security Directive (NIS1, Directive (EU) 2016/1148) because NIS1 failed to deliver consistent security across the bloc. Digitalization has widened the attack surface, and attacks on hospitals, energy suppliers, and managed service providers show how one weak link can disrupt many organizations at once. NIS2 responds by covering more sectors, setting a minimum list of security measures, and imposing comparable penalties across countries. It entered into force in January 2023 and formally repealed NIS1 from October 2024.

Directive vs national law

NIS2 is a directive, not a regulation, so it does not apply directly to companies. Each EU member state must transpose it into national law, and regulators enforce that law. This is why compliance depends on where you operate. Deadlines for registration, the competent authority you report to, the exact incident-reporting channels, and some national add-ons can all differ between, for example, Germany, France, and Italy.

Transposition has also been uneven. The European Commission opened infringement procedures in November 2024 against 23 member states for missing the October 2024 transposition deadline. For anyone operating across several countries, the practical approach is to build to the Directive's common baseline, then check each country's transposing law for local requirements.

How NIS2 differs from NIS1

The differences are most visible in five areas: scope, selection, requirements, enforcement, and accountability.

• Scope. NIS2 covers many more sectors than NIS1, including wastewater, space, public administration, postal services, food, and manufacturing of certain critical products.

• Selection. Under NIS1, member states chose which "operators of essential services" were in scope, creating wide variation. NIS2 largely replaces that with a size-based rule: medium and large entities in covered sectors are in scope by default.

• Requirements. NIS2 sets out a minimum list of risk-management measures, including supply chain security and vulnerability handling. NIS1 left much of this vague.

• Enforcement. NIS2 sets maximum fines and gives supervisors defined powers such as audits, inspections, and binding instructions.

• Accountability. Management bodies must approve and oversee security measures and can be held liable for failures, which NIS1 did not require.

For a security or compliance lead, the shift is from "are we designated?" to "which category are we in, and can we prove our controls work?"

Who Must Comply With NIS2?

NIS2 applies to medium and large organizations that operate in the sectors listed in Annexes I and II of the Directive and provide services in the EU. Some providers, such as DNS and trust service providers, are covered regardless of size. Whether you are "essential" or "important" depends on your sector and size, and that classification determines how closely regulators supervise you and how high your maximum fine can go.

Essential vs important entities

The Directive sorts in-scope organizations into two categories. Essential entities are generally large organizations in the Annex I sectors, plus certain providers that are essential regardless of size. Important entities are medium-sized Annex I organizations and medium or large organizations in the Annex II sectors.

Both categories must meet the same core cybersecurity and reporting obligations. The difference is in supervision and penalties. Regulators can proactively inspect essential entities, while they generally supervise important entities after an incident or evidence of non-compliance. Maximum fines are €10 million or 2% of worldwide annual turnover for essential entities, and €7 million or 1.4% for important entities (Article 34). Your national authority assigns the category, so check how your member state's transposing law defines it.

The sector lists (Annex I and Annex II)

Annex I covers "sectors of high criticality": energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management (B2B, such as managed service providers), public administration, and space.

Annex II covers "other critical sectors": postal and courier services, waste management, chemicals, food production and distribution, certain manufacturing (medical devices, electronics, machinery, motor vehicles), digital providers such as online marketplaces, search engines, and social networks, and research organizations.

Sector placement is by activity, not by how you describe yourself. A company that runs a data center or provides managed security services falls under digital infrastructure or ICT service management even if it markets itself as a software firm.

Size thresholds and exceptions

The default size rule follows the EU definition of enterprise sizes (Recommendation 2003/361/EC). An organization is "medium" if it has at least 50 employees or annual turnover or balance sheet total above €10 million, and "large" at 250 employees or more, or turnover above €50 million and a balance sheet above €43 million. Entities that are micro or small are generally outside scope.

There are exceptions. Some providers are covered regardless of size, including qualified trust service providers, top-level domain registries, DNS service providers, and providers of public electronic communications networks or services. Member states can also include smaller entities, for example, where an organization is the sole provider of a service society depends on. Group structure matters as well, since the size of a parent and its linked enterprises can affect the calculation.

Do non-EU companies need to comply?

Often yes, indirectly, and sometimes directly. For most sectors, NIS2 applies to entities established in the EU. A GCC company with an EU subsidiary that falls within Annex I or II is therefore in scope through that subsidiary.

For certain digital providers, such as DNS and cloud providers, data center operators, content delivery networks, managed service providers, managed security service providers, online marketplaces, search engines, and social networks, the rule is broader. If the company is not established in the EU but offers services there, it must designate a representative in one of the member states where it operates (Article 26). A company that does neither of these is not directly regulated under most other sectors, but that rarely ends the matter, because its EU customers are often in scope and will pass requirements on to it, which is covered next.

Supply chain exposure when you are a supplier to a regulated entity

You can be affected by NIS2 even if you are not in scope. Article 21 requires in-scope organizations to manage the security of their supply chain and direct suppliers, which in practice means they will ask suppliers for evidence of controls, security clauses in contracts, incident notification commitments, and sometimes the right to audit.

This pressure is growing because suppliers are a common route into larger organizations. Verizon's 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled year over year to 30%. For a software vendor, MSP, or cloud provider selling into the EU, expect NIS2-driven questionnaires and contract terms to become standard in procurement, whether or not you are directly regulated.

NIS2 Compliance Requirements

Article 21 of Directive (EU) 2022/2555 sets NIS2 compliance requirements, obliging in-scope organizations to adopt "appropriate and proportionate" technical, operational, and organizational measures to manage cybersecurity risk. Article 21(2) lists ten minimum areas, from risk analysis to multi-factor authentication. Article 20 adds a governance duty for management. The measures must follow an all-hazards approach, covering the security of network and information systems and their physical environment, and the level of rigor should match your size, exposure, and the likely impact of an incident. Auditors test those two elements: proportionality and evidence.

Risk analysis and security policies

First, identify what you are protecting and what could go wrong, then document it in policies people follow. A risk analysis should identify critical services, the systems behind them, the threats and weaknesses that apply, and who owns each risk. For example, a regional energy supplier would document that its metering platform, billing system, and customer portal each have different risk levels and different owners. Policies sit on top of that analysis and must be approved, current, and actually applied.

Incident handling

Article 21(2)(b) requires you to detect, assess, contain, and recover from incidents, and it works together with the separate reporting obligations in Article 23. In practice, this means a defined incident response plan, named roles, logging that supports investigation, and a way to decide quickly whether an event is "significant." Rehearsal matters, since a plan nobody has exercised tends to fail under pressure. Reporting timelines are covered in the incident reporting section below.

Business continuity and crisis management

You must be able to keep operating, or restore service quickly, after a disruption. That covers backup management, disaster recovery, and crisis management. Backups count only if you've tested restores, and ransomware planning should assume your primary environment may be unavailable. IBM's 2025 Cost of a Data Breach Report puts the global average breach cost at $4.44 million, a useful reminder that recovery capability is both a financial control and a compliance one.

Supply chain security

You are expected to manage security risk from direct suppliers and service providers, taking into account their vulnerabilities and the quality of their security practices (Article 21(3)). Start by identifying your critical suppliers and their access. It continues with security clauses in contracts, incident notification commitments, and periodic reassessment. Suppliers that are themselves in scope can usually point to their own NIS2 posture, while others may need questionnaires or evidence requests.

Secure development, vulnerability handling and disclosure

Security has to be built into how you buy, build, and maintain systems. This includes DevSecOps practices in the development pipeline, patch management with defined timelines, and a process for receiving and acting on reported flaws as part of wider vulnerability management. A published vulnerability disclosure policy and a monitored contact address are low-cost ways to show maturity. Fix timelines should reflect severity and exposure, so that internet-facing critical flaws are handled faster than internal low-risk ones.

Effectiveness assessment (testing and audits)

Article 21(2)(f) requires policies and procedures to assess whether your measures actually work. Penetration testing, vulnerability scanning, control audits, and exercises all contribute, but only if you track findings to closure and report them to management. An assessment with no remediation trail will look weak to an auditor. The depth and frequency of testing should be proportionate to the criticality of the systems tested.

Cryptography, access control, MFA, and asset management

These controls protect the data and systems themselves. Encryption policies should define what is encrypted in transit and at rest and how keys are managed. Access control should follow least privilege, the core idea behind zero trust security, with regular access reviews and prompt removal of leavers. NIS2 specifically calls for multi-factor or continuous authentication where appropriate, which in practice means MFA for administrators, remote access, and critical systems first. None of this works without an asset inventory, since you cannot protect or review access to systems you do not know exist.

Basic cyber hygiene and training

Baseline practices include timely patching, secure configuration, malware protection, and backups, supported by role-specific security awareness training. General staff need to understand phishing and how to report it. Administrators and developers need role-specific skills. Auditors typically look for completion records and evidence that training content reflects current threats, not just a yearly slide deck.

Management accountability and board training

Article 20 requires management bodies to approve cybersecurity risk-management measures, oversee their implementation, and undergo training to assess risk. Management can be held liable for infringements. For a board, this means security gets a regular agenda slot, risk decisions are recorded, and directors can show they received training. Delegating work to a CISO is fine, but management retains approval and oversight.

NIS2 Incident Reporting Requirements

NIS2 requires in-scope organizations to report significant incidents in three stages: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report within one month of that notification. These duties come from Article 23 of Directive (EU) 2022/2555 and are separate from the incident-handling measures in Article 21. Both essential and important entities must follow them. Faster detection makes meeting deadlines easier. IBM's 2025 Cost of a Data Breach Report found that organizations took an average of 241 days to identify and contain a breach, so the 24-hour clock demands a different level of readiness from many teams.

The 24-hour early warning, 72-hour notification, and one-month final report

The clock starts when you become aware of a significant incident, and each stage asks for more detail than the last.

The early warning is due within 24 hours. It is deliberately light: it should say whether the incident is suspected to be caused by unlawful or malicious action and whether it could have a cross-border impact. You are not expected to know the cause yet.

The incident notification is due within 72 hours. It updates the early warning and adds an initial assessment of the incident's severity and impact, plus indicators of compromise where available. Qualified trust service providers face a tighter 24-hour deadline for this notification.

The final report is due no later than one month after the incident notification. It should describe the incident in detail, the likely root cause or type of threat, the mitigation measures applied and ongoing, and any cross-border impact. If the incident is still ongoing at that point, you send a progress report instead and submit the final report within one month of handling the incident. Authorities can also request an intermediate status update at any time.

What counts as a significant incident

An incident is significant under Article 23(3) if it has caused, or can cause, severe operational disruption of services or financial loss for your organization. It is also significant if it has affected, or is capable of affecting, other people or organizations by causing considerable material or non-material damage. The words "capable of" matter, because an incident does not need to have already caused harm to trigger reporting.

For some provider types, including DNS and cloud providers, data centers, managed service providers, online marketplaces, and trust service providers, Commission Implementing Regulation (EU) 2024/2690 sets specific significance criteria. Other sectors rely on national guidance, which can differ by member state. Build your threshold from the Directive's definition, then check the guidance from the authority you report to.

Who you report to (national CSIRT or competent authority)

Reports go to the national computer security incident response team (CSIRT) or, where the member state's law says so, the competent authority. Which body that is depends on the country where you are established, so it can vary across an organization operating in several member states. Some countries have a single reporting portal, while others split reporting by sector.

You may also have to notify the recipients of your services without undue delay if a significant incident is likely to adversely affect them, and, where appropriate, tell them about measures they can take. Check your national transposing law before an incident happens. Looking up the right authority and portal during a live incident wastes time you do not have.

Building a reporting workflow that works at 3 a.m.

To implement NIS2 incident reporting in practice, you need a workflow that works with people available at night and on weekends, because attackers don't wait for business hours. Four pieces make that work.

Roles. Name an incident lead who decides whether an event is significant, a person responsible for filing reports, and a deputy for each. Include a legal or compliance contact and an executive who can be woken up. If these roles exist only on paper and are only available during business hours, the 24-hour deadline is at risk.

A decision tree. Write down a short sequence the on-call person can follow: confirm the event is a real security incident, check it against your significance criteria, decide whether to file, and record the time you became aware. That timestamp matters, because it starts your clock and is the first thing an auditor will ask about. Document how you determine awareness, since the Directive does not define it precisely and national guidance may.

Templates. Prepare early warning, notification, and final report templates in advance, pre-filled with entity details and your contacts. At 3 a.m., limit your response to what you know, so the template clearly shows which fields are required at each stage and which can wait.

Rehearsal. Run a tabletop exercise that includes a simulated filing against the 24-hour deadline, and fix what slows you down. Keep records of the exercise, since regulators can ask for evidence that your incident-handling measures work.

NIS2 Compliance Date and Deadlines

The NIS2 Directive had to be transposed into national law by 17 October 2024, and its rules were meant to apply from 18 October 2024. For your organization, the key date is when your member state's law took effect, and many were late. As of mid-October 2026, 24 of the 27 EU countries have a national NIS2 law in force, so most organizations already face enforceable obligations.

Transposition deadline and application date

NIS2 is a directive, so the 17 October 2024 date bound member states, not companies. Your legal obligations start when the national law that transposes NIS2 enters into force in the country where you are established or offer services. Only four member states met the October 2024 deadline (per Pinsent Masons' Out-Law report), which means company deadlines now follow a patchwork of national dates. Even where a country has a law, it may phase in registration or audit requirements, so the entry-into-force date is only the starting point.

Where member states stand now

The Commission's enforcement against late countries has moved in stages. It opened infringement procedures against 23 member states in late November 2024, and sent reasoned opinions to 19 member states on 7 May 2025. On 8 July 2026, it referred Ireland, Spain, France, and the Netherlands to the Court of Justice of the EU for failing to notify full transposition.

Since then, the picture has partly improved. The Netherlands' law has been in force since 15 August 2026, and Austria's since 1 October 2026. One tracker, updated on 16 October 2026, reports that no national law is yet in force in France, Ireland, or Spain. Trackers differ in what they count as "transposed," and the Commission applies a stricter standard than some independent trackers, requiring secondary legislation as well as the primary law. If you operate in France, Ireland, or Spain, expect the earlier NIS1 regime to apply to designated operators until the new law lands, and track the national authority's announcements.

The EU may also change. The Commission has proposed amendments to NIS2 covering scope, ransomware reporting, cross-border supervision, and ENISA's role, which Parliament and Council must still review. These proposals do not change today's obligations, but they could shape later national updates.

Registration and reporting milestones to track

Registration is usually the first deadline you will hit, and Germany shows how quickly it can become a problem. Germany's statutory registration deadline was 6 March 2026, and only around 11,500 of roughly 30,000 affected entities had registered by then. The BSI later set 31 July 2026 as a final date for those who missed it, and late registration alone can carry fines of up to €500,000. Other countries set their own windows. Italy, for example, required registration with its national cybersecurity agency by early 2025, with earlier dates for certain digital providers.

For each country you operate in, track four things:

1. When the national law enters into force.

2. The registration window and the portal you use to register.

3. Reporting channel and timelines, which follow the 24-hour, 72-hour, and one-month structure in the Directive.

4. Audit or evidence dates, which some countries phase in for larger entities. One German law-firm summary notes that particularly important entities must show compliance proactively by December 2028.

International groups should assess each legal entity separately, since each may have a different authority, registration process, and audit cycle.

NIS2 Penalties and Management Liability

Under NIS2, essential entities face administrative fines of at least €10 million or 2% of worldwide annual turnover, whichever is higher. Important entities face a maximum of at least €7 million or 1.4%. Senior management can also be held liable for failures, and for essential entities, authorities can temporarily bar executives from managerial roles. Because NIS2 is a directive, each member state sets its own penalty rules within those minimum ceilings. The national law where you operate decides what you actually face.

Fine ceilings for essential vs important entities

Article 34 of Directive (EU) 2022/2555 sets the minimum maximums that national laws must provide. For essential entities, that is at least €10 million or 2% of the total worldwide annual turnover of the group in the preceding financial year, whichever is higher. For important entities, it is at least €7 million or 1.4% of the group's total worldwide annual turnover in the preceding financial year, whichever is higher.

Two points are easy to miss. First, these are ceilings, not standard fines. Regulators are expected to set penalties that are effective, proportionate, and dissuasive for the case in front of them, taking into account the gravity of the breach, its duration, prior infringements, and the entity's cooperation. Second, the turnover is that of the whole undertaking, so a subsidiary in scope can be exposed to a figure calculated on its group's revenue.

Fines can also attach to obligations beyond core risk management and reporting duties. In Germany, for example, a missed registration can carry a penalty of up to €500,000, which regulators have used as a lever to push late registrants into compliance. Even a small number can hurt, so treat it as a real risk.

Personal accountability of management bodies

Article 20 makes cybersecurity a board-level duty. Management bodies must approve cybersecurity risk-management measures, oversee their implementation, and complete training to understand the risks. They can be held liable for the entity's infringements. Exactly how that liability works depends on national law, including how it interacts with existing rules on director duties.

For essential entities, the Directive goes further. If an entity fails to comply after a regulator's order, the authority can temporarily prohibit a person in a chief executive or equivalent legal representative role from exercising managerial functions in that entity (Article 32). This is intended as a last resort, but it means the risk can be personal as well as financial.

In practice, directors protect themselves by creating a record. That means approving the security program in minuted meetings, receiving regular reports on risk, incidents, and test results, and keeping evidence of their own training. Delegating work to a CISO is normal, but the board retains approval and oversight.

Supervisory powers (inspections, audits, orders)

Regulators have a broad toolkit, and the approach differs by category. Regulators proactively supervise essential entities, with powers that include on-site inspections, regular and targeted security audits, ad hoc audits after a significant incident or breach, security scans, requests for information and evidence, and access to data and documents. Authorities supervise important entities reactively (ex post), meaning they generally act when they receive evidence or indications of non-compliance, though they can use similar tools once they do.

When a regulator finds problems, it can issue warnings and binding instructions, order an entity to bring its measures into compliance within a set time, and require it to inform affected parties of a significant threat. It can also appoint a monitoring officer for a defined period, and require public disclosure of aspects of the infringement. For essential entities, a regulator can also temporarily suspend a certification or authorization. A fine is rarely the first step, since regulators commonly start with an order to fix the problem. Acting early avoids a situation where an order you didn't meet becomes the basis for a larger penalty.

How to Achieve NIS2 Compliance: A Practical Roadmap

To achieve NIS2 compliance, first confirm whether you are in scope and in which category, then assess your gaps against Article 21, reduce your attack surface, assign governance, test your controls, and keep evidence you can show a regulator. The order matters, because each step feeds the next. Many organizations are still early in this process. A 2026 Plusserver study, as reported by Börse Express, found that only 34% of the companies surveyed had fully implemented the NIS2 requirements. The report does not state the sample or country scope, so treat it as a rough indicator.

Step 1: Determine applicability and entity category

Start by mapping each legal entity in your group against the sector lists and size thresholds, in each EU country where you are established or offer services. The result is a category (essential, important, or out of scope) and a named competent authority per country. Do this per entity, not per group, because a subsidiary and its parent can land in different categories under different national laws. Record your reasoning, since an authority may ask how you reached your conclusion, and a documented "not in scope" decision is better than an undocumented one.

Step 2: Gap assessment against Article 21

Compare your current controls with the ten measure areas in Article 21(2). For each, score where you stand, name an owner, and note what evidence exists today. Keep the assessment tied to real systems and processes rather than policy titles, since a policy that nobody follows counts as a gap. The output should be a prioritized remediation list ranked by risk and by how visible the gap would be to an auditor, such as a missing incident response plan or no MFA on administrator accounts.

Step 3: Assess and reduce your attack surface

You cannot secure systems you have not found. Build an inventory of internet-facing assets, including forgotten subdomains, cloud services, exposed APIs, and third-party hosted systems, and check each for exposure and ownership. Retire what you no longer need and fix anything unnecessarily exposed. This feeds directly into risk analysis, supply chain review, and incident readiness, and it is a continuous activity, since new assets appear whenever teams deploy. For a full explanation of how to do this, see our guide to what is attack surface management.

Step 4: Fix governance (ownership, board reporting, budget)

Controls fail when nobody owns them. Assign a named executive accountable for NIS2, define who approves risk decisions, and set a regular board reporting rhythm covering risk, incidents, test results, and open remediation. Article 20 makes the management body responsible for approving and overseeing the measures, so the board needs both training and a clear view of progress. Tie the remediation list from Step 2 to budget and dates. A plan without funding rarely survives its first quarter.

Step 5: Test controls (pentesting and vulnerability assessment)

Article 21(2)(f) expects you to assess whether your measures actually work. Run regular vulnerability assessments to find known weaknesses across your environment, and use penetration testing to check whether an attacker could chain weaknesses into real impact on your most critical services. Scope tests to the systems that support your essential services first. Auditors care about what happens after testing, so track every finding to closure and keep the retest results.

Step 6: Document evidence

Auditors test whether you can prove what you say, so build an evidence pack as you go rather than assembling it before an audit. It should cover your scope decision, risk assessment, approved policies, asset inventory, supplier register and contracts, incident response plan and exercise records, test reports with remediation tracking, training records, and board minutes showing oversight. Store it in one place with named owners and review dates, and keep it current. Older evidence with no update history looks abandoned.

Common mistakes

Treating it as an IT-only project. NIS2 touches legal, procurement, HR, operations, and the board. Security teams cannot deliver governance, supplier contracts, or management training on their own.

Ignoring suppliers. Article 21 requires you to manage supply chain risk, so failing to identify critical suppliers, review their security, or add security terms to contracts leaves a visible gap.

Having no tested reporting process. A written incident plan that has never been rehearsed against the 24-hour early warning will not hold up at 3 a.m. Run a tabletop exercise that includes a simulated filing.

Stopping at registration or certification. Registering with your authority is the first step, not the finish. A certification such as ISO 27001 can support your case, but it does not by itself prove NIS2 compliance.

NIS2 Compliance Audit: What to Expect

A NIS2 compliance audit checks whether your cybersecurity measures, incident-reporting process, and management oversight match what the Directive and your national law require, and whether you can prove it with evidence. Who conducts it, how often, and how deep it goes depends on your category and your member state. Essential entities should expect proactive scrutiny, while important entities are typically examined after an incident or a complaint. Either way, auditors judge you on documented, working controls, not on intentions.

How supervision and audits work

Article 32 of Directive (EU) 2022/2555 lets authorities supervise essential entities through regular and targeted security audits, carried out either by the authority itself or by an independent body. A targeted audit usually follows a significant incident or a suspected breach. Authorities supervise important entities after the fact (Article 33), so an audit generally begins when the authority receives evidence of non-compliance.

Several things vary by country. Some member states require essential entities to commission periodic independent audits on a fixed cycle, while others leave timing to the supervisor. The competent authority, request formats, and response deadlines also differ. Check the national law and your authority's published guidance for your entities, since a group operating in three countries may face three different processes.

An audit rarely starts with a surprise visit. It usually begins with a written request for information and documents, followed by interviews and sample testing, then a findings report with deadlines to fix what they find. How you respond in the first week, including how quickly you can name the right people and produce documents, shapes the auditor's impression of your maturity.

Evidence auditors request

Auditors work from the Article 21 measure areas and ask for proof that each one is operating. Expect requests to fall into five groups:

• Governance: your scope and category decision, who is accountable, and board minutes showing approval and oversight of security measures.

• Risk and controls: the risk assessment and how it drives priorities, approved policies, the asset inventory, and access reviews.

• Incident readiness: the incident response plan; the criteria you use to decide whether an incident is significant; records of past incidents and any reports filed; and logs of exercises.

• Resilience and testing: backup restore results, continuity and recovery tests, and penetration test and vulnerability assessment reports with proof of remediation.

• Third parties and people: a supplier register with risk ratings, security clauses in contracts, and training records.

Auditors often test samples. They may pick a recent leaver and check that access was removed, or a critical supplier and ask for the contract terms. Evidence with dates, owners, and review history carries more weight than a policy with no trace of use.

Audit readiness in a short checklist

A short checklist helps you spot gaps before a regulator does. If you can answer "yes" and produce a document for each item, you are in reasonable shape.

• We have a documented decision on whether each legal entity is in scope and which category it falls under.

• We have identified our competent authority, and registration is complete where required.

• Management has approved our security measures and received training, and minutes show it.

• A current risk assessment exists and ties to our remediation plan.

• We maintain an asset inventory, including internet-facing systems.

• Our incident plan covers the 24-hour, 72-hour, and one-month reporting stages, and we have rehearsed it.

• Backups are tested by actually restoring from them.

• We identify, assess, and cover critical suppliers in contract terms.

• Penetration tests and vulnerability assessments are current, and we track findings to closure.

• Evidence is stored in one place, with named owners and review dates.

This is a readiness test, not a complete audit scope. The Article 21 measure areas remain the reference point.

Certifications that help but do not equal compliance

A recognized certification can support your case, but it does not replace a NIS2 assessment. ISO/IEC 27001 is the most common example. Its information security management system overlaps heavily with Article 21, particularly risk assessment, policies, access control, and incident handling, so an existing certification can supply much of your evidence. For a comparison with other frameworks, see our guide to ISO 27001 vs SOC 2 vs PCI DSS.

The gaps are in scope and specifics. A certificate covers a defined scope, which may exclude systems that support your in-scope services. It also does not address NIS2-specific duties such as the 24-hour early warning, registration, or management liability. Member states can additionally require the use of European cybersecurity certification schemes for certain products or services (Article 24), so check whether your country does. Treat certifications as strong evidence inside a wider NIS2 program, not as a substitute.

NIS2 vs DORA: Which Applies to You?

NIS2 is a cross-sector EU directive for essential and important entities, while DORA (Regulation (EU) 2022/2554) is a financial-sector regulation that has applied since 17 January 2025. If you are a financial entity covered by DORA, DORA's ICT risk and incident rules generally take priority over the equivalent NIS2 rules. If you are not, check NIS2. Some organizations sit under both, and for them the task is to map one program to two sets of obligations.

Scope (cross-sector vs financial sector)

NIS2 covers medium and large organizations across many sectors, from energy and health to digital infrastructure and manufacturing. It also lists banking and financial market infrastructure among its high-criticality sectors. DORA is narrower and deeper: it targets financial entities, including credit institutions, payment and e-money institutions, investment firms, insurers, and crypto-asset service providers authorized under MiCA, along with the critical ICT third-party providers they depend on.

The two laws are linked through the lex specialis principle. Where a sector-specific EU act sets requirements at least equivalent to NIS2, those NIS2 provisions do not apply to the entities it covers. DORA is that act for finance. The practical effect is that a bank or licensed payment firm follows DORA's ICT risk-management and incident rules rather than the NIS2 ones, while NIS2 can still apply to parts of the same group that are not financial entities.

Overlap in incident reporting and third-party risk

Both laws require structured incident reporting and both demand control over technology suppliers, but the details differ. NIS2 uses a 24-hour early warning, a 72-hour notification, and a final report within a month. DORA's major-incident reporting uses an initial notification, an intermediate report, and a final report, with timelines set in technical standards that run on shorter clocks for the first notice. Reports go to different authorities: DORA reports go to the financial supervisor, while NIS2 reports go to the national CSIRT or competent authority.

On third-party risk, NIS2 asks you to manage supply chain security with direct suppliers. DORA is more prescriptive: it requires a register of ICT third-party arrangements, specific contract clauses, exit strategies, and direct EU oversight of designated critical providers. If you supply technology to financial entities, expect DORA's requirements to reach you by contract even though DORA does not directly regulate you, and NIS2 may apply to you in its own right as a digital infrastructure or ICT service provider.

When both apply (fintech and crypto firms serving the EU)

Dual exposure is most common in fintech and crypto groups. A firm with a payment, e-money, or MiCA crypto-asset service license is a DORA financial entity for that regulated activity. A technology affiliate in the same group, such as a cloud, hosting, or managed services arm serving external customers, can be an in-scope NIS2 entity under its own classification. Group structure determines which law applies to each entity, so assess each legal entity separately.

A non-EU firm gets the same treatment based on what it does in the EU. Offering licensed financial or crypto services there triggers DORA, and providing digital infrastructure or ICT services there can trigger NIS2 obligations, including the requirement to appoint an EU representative. The efficient approach is a single control framework, with one incident process that can produce both sets of reports, one supplier register, and one testing program, mapped to each law's wording and timelines.

For a full explanation of DORA's requirements, see our DORA compliance guide.

NIS2 for GCC and Non-EU Organizations

A GCC or other non-EU organization must follow NIS2 if it has an EU establishment in a covered sector, or if it provides certain digital services in the EU and has appointed an EU representative. Even if it isn't directly regulated, its EU customers often are, and they will pass NIS2-style requirements down through contracts. Meeting NIS2 does not replace local obligations in the UAE or Saudi Arabia, but the overlap is large enough that one security program can serve both.

When EU rules reach you

NIS2 can reach a company outside the EU in three ways. The first is establishment: an EU subsidiary or branch in an Annex I or II sector, above the size thresholds, is in scope in its own right. The second is the digital provider rule, where cloud, data center, managed service, DNS, marketplace, and search providers that offer services in the EU without establishing there must designate an EU representative (Article 26). The third is the contractual route: if you supply an in-scope EU customer, you will likely see security questionnaires, incident-notification clauses, and audit rights in your contracts. The detailed scope tests are in the earlier section on who must comply, so check your position there first.

A practical test for a GCC firm is to ask three questions. Do we have a legal entity in the EU? Do we sell a covered digital service to EU customers? Do our EU customers include essential entities? A "yes" to any of them means you should assess NIS2 properly rather than assume it does not apply.

How NIS2 maps to UAE and regional expectations

NIS2's Article 21 measures overlap with the control areas of the main regional frameworks, so existing work carries over. Risk management, access control, incident response, business continuity, supplier oversight, and staff training appear in UAE and Saudi requirements alike, including the UAE Information Assurance standards from the Signals Intelligence Agency (SIA, formerly NESA), Central Bank of the UAE (CBUAE) expectations for regulated financial firms, VARA's rulebooks for virtual asset firms in Dubai, and Saudi Arabia's SAMA and NCA frameworks. For an overview of the UAE landscape, see our guide to cybersecurity regulations in the UAE, and for how risk, control, and compliance functions fit together, see our explanation of governance, risk, and compliance.

The differences matter more than the overlap, so do not treat one framework as proof of the other. NIS2 requires a 24-hour early warning to an EU authority, management-body approval and training, EU-specific registration, and supervision by a national authority, none of which a UAE or Saudi framework satisfies. Equally, meeting NIS2 does not discharge local duties, such as VARA cybersecurity requirements for a Dubai-licensed firm. The efficient approach is a single control set mapped to each regime, with a separate reporting procedure for each regulator and a clear owner for every deadline.

Conclusion

NIS2 compliance comes down to knowing whether each of your entities is in scope, closing the gaps against Article 21, and being able to prove it with evidence. The deadlines that matter are national, so check your member state's registration window and reporting channel, and rehearse the 24-hour early warning before you need it. Management carries the accountability, which makes board approval, training, and regular reporting part of the work rather than an afterthought.

If you want an outside view of where you stand, Femto Security can walk you through a NIS2 gap assessment, covering scope, Article 21 controls, and your reporting readiness.

Frequently Asked Questions (FAQs)

How can I ensure compliance with NIS2?

Confirm whether each legal entity is in scope and in which category, then assess your controls against the ten measure areas in Article 21. Fix gaps in governance, incident reporting, supplier security, and testing, and keep dated evidence of each. Compliance also depends on your member state's national law, so check its registration and reporting rules.

How do I implement NIS2 directive compliance for cybersecurity incident reporting?

Name an incident lead and a filer with deputies, write a short decision tree for deciding whether an incident is significant, and prepare templates for the 24-hour, 72-hour, and one-month reports. Record when you became aware, and rehearse a simulated filing. The reporting section above covers each step in detail.

Does NIS2 apply to companies outside the EU?

Sometimes. A company outside the EU is in scope if it has an EU subsidiary in a covered sector, or if it offers certain digital services in the EU and must appoint an EU representative. Even if it isn't directly regulated, it may face NIS2-driven contract requirements from in-scope EU customers.

Is NIS2 compliance the same as ISO 27001 certification?

No. ISO 27001 certifies an information security management system within a defined scope, and it overlaps heavily with Article 21. NIS2 compliance also requires registration, 24-hour incident reporting, management accountability, and supervision under national law. A certificate is useful evidence, but it does not prove you meet NIS2.

What happens if I miss the 24-hour report?

You risk a regulatory finding and possibly a fine or binding order, depending on national law and your category. If the incident is significant, report as soon as you can rather than waiting, and document why you were late. Regulators generally weigh gravity, cooperation, and past conduct when deciding on a response.