What NIS2 Actually Requires and What It Does Not

NIS2 does not contain a universal technology shopping list. It does not say that every organisation must buy an identity governance platform, adopt one named security framework, keep a prescribed set of log fields or deploy the same controls in the same way. It requires essential and important entities to manage cybersecurity risks with appropriate and proportionate technical, operational and organisational measures, and it makes management accountable for approving and overseeing those measures.

That distinction matters. A company can own modern security products and still fail to show that its risks are understood, its controls work, incidents are reported on time and corrective actions are completed. Another organisation can use simpler controls and still build a defensible programme if those controls are proportionate to its risks, consistently operated and supported by evidence.

This guide separates the text of Directive (EU) 2022/2555 from the more detailed Commission Implementing Regulation (EU) 2024/2690, explains where identity and access governance fit, and gives management and security teams a practical evidence plan. It is based on the EU rules in force and official guidance checked on 12 September 2026. Because NIS2 is a directive implemented through national law, an organisation must also check the law and competent-authority guidance in every Member State relevant to its operations.

The shortest accurate answer: NIS2 requires risk-based governance, ten minimum areas of cybersecurity risk management, staged reporting of significant incidents, management oversight and evidence that the measures are implemented. It names access-control policies and, where appropriate, multifactor or continuous authentication. It does not prescribe one product, one role model or one universal logging schema.

Start with applicability, not a compliance checklist

The first question is whether the organisation is in scope. The European Commission describes NIS2 as a framework covering 18 critical sectors. As a general rule, it applies to medium-sized and larger public or private entities of a type listed in Annex I or Annex II that provide services or carry out activities in the Union. The covered areas include energy, transport, banking, financial-market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space, postal and courier services, waste management, chemicals, food, manufacturing, digital providers and research.

Size is only the starting rule. Article 2 contains cases that apply regardless of size, including specified electronic-communications providers, trust-service providers, top-level-domain registries and DNS service providers. It also covers sole providers of certain essential services, entities whose disruption could materially affect public safety, public security or public health, entities presenting significant systemic risk, and entities designated because of their national or regional importance. Critical entities identified under Directive (EU) 2022/2557 are covered regardless of size. Member States can also extend some coverage, including to local public administration and certain education institutions.

An applicability decision therefore needs evidence, not a quick sector label. Record:

1. the legal entities and Member States involved;
2. the services each entity provides in the Union;
3. the Annex I or Annex II category that may apply;
4. the workforce and financial data used for the size test;
5. any designation, registration or notification received from an authority;
6. any sector-specific EU law that may replace equivalent NIS2 provisions under Article 4; and
7. the national law and regulator guidance used for the conclusion.

This record should have a legal owner and a review date. Corporate structures, services and national implementation can change. In January 2026 the European Commission proposed targeted amendments intended to simplify parts of the cybersecurity framework and clarify NIS2. A proposal is not the same as enacted law. Teams should monitor the legislative process without treating proposed wording as a current obligation.

Essential and important do not mean compliant and exempt

NIS2 divides covered organisations into essential entities and important entities. Article 3 sets the classification rules. The practical difference is especially visible in supervision. Competent authorities can subject essential entities to proactive and reactive measures, including inspections, regular or targeted audits, scans and requests for evidence. Article 33 describes supervision of important entities as ex post: the authority acts when it has evidence, indication or information suggesting non-compliance.

Both categories must comply with the core risk-management and incident-reporting duties in Articles 21 and 23. “Important” is therefore not a lighter label that removes the need for controls. It changes the supervisory model and some enforcement details.

The board owns the decision and the oversight

Article 20 moves NIS2 out of the security department. Member States must ensure that management bodies of essential and important entities approve the cybersecurity risk-management measures used to comply with Article 21, oversee their implementation and can be held liable for infringements by the entity, subject to national liability rules. Members of those management bodies must follow training. Member States must also encourage organisations to offer similar training to employees regularly.

For management, approval should mean more than signing a policy. A useful board record answers five questions:

