NIS2 Quick Wins: 10 Controls Ranked by Coverage — 47 of the 161 CIR Requirements Sit Under One Article 21 Point

Almost every NIS2 “quick wins” list opens with multi-factor authentication. It is the wrong place to start, and the Commission’s own implementing regulation says so in a way nobody seems to have counted: in the 161 requirement points of the Annex to Commission Implementing Regulation (EU) 2024/2690, Article 21(2) point (j) — the MFA point — is never named once. Point (i), the unglamorous bundle of human resources security, access control and asset management, is named four times — more than any other point — and the three chapters and one section it opens hold 47 of those 161 requirements.

That is the useful way to rank quick wins: not by how cheap a control is, but by how much of the binding text one action produces evidence for. Below are ten ranked that way, with the Annex point numbers so you can check every claim, and a dependency order that explains why the cheapest control on the list has to come before the famous one.

Are you measured against the CIR Annex, or just Article 21?

Two documents, two levels of detail. Which one you are measured against decides how literally to read everything below.

Article 21(2) of the NIS2 Directive binds every essential and important entity. It is ten short points, (a) to (j), and it says almost nothing about how to implement them. CIR 2024/2690 turns those ten points into 161 discrete requirements across 13 Annex chapters — but it binds only the eleven categories of entity listed in the first subparagraph of Article 21(5): DNS service providers, TLD name registries, cloud computing providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking services platforms, and trust service providers.

If you are…	The CIR Annex is…	Read this article as…
One of the eleven Article 21(5) entity types	Binding law, requirement by requirement	A coverage map of obligations you already carry
Any other essential or important entity	Not binding on you — but the most detailed public statement of what the Commission thinks Article 21(2) means	The best available benchmark, plus whatever your national authority has published

For the second group the Annex still matters, because supervisors reaching for a yardstick reach for the one the Commission wrote — our complete Article 21 breakdown walks all ten measures and their CIR sections. And the ranking logic survives the distinction intact, because each Annex chapter opens by naming the Article 21(2) point it implements. Coverage across chapters is therefore coverage across the Directive — though not one chapter to one point: chapters 10, 11 and 12 all implement the same point (i), which is exactly the concentration this ranking exploits.

The 10 quick wins, ranked by coverage

Coverage here means one thing: how many separate requirement points, in how many chapters, one action creates evidence for. Effort ratings are practical estimates for a mid-sized entity with no existing programme — treat them as planning heuristics, not measurements.

#	Control	Reaches	Effort	Owner
1	A dated review calendar	All 13 chapters	Low	Compliance
2	One documented risk assessment	9 of 13 chapters cite point 2.1	Medium	Compliance / IT
3	Asset inventory with classification levels	Chapters 3, 4, 9, 11, 12	Medium	IT
4	MFA on remote access and privileged accounts	Chapter 11 (11.7.1, 11.7.2, 11.3.2)	Low–Medium	IT
5	Logging on identity and access events	Chapters 3, 9, 11	Low	IT
6	A joiners-movers-leavers checklist	Chapters 10, 11, 12	Low	HR + IT
7	One awareness programme, extended to suppliers	Chapters 5, 8, 10	Low	HR
8	A register of access rights with named system owners	Chapters 1, 11, 12	Low	IT
9	Written authentication and credential rules	Six sub-points of 11.6.2 in one document	Low	IT
10	A board approval with a date on it	Chapters 1, 2, 8, 10	Low	Board

Five of the ten — numbers 3, 5, 6, 8 and 9 — draw most of their coverage from the chapters that name point (i). That is not an artefact of the ranking method; it is what the 47-out-of-161 concentration looks like in practice.

The three controls everything else is conditioned on

