Control map · Regulation (EU) 2022/2554

DORA

Code evidence for protection and prevention, and process evidence from deployments and releases for Article 9.

Book an audit pilot See a sample report

DORA · Regulation (EU) 2022/25546 articles in scope · as mapped in v1.4.1

Code 1
Process Art.9
Planned 5

Code evidence

1articles checked on every pull request

Live (process)

Art.9from deployments and releases

Planned

5can be evidenced from code or GitHub; not built yet

Organisation-level articles

Policies, people, vendors, physical security and the like, listed below.Toevan gives supporting evidence for 1 of these.Managed by your organisation’s workflows

DORA has applied to EU financial entities since 17 January 2025. It asks for an ICT risk-management framework you can show working, including documented change management.

The DORA blueprint gives code evidence for Article 9 (protection and prevention) on every pull request; detection under Article 10 is planned. Article 9 also has process evidence from deployments and releases: a successful deployment of a commit to production, an approved deployment review with its separation of duties computed, and the tag of a release and the commit it names. Governance, incident reporting, resilience testing and third-party risk stay with your process.

On the roadmap: the RTS on ICT risk management (Delegated Regulation (EU) 2024/1774), with Article 17 ICT change management from process evidence and Article 16 from code evidence. Its catalog edition still has to be added.

Toevan gives evidence for controls; it never certifies them or claims a framework is covered. Whether the evidence is sufficient is your auditor’s judgement.

Code evidence1

Sealed on every pull request. Always partial: the control also asks for things outside code. Rules in the DORA blueprint check part of each on every pull request.

Art.9Protection and preventionCh.II ICT Risk ManagementProcess evidence from deployments and releases: A successful deployment of a commit to production, by GitHub’s flag or the organisation’s designation. An approved deployment review with its separation of duties computed. The tag of a release and the commit it names.

Supporting1

Toevan records related evidence, but the duty is organisational, so it never counts as covered.

Art.28General principlesCh.V Managing of ICT third-party riskSupporting evidence: a rule records evidence related to this duty. The duty itself is organisational policy.

Planned5

Can be evidenced from code or GitHub. No rule checks these yet; each is planned, and none counts as evidence today.

Art.7ICT systems, protocols and toolsCh.II ICT Risk Management
Art.8IdentificationCh.II ICT Risk Management
Art.10DetectionCh.II ICT Risk Management
Art.12Backup policies and procedures, restoration and recovery procedures and methodsCh.II ICT Risk Management
Art.25Testing of ICT tools and systemsCh.IV Digital operational resilience testing

Organisation-level articles

Organisation-level controls (policies, people, vendors, physical security and the like) stay with your organisation’s own process; Toevan does not cover them.

Show the list

Ch.II ICT Risk Management

Art.5Governance and organisationorganisational policy

Art.6ICT risk management frameworkorganisational policy

Art.11Response and recoveryan operational process

Art.13Learning and evolvingan operational process

Art.14Communicationan operational process

Art.15Further harmonisation of ICT risk management tools, methods, processes and policiesregulatory procedure

Art.16Simplified ICT risk management frameworkorganisational policy

Ch.III ICT-related incident management, classification and reporting

Art.17ICT-related incident management processan operational process

Art.18Classification of ICT-related incidents and cyber threatsan operational process

Art.19Reporting of major ICT-related incidents and voluntary notification of significant cyber threatsregulatory procedure

Art.20Harmonisation of reporting content and templatesregulatory procedure

Art.21Centralisation of reporting of major ICT-related incidentsregulatory procedure

Art.22Supervisory feedbackregulatory procedure

Art.23Operational or security payment-related incidents concerning credit institutions, payment institutions, account information service providers, and electronic money institutionsregulatory procedure

Ch.IV Digital operational resilience testing

Art.24General requirements for the performance of digital operational resilience testingorganisational policy

Art.26Advanced testing of ICT tools, systems and processes based on TLPTan external assessment

Art.27Requirements for testers for the carrying out of TLPTan external assessment

Ch.V Managing of ICT third-party risk

Art.29Preliminary assessment of ICT concentration risk at entity levelorganisational policy

Art.30Key contractual provisionscontracts and vendors

Ch.VI Information-sharing arrangements

Art.45Information-sharing arrangements on cyber threat information and intelligenceregulatory procedure

Using it in an audit

Take the population from the change records
Every pull request merged into the default branch and every push to a protected branch that no merged pull request explains, in the period, captured from GitHub as it happened, is a sealed record you can export for sampling. You can re-perform the default branch’s population from git history; designated production branches are planned.
Read the code evidence for the period
Each pull request carries sealed code results against the blueprint’s rules, pinned to the commit and the rule-set version in force.
Test a sample
For each sampled record, check its results, then verify it offline against the published key with openssl and the shell: get the evidence, confirm the key, check the record. To replay the whole chain, Toevan provides the toevan command on request; it is not yet public.
The three steps, with the exact commands

How each fact was obtained6 labels

Recomputed: Toevan computed it from the code or git history itself.
Reported + sealed: GitHub reported it; Toevan captured it at the event and signed it.
Declared + sealed: The organisation declared it, such as a change to what is checked; Toevan signed the declaration and its history.
Toevan record, not sealed: Held in Toevan’s database but not sealed in the ledger, such as a waiver today. Nothing protects it by a signature.
Consumed: Taken from GitHub’s deployment and release records and linked by commit or digest.
Not captured: No reliable source was available. Toevan does not infer it.

The sample change evidence report shows the evidence as your auditor receives it, with every fact labelled.Open the sample report

Test the mapping on a real audit.

Bring one repository and an upcoming audit. We’ll set up the blueprint and walk your auditor through verification.

Book an audit pilot See a sample report

One repository, one framework
Evidence from the first pull request
Verifiable without a Toevan account