NIS2 Compliant on Infra You Run: Article 21 vs 2024/2690

Most NIS2 guides stop at the ten Article 21(2) headings. The work is which text applies, what inspectors can demand, and whether the clock has ever run.

Two tests share one name

Directive (EU) 2022/2555 — NIS2 — is a directive. Member States had to adopt and publish transposition measures by 17 October 2024 and apply them from 18 October 2024. Most entities meet it as national law, and Article 21 states outcomes, not specifications.

Article 21(5) required the Commission, by 17 October 2024, to adopt implementing acts with technical and methodological requirements for DNS, TLD, cloud, data centre, CDN, managed and managed security service providers, online marketplaces, search engines, social networks and trust services. Implementing Regulation (EU) 2024/2690 is that act. It calls these the relevant entities, sets out requirements for Article 21(2) points (a) to (j) in its Annex, and is binding in its entirety and directly applicable in all Member States.

The sorting question has three answers:

• Relevant entity under Article 21(5). The 2024/2690 Annex is the test, point by point, plus whatever national law adds.
• Other essential or important entity. The transposed Article 21 is the test; the Annex is a reference model unless national law adopts it.
• Out of scope. Article 2(1) limits the Directive by sector annex and size, but Article 2(2)(a) applies it regardless of size to providers of public electronic communications networks or publicly available electronic communications services, trust service providers, TLD name registries and DNS service providers, and Article 2(4) does the same for domain name registration services. Article 2(2)(b) to (f) and Article 2(3) (critical entities under Directive (EU) 2022/2557) are further regardless-of-size gates, several turning on national or CER identification.

The comparison of NIS2, DORA and the EU AI Act places NIS2 among neighbouring regimes.

Click to zoom

What Article 21(2) actually lists — and what Article 20 puts on the board

Article 21(2) requires measures based on an all-hazards approach that include at least: (a) risk analysis and information system security policies; (b) incident handling; (c) business continuity, such as backup management and disaster recovery, and crisis management; (d) supply chain security; (e) security in acquisition, development and maintenance, including vulnerability handling and disclosure; (f) procedures to assess the effectiveness of the measures; (g) basic cyber hygiene and training; (h) cryptography and, where appropriate, encryption; (i) human resources security, access control and asset management; and (j) multi-factor or continuous authentication, secured voice, video and text communications, and secured emergency communication systems within the entity, where appropriate.

Article 21(1) makes them proportionate to the state of the art, cost, exposure, size, and incident likelihood and severity. Under Article 21(4), an entity that finds it does not comply must take corrective measures without undue delay.

Article 20 puts the measures on the board: management bodies must approve the Article 21 measures, oversee their implementation, can be held liable for infringements, and must follow training.

Article 34 sets floors on the maximum fine. For infringing Article 21 or 23, essential entities face a maximum of at least EUR 10 million or 2% of the preceding year's total worldwide annual turnover of the undertaking to which the entity belongs, whichever is higher; important entities, at least EUR 7 million or 1.4%.

Where 2024/2690 stops being outcome-based

The Directive names incident handling; the 2024/2690 Annex says what goes in the log. Point 3.2.3 lists what logs shall include where appropriate — among them all privileged access to systems and applications and the activities performed by administrative accounts (e), access or changes to critical configuration and backup files (f), and the activation, stopping and pausing of the various logs (k). The pipeline must record its own silence.

Point 3.2.5 asks for logs kept for a predefined period, a backup of them for that period, and protection from unauthorised access or changes. Point 3.2.6 adds that, to the extent feasible, all systems have synchronised time sources; that the entity keeps a list of every asset being logged; that monitoring and logging systems are redundant; and that their availability is monitored independently of the systems they monitor. Replication is not the 3.2.5 backup, and a backup is not 3.2.6 redundancy; a single Loki with free-running clocks misses two 3.2.6 points.

The rest of the Annex follows suit:

• 4.2 — Backup. 4.2.2(c): copies off the system's network and far enough to escape a main-site disaster. 4.2.6: regular, documented recovery tests, with corrective action where needed.
• 6.3.2(b) — Secure configuration. Tools that enforce secure configurations for new systems and over each system's lifetime — an admission controller, not a wiki page.
• 6.6 — Security patches. 6.6.1: patches applied within a reasonable time after release, tested before production, from trusted sources, integrity-checked. 6.6.2 derogates from 6.6.1(a) only: an entity may decline a patch whose disadvantages outweigh its cybersecurity benefits, documenting and substantiating why; under 6.6.1(d) an unapplied patch still needs additional measures and an accepted residual risk.
• 11.3 — Administrative accounts. strong authentication such as MFA for privileged accounts; dedicated admin-only accounts that connect only to administration systems; 11.3.3 adds documented periodic reviews.

Evidence a self-hosted estate has to produce itself

Start with the API server audit log. Secrets, ConfigMaps, and pods/exec, pods/attach and pods/portforward stay at Metadata: who, verb and resource, no bodies, so values never land in the log. RBAC writes are RequestResponse, with both bodies; Velero backup, restore and schedule writes are Request, request body only. The API audit log cannot see backup copies in object storage; log 3.2.3(f) access on the store itself. A self-operated Kubernetes audit-log SIEM pipeline covers shipping and retention.

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - RequestReceived
rules:
  # Annex 3.2.3(f) - access or changes to critical configuration.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  # Annex 3.2.3(e) - activities performed by administrative accounts.
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
  # Annex 3.2.3(e) - privileged access to systems and applications.
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach", "pods/portforward"]
  # Who created or changed Velero backup, restore and schedule objects.
  # API audit only: backup-file access is logged on the backup store.
  - level: Request
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "velero.io"
        resources: ["backups", "restores", "schedules"]
  - level: None
    nonResourceURLs: ["/healthz*", "/livez*", "/readyz*"]
  - level: Metadata

Point 3.2.3(k) needs a log event whenever a log is activated, stopped or paused; an alert writes none, so have each collector emit and retain those events. The rule below covers 3.2.6 instead — logging availability watched independently of the systems it watches, so run this Prometheus outside the logging stack, with clocks checked through node_exporter's timex collector. It is not a 3.2.4 control: Annex 3.2.4 is a separate duty to review logs for unusual trends, set alarm thresholds, and respond when they are exceeded. It loads only if it matches your Prometheus ruleSelector; job and namespace are examples. Treat clock alerts as a signal, not proof — chrony does not always surface its state through these kernel values — and keep per-node chronyc tracking output as time-sync evidence.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: nis2-logging-evidence
  namespace: monitoring
spec:
  groups:
    - name: nis2-logging
      rules:
        # Pipeline availability (3.2.6), not a 3.2.3(k) log event.
        - alert: LogShipperDown
          expr: up{job="fluent-bit"} == 0
          for: 5m
          labels:
            severity: critical
            annex_point: "3.2.6"
        - alert: NodeClockNotSynchronised
          expr: node_timex_sync_status == 0
          for: 10m
          labels:
            severity: warning
            annex_point: "3.2.6"
        - alert: NodeClockOffsetHigh
          expr: abs(node_timex_offset_seconds) > 0.05
          for: 10m
          labels:
            severity: warning
            annex_point: "3.2.6"

The drill restores one namespace of a Velero backup into a scratch namespace, hashes a canary object and appends a JSON line — pass or fail, since a recorded failure plus corrective action is evidence too (a missing canary is a fail). Prerequisites: Velero's Restore objects live in namespace velero; the backup must contain a ConfigMap restore-canary with key payload in the source namespace; and /etc/restore-drill/<namespace>.sha256 must hold the hex SHA-256 of that value exactly as stored, with no trailing newline. The backup side is in the Velero and etcd disaster-recovery guide.

#!/usr/bin/env bash
set -euo pipefail

USAGE="usage: restore-drill.sh <velero-backup-name> <source-namespace>"
BACKUP="${1:?$USAGE}"
SOURCE_NS="${2:?$USAGE}"
SCRATCH_NS="drill-$(date -u +%Y%m%d%H%M%S)"
RESTORE="drill-$(date -u +%s)"
EXPECTED_SHA="$(awk 'NR == 1 { print $1 }' "/etc/restore-drill/${SOURCE_NS}.sha256")"
EVIDENCE_LOG="/var/lib/evidence/restore-drills.jsonl"
mkdir -p "$(dirname "$EVIDENCE_LOG")"
started="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

velero restore create "$RESTORE" \
  --from-backup "$BACKUP" \
  --include-namespaces "$SOURCE_NS" \
  --namespace-mappings "${SOURCE_NS}:${SCRATCH_NS}" \
  --wait || true

phase="$(kubectl get restore "$RESTORE" -n velero -o jsonpath='{.status.phase}' || echo Unknown)"
actual_sha=""
if payload="$(kubectl get configmap restore-canary -n "$SCRATCH_NS" \
  -o jsonpath='{.data.payload}' 2>/dev/null)"; then
  actual_sha="$(printf '%s' "$payload" | sha256sum | cut -d' ' -f1)"
