Control map · Regulation (EU) 2022/2554

DORA

2 of 6 DORA controls code can evidence, with v1.4.0, plus 1 supporting

Code evidence for protection and prevention and for detection, strengthened by change-management evidence in v1.4.0.

Live2
Coming in v1.4.00
Supporting1
Planned4
Your organisation20

2 with code evidence todayPartial evidence, checked on every pull request.
1 with supporting evidenceToevan records related evidence; the duty stays organisational.
20 stay with your organisationListed in full below, so nothing is implied.

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) and Article 10 (detection) on every pull request. From v1.4.0, change-management evidence for every merged change strengthens Article 9. 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.

Live2

Code evidence today, sealed on every pull request. Always partial: the control also asks for things outside code. Code evidence today: rules in the DORA blueprint check part of this on every pull request.

Art.9
Protection and prevention
Ch.II ICT Risk Management
Strengthened in v1.4.0: change management evidence per merged change.
Art.10
Detection
Ch.II ICT Risk Management

Supporting1

Toevan records related evidence, today or in v1.4.0, but the duty is organisational, so it never counts as covered.

Art.28
General principles
Ch.V Managing of ICT third-party risk
Supporting evidence today: a rule records evidence related to this duty. The duty itself is organisational policy.

Planned4

Can be evidenced from code or GitHub. The rule or mapping is not built yet.

Art.7
ICT systems, protocols and tools
Ch.II ICT Risk Management
Art.8
Identification
Ch.II ICT Risk Management
Art.12
Backup policies and procedures, restoration and recovery procedures and methods
Ch.II ICT Risk Management
Art.25
Testing of ICT tools and systems
Ch.IV Digital operational resilience testing

Your organisation20

Policy, people, physical security, contracts, regulatory procedure, operations or external audit. Your organisation evidences these.

Show all 20 controls

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 (from v1.4.0)
Every merge into a protected branch and every direct push 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 for v1.4.1.
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 its signature and its place in the chain offline.
$ toevan audit verify --path evidence-clone --pub-key toevan.pub

How each fact was obtained

Every fact in a record and a report carries one of six labels, so your auditor knows how far to rely on it.

Recomputed: Toevan computed it from the code or git history itself.; Re-perform it from the same inputs and get the same result.
Reported + sealed: GitHub reported it; Toevan captured it at the event and signed it.; Rely on it as far as you rely on GitHub. Any later change is detectable.
Declared + sealed: The organisation declared it, such as a change to what is checked; Toevan signed the declaration and its history.; See who declared what, when, and every later change.
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.; Treat it as Toevan’s statement, and ask the organisation for the approval behind it.
Consumed: Taken from another system’s signed record, such as build provenance, and linked by commit or digest. Planned.; Check the original record independently.
Not captured: No reliable source was available. Toevan does not infer it.; Obtain it from the organisation by other means.

See it in a report

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