NIS2 Automated Compliance: Which of the 10 Article 21 Security Measures You Can Actually Automate

Vendor marketing around NIS2 automation tends to converge on the same pitch: plug in a platform, watch a dashboard turn green across all ten Article 21(2) measures, and cut compliance effort by 80–90%. After checking those claims against the directive’s own text and against the practitioner guidance actually written for security teams, the picture is less binary. Some of the ten measures genuinely run on autopilot once the tooling is in place. Others only look automated — the software tracks an activity while the thing that actually matters (a judgment call, a sign-off, a human decision under pressure) still sits with a person. This article rates all ten measures individually, on the evidence, rather than selling a single automation number.

This matters because getting the split wrong has consequences. Article 20 makes an organisation’s management body responsible for approving its Article 21 risk-management measures and liable for infringements — a duty a software licence cannot absorb. Treating a compliance dashboard as a substitute for that oversight is the single most common automation mistake this article is written to prevent.

What “Automated NIS2 Compliance” Actually Means (and What It Doesn’t)

Article 21(2) requires essential and important entities to implement at least ten categories of cybersecurity risk-management measures, based on an all-hazards approach. Automation, in the way security and compliance tooling actually uses the word, means software continuously performing, monitoring, or evidencing a specific activity that supports one of those ten measures — scanning for vulnerabilities, enforcing multi-factor authentication, logging access changes. It does not mean software deciding, on the organisation’s behalf, that a compliance obligation has been satisfied.

That distinction splits the audience for this article into two groups with genuinely different jobs. A CISO or IT security manager is choosing which tools to deploy and how to configure them — scan frequency, alert thresholds, integration points. A compliance officer is doing something different: mapping what those tools produce back to a specific Article 21(2) point, and being ready to explain to an auditor why an automated control counts as evidence. Both roles need the measure-by-measure breakdown below; neither can do the other’s job with a dashboard alone.

The 10 Article 21(2) Measures, Rated for Automation Potential

The table below rates each of the ten measures on a three-tier scale — High, Medium, or Requires Human Judgment — rather than the binary “automatable / not automatable” split common in vendor content. A three-tier rating is more honest: most measures have an automatable component and a component that doesn’t automate, and collapsing that into a single yes/no answer is where oversold automation claims usually start.

Art. 21(2) Measure	Automation Potential	What Tooling Handles	What Still Needs a Human
(a) Risk analysis & security policies	Medium	Risk-scoring feeds from asset/vulnerability data, automated risk-register updates	Setting risk appetite, approving the policy (Art.20)
(b) Incident handling	Medium–High for detection	SIEM/SOAR alerting, automated triage, evidence collection, playbook containment for known patterns	Judging whether an incident is “significant” and deciding to notify
(c) Business continuity	Split by sub-activity	Backup verification, automated disaster-recovery failover testing	Activating the plan, crisis communication, business-impact calls
(d) Supply chain security	Medium–High	Continuous vendor breach/risk-score monitoring, contract-clause tracking	Criticality tiering, contract negotiation
(e) Acquisition, development & maintenance (incl. vulnerability handling)	High	Continuous vulnerability scanning, dependency/SBOM scanning, patch orchestration	Deciding which flaws justify emergency production patching
(f) Effectiveness assessment	Medium–High	Continuous control-monitoring dashboards, automated KPI/evidence tracking	Penetration testing and the audit judgment itself
(g) Cyber hygiene & training	Medium (tracking only)	Phishing simulations, patch/hygiene compliance scoring, training-assignment tracking	Whether the training changed behaviour
(h) Cryptography & encryption	High	Encryption-policy-as-code enforcement, automated key rotation, TLS/cipher config scanning	Choosing the cryptographic standard itself
(i) HR security, access control & asset management	High	Automated asset discovery, IAM-driven joiner-mover-leaver deprovisioning, access-review automation	HR background-check judgment, exception approvals
(j) MFA/continuous authentication & secure comms	High	MFA and conditional-access policy engines, automated enforcement	Deciding which “where appropriate” exceptions apply

Every label in the left column is drawn directly from Article 21(2) [1]; the automation-potential ratings and tooling categories are this article’s own analysis, built by cross-checking each measure against practitioner scanning and monitoring guidance [4][5] — not a claim about what the directive itself requires.

The Three Measures With the Highest Automation Payoff

Three measures reward automation investment fastest, because the underlying activity is inherently repetitive and machine-checkable rather than judgment-driven.

