Directive 2022/2555 Article 21 cybersecurity risk-management obligations mapped to SWT3 witness procedures. Management body accountability, supply chain evidence, incident reporting timelines, and EU AI Act convergence.
Who this is for: CISOs and security architects at essential and important entities under NIS 2, management body members responsible for approving cybersecurity measures (Article 20), supply chain compliance teams at global technology vendors serving EU customers, and auditors evaluating NIS 2 risk-management implementation.
Enforcement active. NIS 2 transposition deadline was October 17, 2024. 22 of 27 EU member states have adopted transposing legislation. Competent authorities are issuing formal notices and remediation orders. Penalties up to EUR 10 million or 2% of global turnover for essential entities. Management body members face personal liability under Article 20, including temporary bans on exercising managerial functions.
The NIS 2 Directive (Directive 2022/2555) requires essential and important entities across 18 sectors to implement appropriate and proportionate technical, operational and organisational measures to manage risks to their network and information system security. It replaces the original NIS Directive (2016/1148) with significantly broader scope, stronger enforcement, and direct management accountability.
Article 21(2) specifies 10 minimum measures that all in-scope entities must implement, based on an all-hazards approach:
| Point | Measure | Scope |
|---|---|---|
| (a) | Risk analysis and information system security policies | Governance foundation for all other measures |
| (b) | Incident handling | Detection, classification, response, and recovery |
| (c) | Business continuity and crisis management | Backup, disaster recovery, and crisis procedures |
| (d) | Supply chain security | Direct supplier and service provider security relationships |
| (e) | Security in acquisition, development, and maintenance | Vulnerability handling and disclosure for network/information systems |
| (f) | Effectiveness assessment | Policies and procedures to evaluate the effectiveness of risk-management measures |
| (g) | Basic cyber hygiene and training | Organizational cybersecurity practices and competence |
| (h) | Cryptography and encryption | Policies on the use of cryptographic controls where appropriate |
| (i) | Human resources, access control, and asset management | Personnel security, access policies, and asset inventory |
| (j) | Multi-factor authentication and secured communications | MFA, continuous authentication, secured voice/video/text/emergency comms |
These measures must account for the state of the art, relevant European and international standards, cost of implementation, degree of risk exposure, entity size, and the likelihood and severity of incidents.
Energy (electricity, oil, gas, hydrogen, district heating), transport (air, rail, water, road), banking, financial market infrastructures, health (hospitals, laboratories, pharmaceutical manufacturing), drinking water, waste water, digital infrastructure (IXPs, DNS, TLD registries, cloud, data centres, CDNs, trust services, telecoms), ICT service management (managed service providers, managed security service providers), public administration (central government), and space.
Postal and courier services, waste management, chemicals (manufacturing, production, distribution), food (production, processing, distribution), manufacturing (medical devices, electronics, machinery, vehicles), digital providers (online marketplaces, search engines, social networks), and research organisations.
| Category | Size Threshold | Supervision | Maximum Penalty |
|---|---|---|---|
| Essential | Large (250+ employees or EUR 50M+ turnover) in Annex I sectors | Proactive, ex ante (audits, inspections, on-site checks) | EUR 10M or 2% global turnover |
| Important | Medium or large in Annex I or II sectors | Reactive, ex post (triggered by evidence of non-compliance) | EUR 7M or 1.4% global turnover |
Non-EU entities that provide services within the EU (cloud computing, data centre, CDN, managed services, digital platforms) must designate a representative in an EU member state (Article 26). If no representative is designated, any member state where the entity provides services may take enforcement action. This mechanism extends NIS 2's reach to global technology providers serving European customers.
Supply chain cascade: Even if a company is not directly in scope, NIS 2 Article 21(2)(d) requires essential entities to secure their supply chain relationships. A US-based AI vendor whose models or infrastructure are used by an essential entity in the EU will face contractual demands for verifiable security evidence. SWT3 anchors provide that evidence without requiring the supplier to adopt the customer's internal compliance framework.
NIS 2 introduces direct personal accountability for management body members -- a structural shift from prior EU cybersecurity law.
Accountability cannot be delegated. A board may delegate operational execution to a CISO or security team, but the legal accountability for approving and overseeing cybersecurity measures remains with the management body. For essential entities, competent authorities can impose temporary bans on natural persons exercising managerial functions (Article 32(5)(b)).
SWT3 does not implement cybersecurity measures. It provides timestamped, independently verifiable evidence that measures were approved, implemented, and are actively operating. When a competent authority asks a management body member to demonstrate oversight, the anchor chain answers three questions simultaneously: what controls are active (procedure ID), when they last executed (anchor timestamp), and what they found (factor values).
An AI-GOV.1 anchor proves that a cybersecurity policy was attested on a specific date with a specific reviewer. An AI-RISK.1 anchor proves that a risk assessment was conducted. The management body member can point to the anchor chain as evidence that they fulfilled their Article 20 oversight obligation -- without needing to understand the technical details of each measure.
Filter the witness ledger for AI-GOV.1 (policy attestation) anchors. Factor C identifies the approving authority -- this should be a management body member or their formally delegated representative. The anchor timestamp establishes when approval occurred. Cross-reference with AI-RISK.1 anchors to prove that the approved measures are based on a current risk assessment.
Each Article 21(2) measure maps to SWT3 witness procedures that generate cryptographically anchored evidence of implementation. SWT3 does not perform these measures -- it independently witnesses that they occurred.
| Art. 21(2) | Measure | SWT3 Procedure(s) | What It Witnesses | Evidence (Factors) |
|---|---|---|---|---|
| (a) | Risk analysis policies | AI-RISK.1AI-GOV.1 | Risk assessment execution Policy attestation | Risk category, severity, mitigation status Policy version, compliance status, review date |
| (b) | Incident handling | AI-INCIDENT.1AI-IR.1 | Incident detection and classification Incident response execution | Incident type, severity, detection method Response plan, containment status, timeline |
| (c) | Business continuity | AI-SAFE.1 | Safe state verification and recovery readiness | Risk scenario, mitigation status, safe state definition |
| (d) | Supply chain security | AI-CHAIN.1AI-HW.1AI-TRUST.1 | Software supply chain attestation Hardware infrastructure attestation Vendor trust verification | Supplier ID, attestation status, hash Silicon vendor, device hash, driver version Trust level, verification method, credential |
| (e) | Acquisition / development security | AI-MDL.1AI-SBOM.1AI-MDL.2 | Artifact integrity verification Software bill of materials Version tracking | Identifier, integrity hash, version Component count, SBOM hash, format Previous version, current version, change summary |
| (f) | Effectiveness assessment | AI-DRIFT.1AI-PERF.1AI-REDTEAM.1 | Drift detection Performance monitoring Adversarial testing | Metric, current value, baseline Metric, threshold, measurement Test scope, findings count, severity distribution |
| (g) | Cyber hygiene and training | AI-HITL.1AI-GOV.1 | Competence attestation Policy compliance | Reviewer identity, role, authorization Policy version, compliance status, review date |
| (h) | Cryptography | Inherent in SWT3 protocol: SHA-256 fingerprints, HMAC-SHA256 signing, ML-DSA-65 post-quantum signatures, domain-separated Merkle trees | The anchor chain itself demonstrates cryptographic evidence practices | |
| (i) | HR security and access control | AI-ACC.1AI-ID.1 | Access control verification Identity attestation | Access method, auth requirement, scope Agent/user identity, system, timestamp |
| (j) | MFA and secured comms | AI-TRUST.1AI-TRUST.2 | Trust verification Credential presentation | Trust level, verification method Credential type, issuer, validity |
NIS 2 establishes a three-stage incident reporting obligation for significant incidents -- those causing severe operational disruption, financial loss, or considerable damage to other persons.
| Stage | Deadline | Content Required | SWT3 Evidence |
|---|---|---|---|
| Early Warning | 24 hours after awareness | Whether the incident is suspected to be caused by unlawful or malicious acts; whether it could have cross-border impact | AI-INCIDENT.1 anchor timestamp establishes the moment of awareness. Factor B (severity) determines whether the incident qualifies as "significant." |
| Incident Notification | 72 hours after awareness | Update to early warning with initial assessment of severity, impact, and indicators of compromise | AI-IR.1 anchor records the response plan, containment status, and timeline. The delta between AI-INCIDENT.1 and AI-IR.1 timestamps proves the notification window was met. |
| Final Report | 1 month after notification | Root cause analysis (or most probable root cause), mitigation measures applied and ongoing, cross-border impact | AI-AUDIT.1 anchor captures the final report's integrity hash and retention period. AI-AUDIT.2 provides RFC 3161 external timestamp from an independent TSA. |
If the incident is still ongoing at the one-month mark, a progress report is due at one month, then a final report within one month of the incident's resolution.
NIS 2 requires: Essential and important entities must report significant incidents to their CSIRT or competent authority within 24 hours (early warning), 72 hours (incident notification), and 1 month (final report).
How SWT3 addresses it: The witness_incident() call records the moment the entity became aware of the incident, the severity classification, and the detection method. The witness_incident_response() call records the response plan activated, containment status, and timeline. These anchors create an immutable record of the entity's incident timeline that a competent authority can independently verify without accessing internal systems.
The AI-INCIDENT.1 anchor timestamp is the legally relevant "awareness" moment that starts the 24-hour clock. The AI-IR.1 anchor timestamp must fall within 72 hours. If the authority disputes the claimed awareness time, the SWT3 fingerprint -- computed from tenant, procedure, factors, and timestamp -- serves as a tamper-evident record that cannot be retroactively altered. Cross-reference with Merkle rollup proofs for independent temporal verification.
Article 21(2)(d) requires entities to address supply chain security, including security-related aspects of relationships with direct suppliers and service providers. Article 21(3) adds that entities must consider:
This creates a cascade effect: essential entities contractually require their suppliers to provide verifiable security evidence. Suppliers who cannot produce this evidence risk losing contracts with EU-regulated customers.
The SWT3 Kubernetes DaemonSet (v0.5.8) queries physical compute nodes and mints AI-HW.1 anchors capturing the silicon vendor, device identifier hash, and driver version. This creates a continuous attestation record of the hardware substrate. For NIS 2, this proves that the computing infrastructure has been cataloged and that its composition is tracked over time. Any unauthorized hardware change produces a different hash, creating a detectable event.
AI-CHAIN.1 anchors attest to the supply chain status of software dependencies. AI-SBOM.1 anchors record the software bill of materials (component count, SBOM hash, format). Together, they provide evidence that the entity has assessed the composition and security posture of its software supply chain.
The Trust Mesh protocol enables mutual verification between entities in a supply chain. AI-TRUST.1 anchors record that a trust verification occurred between two parties. AI-TRUST.2 anchors record credential presentation. This creates a cryptographic record of supply chain trust relationships that satisfies Article 21(3)'s requirement to assess supplier cybersecurity practices.
Scope note: NIS 2 Article 21(2)(d) applies to direct suppliers and service providers only, not the full supply chain depth. However, the contractual pressure cascades: if an essential entity requires SWT3 attestation from its direct suppliers, those suppliers may in turn require it from theirs.
An AI system used in a critical sector (energy, health, transport, financial services) may simultaneously be a high-risk AI system under the EU AI Act and a critical asset under NIS 2. There is no official harmonization guidance between the two frameworks, but significant overlap exists. A single SWT3 deployment generates anchors that satisfy both.
| Requirement | NIS 2 Article | EU AI Act Article | SWT3 Procedure |
|---|---|---|---|
| Risk management | Art. 21(2)(a) | Art. 9 | AI-RISK.1 |
| Incident handling | Art. 21(2)(b), Art. 23 | Art. 62 (serious incidents) | AI-INCIDENT.1, AI-IR.1 |
| Logging and monitoring | Art. 21(2)(f) | Art. 12 (record-keeping) | AI-LOG.1, AI-AUDIT.1 |
| Supply chain security | Art. 21(2)(d) | Art. 15(3) (robustness, third-party) | AI-CHAIN.1, AI-HW.1 |
| Vulnerability management | Art. 21(2)(e) | Art. 15(1) (accuracy, robustness) | AI-MDL.1, AI-SBOM.1 |
| Human oversight | Art. 21(2)(g,i) | Art. 14 | AI-HITL.1 |
| Cryptographic controls | Art. 21(2)(h) | Art. 15(4) (cybersecurity) | Inherent (anchor chain) |
| Transparency | Art. 21(2)(a) (policy disclosure) | Art. 13 | AI-EXPL.1, AI-TRANS.1 |
No double-jeopardy protection. Unlike the NIS 2/GDPR overlap (Article 35, which prevents double fines for the same conduct), there is no equivalent provision between NIS 2 and the EU AI Act. An entity could theoretically face penalties under both frameworks for the same AI system failure. A unified evidence chain reduces this risk by demonstrating compliance with both simultaneously.
| Competent Authority Question | Where to Look |
|---|---|
| Has the management body approved cybersecurity measures? | AI-GOV.1 anchors. Factor C identifies the approving authority (must be management body member or formal delegate). Anchor timestamp proves when approval occurred. |
| Is a risk assessment current? | AI-RISK.1 + AI-IMPACT.1 anchors. Factor A identifies risk categories. Factor B shows severity. Most recent anchor timestamp must be within the entity's stated assessment cycle. |
| Can you prove you met the 24-hour early warning? | AI-INCIDENT.1 anchor timestamp = awareness time. The CSIRT notification must have occurred within 24 hours of this timestamp. Factor B (severity) determines whether the incident qualifies as "significant." |
| How is supply chain security verified? | AI-CHAIN.1 + AI-HW.1 + AI-TRUST.1 anchors. AI-CHAIN.1 covers software supply chain. AI-HW.1 covers hardware. AI-TRUST.1 proves mutual vendor verification. Factor A identifies the supplier. |
| Are vulnerability management practices active? | AI-MDL.1 (integrity verification) + AI-SBOM.1 (SBOM attestation) + AI-MDL.2 (version tracking) anchors at regular intervals. AI-REDTEAM.1 anchors prove adversarial testing occurred. |
| Is MFA deployed? | AI-TRUST.1 + AI-TRUST.2 anchors prove authentication mechanisms are active. Factor A identifies the authentication method. Factor B shows verification result. |
| What cryptographic measures protect your systems? | The SWT3 anchor chain itself: SHA-256 fingerprints, HMAC-SHA256 signing, ML-DSA-65 post-quantum signatures, domain-separated Merkle trees. AI-AUDIT.2 provides RFC 3161 external timestamps from independent TSAs. |
| Can you prove cybersecurity training compliance? | AI-HITL.1 anchors. Factor A identifies the reviewer. Factor B shows competence verification result. AI-GOV.1 anchors with management body members in Factor C prove Article 20(2) training compliance. |
| How long are records retained? | AI-AUDIT.1 Factor C shows retention period. SWT3 Enclave tier retains 7 years, Sovereign tier retains indefinitely. Merkle rollup proofs at /api/v1/merkle/proof provide independent temporal verification. |
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup