Frameworks · Laws and regulations

qodiqa and NIS2

qodiqa checks each AI request before the call and keeps tamper-evident, offline-verifiable evidence. This page shows where that evidence supports NIS2, and where it does not.

Law
European Union
National measures apply from 18 Oct 2024.
Verified 2026-11-01

Read the official text Back to all frameworks

Overview

What it is

Issuer: European Union
Type: Law
Status: Transposition due 17 Oct 2024; national measures apply from 18 Oct 2024
Official text: eur-lex.europa.eu

Directive (EU) 2022/2555, the NIS2 Directive. NIS2 is the EU’s directive on a high common level of cybersecurity. It obliges essential and important entities to take appropriate and proportionate risk-management measures (Art. 21) and to report significant incidents in stages (Art. 23), with management bodies approving and overseeing the measures (Art. 20).

Who it applies to. Essential and important entities in sectors such as energy, transport, health, digital infrastructure and public administration, as transposed into each Member State’s law.

Where it meets qodiqa

The parts of NIS2 where the evidence matters.

Robustness and security

Concrete security controls: signed artifacts, key separation, fail-closed checks and access control.

Record-keeping and logging

A tamper-evident record for incident handling.

Accountability

Evidence an assessor can verify offline.

Risk management

Measurable runtime output for the risk process.

Traceability

A request hash ties each logged event to one request.

Human oversight

A kill switch and revocation let operators stop AI use quickly during an incident.

Mapping

What qodiqa provides, and what stays with you.

Requirement or control	What qodiqa provides	What stays with you
`Art. 21(2)(a)` Policies on risk analysis and information system security.	Written, versioned tenant policies with a governed change path and recorded outcomes.	Your risk analysis and your security policy.
`Art. 21(2)(b)` Incident handling.	A tamper-evident record of what was blocked and why, alert rules and runbooks.	The incident-handling process and team.
`Art. 21(2)(e)` Security in acquisition, development and maintenance, including vulnerability handling and disclosure.	A public security policy with a private reporting route, open source code and supply-chain documentation.	The security of what you buy and build, and your own vulnerability handling.
`Art. 21(2)(f)` Policies and procedures to assess the effectiveness of cybersecurity measures.	Test vectors, a verifier written separately, and signed evidence that an assessor can check offline.	The assessment programme.
`Art. 21(2)(h)` Policies and procedures regarding the use of cryptography and encryption.	Ed25519 only with no algorithm negotiation, separate key domains, encrypted keys at rest, and documented rotation and revocation.	Your wider cryptography policy and key custody.
`Art. 21(2)(i)–(j)` Access control policies, multi-factor authentication.	Per-actor keys, role-based operator access, optional OIDC, SAML and TOTP for operators.	Access control and authentication for everything outside the gateway.
`Art. 23(1) and 23(4)` Reporting of significant incidents in stages: early warning within 24 hours, an incident notification within 72 hours, and a final report.	Audit records and alerts that help establish what happened and when.	Deciding that an incident is significant, and notifying your CSIRT or authority on time.

The specification’s Regulatory Alignment Matrix does not cover NIS2. This page maps the gateway documentation only.

How it fits

What NIS2 asks, and what qodiqa produces.

Cryptography policy (Art. 21(2)(h)) is supported by Ed25519 and key separation (Rotation and revocation).
Incident handling (Art. 21(2)(b)) is supported by Tamper-evident record (Alerts and runbooks).
Access control (Art. 21(2)(i)) is supported by Per-actor keys and RBAC (Optional OIDC, SAML, TOTP).

Evidence

Evidence you can hand to an auditor.

Five artifacts, each checkable on its own

Consent artifact Signed with Ed25519, bound to one request, single use.
INTENT entry The audit entry written before the provider call.
Receipt A signed decision record that checks offline.
Audit export Hash-chained entries with a Merkle inclusion proof.
Anchor proof A signed checkpoint pinned outside the gateway.

Verify offline, from a clone of qodiqa-verify

node bin/verify.bundle.external.js \
  --keys examples/front-half/keys.json \
  --transparency-keys examples/front-half/transparency-keys.json \
  examples/front-half/bundle-with-proof.json

The example files ship with the repository and are signed with throwaway keys. The command exits 0 and prints "valid": true. For your own evidence, take keys and anchors from a source other than the gateway that wrote it.

Scope and limits

Technical evidence, not a compliance outcome

qodiqa produces verifiable technical evidence that supports parts of NIS2. It is not a compliance certification, it is not legal advice, and no regulator or standards body has endorsed it. Whether your use meets NIS2 is a decision for you and your advisers.

What qodiqa does not address:

National transposition laws and thresholds, which differ by country.
Supply-chain risk, business continuity and crisis management.
Reporting significant incidents to the authority within the set deadlines.
Only requests that pass through the gateway are checked, and a receipt proves a decision was recorded, not that it was correct.

Sources

Article, clause and control references were read in the official texts listed first. The remaining links are qodiqa’s own documents. Checked on 2026-11-01; rules change, so read the current text.

Directive (EU) 2022/2555 (NIS2), EUR-Lex accessed 2026-11-01
qodiqa-gateway: key management accessed 2026-11-01
qodiqa-gateway: role-based access model accessed 2026-11-01
qodiqa-gateway: supply-chain security accessed 2026-11-01

Next steps

See the evidence for yourself.

Read the spec section Run a simulation Quickstart