1. A dated review calendar. Every one of the thirteen Annex chapters closes with a review-and-update requirement — 1.1.2, 2.1.4, 3.1.3, 4.1.4, 5.1.6, 6.1.3, 7.3, 8.1.3, 9.3, 10.1.3, 11.1.3, 12.1.3 and 13.1.3. Twelve of the thirteen use the words “at planned intervals” (chapter 1 at point 1.2.6, chapter 12 at 12.2.3); chapter 13 alone says “on a regular basis”. And the same trigger phrase — “significant incidents or significant changes to operations or risks” — recurs 22 times, more than any other formula in the Annex. Point 2.1.4 shows the full pattern: risk assessment results and the risk treatment plan are reviewed “at planned intervals and at least annually and when significant changes to operations or risks or significant incidents occur.”

The mechanism matters more than the effort. A review requirement is not evidenced by having reviewed something — it is evidenced by a dated record showing the interval was planned in advance and met. That is a calendar and a log, and it is the only control on this list that can be completed in an afternoon and still reach almost every chapter. It is also the one that fails silently: nothing breaks when you skip a review, until someone asks for eighteen months of them. In the gap analyses we run, the review evidence is almost always the thinnest file in the set — the policies exist, the reviews happened, and nobody wrote down when.

2. One documented risk assessment. Requirement points in nine of the thirteen chapters — 2, 3, 4, 5, 6, 7, 9, 11 and 13 — condition themselves on the risk assessment carried out under point 2.1. No other point in the Annex is cross-referenced anything like as often. Point 3.2.3 makes the dependency concrete: the list of assets subject to logging is established “based on the results of the risk assessment carried out pursuant to point 2.1.” Point 5.1.4 routes supplier contract terms through it. Point 9.1 routes cryptographic strength through it.

Practically, this means an undocumented risk assessment does not merely leave chapter 2 unevidenced. It removes the stated basis for decisions in eight other chapters, and each of those decisions then has to be defended on some other ground. Our NIS2 risk assessment walkthrough covers the method; the point here is only its position in the dependency graph.

3. An asset inventory with classification levels. Point 12.4.1 asks for an inventory that is “complete, accurate, up-to-date and consistent”, with changes recorded “in a traceable manner”, and 12.4.2 sets the minimum contents: a list of operations and services with descriptions, and a list of the systems and other assets supporting them. Point 12.1.2 adds the classification layer — every asset associated with a level based on confidentiality, integrity, authenticity and availability requirements, with availability aligned to the recovery objectives in the business continuity plans.

That classification is what the rest of the Annex reads. Backup access controls are set “in accordance with the asset classification level” (4.2.2(d)). Cryptographic strength is set per classification (9.2(a)). And all four authentication requirements in chapter 11 are scoped by it. A spreadsheet does this; see NIS2 asset management requirements for the granularity question.

MFA is a quick win. It is not the first one.

Point 11.7.1 does not say deploy MFA. It says entities “shall ensure that users are authenticated by multiple authentication factors or continuous authentication mechanisms for accessing the entities’ network and information systems, where appropriate, in accordance with the classification of the asset to be accessed.” Point 11.7.2 repeats the conditioning: authentication strength “appropriate for the classification of the asset to be accessed”. So do 11.6.2(a) and 11.6.3.

Two consequences follow, running in opposite directions. MFA is genuinely cheap and genuinely expected — Ireland’s NCSC lists it as a Foundation Action and scopes it exactly where the market does: “Multi factor and/or continuous authentication is used for remote access or privileged accounts where appropriate and proportionate to the risk.” Turning it on for VPN, remote desktop and every administrative account is a short project with a real security return.

But “where appropriate” is a question you cannot answer without control 3. Appropriateness here is defined against asset classification, so an entity with MFA everywhere and no classification scheme has a strong control and a weak evidence file — it can show what it did, not that what it did was appropriate. Under the CIR a qualifier like “where appropriate” is not permission to skip. Article 2(2) routes a requirement you judge inapplicable into a documented exception — and ENISA’s technical implementation guidance lists “logs of policy exceptions”, naming Article 2(2) situations explicitly, among the evidence for the compliance-monitoring requirement at point 2.2.2. The judgement is the artefact, in both directions.

