NIS2 for IT Managers: Article 21 Mapped to MFA, SIEM, Backup, and Network Segmentation Decisions

Only 16% of organisations report confidence in their NIS2 compliance. In most cases, the gap between knowing what the directive says and having systems configured to prove it lands squarely on the IT department.

NIS2’s Article 21 lists ten cybersecurity measures that covered entities must implement. Six of those measures translate directly into IT infrastructure decisions: how you deploy MFA, architect your backups, configure your SIEM, segment your network, manage patches, and detect endpoint threats. The other four — supply chain security, secure development, HR security, and cyber hygiene training — require significant IT input even if ownership sits elsewhere.

The directive’s language is intentionally principle-based. “Appropriate and proportionate technical measures” does not specify products or architectures, which gives your organisation flexibility but requires you to make and document the reasoning behind each decision. Commission Implementing Regulation (EU) 2024/2690 translates those principles into more than 150 specific controls — but the six workstreams covered here account for the majority of the compliance gap most IT teams face.

This guide maps each Article 21 obligation to a concrete IT programme workstream. It explains what each control is designed to achieve — not which vendor to buy from — and provides an effort/impact matrix to sequence the work in a defensible, risk-justified order.

For a complete overview of NIS2’s technical and organisational obligations, see our NIS2 requirements guide.

What Article 21 Asks of Your IT Team

Article 21(1) of Directive (EU) 2022/2555 requires entities to implement “appropriate and proportionate technical, operational and organisational measures” to manage risk. “Appropriate” means demonstrably matched to your actual risk profile. “Proportionate” means sized to your organisation’s exposure, sector, and capacity — a mid-market manufacturer and a cloud service provider face different implementation expectations under the same directive.

Article 21(2) specifies ten minimum areas. Not all of them live in IT, but most touch it:

Art. 21(2) Measure	Primary Owner	IT Involvement
(a) Risk analysis & security policies	CISO / Compliance	Supporting: asset inventory, system data
(b) Incident handling	IT Security / SOC	Core: detection, containment, evidence
(c) Business continuity & backup	IT / Business	Core: backup architecture, RTO/RPO
(d) Supply chain security	Procurement / IT	Vendor access controls, third-party monitoring
(e) Secure development & vulnerability handling	IT / Dev	Core: patch management, vulnerability scanning
(f) Effectiveness assessment	CISO / IT	Core: metrics, control testing, SIEM evidence
(g) Cyber hygiene & training	IT / HR	Device configuration, update management
(h) Cryptography & encryption	IT / Architecture	Core: TLS standards, key management
(i) HR security & access control	IT / HR	Core: IAM, JML process, least privilege
(j) MFA & secured communications	IT	Core: MFA rollout, communication security

Article 21 Mapped to Your IT Stack

The six IT workstreams below map Article 21(2) obligations to specific infrastructure decisions. Each entry shows the regulatory requirement and what it requires you to build, configure, or document:

Workstream	Article 21(2)	What it achieves
Identity & Access (MFA, IAM)	(i), (j)	Prevents credential-based intrusions; limits privilege escalation
Security monitoring (SIEM, logs)	(b), (f)	Creates detection capability and audit evidence trail
Backup architecture	(c)	Ensures recovery within defined RTO/RPO after incident or ransomware
Network segmentation	(a), (g)	Limits lateral movement; reduces blast radius of any intrusion
Patch & vulnerability management	(e)	Removes exploitable attack surface on a defined, documented timeline
Endpoint detection (EDR/XDR)	(b), (f)	Detects behavioural threats; feeds SIEM with endpoint telemetry

Workstream 1: Identity and Access (Art. 21(2)(i) and (j))

Article 21(2)(j) is the most explicit technical requirement in the directive: multi-factor authentication or continuous authentication solutions. Article 21(2)(i) adds the access control policy requirement that determines who is allowed to authenticate to what.

The IT decision is not whether to implement MFA — the directive removes that choice. The decisions are: which accounts, which systems, which authentication methods, and in what order.

Commission Implementing Regulation (EU) 2024/2690 (Point 10.1.1) specifies that MFA should be applied particularly to remote access, privileged accounts, and access to sensitive information. That maps to a three-phase rollout most IT teams can execute sequentially:

• Remote access first — VPN, RDP, remote desktop gateways. This is where credential-based intrusions most commonly begin, and MFA deployment here produces the highest risk reduction per hour of IT effort.
• Privileged accounts second — Domain admins, server admins, cloud IAM roles, CI/CD pipeline credentials. Compromise here enables lateral movement across your entire environment.
• All user accounts third — Email, SaaS platforms, collaboration tools. Broader rollout with lower individual impact but required for full Art. 21(2)(j) coverage.

The access control policy under Art. 21(2)(i) requires documented least-privilege assignment and a Joiner-Mover-Leaver (JML) process — the procedure for creating, modifying, and revoking access rights. Auditors specifically look for evidence that departed employees’ accounts are disabled promptly, with timestamps showing when the revocation occurred relative to the termination date.

For detailed implementation guidance, see our full articles on NIS2 MFA requirements and NIS2 access control obligations.

Workstream 2: Security Monitoring and SIEM (Art. 21(2)(b) and (f))

Incident handling under Art. 21(2)(b) requires detection capability — you cannot report an incident you did not detect. Effectiveness assessment under Art. 21(2)(f) requires that you can demonstrate your controls are working. Both requirements converge on the same IT infrastructure: centralised logging and security monitoring.

Commission Implementing Regulation (EU) 2024/2690 (Points 3.2.1–3.2.4) specifies that entities shall maintain logs of network traffic, authentication events, privileged access, and system resource usage, with alarm thresholds triggering appropriate responses in a timely manner.

What this translates to in IT infrastructure terms:

Log sources (minimum coverage): Firewalls, domain controllers and authentication events, endpoint agents, cloud platforms, email gateways, and privileged access management systems. Every authentication event and every privileged action must be logged.

Log retention: The implementing regulation does not specify a fixed period, but enforcement practice across comparable frameworks points to a minimum of 12 months total, with at least 6 months in hot storage for rapid investigation.

SIEM or centralised log management: A SIEM aggregates these sources and applies detection rules. The critical implementation decision is not which product to select — it is whether your organisation has the analyst capacity to triage alerts. A SIEM generating alerts that nobody investigates does not satisfy Art. 21(2)(b)’s incident handling requirement. The directive requires demonstrably effective detection, not merely deployed tooling.

Evidence for auditors: Document your detection rules, alert thresholds, and the process for investigating and escalating alerts. A detection runbook — a table mapping event type to response action and escalation path — constitutes evidence of an effective effectiveness assessment framework under Art. 21(2)(f).

Workstream 3: Backup Architecture and Business Continuity (Art. 21(2)(c))

Business continuity under Article 21(2)(c) includes “backup management and disaster recovery.” Commission Implementing Regulation (EU) 2024/2690 (Point 4.2.1) requires entities to maintain backup copies with sufficient redundancy, and Point 4.2.2(c) requires storage at sufficient distance to escape any disaster affecting the primary site.

The IT infrastructure decision is not whether to have backups — it is whether your current backup architecture can demonstrate compliance with three specific requirements:

Recovery objectives: You must define and test RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for each critical system. The regulation requires a business impact analysis under Point 4.1.3 that justifies your RTO/RPO values against actual operational impact. “We have backups” is insufficient; you need documented, tested recovery targets per system.

Backup architecture: The 3-2-1 rule — three copies, two media types, one offsite — satisfies the geographic separation requirement. The critical addition for NIS2 is immutability: at least one copy must be protected against modification or deletion. Object storage with write-once retention policies achieves this for cloud backups; air-gapped tape for on-premises environments. Both protect against ransomware scenarios where attackers attempt to destroy backups before encrypting production systems.

Recovery testing: The regulation requires tested recovery, not just stored backups. Quarterly restoration tests of production systems — not just file-level verification — and at least annual disaster recovery exercises constitute evidence of a working business continuity capability. Log the test date, systems covered, RTO achieved, and any failures identified.

Backup systems themselves must be included in your patch management scope. An unpatched backup server is a vulnerability in your last line of defence.

Workstream 4: Network Segmentation (Art. 21(2)(a) and (g))

Article 21(2)(g) lists network segmentation among the basic cyber hygiene practices entities must implement. Recital 89 of Directive (EU) 2022/2555 explicitly names “network segmentation” alongside zero-trust principles and identity and access management as foundational cyber hygiene measures.

Network segmentation’s purpose is blast radius reduction. If an attacker compromises one system — through phishing, an unpatched vulnerability, or a supply chain intrusion — segmentation limits how far they can move laterally through your environment before detection and containment.

The IT infrastructure decisions map to three implementation layers:

Perimeter segmentation: Separate IT networks from operational technology (OT) networks, guest access zones, and external partner connections. This is the minimum required under any risk analysis that treats ransomware as a credible threat — which it is in every NIS2-covered sector.