• Which material cyber risks threaten the services that put us in scope?
• Which measures reduce each risk, and why are they proportionate?
• Who owns the measures and the remaining risk?
• How do we know the measures operate effectively?
• Which gaps, exceptions and overdue actions has management accepted?

A dashboard that only reports the number of blocked attacks cannot answer those questions. The board needs measures tied to service risk: recovery tests completed, critical vulnerabilities outside their deadlines, privileged accounts without a current owner, leavers whose access was not removed on time, suppliers without agreed security duties, overdue access reviews, incident exercises and open audit findings. The organisation must preserve the decisions behind exceptions as well as the exceptions themselves.

Article 21. The ten minimum areas, translated into evidence

Article 21 starts with a principle: measures must be appropriate and proportionate to risk. They must reflect the state of the art, relevant standards where applicable, implementation cost, exposure, size, incident likelihood and severity, and potential societal and economic impact. The measures use an all-hazards approach and protect both network and information systems and their physical environment.

The Directive then names ten minimum areas. The following table keeps the legal categories separate from practical evidence. The evidence examples are implementation guidance, not extra legal text.

The word minimum matters. The list does not cap the programme. A risk assessment can justify additional measures. The word proportionate matters equally: it prevents teams from copying a generic checklist without considering their services and risk exposure. A control catalogue becomes defensible when each control has a purpose, owner, scope, operating procedure, test and retained result.

What NIS2 does not require

Vendor material often turns good security practice into supposed statutory wording. That makes the requirement easier to sell and harder to defend. The following claims need correction.

“NIS2 prescribes the fields every security log must contain”

The Directive does not prescribe a universal set of log fields for every covered organisation. Article 21(2) defines risk-management areas rather than a common event-log schema. The Directive does require incident handling and assessment of control effectiveness, which may make logging necessary in a real risk-based design. That is a control conclusion, not a universal logging schema written into the Directive.

Detailed logging requirements do appear in the Annex to Implementing Regulation (EU) 2024/2690. That regulation requires relevant entities to establish procedures and use tools to monitor and log activities in their network and information systems, and it sets out items that logs should include where appropriate. Its Article 1, however, binds a defined list: DNS service providers, TLD registries, cloud computing and data-centre providers, content-delivery networks, managed service and managed security service providers, online marketplaces, online search engines, social-networking platforms and trust-service providers.

That list is not every hospital, manufacturer, energy company or public-sector organisation covered by NIS2. Other entities may face detailed national or sector rules, and good incident detection normally needs suitable logs. The accurate statement is: the Directive sets the outcome; the 2024 implementing regulation supplies mandatory technical detail for its listed digital entities; national law and risk analysis determine the rest.

“NIS2 mandates an IGA platform”

It does not. Article 21(2)(i) expressly includes human-resources security, access-control policies and asset management. Article 21(2)(j) includes multifactor or continuous authentication solutions and secure communications where appropriate. Neither provision names an identity governance and administration product.

An IGA platform can help an organisation implement and prove access-control outcomes across many systems. It does not make the organisation compliant by its presence. The organisation still needs correct source data, accountable owners, proportionate policies, functioning connectors, tested removal, exception handling and evidence review.

“MFA everywhere is the complete NIS2 identity requirement”

MFA is explicitly named, with the qualifier “where appropriate”. It is valuable, especially for privileged, remote and sensitive access, but it does not answer who should have an account, which permissions they should hold, who approved them, whether conflicting access exists or whether access was removed after a role change. Authentication proves something about the current sign-in. Governance decides whether the account and entitlements should exist.

“Certification automatically proves NIS2 compliance”

NIS2 refers to the state of the art and relevant European and international standards. Article 24 also allows Member States, in specified circumstances, to require the use of certified ICT products, services or processes. The Directive does not create one universal certificate that replaces risk analysis, incident reporting, management oversight or national obligations. Standards can provide a strong control structure; the organisation still has to show scope, implementation and effectiveness.

“The maximum fine is the normal fine”