Vulnerability handling (e) tops the list. A vulnerability scanner doesn’t get tired of re-checking the same asset inventory every night, and authenticated scanning — where the scanner logs into a system rather than probing it from outside — catches misconfigurations that unauthenticated black-box scans commonly miss [4]. The mechanism is straightforward: known vulnerabilities are published against a common naming scheme (CVE identifiers), so matching an asset’s software inventory against that list is exactly the kind of large, repetitive lookup task automation was built for. What doesn’t automate is the triage call on a critical production system — patching a payment gateway at 2 p.m. on a Tuesday carries business risk a scanner can’t weigh.

Access control and asset management (i) is the most consistently under-rated measure in vendor content, which tends to file it as “human-required” because it touches HR processes. In practice, the highest-friction part of access control — removing a departed employee’s access across a dozen systems the same day they leave — is precisely what identity and access management (IAM) tooling automates via joiner-mover-leaver workflows. Asset discovery tools solve the parallel problem on the inventory side: you can’t secure what you don’t know exists, and automated discovery finds shadow IT that a manually maintained spreadsheet never will [4]. The genuinely human part is upstream of the automation — background-check decisions and access exception approvals.

Cryptography (h) automates cleanly because “is this connection using an approved cipher” is a binary, machine-checkable question. Policy-as-code lets an organisation encode its encryption standard once and have it enforced automatically across every new deployment, rather than relying on a developer remembering the policy document. Key rotation — traditionally a manual, easy-to-forget task — is one of the simpler things to schedule and automate outright.

Where Automation Claims Overreach — Three Corrections

Three measures get marketed as “continuously monitored” in ways that don’t survive scrutiny against what the underlying activity actually requires.

Risk analysis (a) is not the same activity as risk-score aggregation. A tool can continuously recalculate a numeric risk score from vulnerability counts and asset criticality, and that score is genuinely useful input. But the score is only as good as its inputs, and it cannot set the organisation’s risk appetite — how much residual risk is acceptable is a decision the directive assigns to the entity, and Article 20 puts the approval of that decision squarely with the management body [2].

Cyber hygiene and training (g) gets marked “automatable” because phishing-simulation platforms and patch-compliance dashboards produce clean, trackable metrics. Tracking who completed a training module, or who clicked a simulated phishing link, is genuinely automatable. Whether the training changed anyone’s actual behaviour under a real attempt is a different question entirely, and no completion-rate dashboard answers it.

Business continuity (c) is usually classified as entirely human-required, which undersells it. Backup verification and disaster-recovery failover testing are strong automation candidates — running a scheduled DR test and confirming the recovery point objective was met is exactly the kind of repeatable check a tool should own. What doesn’t automate is the decision to actually activate the continuity plan during a live incident, and the crisis communication that follows — both require weighing business impact and stakeholder fallout in ways a runbook can inform but not replace. Splitting this measure into its automatable and non-automatable halves, rather than rating it as one block, is the more accurate read of the requirement [1].

Automating the Notification Clock Without Automating the Judgment Call

Article 23 sets a three-stage reporting timeline once an entity becomes aware of a significant incident: an early warning within 24 hours, a fuller incident notification within 72 hours, and a final report within one month [3]. Automation genuinely compresses the mechanical part of that clock — a SIEM or SOAR platform can detect an anomaly, correlate it against known indicators, and pre-populate a notification draft with the technical detail (affected systems, timestamps, indicators of compromise) in minutes rather than hours.

What automation cannot do is make the determination that starts the clock in the first place: whether the incident meets Article 23’s significance threshold. That’s a judgment the directive assigns to the entity itself, not to a monitoring tool, and getting it wrong in either direction — under-reporting a genuine significant incident, or flooding a competent authority with notifications for routine events — carries its own consequences. Compliance officers weighing that call benefit from understanding the underlying significant-incident threshold in detail before automation enters the picture, not after.

Who Owns What: A Role-Responsibility Table for Automated Controls

Automating a measure doesn’t relocate the responsibility for it — it just changes what each role is responsible for doing.

Role	Owns (with automation)	Cannot delegate to a tool
CISO / IT Security Manager	Tool selection, scan cadence, SIEM/SOAR tuning, alert thresholds	Final call on emergency patching of critical production systems
Compliance Officer / Legal	Mapping automated evidence to specific Art.21(2) points, audit-trail readiness	Significant-incident determination under Article 23
Management Body / Board	Approving which measures are automated and how	Approval and oversight of the overall risk-management measures, and liability for infringements (Art.20(1)) [2]

