NIS2 Minimum Compliance at 50 Employees: 105 of the 161 CIR Requirements Carry No Escape Clause

The Annex to Commission Implementing Regulation (EU) 2024/2690 contains 161 individually numbered requirements. Exactly 56 of them carry one of the three phrases that let an entity decide a requirement does not apply to it: where appropriate, where applicable, or to the extent feasible. The remaining 105 give you nothing to argue with.

That ratio is the closest thing to an honest answer to “what is the minimum?” — and it inverts what most compliance advice implies. Proportionality is real, it is written into the binding text, and it reaches roughly a third of the technical requirements. Even there, it does not authorise a skip. It authorises a documented decision.

Every count below is taken from the Official Journal text, not from a vendor summary.

First: Does CIR 2024/2690 Even Bind You?

Probably not. The Implementing Regulation is not a general NIS2 rulebook — Article 1 names the entities it governs and the list is closed.

It applies “with regard to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers (the relevant entities)” [1]. Eleven categories, all digital infrastructure or digital service. A 50-person food producer, waste operator, chemical distributor or medical device manufacturer is not among them.

Directive Article 21(5) explains why. Its first subparagraph obliged the Commission to adopt an implementing act for exactly those eleven types. The second says the Commission “may” adopt implementing acts for other essential and important entities — permissive, and as at August 2026 the Commission has not exercised it for any other sector [2]. For everyone else the binding obligation remains national law transposing Article 21(2), points (a) to (j): ten headings, no sub-points at all.

Your situation	What legally binds you	Status of the 161 Annex requirements
You are one of the 11 types in CIR Article 1	National transposition of Article 21 plus CIR 2024/2690 directly	Binding, verbatim
Any other Annex I or Annex II entity	National transposition of Article 21(2)(a)–(j) only	Not binding — but it is the Commission’s own reading of what those ten points mean

That distinction is almost never made, and it does not let you ignore the Annex. Recital 3 records that the requirements were built on ISO/IEC 27001, ISO/IEC 27002, ETSI EN 319401 and CEN/TS 18026:2024 [1] — so when an authority or auditor decides whether your measures were “appropriate and proportionate”, the Annex is the most detailed statement of the Commission’s own view in existence. It is the benchmark you will be measured against, not law you must recite. Our breakdown of Article 21(2)(a) and the eleven-entity test works through the scope question in detail.

At 50 employees you have crossed the small-enterprise ceiling: Commission Recommendation 2003/361/EC defines a small enterprise as one employing “fewer than 50 persons” [4], so you qualify as medium-sized and Directive Article 2(1) pulls you into scope if you are an Annex I or Annex II type. Article 3(2) then makes you an important entity unless an Article 3(1) route applies [2].

The Floor, Counted: 161 Requirements, 56 Escape Clauses

Here is the method, so the number can be checked. The Annex has 13 chapters. Each chapter breaks into sections, and most sections break again into numbered points. Counting the deepest numbered unit in each branch — three levels in eleven chapters, two levels in the cryptography and effectiveness chapters plus points 5.2 and 12.5 — gives 161 discrete requirement units. Across the Annex, “where appropriate” occurs 48 times, “where applicable” 10 times and “to the extent feasible” 4 times; those 62 occurrences fall inside 56 of the 161 units [1].

The distribution is the useful part, and it is not uniform:

Annex chapter (Article 21(2) point)	Requirements	With an escape clause	With none
1. Security policy (a)	8	3	5
2. Risk management policy (a)	11	3	8
3. Incident handling (b)	22	9	13
4. Business continuity and crisis management (c)	14	6	8
5. Supply chain security (d)	8	4	4
6. Acquisition, development, maintenance (e)	31	11	20
7. Effectiveness assessment (f)	3	1	2
8. Cyber hygiene and training (g)	8	2	6
9. Cryptography (h)	3	2	1
10. Human resources security (i)	10	3	7
11. Access control (i), (j)	21	3	18
12. Asset management (i)	13	4	9
13. Environmental and physical security (c), (e), (i)	9	5	4
Total	161	56	105

Read the two ends together and a pattern emerges that should change how a small budget is spent. The text most often lets you argue under cryptography (2 of 3 requirements qualified), physical and environmental security (5 of 9) and supply chain (4 of 8) — the expensive chapters, the ones needing hardware, facilities or a vendor programme. It almost never lets you argue under access control (3 of 21), cyber hygiene and training (2 of 8) or risk management (3 of 11) — the ones that cost discipline rather than capital.

For a 50-person entity that inverts the intuitive reading: your flexibility sits where spending is heaviest, your hard obligations where it is lightest. A proportionality argument needs a phrase in the text to attach itself to, and under access control there is usually no phrase there.

A Qualifier Is Permission to Skip With a Written Reason

The 56 qualified requirements are not free either, and this is the single most misread sentence in the Regulation.