fi

result="fail"
if [[ "$phase" == "Completed" && "$actual_sha" == "$EXPECTED_SHA" ]]; then
  result="pass"
fi

jq -nc \
  --arg started "$started" \
  --arg finished "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --arg backup "$BACKUP" --arg restore "$RESTORE" \
  --arg phase "$phase" --arg result "$result" \
  --arg expected "$EXPECTED_SHA" --arg actual "$actual_sha" \
  '{annex_point: "4.2.6", started: $started, finished: $finished,
    backup: $backup, restore: $restore, phase: $phase,
    sha256_expected: $expected, sha256_actual: $actual, result: $result}' \
  >> "$EVIDENCE_LOG"

kubectl delete namespace "$SCRATCH_NS" --ignore-not-found --wait=false
[[ "$result" == "pass" ]]

The rest map to artefacts a self-run estate already generates:

• 6.3.2(b) secure configuration — admission policies in Git plus enforcement reports, as Kyverno policy-as-code produces.
• 6.6 security patches — a decision log: CVE, date available, test, source and integrity check, date applied; or the 6.6.2 reasoning, additional measures and residual-risk acceptance.
• 6.4.3 emergency change — when an emergency bypasses change management, a record of the result and the reason.
• 11.3 admin accounts — an IdP export of MFA on admin groups plus dated review sign-offs.
• 5.2 supplier register — a current, version-controlled registry of direct suppliers and service providers, contact points and what each provides.
• 2.3 independent review — reviewers with audit competence, outside the line of authority of the area reviewed (or, where size prevents that, the alternative impartiality measure), and proof the result reached the management bodies.

ENISA's Technical Implementation Guidance (v1.0, June 2025) gives evidence examples per 2024/2690 requirement — for backups, records of regular restore tests and checksum or hashing settings. It is non-binding, its examples indicative and non-exhaustive, and implementing them does not assume compliance.

The reporting clock nobody has rehearsed

Article 23(4) counts from becoming aware of the significant incident, not from first detection. Early warning to the CSIRT or authority within 24 hours. Incident notification within 72 hours of awareness — not 48 hours after the early warning — with an initial assessment of severity and impact and, where available, indicators of compromise. Intermediate reports on request. Final report no later than one month after the notification: detailed description, likely threat type or root cause, mitigation, cross-border impact. If the incident is ongoing, a progress report goes in instead, with the final report within one month of handling it.

For trust service providers, Article 23(4) replaces point (b) only: significant trust-service incidents are notified within 24 hours of awareness, and the early warning and final report still apply.

The hard part is significance. Under the Directive, an incident is significant if it caused or can cause severe operational disruption or financial loss, or considerable material or non-material damage to others. For relevant entities, 2024/2690 Article 3(1) is a one-or-more list — any one suffices:

• (a) the incident has caused or is capable of causing direct financial loss for the relevant entity above EUR 500,000 or 5% of the relevant entity's own total annual turnover in the preceding financial year, whichever is lower — not the undertaking-wide turnover behind the Article 34 fines;
• (b), (c), (d) the incident has caused or is capable of causing, respectively, the exfiltration of trade secrets, the death of a natural person, or considerable damage to a natural person's health;
• (e) a successful, suspectedly malicious and unauthorised access to network and information systems capable of causing severe operational disruption;
• (f) the Article 4 recurrence rule — incidents individually not significant that occurred at least twice within 6 months, share the same apparent root cause, and collectively meet criterion (a) — direct financial loss caused or capable of being caused above the same threshold;
• (g) any criterion in the provider-type Articles 5 to 14.

Complete unavailability for more than 30 minutes is one criterion among others for DNS (Article 5), cloud (Article 7), CDN (Article 9) and managed and managed security services (Article 10). For TLD resolution (Article 6) and data centres (Article 8), any complete unavailability counts. Marketplaces, search and social (Articles 11–13) use complete unavailability for more than 5% or 1 million Union users, whichever is smaller, with no duration. Trust services (Article 14) use more than 20 minutes.