Internal segmentation: Group systems by function and sensitivity — domain controllers isolated from workstations; database servers separated from web servers; development environments air-gapped from production. VLANs with ACL enforcement implement this at the network layer; micro-segmentation applies the same logic to east-west traffic within a data centre or cloud environment.

Document your segmentation rationale: NIS2 requires demonstrability. A network diagram showing segments, the business justification for each boundary, and periodic validation records that controls remain enforced constitutes the evidence an auditor needs under Art. 21(2)(a)’s requirement for documented security policies.

For legacy systems that cannot be segmented without operational disruption, compensating controls — increased monitoring frequency and accelerated patch cycles — are acceptable provided the risk acceptance decision is documented with a named approver and review date.

Workstream 5: Patch and Vulnerability Management (Art. 21(2)(e))

Article 21(2)(e) covers “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.” For most IT teams, this translates to patch management and vulnerability scanning.

Commission Implementing Regulation (EU) 2024/2690 (Point 6.2) requires documented patch management procedures aligned with change management, vulnerability management, and risk management processes. The regulation requires a documented process — not merely a practice that exists informally.

The IT infrastructure decisions are:

Scanning cadence: At minimum, weekly authenticated vulnerability scans of your complete asset inventory. Unauthenticated scans miss locally installed software and configuration weaknesses — authenticated scans are required for reliable coverage and audit-defensible results.

Remediation SLAs: Organisations maintaining sub-30-day remediation for critical vulnerabilities pass compliance audits at a significantly higher rate. A defensible SLA structure: critical vulnerabilities within 14 days; high within 30 days; medium within 90 days; low risk-accepted with documented justification and compensating controls.

Change control integration: Patch management must connect to your change management process. Emergency patches for actively exploited vulnerabilities need a documented expedited approval path. The NIS2 requirement to report significant incidents within 24 hours (early warning) and 72 hours (full report) makes unpatched known-exploited vulnerabilities a direct liability in any incident investigation.

Asset inventory as prerequisite: You cannot patch what you do not know exists. A complete, current asset inventory is both the prerequisite for effective patch management and an explicit requirement under Art. 21(2)(i)’s asset management obligation.

For secure development lifecycle requirements and vulnerability disclosure obligations, see our guide on NIS2 secure development requirements.

Workstream 6: Endpoint Detection (Art. 21(2)(b) and (f))

Endpoint detection and response (EDR) tools support the same two Article 21 obligations as centralised logging: incident handling (b) and effectiveness assessment (f). EDR operates at the endpoint level — detecting process behaviour, file system changes, and network connections that indicate compromise.

The mechanism that makes EDR necessary for NIS2 compliance: signature-based antivirus detects known malware by matching file hashes. EDR detects behaviour — which means it catches attacks using legitimate tools (living-off-the-land techniques), novel malware variants, and post-exploitation activity before significant damage occurs. Many of the incidents NIS2’s reporting timeline requires you to disclose would remain undetected without behavioural endpoint monitoring.

Coverage: Every managed endpoint must have an agent deployed. Coverage gaps — unmanaged devices, legacy systems, contractor laptops — represent unmonitored attack surface that undermines your incident handling capability and your ability to scope an incident accurately for the 72-hour report.

Integration with SIEM: EDR telemetry is one of the highest-value log sources for your centralised monitoring platform. Configure alert forwarding from your EDR to your log management system so endpoint-detected events are correlated with network and authentication events — cross-source correlation is where modern attacks are detected.

Response capability: Detection without a documented response procedure does not satisfy Art. 21(2)(b). Define who has authority to isolate an endpoint, what the escalation path is, and how forensic evidence is preserved for the NIS2 incident report.

Effort/Impact Matrix: Prioritising Your NIS2 IT Programme

The six workstreams above are not equally urgent or equally difficult. The matrix below scores each by implementation effort and risk reduction impact, using a typical IT team’s capacity as the baseline. Both dimensions are scored Low / Medium / High.

Workstream	Effort	Risk Reduction	Priority	Rationale
MFA for admin and remote access	Low	Very High	1	Stops the majority of credential-based initial access at low deployment cost and time
Centralised log management	Medium	High	2	Without logs you cannot detect, report, or evidence incidents — all three are Art. 21 requirements
Backup architecture (immutable, tested)	Medium	Very High	3	Ransomware recovery outcome changes fundamentally with immutable, tested backups
Patch management process	Medium	High	4	Unpatched known vulnerabilities are the second most common initial access vector; documented SLAs reduce audit exposure
Network segmentation	High	High	5	Higher effort but limits blast radius of any successful intrusion; essential for mature programmes
Endpoint detection (EDR)	Medium	High	6	Enables behavioural detection and feeds SIEM; required for effective incident handling evidence