Deploy MFA in week one if you like — the security benefit does not wait for paperwork. Just do not book it as the first compliance win, because the classification it is measured against is the cheaper control sitting behind it. Our NIS2 MFA requirements guide covers the deployment side.

Six more single actions that reach across chapters

5. Logging on identity and access events. Most teams file logging under incident handling, and chapter 3 does own the bulk of it — 3.2.3 lists authentication-related events, privileged access, and changes to critical configuration and backup files among the categories to capture “where appropriate”. But chapter 11 carries its own logging duties independently: 11.2.2(f) applies logging to the management of access rights, and 11.5.2(d) applies it to the management of identities. Chapter 9 adds its own line: the key management approach must cover “logging and auditing of key management-related activities” (9.2(c)(xi)). One logging design, three chapters. See NIS2 logging and monitoring requirements.

6. A joiners-movers-leavers checklist. One HR form reaches three chapters. Point 11.2.2(b) requires access rights modified on termination or change of employment; 11.5.4 requires unneeded identities deactivated without delay; chapter 10 covers termination and change-of-employment procedures; and point 12.5 requires assets under staff custody to be deposited, returned or deleted on termination, with the outcome documented. Ireland’s NCSC makes a JML process a Foundation Action for access control. A leaver checklist that ticks accounts, identities and hardware in one pass is about as much compliance coverage as twenty minutes of process design can buy.

7. One awareness programme, extended to suppliers. Point 8.1.2 sets the reach of the programme itself: it goes to “all employees, including members of management bodies, as well as to direct suppliers and service providers where appropriate in accordance with point 5.1.4”. Point 10.1.2(a) then requires mechanisms ensuring employees and direct suppliers follow the hygiene practices applied “pursuant to point 8.1”, and 5.1.4(b) puts training and awareness requirements into supplier contracts. Building one programme and sending the deck to your critical suppliers touches chapters 5, 8 and 10. Building three separate programmes is the common and expensive alternative — see NIS2 training requirements.

8. A register of access rights with named system owners. Point 11.2.2(e) asks for a register of access rights granted; 11.2.3 requires the rights reviewed at planned intervals with results documented. Add an owner column and the same table also carries chapter 1’s allocation of responsibilities to roles and chapter 12’s list of systems supporting each service. This is the same spreadsheet as control 3 with two extra columns, which is why it ranks where it does rather than higher. More at NIS2 access control requirements.

9. Written authentication and credential rules. Point 11.6.2 is unusually concrete for the Annex: six sub-requirements covering authentication strength, allocation and confidentiality of secret authentication information, credential change on first use and on suspected compromise, reset and lockout after a set number of failed attempts, session termination after inactivity, and separate credentials for privileged accounts. One document answers all six. The configuration work to enforce it is separate and larger — but the document is the artefact a supervisor asks for first.

10. A board approval with a date on it. The phrase “management bodies” runs through requirement points in chapters 1, 2, 8 and 10. Point 1.1.1(k) asks the security policy to “indicate the date of the formal approval by the management bodies of the relevant entities”; 1.1.2 puts the annual review in the management body’s hands; 2.1.1 has residual risk accepted by management bodies or a properly reporting delegate; 2.2.1 requires regular compliance reporting to them; 8.1.2 puts them inside the awareness programme. A single signed, dated board minute covering policy approval, resource commitment and residual risk acceptance is the cheapest artefact on this list and one of the hardest to reconstruct after the fact.

What your own regulator counts as the minimum

The CIR Annex tells you what the Commission thinks the measures mean. It does not rank them. The closest thing to an official ranking published so far comes from Ireland’s National Cyber Security Centre, whose draft Risk Management Measures guidance splits every control into Foundation Actions — “the minimum required to meet the legislative obligations of the Directive” — and Supporting Actions, which “supplement the foundation actions” where risk demands it.