Each of those is only point (a). DNS and TLD (Articles 5(b) and 6(b)) add an average response time to DNS requests of more than 10 seconds for more than one hour. Cloud, CDN and managed services (Articles 7(b), 9(b) and 10(b)) add limited availability for over 5% or 1 million Union users, whichever is smaller, lasting over one hour; data centres (Article 8(b)) add limited availability for more than one hour. Trust services add unavailability to users or relying parties for over one hour on a calendar-week basis (Article 14(b)), and limited availability for over 1% or 200,000 Union users or relying parties, whichever is smaller (Article 14(c)). Under Articles 7(c) to 13(c), a suspectedly malicious compromise of the integrity, confidentiality or authenticity of data related to providing the service is significant with no user-count or duration floor; under Articles 7(d) and 9(d) to 13(d), that same compromise without the malicious-action requirement counts once it affects more than 5% or 1 million Union users, whichever is smaller. DNS (Article 5(c)) counts a compromise of data related to the provision of the authoritative domain name resolution service, except where the data of fewer than 1,000 domain names, amounting to no more than 1% of the domain names the provider manages, is incorrect through misconfiguration; TLD (Article 6(c)) counts a compromise of technical-operation data with no numeric floor. For data centres, compromised physical access to a data centre the provider operates is significant on its own, with no user or duration floor (Article 8(d)). Trust services have a different test: compromised physical access to a restricted area where the trust service's network and information systems are located and access is limited to trusted personnel of the provider, or a compromise of the protection of that physical access, with no user or duration floor (Article 14(d)). Article 14(e) counts a trust-service data compromise affecting more than 0.1% or 100 Union users or relying parties, whichever is smaller. Marketplaces, search and social (Articles 11(b) to 13(b)) also count limited availability above 5% or 1 million Union users, with no duration. For Articles 7 and 9 to 14, not 8, Article 3(3) counts contracted customers plus persons associated with business customers as users. Under 2024/2690 Article 3(2), scheduled interruptions of service and the planned consequences of scheduled maintenance are not significant incidents.

Click to zoom

At awareness this record must hold the awareness timestamp, the significance decision, and early_warning_due and notification_due, both computed only from became_aware_at. Submission timestamps fill in as the clock runs; final_report_due is set only once the notification is submitted: one month after notification_submitted_at.

{
  "incident_id": "INC-2026-0142",
  "entity_type": "cloud_computing_service_provider",
  "detected_at": "2026-11-03T02:14:09Z",
  "became_aware_at": "2026-11-03T03:40:00Z",
  "significance": {
    "instrument": "Implementing Regulation (EU) 2024/2690",
    "criteria_met": ["Art 7(a): cloud service completely unavailable > 30 min"],
    "criteria_assessed_not_met": ["Art 3(1)(a)", "Art 3(1)(b)", "Art 3(1)(e)"],
    "decided_at": "2026-11-03T04:05:00Z",
    "decided_by": "incident-commander"
  },
  "early_warning_due": "2026-11-04T03:40:00Z",
  "early_warning_submitted_at": "2026-11-03T05:10:00Z",
  "notification_due": "2026-11-06T03:40:00Z",
  "notification_submitted_at": "2026-11-05T16:20:00Z",
  "final_report_due": "2026-12-05T16:20:00Z"
}

Run it as a tabletop with real timestamps from real logs; it shows whether three systems' logs fit one timeline. India's CERT-In six-hour rule makes the same demand on a tighter clock.

Failure modes inspectors find first

• Logs that stopped silently. A shipper crash-looped all weekend with no stop event and no alarm — a 3.2.3(k) and 3.2.6 gap.
• Backups never restored. A green backup job is not a 4.2.6 recovery test.
• Reviews whose impartiality cannot be shown. The platform lead reviewed the platform; results never reached the management body.
• Proactive audits with no evidence trail. Essential entities face on-site inspections, random checks, regular, targeted and ad hoc security audits; important entities are supervised ex post, on evidence or indication of non-compliance.

Exit ramps: evidence that survives a tool change

Evidence keyed to a tool dies with the tool. Key it to the control — an annex_point field on every record, open formats (JSON Lines, YAML in Git), storage outside the evidenced system — and the SIEM, backup tool or IdP can change without touching history.

ENISA maps each 2024/2690 requirement to standards including ISO/IEC 27001:2022, so an ISMS with Annex A controls you operate can reuse evidence where the mapping supports it — though certification is not NIS2 compliance. A self-hosted DORA programme can share the supplier register and restore records.

The long game: the law is still moving

NIS2 is not settled. In July 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify full transposition. That is a July snapshot; laws may have landed since.

Evidence keyed to Article 21 points and Annex numbers absorbs that churn: a new national rule changes where a report goes, not what logs, drills and registers prove. Infrastructure you own, evidence you own, in formats still readable after the next amendments.