45 NIS2 Technical Controls Every IT Administrator Must Implement (CIR 2024/2690, Effort-Rated)

If you’re the IT administrator who actually has to make NIS2 real — not the consultant who writes the policy, the person who configures the firewall — the Directive itself won’t help you much. Article 21 of NIS2 tells you that you need “network security” and “cryptography” [5]. It doesn’t tell you which controls, at what depth, or what to build first. Commission Implementing Regulation (EU) 2024/2690 (CIR 2024/2690) is the document that actually gets specific — but it’s written as regulatory text, organised into 13 thematic sections, not as a build list [1].

This is that build list. Below are 45 technical controls pulled from four CIR sections that map directly onto an IT admin’s day job — network security, access control and authentication, cryptography, and asset management — each with a realistic effort rating and the category of tooling you’d use to close the gap. I’ve also corrected a common mislabeling: these requirements sit at CIR Annex Section 6.7 (network security), Section 9 (cryptography), Section 11 (access control, including 11.7 multi-factor authentication), and Section 12 (asset management) — not “Annexes 6-9” as a flat sequence, which is how this mapping sometimes gets summarised second-hand [2].

Who This CIR Actually Applies To — and Who Should Read Each Section

CIR 2024/2690 doesn’t apply to every NIS2 entity. It’s a narrower instrument that binds specific digital-infrastructure and ICT entity types: DNS service providers, top-level domain (TLD) name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers and managed security service providers, online marketplaces, and trust service providers [1][2]. If you administer IT for a hospital or a manufacturer, your organisation’s technical obligations come from Article 21 of the Directive directly, and your national competent authority’s guidance — not this CIR. If you’re unsure which applies to you, our scope guide walks through the classification test.

For the entities the CIR does bind, the technical detail below is not optional interpretation — it’s the actual compliance bar. Three roles will use this checklist differently:

• IT Administrator / Sysadmin: this is your implementation punch list. Work through the tables in priority order — Access Control first (it’s the fastest to show measurable progress), then Network Security, then Cryptography and Asset Management in parallel.
• CISO / Security Manager: use the effort ratings to build a realistic 6-12 month roadmap and to push back on unrealistic “full compliance by Friday” asks from the board.
• Compliance Officer: the Documentation Checklist near the end lists exactly what auditors will ask to see for each category — collect it as you go, not retroactively.

If you need the full policy documents that back these controls — not just the checklist — that’s a different deliverable than this article; more on that below.

How This Checklist Is Built

Each of the 45 items below maps to a specific CIR sub-requirement. The effort rating is a practical estimate for a mid-sized IT team with an existing Active Directory/Entra ID or equivalent identity backbone, not a green-field build — adjust upward if you’re starting from spreadsheets and shared local-admin passwords:

• Low — policy/configuration change, days not weeks, minimal budget
• Medium — needs a new tool, a project, or cross-team coordination; weeks to a couple of months
• High — architectural change, new platform, or organisation-wide rollout; months, often needs budget approval

The “tooling category” column names a class of tool, not a specific vendor — CIR 2024/2690 is technology-neutral by design, and a smaller organisation’s “PAM solution” might be a documented process, not a product. Practitioner analyses of the full Annex count more than 150 discrete sub-requirements spread across all 13 sections [4]; the 45 below are the subset an IT administrator typically owns directly, rather than the parts that sit with legal, HR, or the board.

Category 1: Network Security — CIR Section 6.7 (11 controls)

Section 6.7 sits inside the broader Section 6 (“security in network and information systems acquisition, development and maintenance”) and requires measures to protect networks against cyber threats, documented network security controls, secure remote access, and periodic review after incidents or organisational change [2][3].

#	Control	CIR Ref	Effort	Tooling Category
1	Network topology & asset map documented and current	6.7.2	Low	CMDB export / network diagram tool
2	Network segmentation (VLANs, DMZ, IT/OT separation where relevant)	6.7.2	High	Firewall / NAC platform
3	Firewall ruleset reviewed for least privilege, unused rules removed	6.7.2	Medium	Firewall rule-review tool or scheduled manual audit
4	Intrusion detection/prevention deployed at network boundaries	6.7.2	High	IDS/IPS (network sensor or NGFW module)
5	DNS resolver hardening and validation configured	6.7.2	Medium	DNS security extension / resolver logging
6	Secure remote-access gateway in place (VPN or zero-trust broker)	6.7.2	Medium	VPN concentrator / ZTNA broker
7	Wireless networks on enterprise authentication, rogue AP detection enabled	6.7.2	Medium	WIDS / enterprise Wi-Fi controller
8	Network traffic monitoring with anomaly alerting	6.7.2	High	NetFlow collector / SIEM ingestion
9	Network device configurations follow a documented secure baseline	6.7.2	Medium	Configuration management / CIS benchmark scanner
10	Network device firmware and OS patched on a defined cycle	6.7.2	Medium	Patch management / device inventory tool
11	Network security measures re-reviewed after incidents or major changes	6.7.3	Low	Change-management ticketing system