Counted across the sixteen measures, that draft contains 74 Foundation Actions and 129 Supporting Actions — and the two most technical measures are the most optional: acquisition, development and maintenance runs 5 Foundation to 21 Supporting, and incident handling 8 to 24. Registration is 4 Foundation and zero Supporting — a measure you can finish completely. Asset management is 3 Foundation to 10 Supporting, meaning the inventory and classification that gate so much of chapter 11 are, in the regulator’s own framing, a small baseline with a large optional tail.

Two calibrations travel with this. It is draft guidance, and Ireland had not transposed NIS2 at the time of writing, so it binds nobody yet. And it is one member state: your own authority may set the baseline elsewhere. Read it as the best-documented regulator opinion available, not as a rule — and note that its own guidance on cyber hygiene builds that measure out of four others, which is the same overlap this article ranks by.

A four-week order of work

Week	Do	Who owns it	Artefact produced
1	Controls 1 and 3 — review calendar, asset inventory and classification	Compliance + IT	Calendar with owners and dates; asset spreadsheet with classification column
2	Control 2 — risk assessment against the classified asset list	Compliance, IT input	Risk assessment, treatment plan, residual risk list
3	Controls 4, 5, 8, 9 — MFA scoped by classification, logging, access register, credential rules	IT	Access register; authentication policy; log configuration record
4	Controls 6, 7, 10 — JML checklist, awareness programme, board sign-off	HR + Board	Leaver checklist; awareness deck and attendance log; dated board minute

The sequence exists for one reason: weeks 3 and 4 are cheap only if weeks 1 and 2 have already defined what “appropriate” means. Run them the other way round and you buy the same tools, write the same documents, and still have to answer the appropriateness question afterwards. If you would rather score your current position before starting, our NIS2 gap analysis guide covers the assessment step, and NIS2 minimum compliance at 50 employees looks at the opposite question — which requirements carry an escape clause and which do not.

Frequently Asked Questions

Does doing these ten controls make us NIS2 compliant? No. They are the highest-coverage starting points, not a complete programme — the Annex has 161 requirement points and this list touches a fraction of them directly. What the ranking buys you is the fastest route to a defensible evidence file, and an order of work in which later controls are cheaper because earlier ones defined their scope.

Why is MFA ranked fourth when every other list puts it first? Because the Annex conditions it on asset classification in all four places it appears, and never names Article 21(2) point (j) at all. Deploy it early for the security benefit; just do the classification first, or you can show the control without showing that it is appropriate.

We are not one of the eleven CIR entity types. Does any of this bind us? Article 21(2) binds you; the CIR Annex does not. But the coverage relationships are structural rather than jurisdictional — a risk assessment still underpins your logging scope and your supplier terms whether or not point 2.1 applies to you by name. Check what your national competent authority has published, and treat the Annex as the reference benchmark.

How much does this cost? Nine of the ten are documents, spreadsheets, calendar entries or a signature. MFA carries a licence cost and logging carries a storage cost; the rest cost time. Article 21(1) explicitly allows cost of implementation to be taken into account in deciding what is appropriate — which is precisely why the document-first controls rank highest: they are the ones cost cannot excuse.

What if we find a gap while doing this? Article 21(4) requires an entity that finds it does not comply to take “all necessary, appropriate and proportionate corrective measures” without undue delay. Discovery starts a clock. Record the finding, the corrective action and the date — that record is worth more at an inspection than a clean sheet with no history. Our NIS2 evidence collection guide covers what to keep.

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

• ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 (June 2025) — quotes the CIR 2024/2690 Annex requirement points verbatim; source for every Annex citation and count in this article. Linked in full above.
• National Cyber Security Centre (Ireland), NIS2 programme page; its Draft Risk Management Measures Guidance (June 2025), linked in full above, is the source of the Foundation and Supporting Action counts.
• Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex, eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
• Directive (EU) 2022/2555 (NIS2) — EUR-Lex, eur-lex.europa.eu/eli/dir/2022/2555/oj