What a signed receipt can and cannot evidence under DORA, NIS2 and the AI Act

2026-10-02. Legal review pending — this is the author's reading of the texts, not legal advice.

1. The obligations

DORA, Article 9(4)(e) — Regulation (EU) 2022/2554 (https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng): financial entities need a documented ICT change-management process under which changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner. The process must be approved by the appropriate lines of management and include specific protocols. "Recorded" is one of six separate requirements.

Article 17 of Delegated Regulation (EU) 2024/1774 (https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng) sets the minimum elements of those procedures, for changes to software, hardware, firmware components, systems or security parameters:

• a verification of whether the ICT security requirements have been met;
• independence between the functions that approve changes and those that request and implement them;
• roles and responsibilities so that changes are specified and planned, an adequate transition is designed, changes are tested and finalised in a controlled manner, and quality assurance is effective;
• documenting and communicating the change's purpose, scope, timeline and expected outcomes;
• fall-back procedures and responsibilities, including aborting or recovering from unsuccessful changes;
• procedures, protocols and tools for emergency changes with adequate safeguards;
• documenting, re-evaluating, assessing and approving emergency changes after implementation, including workarounds and patches;
• the potential impact on existing ICT security measures, and whether additional measures are needed.

Article 12 of the same Regulation requires change-management events to be logged, the logs protected against tampering, deletion and unauthorised access, and system clocks synchronised to a documented reliable time source.

AI Act, Articles 12 and 26 — Regulation (EU) 2024/1689 (https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng): Article 12(1) requires high-risk AI systems to technically allow automatic event logging over their lifetime. Article 12(2) says logging must enable the recording of events relevant to identifying risk situations or substantial modifications, post-market monitoring, and monitoring operation under Article 26(5). Article 12(3) adds minimum log content for remote biometric identification systems (Annex III, point 1(a)).

Article 26 assigns deployer duties: human oversight by natural persons with the necessary competence, training, authority and support (26(2)); monitoring operation in line with the instructions for use and, where relevant, informing the provider (26(5)); and keeping system-generated logs under the deployer's control for a period appropriate to the intended purpose, at least six months unless Union or national law provides otherwise (26(6)).

These concern high-risk systems. As amended by Regulation (EU) 2026/1744 (https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng), they apply from 2 December 2027 to systems that are high-risk under Article 6(2) and Annex III, and from 2 August 2028 to those under Article 6(1) and Annex I. Check the classification and any exception before treating them as applicable.

NIS2, Article 21(2)(e) — Directive (EU) 2022/2555 (https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng): security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure. The English text of the Directive does not use the term "change management".

Implementing Regulation (EU) 2024/2690 (https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng), Annex point 6.4, does — but only for the entity types it lists: DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers. Not NIS2 entities generally. Point 6.4.2 covers releases, modifications, emergency changes and configuration changes: documented and, based on the risk assessment, tested and assessed before implementation. Under 6.4.3, if an emergency prevents the regular procedure, the entity documents the outcome and why the procedure could not be followed. That is not DORA's after-the-fact assessment and approval.

2. How practice answers it — in layers

The organisation's own change process carries the weight: independent approval, test records, fall-back and an emergency path, usually spread across an ITSM ticket, code review and repository configuration.

A machine gate blocks a merge only on a path where branch protection or a ruleset requires the check and bypass is closed. That is evidence about the configured path. It does not show that no other path could carry an unauthorised change, nor that a change was implemented or verified.

A signed record bound to a hash of the evaluated change set can support a record of what was authorised, if the recipient matches the hash to the change set it holds. Offline verification checks the signature against a pinned key snapshot. It cannot establish current key trust, revocation, or that the issuer's clock was accurate.

For the AI Act, the system's logging capability and the deployer's oversight, monitoring and retention are separate duties. An external change gate does neither.

3. CodeRifts: what it does

On a boundary that requires it, a contract change does not cross without a signed grant for that exact change set. CodeRifts reads the diff of the contracts a pull request touches — OpenAPI, GraphQL, protobuf, AsyncAPI and MCP tool manifests, together as one change set — classifies what breaks (a removed field, a parameter that became required, a narrowed enum, a tool whose description gained an instruction), and answers with a decision and a machine instruction. On GitHub, a required check refuses the merge until a receipt for that diff verifies on the runner; the receipt names the operation it was granted for (merge, deploy, publish or a tool call) and expires. Analysis is free and needs no account; the check is on the GitHub Marketplace (https://github.com/marketplace/actions/coderifts-contract-gate).

What it signs, and what it does not

What it signs. A receipt is a signed token: a short JSON body and a raw Ed25519 signature over its fields (format v4, specified in the open verifier's RECEIPT_FORMAT.md). Its central field, fp, is the change-set fingerprint. It is a SHA-256 over each artifact's type, id and the hashes of its exact before and after text, together with the operation, environment, repository, branch, pull request and policy profile the caller declared. So the signature binds the diff and the declared operation, and anyone who holds the same change set can recompute it. The token also carries the signing key id (kid), the issue time and a hard expiry (expires_at). The decision itself — decision, execution_action, the operation field and the rest of the decision envelope, including its artifact_digest — is not in the token. It is bound by bh, the hash of the canonical envelope without its receipt, which the open verifier re-checks when it is handed the envelope. A token verified on its own therefore shows which change set and declared operation were evaluated, and until when; what was decided is shown only together with the envelope it came with. An execution grant, when one is requested, is a separate signed token. It binds the receipt by hash and adds the executor, the target, the hash of the content to be written, a state and nonce check, and a single-use window of minutes.

The open verifier checks it offline against a pinned key snapshot — no account, no call to us. A decision is an authorisation answer for the submitted request, not an observation that anything was merged, deployed or published.

It may support the "recorded" part of DORA Article 9(4)(e). Under NIS2 it is at most supporting evidence for Article 21(2)(e); for an entity under Implementing Regulation 2024/2690 it might sit next to the evidence for point 6.4. The fields do not become stronger evidence because a text is less detailed.

It does not:

• name the human approver. A GitHub review names a login, not the account holder's role or whether the process was followed. Distinct logins do not prove distinct people.
• test, assess, implement or verify anything.
• record a fall-back plan, an emergency change, or the independence of the approving function.
• replace a high-risk AI system's own logs, its classification, human oversight or the deployer's retention.
• establish whether a signing key is currently trusted. A recently compromised key still verifies against a snapshot that does not yet show its revocation. Where current authorisation cannot be established, currently_authorized is null, not true. The hosted verify_receipt route, given a token alone, answers currently_authorized null. The open offline verifier prints VERIFIED_CURRENT and has no currently_authorized field.

Measured today: the open verifier (https://coderifts.com/verify/) and a required check on our own demo repository that blocks on both contexts — a configuration fact we re-measure before calling it enforced. Shipped, but not installed by anyone else: a Kubernetes admission verifier and an agent tool guard. No external repository requires the check yet.

4. How to read it

In a DORA change file, a receipt is one line: what was authorised, for which hash, until when and under which key. Next to it belong the test record, an approver in the independent function, the fall-back plan, the emergency path if one was used, and — where the merge path is actually closed — the required-check configuration. The receipt does not stand in for any of those.

The short page: https://coderifts.com/docs/evidence/record-keeping/