Under NIS2, "important" is not a lighter security tier
Teams read the important label as NIS2-lite and scope their controls down. The security measures in Article 21 are the same either way; the tier changes supervision, some enforcement tools, and the floor on the national fine maximum.

A NIS2 scoping exercise can end with a moment of relief. The team works through its sector under Annexes I and II, checks its headcount and turnover against the size thresholds, and concludes that it is an "important" entity rather than an "essential" one. The finding travels up as good news: we are in the lighter tier, so the security programme can be scoped accordingly. The controls list gets trimmed, the incident process is set aside as a later phase, and the board hears that NIS2 lands softly.
That reading of the word "important" is the mistake. The essential and important tiers are not a heavy and a light version of the same security obligation. They are two supervision and enforcement regimes attached to the same obligation. The tier a team lands in changes how it will be checked, which extra enforcement tools the authority can use, and the floor on the national fine maximum. It does not change the security measures it owes.
The obligations that do not move with the tier
The substantive duties of NIS2 are written to both tiers at once. Article 21(1) of Directive (EU) 2022/2555 (adopted 14 December 2022) requires Member States to ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of the network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents on recipients of their services and on other services. The minimum list that follows in Article 21(2), from risk analysis and incident handling to supply-chain security, access control, and the use of cryptography, is a single list. There is no shorter Annex of measures for important entities and no longer one for essential entities.
The reporting duty is written the same way. Article 23 requires both essential and important entities to notify significant incidents to the CSIRT or competent authority: an early warning within 24 hours of becoming aware and an incident notification within 72 hours. For trust service providers, that second deadline is 24 hours where the significant incident affects the provision of their trust services. A final report follows within one month of the incident notification; if the incident is still ongoing then, a progress report is due, followed by a final report within one month after the incident is handled. The clock does not slow down for the important tier. An important entity that treats its incident-reporting readiness as optional has misread the same article an essential entity is bound by.
So the first correction is factual. If the scoping exercise concludes "important, therefore fewer controls," it has invented a distinction the directive does not make. Article 21 is the source of the obligation, and Article 21 does not know which tier you are in.
The label is not even a proxy for how much work you owe
There is a second, quieter error underneath the first: the assumption that "important" tracks "smaller," so a lighter programme is proportionate anyway. The classification does not work that way. Under Article 3, essential entities are, broadly, entities of a type listed in Annex I (the high-criticality sectors, such as energy, transport, banking, health, and digital infrastructure) that exceed the ceilings for medium-sized enterprises in Commission Recommendation 2003/361/EC of 6 May 2003, together with specific types that are essential regardless of size. Qualified trust service providers, TLD name registries, and DNS service providers are essential whatever their headcount. Important entities are, as a starting point, the residual set in Article 3(2): entities of a type referred to in Annex I or II that do not qualify as essential. Read with Article 2, that residual is not every non-essential Annex I or II entity. The general rule covers medium-sized and larger entities; smaller entities are in scope only through specified size-independent routes. Member States may also identify entities as important under Article 2(2)(b) to (e), and a large Annex II entity can be designated essential under Article 3(1)(e) or become essential through critical-entity identification under Article 3(1)(f).
Follow that through and the label detaches from size. A large multinational operating in a specified Annex II sector, for example industrial production of food, chemicals, or a digital provider such as an online marketplace, can be an "important" entity even with tens of thousands of employees, because size alone does not lift an Annex II sector into the essential tier. Meanwhile a small DNS provider is essential regardless of size. The proportionate measures for that large important manufacturer are not modest, because proportionality in Article 21(1) is set against the entity's risk exposure, the size of the entity, the likelihood and severity of incidents, and the state of the art, not against its tier. You cannot read your workload off the word "important." A firm that does so is likely to under-build. That last sentence is practitioner judgment, not a statistic.
What the tier actually changes
The tier does three things that are worth naming because they are real.
First, it sets the supervision posture. Article 32, governing essential entities, gives competent authorities a proactive toolkit: regular and targeted security audits, on-site inspections, off-site supervision including random checks, and security scans. An essential entity can be audited because it is time to audit it, with no incident required. Targeted audits can be paid for by the entity and can lead to enforcement; they are not a free rehearsal. Article 33, governing important entities, is written to a reactive trigger. Its supervisory and enforcement measures apply "when they are provided with evidence, indication or information that an important entity allegedly does not comply." Article 33 is explicit that this is ex post supervision. Information arising from an incident or its Article 23 notification can supply that trigger if it indicates possible non-compliance. So can a complaint, a media report, or information from another authority. An incident is not, by itself, proof of non-compliance.
Second, it sets extra enforcement tools for essential entities. Article 32(5) lets the authority, as a last resort, suspend a certification or authorisation concerning the relevant parts of the service, or request that a natural person discharging managerial responsibilities at chief executive or legal representative level be temporarily prohibited from exercising those functions. Those tools are written for essential entities, not important ones.
Third, it sets the floor on the national fine maximum for infringements of Articles 21 or 23. Article 34(4) requires that essential entities be subject to administrative fines of a maximum of at least 10,000,000 EUR or at least 2% of total worldwide annual turnover, whichever is higher. Article 34(5) sets the important-entity floor lower, at a maximum of at least 7,000,000 EUR or at least 1.4% of total worldwide annual turnover. Those figures are the minimum level each Member State must give its maximum fine for those infringements. They are not an EU-wide cap, and they are not a formula for every individual fine.
Those three differences change your operating relationship with the regulator. None of them is a reduction in the security you are required to have in place.
Reactive supervision is a reason to be more rigorous, not less
Here is the turn a scoping team can miss. The important tier's lighter supervision is easy to read as lower pressure. Operationally it can cut the other way. An essential entity is more likely to meet the authority on a scheduled Article 32 audit, while systems are running normally. That meeting can still produce findings and costs. What it does give is a chance to close gaps before an incident. An important entity is subject to Article 33 supervisory action once there is an indication of non-compliance. It can still have other regulatory interactions, including incident notifications under Article 23. Recital 122 of the same directive says important entities should not be required to document compliance with the cybersecurity risk-management measures systematically. That is not a licence to have no evidence. It is a reason, as practitioner advice rather than a legal duty, to keep the risk decisions, the incident process, and the logs you would actually need if the first conversation with the authority is an investigation rather than an audit.
So the tier that is supervised more lightly is the tier that has to supervise itself. Lighter supervision is not lighter risk. It is risk deferred to a worse moment.
The honest objection
The strongest counterargument is the word "proportionate" in Article 21(1). A small important entity genuinely can, and should, implement a lighter set of measures than a large essential energy operator, and the directive intends exactly that. This is true. But notice what is doing the work: size and risk exposure, not the tier label. Proportionality would scale the programme of a small essential entity down too, and it would scale the large Annex II manufacturer's programme up despite its important status. (A large bank is the wrong example here: Regulation (EU) 2022/2554 (DORA) is lex specialis for covered financial entities and displaces NIS2 Articles 21 and 23 and the related supervision and enforcement provisions, per Article 4 and Recital 28 of the NIS2 Directive.) The tier and the proportionality assessment are different axes. Reading the tier as a shortcut for the proportionality assessment is how a large important entity ends up with a small entity's controls.
The rule worth keeping
Treat the essential and important classification as a supervision, enforcement, and penalty line, not a security-scope line. Derive your obligations from Article 21 and your own risk assessment, size your measures by proportionality against that risk, and let the tier tell you how you will be checked, which extra enforcement tools exist, and the floor on the national fine maximum. When the tier is important, read the reactive supervision of Article 33 as a signal to keep the evidence you would need in an investigation, not to defer the work.
One jurisdictional caveat matters throughout. NIS2 is a directive, so the operative obligations bind through each Member State's transposing law. The transposition deadline of 17 October 2024 (Directive (EU) 2022/2555, Article 41) has not been met uniformly. The European Commission opened infringement proceedings against 23 Member States on 28 November 2024 and, on 8 July 2026, referred Ireland, Spain, France, and the Netherlands to the Court of Justice for failing to notify complete transposition (press release IP/26/1499). The core classification architecture and size criteria come from the directive and from Recommendation 2003/361/EC. National law makes the obligations operative and may add gold-plating; it does not independently invent the EU size thresholds. A firm in a state still finishing transposition should read the architecture from the directive and confirm the specifics against the national law as it lands.
Separating the obligations that follow you across tiers from the supervision and enforcement that change with them, and mapping both against the articles and your national transposing act, is the kind of cross-referencing ISMS Copilot is built to support. The tier is worth getting right for your penalty exposure and your dealings with the regulator. It is the wrong variable to let shape the size of your security programme.
This is practical compliance analysis, not legal advice. Confirm your entity's classification and obligations against your Member State's transposing law and, where it matters, with your competent authority or counsel.
Related Posts

Your ISO 27001 certificate does not start DORA's clocks
Financial entities keep mapping ISO 27001 controls onto DORA articles and calling the residue paperwork. DORA's real additions are duties that must be performed, to a specification and on a clock, that a certificate was never designed to test.

The scope statement is the certificate
"ISO 27001 certified" is not a yes-or-no fact about a company. The real claim is the scope statement on the certificate, and it is checkable.

The CRA is a 2026 problem, not a 2027 one
The Cyber Resilience Act's reporting duty applies from 11 September 2026, more than a year before its essential requirements. Teams planning backwards from the 2027 CE mark are sequencing the work in the wrong order.