That last row is the argument every automation vendor’s pitch tends to skip. Article 20(1) states plainly that management bodies must approve the cybersecurity risk-management measures an entity takes to comply with Article 21, oversee their implementation, and can be held liable for infringements of that Article [2]. A dashboard showing ten green checkmarks doesn’t discharge that duty — someone on the management body still has to have reviewed and approved what the dashboard is checking, and how. Organisations building out their governance structure around this obligation can work from a dedicated breakdown of Article 20 management liability.

Audit Defensibility: Making Automated Evidence Survive Scrutiny

Automated controls generate far more evidence than manual ones — which sounds like an advantage until an auditor asks who validates that the automation itself is working correctly. A defensible automated-evidence trail typically includes four things: retained logs covering the full audit period (not just the current dashboard snapshot), a version history for any policy-as-code configuration showing when rules changed and who approved the change, a record of who tunes the detection logic and how often false positives are reviewed, and a documented human sign-off step for any automated action that closes a finding rather than just flagging it. Teams building this out alongside their broader audit preparation work should treat the fourth point as non-negotiable — an auditor who finds an automated system closing its own findings with no human review will treat that as a control gap, not a strength.

On implementation effort: as a general guideline, not a benchmarked statistic, the measures rated High automation potential above — MFA enforcement (j), asset discovery (i), vulnerability scanning (e), encryption policy-as-code (h) — tend to be the fastest wins, since mature commercial tooling exists and the activity is narrow enough to deploy in weeks rather than months. The Medium-rated measures (incident-response tooling, continuous control monitoring) usually need a full vendor-selection and integration cycle. The measures this article split into automatable and human halves — business continuity, risk analysis, training — take longest, because the automatable slice is often a small part of a larger process that still needs redesigning around it. Treat these as planning heuristics, not a promised timeline; actual effort depends heavily on existing tooling maturity and headcount.

Frequently Asked Questions

Can AI or automation make an organisation NIS2 compliant on its own?

No. Tooling can continuously perform and evidence several of the ten Article 21(2) measures, but Article 20 keeps approval, oversight, and liability with the management body — a responsibility no software licence transfers [2].

Which Article 21 measure should we automate first?

Start with the measures rated High automation potential above — vulnerability scanning, asset discovery, and MFA enforcement are the most mature, fastest-to-deploy categories, and they also tend to generate the audit evidence assessors ask for earliest.

Does automating a measure reduce management liability under Article 20?

No. Article 20(1) ties liability to approval and oversight of the risk-management measures, not to the manual-versus-automated method of executing them [2]. Automation can make oversight easier to perform; it cannot substitute for it.

Is the ENISA/CIR technical guidance on security tooling mandatory for every entity?

No. The Commission Implementing Regulation’s technical annex, and ENISA’s related non-binding implementation guidance, formally bind only specific digital-infrastructure entity types — DNS and cloud providers, CDNs, MSPs/MSSPs, marketplaces and similar [6]. Other entities can use that guidance as a useful reference for tooling choices, but it isn’t a binding checklist for them.

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.

Key Takeaways

Automation earns its keep on repetitive, machine-checkable activity — scanning, enforcement, evidence logging — and struggles wherever a measure hinges on judgment: risk appetite, incident significance, crisis activation, or whether training actually worked. The practical sequence is to automate the high-payoff measures first, correct for the three most commonly oversold claims before they reach a board presentation, and keep the Article 20 approval-and-oversight loop firmly with the management body regardless of how much of the underlying work a tool now performs. As enforcement matures across member states, auditors are likely to scrutinise automated evidence chains more closely, not less — building the human sign-off and validation habits in now costs far less than retrofitting them under audit pressure later.

Sources

1. “Article 21: Cybersecurity risk-management measures,” NIS 2 Directive
2. “Article 20: Governance,” NIS 2 Directive
3. “Article 23: Reporting obligations,” NIS 2 Directive
4. “Continuous Monitoring,” Tenable NIS 2 Directive Cyber Exposure Study
5. “NIS2 Article 21 Risk Management Measures Explained: All 10 Controls,” GloCert International
6. “Technical Implementation Guidance on cybersecurity risk-management measures,” v1.0, ENISA, June 2025