Category 2: Access Control & Authentication — CIR Section 11 (12 controls)

Section 11 is the section every IT admin already half-recognises: access rights management, privileged-account control, unique identification, authentication, and — at sub-point 11.7 — multi-factor or continuous authentication for critical systems and remote access, reviewed at planned intervals [2]. Our access control guide and MFA requirements breakdown cover the policy side; the table below is the implementation side.

#	Control	CIR Ref	Effort	Tooling Category
12	Written access control policy covering rights management and privileged accounts	11	Low	Policy document
13	Joiner/mover/leaver workflow removes and adjusts access automatically	11	Medium	IAM / identity governance (IGA) platform
14	Privileged account inventory maintained and reviewed	11	High	Privileged access management (PAM) tool
15	Just-in-time or just-enough privileged access (no standing admin rights)	11	High	PAM with session brokering
16	Administration performed through hardened jump hosts, not directly on production	11	Medium	Bastion host / PAM gateway
17	Every user and service account uniquely identified — no shared logins	11.5	Low	Directory service cleanup (AD / Entra ID)
18	Baseline authentication policy enforced (password strength, lockout, rotation where risk-justified)	11.6	Low	Directory / identity provider policy
19	MFA enforced for all remote access	11.7	High	MFA / identity provider (conditional access)
20	MFA or continuous authentication enforced for access to critical systems	11.7	High	Conditional access / continuous auth policy engine
21	Access rights recertified on a defined schedule, not just at onboarding	11	Medium	IGA access-review module
22	Service-account credentials and API keys rotated on a defined schedule	11	Medium	Secrets manager (vault-type tool)
23	Privileged sessions time out and require re-authentication	11.7	Low	PAM / identity provider session policy

Category 3: Cryptography — CIR Section 9 (10 controls)

Section 9 requires a documented cryptography policy covering algorithm and key-strength selection, plus key-lifecycle management — generation, storage, rotation, and destruction — reviewed against current best practice [2]. It’s the section IT admins most often treat as “done” because TLS is on by default somewhere, without a policy or key-management process behind it — which is exactly what a CIR audit checks for.

#	Control	CIR Ref	Effort	Tooling Category
24	Written cryptography policy defining approved algorithms and minimum key strengths	9.1	Low	Policy document + crypto asset inventory
25	Data-at-rest encryption on servers, databases, and endpoints	9.1	Medium	Disk/volume encryption (e.g. platform-native full-disk encryption), database TDE
26	Data-in-transit encryption enforced (TLS 1.2 minimum, 1.3 preferred)	9.1	Medium	TLS configuration scanner, load-balancer/reverse-proxy config
27	Certificate lifecycle managed — issuance, renewal, revocation tracked centrally	9	Medium	Certificate lifecycle manager / internal PKI
28	Key generation uses approved methods; hardware-backed keys where risk warrants it	9	High	HSM or cloud key-management service (KMS)
29	Encryption keys stored separately from the data they protect	9	Medium	KMS / HSM
30	Keys rotated on a defined schedule	9	Medium	KMS automation
31	Documented key destruction procedure for decommissioned keys	9	Low	KMS / documented procedure
32	Deprecated algorithms and protocols tracked and retired (e.g. legacy TLS versions, weak hash functions)	9.1	Medium	Vulnerability scanner with cryptographic checks
33	Cryptography policy reviewed on a schedule against current guidance	9.1	Low	Calendar review against ENISA/standards-body bulletins

Category 4: Asset Management — CIR Section 12 (12 controls)

Section 12 requires an asset management policy, an actual inventory of network and information systems and their supporting assets, classification-based handling rules, removable media controls, and secure disposal procedures [2]. This is the section that turns up the most audit findings in practice — not because the controls are hard, but because “the inventory” quietly stops being current within a few months of being built.

#	Control	CIR Ref	Effort	Tooling Category
34	Written asset management policy	12	Low	Policy document
35	Asset classification scheme defined (confidentiality/criticality tiers)	12.1	Medium	Data classification / tagging tool
36	Inventory of network and information systems maintained	12	Medium	Configuration management database (CMDB)
37	Inventory extended to supporting assets — cloud resources, SaaS, shadow infrastructure	12	Medium	Cloud asset inventory / CSPM tool
38	Automated discovery reconciles the inventory against what’s actually deployed	12	High	Network/asset discovery scanner
39	Handling rules defined per classification tier and actually enforced	12	Low	Policy + data-loss-prevention tagging
40	Removable media policy in place (allowed devices, approval process)	12	Low	Endpoint/USB control policy
41	Removable media encryption enforced where use is permitted	12	Medium	Endpoint encryption agent
42	Secure return/disposal procedure for decommissioned assets (certified wipe or destruction)	12.2	Low	Certified data-destruction service or wipe tool
43	End-of-life hardware tracked so nothing is quietly retired off-inventory	12	Medium	CMDB lifecycle field
44	Unauthorized/shadow-IT assets actively detected, not assumed absent	12	High	Network discovery + CASB
45	Every asset has a named owner accountable for its classification and handling	12	Low	CMDB owner field