Article 2(2), third subparagraph: where the Annex says a requirement applies “where appropriate”, “where applicable” or “to the extent feasible”, and the entity considers it not appropriate, not applicable or not feasible, “the relevant entity shall in a comprehensible manner document its reasoning to that effect” [1]. The verb is shall. The escape clause converts an implementation obligation into a documentation obligation; it does not remove it.

The genuine size concession sits one layer up, in Recital 5: where entities cannot implement requirements “due to their size”, they “should be able to take other compensating measures that are suitable to achieve the purpose of those requirements” [1]. The Commission’s own worked example is a micro-sized entity that cannot segregate conflicting duties, with “targeted oversight by the entity’s management or increased monitoring and logging” offered as substitutes. Recital 5 is interpretive rather than binding, so it signals intent rather than creating a right — but it tells you what a defensible small-entity file looks like: not an empty control, a substituted one.

The practical reframing is this. Minimum viable compliance at 50 people is not a shorter list of controls. It is 161 decisions, 105 of which have only one available answer, and 56 of which have two — implement, or record in writing why not. The evidence you keep for each decision is what survives contact with a regulator; the decision itself is invisible.

Your Headcount Appears Twice in 9,300 Words

Search the Annex for the word “size” and you get two hits. The standalone word “small” returns none [1].

Point 1.2.4: “Depending on the size of the relevant entities, network and information system security shall be covered by dedicated roles or duties carried out in addition to existing roles.” Point 2.3.2: where an independent review is done in-house, the reviewers must sit outside the line of authority of the area under review, and “if the size of the relevant entities does not allow such separation of line of authority, the relevant entities shall put in place alternative measures to guarantee the impartiality of the reviews” [1].

Neither removes a requirement. The first says a 50-person company may hand security duties to someone who already has another job. The second says a company too small for reviewer independence must buy impartiality another way. Both change who performs a control, never whether it exists.

ENISA’s Technical Implementation Guidance — 170 pages written to operationalise this Annex — adds three concrete size dials and no more. Under 1.2.4: “In entities with limited resources, information security responsibilities may be distributed among existing roles … However, the persons assigned should have relevant experience and training.” Under 6.2.2: a secure development life cycle “should be implemented by all entities. However, smaller entities can use a less demanding process such as implementing secure-by-design practices and security-testing processes” — relevant if you build software, and covered further in our guide to CIR Section 6.2 and the development pipeline. Under 11.5.4: identity reviews should run “as a minimum quarterly … However, for micro-sized entities, this can be done annually” [3].

Across those 170 pages, “limited resources” appears once, “smaller entities” twice, “micro-sized” once. “Proportional” and “proportionality” do not appear at all [3]. The guidance built to explain how much is enough never answers the question — a silence worth citing when you write your own justifications. ENISA states plainly that the document “is not legally binding and is only of an advisory character”, and that it “is not able to define whether an entity needs to have all or just some of the ‘evidence’ listed” [3].

What “Minimum” Means When the Regulator Is Reactive

An important entity is supervised differently from an essential one, and that difference is what “minimum” looks like in practice.

Essential entities face routine scrutiny: Article 32(2) empowers authorities to run “regular and targeted security audits” and “random checks”. Important entities do not. Article 33(1) confines authorities to ex post measures, taken “when provided with evidence, indication or information that an important entity allegedly does not comply” [2]. Something has to surface first — an incident report, a complaint, a supplier questionnaire, a former employee.

When it does, two powers do the work. Article 33(2)(d) allows “requests for information necessary to assess, ex post, the cybersecurity risk-management measures adopted by the entity concerned, including documented cybersecurity policies”. Article 33(2)(f) allows “requests for evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor and the respective underlying evidence” [2]. Both are answered from a standing file. Neither can be satisfied retroactively.

Role	What the count above changes for you
Owner / managing director	Budget for the 105 unqualified requirements as fixed cost. Treat the 56 as a written-justification exercise, not a saving — the writing is cheap, the omission is not.
IT manager (no CISO)	Annex 1.2.4 lets the security role sit on top of your existing job. It does not thin the access-control chapter: 18 of its 21 requirements carry no escape clause, the highest proportion in the Annex.
Compliance officer / legal	Build the file around Article 33(2)(d) and (f): documented policies, plus dated evidence that they operate. Every “not applicable” decision needs a comprehensible written reason attached.
Board	Article 34(5) exposure is up to at least EUR 7 000 000 or 1,4 % of worldwide turnover, whichever is higher. Article 21(4) requires corrective measures “without undue delay” once a gap is found — discovery starts a clock.

Entity class	Supervision	Maximum administrative fine (Art. 34)
Essential	Proactive: regular and targeted audits, random checks (Art. 32(2))	At least EUR 10 000 000 or 2 % of total worldwide annual turnover, whichever is higher
Important (the 50-person case)	Ex post only, on evidence or indication of non-compliance (Art. 33(1))	At least EUR 7 000 000 or 1,4 % of total worldwide annual turnover, whichever is higher