Article 34 requires Member States to provide maximum administrative fines of at least EUR 10 million or 2% of worldwide annual turnover, whichever is higher, for essential entities that infringe Articles 21 or 23. For important entities, the corresponding levels are EUR 7 million or 1.4%. These are minimum levels for the maximum available penalties in national regimes. They are not automatic prices for an incident. Authorities must consider the circumstances of each case, and national law governs the actual process.

Prepare for the incident-reporting deadlines

Article 23 applies when an incident significantly affects the provision of services. An incident is significant if it has caused or can cause severe operational disruption or financial loss for the entity, or if it has affected or can affect other people or organisations through considerable material or non-material damage.

The reporting sequence begins when the entity becomes aware of a significant incident:

Trust-service providers have a specific 24-hour rule for the incident notification referred to in Article 23(4)(b). National processes can add practical requirements, portals and contacts. Where appropriate, organisations must also inform service recipients about significant incidents likely to affect the service and communicate measures recipients can take against a significant cyber threat.

The operational implication is simple: a team cannot design the reporting process during the incident. It needs an agreed significance test, decision authority, evidence sources, regulator contacts, legal review path and out-of-hours escalation. Exercise the first 24 hours. If the people who recognise the incident cannot reach the people authorised to notify, the written policy will fail at the exact point it matters.

Where identity governance provides NIS2 evidence

Identity governance is one part of the Article 21 programme, centred on access control and connected to human-resources security, asset management, incident handling, supply-chain security and effectiveness testing. It connects a business event with a verified access state and the records needed to explain that change.

For each material system, an organisation should be able to answer:

• Which identities can access it, including employees, contractors, suppliers, service accounts and other non-human identities?
• What entitlements does each identity hold, and what business purpose supports them?
• Who requested and approved access, under which policy and for how long?
• What changed when the person joined, moved role, changed contract or left?
• Who owns the application, role and entitlement definitions?
• Which access is privileged, exceptional, dormant, orphaned or conflicting?
• When was the access last reviewed, what did the reviewer decide and was the decision fulfilled?
• Can the organisation reconcile the intended state with the target system’s actual state?

A spreadsheet can answer some of these questions for a small, stable environment. It becomes fragile when applications, identities, entitlements and changes multiply. Automation becomes useful when it reduces uncontrolled delay and preserves a consistent evidence chain. The control still needs human ownership and testing.

A defensible access-control evidence pack

Build the evidence pack before an audit request. At minimum, include:

1. Policy and scope: access-control policy, identity populations, critical applications, privileged-access boundary and exception rules.
2. Authority: application owners, role owners, approvers, reviewers and escalation routes.
3. Lifecycle proof: samples and metrics for joiners, movers, leavers, contractors and inactive identities, including completed removal in target systems.
4. Decision proof: access requests, approval context, expiry, policy checks and rejected requests.
5. Review proof: review scope, reviewer independence where required, decisions, fulfilment and overdue actions.
6. Technical proof: connector status, reconciliation results, failed operations, retry or manual correction and monitoring.
7. Privileged and non-human access: inventory, ownership, authentication controls, credential handling, use and periodic review.
8. Exceptions and effectiveness: risk acceptance, compensating controls, test results, incidents, findings and remediation.

Do not select only perfect samples. Use a repeatable sampling method and preserve failures with their remediation. Evidence that shows how the control detects and corrects defects is stronger than a presentation claiming that defects never occur.

A practical 90-day NIS2 identity workstream

NIS2 implementation is broader than identity governance, but access control is a bounded workstream that can produce measurable evidence quickly.

Days 1 to 30. Establish the factual baseline

Confirm the legal applicability record with counsel or the responsible compliance function. Name the management sponsor and operational owners. Define critical services and the systems supporting them. Inventory authoritative identity sources, identity populations, applications, privileged accounts and non-human identities. Map current joiner, mover and leaver processes from the source event to the target result.

Measure what can already be measured: accounts without an owner, active accounts for departed workers, dormant privileged accounts, overdue reviews, failed provisioning changes, manual queues and applications without a named business owner. Do not estimate these numbers when system data is available.

Days 31 to 60. Prioritise controls by service risk

Choose the systems where inappropriate access could cause severe service disruption, safety impact, significant loss or material harm. Define approval, expiry, separation-of-duties, privileged-access and review requirements for those systems. Set removal and fulfilment targets that match the operational risk. Establish an exception process with a named risk owner and expiry date.

Connect access events to incident handling. The security team should know how to obtain identity history, approval records and target-state evidence during an investigation. The identity team should know when a suspicious account, failed mass removal or compromised privileged identity becomes an incident input.

Days 61 to 90. Prove operation

Run one complete access review for the priority scope. Test at least one joiner, mover and leaver path end to end. Reconcile requested changes with the target systems. Test failure handling rather than only the successful path. Verify privileged and service-account ownership. Present the results, exceptions and residual risk to management in a form that supports an approval or remediation decision.

The 90-day result is not “NIS2 complete”. It is a verified control slice and a delivery pattern that can expand. That is more useful than a large policy library with no operating evidence.

How easyIGA fits and where it does not

easyIGA is designed to help organisations govern access across connected systems through structured requests, approvals, lifecycle changes, reviews and retained decision evidence. That directly supports the practical work behind access-control policies and control-effectiveness evidence.

It should be evaluated against the organisation’s real application estate and control requirements. A credible evaluation proves create, modify, disable and remove operations; reconciliation; exception handling; owner accountability; review completion; and exportable evidence. It also tests systems that are difficult to govern, including legacy applications and non-Microsoft environments, instead of demonstrating only the simplest directory account.

easyIGA does not determine whether a legal entity is in scope, replace national legal advice, run the entire cybersecurity programme or guarantee compliance. It can support a defined part of the evidence chain. The organisation remains responsible for risk decisions, system security, incident reporting, business continuity, supply-chain controls and management oversight.

If your access-control policy cannot yet be proved across the systems that support critical services, discuss the gap with us. We can start with a limited technical assessment: identity sources, priority applications, lifecycle events, approvals, reviews, reconciliation and evidence. The output should be a testable control map, whether or not easyIGA is selected.

Questions management should ask before approving the programme

Use these questions in the approval meeting:

• Have we recorded why each legal entity is in or out of scope under the relevant national law?
• Which critical services and dependencies drive our risk assessment?
• Do our measures cover all ten areas in Article 21(2), with owners and effectiveness tests?
• Which detailed implementing rules apply to our entity type, and which do not?
• Can we make and support a significant-incident decision inside the 24-hour window?
• Can we prove that leaver, privileged and supplier access is removed or reviewed in the target systems?
• Do exceptions have accountable owners, compensating measures and expiry dates?
• Has management received enough evidence to approve the measures and oversee remediation?

An honest “no” is useful if it creates an owned action. The dangerous answer is an unsupported “yes” based on a policy title, a product licence or a generic checklist.

Confirm the product scope before choosing a platform

Use the easyIGA evidence overview to map available records to your access-control requirements. It explains captured approval stages, grants made outside easyIGA and missing historical information. Decision-time policy checks are available; rule authoring in easyIGA is planned. Our team has delivered 14+ midPoint implementations, providing practical experience for the design and operation of access controls.

Continue with the implementation

Use the IGA guide for the access-governance operating model and the offboarding playbook to test removal end to end. Financial-sector teams should also assess the DORA access-control framework.

Sources and verification record

Product scope and editorial wording updated on 24 September 2026. The original source-check dates below remain the dates of those checks.

All sources were checked on 12 September 2026.

1. Directive (EU) 2022/2555, official text, EUR-Lex
2. Commission Implementing Regulation (EU) 2024/2690, official text, EUR-Lex
3. European Commission: NIS2 Directive, policy overview and transposition status
4. European Commission: 2026 proposal for targeted amendments
5. ENISA: NIS2 Technical Implementation Guidance
6. ENISA: Supporting NIS2 implementation through actionable guidance
7. ENISA: Cybersecurity of Critical Sectors