The priority order reflects risk reduction per unit of implementation effort for a typical IT team. Your organisation’s specific risk profile — sector, existing controls, threat landscape — will shift these priorities. Document the reasoning behind your sequencing: NIS2 requires proportionate decisions, and a defensible prioritisation log is itself compliance evidence under Art. 21(2)(a)’s risk analysis requirement.

What Auditors Look For: Documentation Requirements per Workstream

NIS2 requires demonstrability, not perfection. An entity with an incomplete control set but thorough documentation of its risk-based prioritisation is in a stronger audit position than one with deployed tools and no evidence of managed processes.

For each workstream, the audit-critical documentation is:

Workstream	What auditors need to see
Identity & Access	Access control policy; MFA rollout scope and coverage; JML procedure with timestamps
Security monitoring	Log source inventory; detection runbook; alert-to-investigation workflow; retention policy
Backup	RTO/RPO definitions; restoration test results with dates; backup architecture diagram
Network segmentation	Network diagram with segment rationale; ACL evidence; periodic review records
Patch management	Vulnerability scanning schedule; remediation SLA policy; closed-ticket evidence per severity tier
Endpoint detection	Coverage report showing endpoint agent deployment rate; containment procedure; integration with incident response plan

Commission Implementing Regulation (EU) 2024/2690 requires entities to document their risk management approach and maintain evidence of implementation. “We have the tool deployed” is a starting point; “here is the evidence it is functioning and managed” is what satisfies Art. 21(1)’s requirement for effective, demonstrable measures.

NIS2 IT Manager Checklist

Use this as a programme status tracker. Each item maps to a specific Article 21(2) obligation.

Identity & Access

• MFA deployed for all remote access — Art. 21(2)(j)
• MFA deployed for all privileged accounts — Art. 21(2)(j)
• Access control policy documented, JML process in place — Art. 21(2)(i)
• Quarterly access rights review scheduled — Art. 21(2)(i)

Security Monitoring

• Log sources identified, centralised, and retained for a minimum of 12 months — Art. 21(2)(b)
• Alert thresholds configured and tested — Art. 21(2)(b)
• Detection runbook documented and owned by a named role — Art. 21(2)(f)

Backup & Recovery

• RTO/RPO defined for all critical systems, backed by a BIA — Art. 21(2)(c)
• Immutable backup copy confirmed — Art. 21(2)(c)
• Quarterly restoration test completed with documented results — Art. 21(2)(c)

Network & Endpoints

• Network segmentation diagram documented with business rationale — Art. 21(2)(g)
• EDR deployed to all managed endpoints — Art. 21(2)(b)
• Vulnerability scanning schedule active with authenticated scans — Art. 21(2)(e)
• Remediation SLAs defined, tracked, and reported — Art. 21(2)(e)

Frequently Asked Questions

Does NIS2 mandate specific products or vendors?

No. The directive is technology-neutral and specifies outcomes, not products. The choice of SIEM platform, MFA solution, backup tool, or EDR is yours — what matters is that the chosen solution demonstrably achieves the required security outcome and that the decision rationale is documented.

Which workstream should we start with?

MFA for privileged and remote access. It has the highest impact-to-effort ratio of any NIS2 control, addresses the most common initial access vector, and can be deployed in weeks rather than months. See the effort/impact matrix above for the full prioritisation rationale.

How do we handle legacy systems that cannot support MFA or modern segmentation?

Document them in your risk register, apply compensating controls — increased monitoring, network isolation where feasible — and record the risk acceptance decision with a named approver and review date. NIS2 requires proportionate decisions, and compensating controls with documented rationale satisfy the proportionality principle better than undocumented gaps.

What are the penalties for non-compliance?

Essential entities face fines up to €10 million or 2% of global annual turnover, whichever is higher. NIS2’s Article 20 also holds management bodies personally accountable for cybersecurity governance failures — making IT programme documentation a board-level concern, not just an IT concern. For a full overview of NIS2 obligations, see our NIS2 requirements guide.

Sources

• Directive (EU) 2022/2555 (NIS2), Article 21 — nis-2-directive.com
• Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex
• NIS2 Technical Implementation Guidance — ENISA, June 2025
• NIS2 from the Technical Side: Implementation Guide for IT Professionals — nflo.tech
• NIS2 Article 21 Mapped to Microsoft Sentinel — Falconer Security
• NIS2 Compliance: A Technical Guide — BrotCode
• A Practical NIS2 Guide for Network Managers and IT Directors — Nomios Germany

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.