Who Owns Which Control

NIS2 assigns liability at management-body level even though implementation is technical — which means every control above needs an owner beyond “IT will handle it.” A realistic split:

Role	Owns
IT Administrator	Day-to-day implementation and maintenance of all 45 controls; first point of contact for control failures
CISO / Security Manager	Control design decisions, effort/risk trade-offs, exception approvals, reporting status to the board
Compliance Officer	Evidence collection, mapping controls to CIR/Article 21 references, audit-readiness
Management Board	Budget approval for High-effort items, formal sign-off on residual risk for anything deliberately not implemented

A Worked Gap-Analysis Example

Take control #19 (MFA on all remote access) and control #36 (systems inventory) as a two-item worked example of the gap-analysis approach that scales to all 45:

Control	Current State	Required State	Steps to Close	Effort
#19 MFA on remote access	VPN protected by password only; MFA exists for email but not VPN	MFA required for every remote-access session, reviewed periodically (11.7)	Extend existing MFA/identity provider policy to the VPN or ZTNA login; pilot with IT team; roll out org-wide; document review cadence	High
#36 Systems inventory	Spreadsheet last updated 8 months ago; several cloud resources untracked	Current, actively maintained inventory covering on-prem and cloud (12.2)	Stand up a CMDB or lightweight asset-tracking tool; run a discovery scan to reconcile; assign an owner to keep it current going forward	Medium

The pattern is always the same: name the current state honestly (this is where audits fail — optimistic self-assessment), state the CIR-required end state precisely, and rate the real effort to close the gap rather than the effort you’d like it to be.

Documentation Checklist — What an Auditor Will Ask to See

Implementing the control isn’t the same as proving you implemented it. For each category above, keep:

• Network Security: current network diagram, firewall rule-review log with dates, IDS/IPS alert-handling records
• Access Control: access control policy, privileged-account inventory, MFA enforcement report from your identity provider, most recent access recertification record
• Cryptography: cryptography policy document, certificate inventory with expiry dates, key-rotation log
• Asset Management: current asset inventory export, classification scheme document, disposal certificates for decommissioned hardware

Our audit preparation guide covers how these get assembled into an actual audit trail rather than a folder of loose files.

Where IT Admins Most Often Get This Wrong

Three patterns show up repeatedly in gap assessments:

Treating the inventory as a one-time project. An asset inventory built once for a compliance deadline and never touched again fails the next audit just as hard as having no inventory — the CIR’s asset management section requires a maintained inventory, not a historical snapshot [2].

MFA everywhere except the one system that matters most. It’s common to find MFA rolled out to email and general SaaS while the actual production VPN, the domain admin console, or a legacy system with no MFA support is quietly excluded. Section 11.7 specifically calls out critical-system and remote access — the systems most likely to have been carved out as “too disruptive to touch.”

Cryptography policy that describes what should happen, disconnected from what’s deployed. A policy mandating TLS 1.3 and rotated keys is worth little if nobody has actually scanned the environment for services still running TLS 1.0 or self-signed certificates nobody tracks. Pair every crypto policy line with a scan that verifies it.

Frequently Asked Questions

Does CIR 2024/2690 apply to my organisation if we’re not a cloud or DNS provider?
Not directly. The CIR’s technical requirements bind the specific entity types listed above. If you’re outside that list, your technical obligations come from Article 21 of the NIS2 Directive and your national competent authority’s guidance, which cover similar ground with more room for proportionality [5][6].

Is this a complete list of every CIR 2024/2690 requirement?
No. The Annex covers 13 sections in total; this checklist focuses on the four most directly relevant to hands-on IT administration — network security, access control, cryptography, and asset management. Risk management, incident handling, business continuity, supply chain, and training sit in other sections and warrant their own checklists.

What effort rating should I expect if we’re starting from nothing?
Add roughly one tier to every rating above. An organisation with no MFA, no CMDB, and no cryptography policy should expect most of this list to run Medium-to-High rather than Low-to-Medium — the ratings above assume an existing identity backbone and some baseline hygiene.

How current is Ireland’s NIS2 transposition, and does it change what applies to me?
As of early 2026, Ireland had not completed formal transposition — the National Cyber Security Bill remained in pre-legislative scrutiny after missing the October 2024 deadline, with NIS1 rules still in force in the interim [7]. This affects which national authority enforces against you and under what interim rules — it does not change CIR 2024/2690 itself, which is a directly applicable EU regulation for the entity types it covers.

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.

[2] CIR 2024/2690 — NIS2 Technical Measures. nisd2.eu.

[3] NIS2 Implementing Act DVO (EU) 2024/2690. OpenKRITIS.

[4] NIS2 CIR 2024/2690: Cybersecurity Requirements for EU Digital Infrastructure. Advisera.

[5] Article 21, Directive (EU) 2022/2555 (NIS2 Directive). nis-2-directive.com.

[6] NIS2. National Cyber Security Centre, Ireland.

[7] NIS 2 Directive — Transposition in Ireland. nis-2-directive.com.