The Floor Document Set

Strip the Annex down to the artefacts its own text names and you get thirteen items — one per chapter. This is the smallest file that can answer an Article 33(2)(d) request without gaps.

Annex chapter	Artefact the text names	Evidence that it operates
1	Policy on the security of network and information systems, with a formal approval date at point 1.1.1(k)	Signed and dated approval record; distribution acknowledgements
2	Risk management framework, plus documented risk assessments (2.1.1)	Dated risk register with owners and treatment decisions
3	Incident handling policy (3.1.1)	Incident log; recorded response evidence (3.5.4)
4	Business continuity and disaster recovery plan (4.1.1)	Test records; backup plans with retention periods (4.2.2)
5	Supply chain security policy (5.1.1) and a registry of direct suppliers (5.2)	Supplier register with contact points; selection criteria
6	ICT acquisition risk process (6.1.1); secure development rules (6.2)	Vulnerability scan results (6.10.2(b)); patching decisions
7	Policy and procedures to assess effectiveness (7.1)	Named metrics, owners, review dates (7.2)
8	Awareness and cyber hygiene programme (8.1.1)	Training records covering staff and management bodies
9	Cryptography policy and procedures (9.1)	Algorithm and key-management decisions recorded (9.2)
10	Human resources security arrangements (10.1.1)	Signed responsibility statements; a maintained disciplinary process (10.4.1)
11	Logical and physical access control policies (11.1.1)	Documented access-rights reviews with recorded changes (11.2.3)
12	Asset classification levels (12.1.1)	Asset inventory; return-on-termination records (12.5)
13	Protection of supporting utilities (13.1.1) and against physical and environmental threats (13.2.1)	Recorded minimum and maximum control thresholds; environmental monitoring records (13.2.2)

Thirteen artefacts is not thirteen documents-worth of work — several collapse sensibly into one file at this size, and the Annex nowhere requires them to be separate. What it does require is that each subject is addressed and that the reasoning is legible to someone who was not there. If you are starting from nothing, running a structured gap analysis first is cheaper than drafting blind, and our guides to proportionality at 50–249 employees and to compliance without a CISO cover the sequencing.

Frequently Asked Questions

Is there an officially defined minimum set of NIS2 controls?

No. Neither the Directive nor CIR 2024/2690 defines a reduced control set for smaller entities. Directive Article 21(2) lists ten measure areas that entities “shall include at least”, and Article 21(1) sets a per-entity appropriateness test rather than a fixed floor [2]. Any published “minimum list” is someone’s interpretation, including the one on this page — the difference is that this one shows its arithmetic.

If CIR 2024/2690 does not bind my company, can I ignore the Annex?

Legally, the Annex imposes no obligation on you unless you are one of the eleven entity types in Article 1 [1]. Practically, it is the most detailed statement the Commission has published of what Article 21(2) requires, built on ISO/IEC 27001 and 27002. Most national authorities and auditors will reach for it as the reference point.

Does having 50 employees reduce what I have to implement?

It changes how a requirement is met more than whether it is met. Inside the Annex, size is named twice — points 1.2.4 and 2.3.2 — and both times it adjusts staffing or independence rather than removing a control [1]. Recital 5 adds compensating measures where size genuinely prevents implementation, which is a substitution, not an exemption.

What happens if I decide a requirement is “not applicable”?

For the 56 requirements carrying “where appropriate”, “where applicable” or “to the extent feasible”, Article 2(2) requires you to “in a comprehensible manner document” your reasoning [1]. Write it at the time of the decision, date it, and name the person who made it. A justification written after an authority asks is worth considerably less than one written before.

How likely is a 50-person important entity to be inspected?

Important entities are not subject to routine audits. Article 33(1) allows only ex post measures, triggered when an authority is “provided with evidence, indication or information” of non-compliance [2]. Realistically the trigger is an incident notification, a customer or supplier complaint, or a sector-wide sweep — none of which you control, and all of which arrive without warning.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex, Official Journal. Article 1 (scope), Article 2(2) (proportionality and documented reasoning), Recitals 3 and 5, and the Annex. Requirement counts in this article were computed from the Official Journal text.
2. Directive (EU) 2022/2555 (NIS2) — EUR-Lex, Official Journal. Articles 2, 3, 21, 32, 33 and 34.
3. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 (June 2025) — ENISA. Guidance and examples of evidence for Annex points 1.2.4, 6.2.2 and 11.5.4; disclaimer on non-binding status.
4. Commission Recommendation 2003/361/EC concerning the definition of micro, small and medium-sized enterprises — EUR-Lex. Annex, Article 2 (staff headcount and financial ceilings).