How V-PROOF Helps with DORA Compliance in the Financial Sector

V-PROOF JOURNAL

Regulatory AI Governance Technology vproofprotocol.com

Regulations · Financial Sector

DORA and the Financial Sector: What the Regulation Requires and How V-PROOF Evidence

Regulation (EU) 2022/2554 has been fully in effect since January 2025. More than 22,000 European financial institutions must demonstrate verifiable IT controls. The question is no longer whether to comply, but how to prove compliance to the regulator.

Published: July 2026

Regulatory coverage: DORA · Articles 9, 10, 11, 12, 13, 17

Category: Regulation

DORA · EU 2022/2554 European supplier Financial Sector

Key Points

• DORA is mandatory as of January 17, 2025, for all financial institutions regulated in the EU, with no additional grace period.
• Articles 9, 10, 11, and 17 require verifiable technical records of ICT controls, logs of anomaly detection, and incident classification—not mere statements.
• The EBA, ESMA, and EIOPA have published the Regulatory Technical Standards (RTS) and Guidelines that specify what documentation they will require during inspections.
• V-PROOF generates verifiable cryptographic evidence for DORA controls on an asset-by-asset basis, with a timestamp that the supervisor can verify.
• The convergence of DORA and the EU AI Act creates a dual obligation for entities that use AI in financial decision-making: V-PROOF helps document both through a single integration.
• As a provider with its registered office in Spain, V-PROOF is not subject to the CLOUD Act, which is an essential safeguard for entities whose data is subject to European sovereignty.

The Regulatory Framework

What is DORA, and why is it different from any previous regulation?

The Digital Operational Resilience Act is not just another voluntary cybersecurity framework. It is a directly applicable European regulation that establishes legally binding requirements for digital operational resilience in the financial sector and requires technical evidence, not just documented policies.

Published in the Official Journal of the EU on December 27, 2022 (Regulation (EU) 2022/2554), DORA entered into force on January 16, 2023, and has been fully applicable since January 17, 2025. There is no extension. National supervisory authorities, under the coordination of the EBA, ESMA, and EIOPA, began inspections in the first half of 2025.

The regulation affects a very broad range of entities: banks, savings banks, credit unions, investment firms, alternative investment funds and UCITS, pension fund managers, insurance and reinsurance companies, crowdfunding platforms, crypto-asset issuers under MiCA, and third-party ICT providers that offer critical services to the financial sector. In total, more than 22,000 entities in the EU.

The Structural Difference of DORA

Previous cybersecurity frameworks (ISO 27001, ENS, and even NIS) were based on self-declaration of controls. DORA stipulates that supervisors will verify this operational resilience through on-site and remote inspections. The difference is not philosophical; it is legal: noncompliance can result in fines of up to 2% of annual global revenue, and for responsible individuals, up to 1 million euros.

The regulation is structured around five pillars: ICT risk management (Arts. 5–16), reporting of serious incidents (Arts. 17–23), digital operational resilience testing (Arts. 24–27), ICT third-party risk management (Arts. 28–44), and the exchange of information on cyber threats (Arts. 45–46). V-PROOF directly addresses the first three.

Implementation Status

The DORA Timeline: Where We Stand Now

December 27, 2022

Publication in the Official Journal of the European Union

Regulation (EU) 2022/2554 and Directive (EU) 2022/2556 (amending DORA) are published in the Official Journal of the European Union.

January 16, 2023

Effective Date

The regulation takes effect. The 24-month period during which entities must prepare for its implementation begins.

2023–2024

Publication of RTS and Guidelines

The EBA, ESMA, and EIOPA publish the Regulatory Technical Standards (RTS) and Guidelines that specify the detailed technical requirements. Batch 1 of the RTS is approved in January 2024; Batch 2 in July 2024.

January 17, 2025, TODAY

Full and mandatory implementation

DORA is fully applicable to all entities within its scope. National supervisory authorities have begun reviews and inspections. There is no additional grace period.

2025–2026

Inspections and Initial Penalties

National regulators (the Bank of Spain, the CNMV, and the DGSFP in Spain) are conducting compliance reviews. The first significant penalties are expected in the second half of 2026 for institutions that lack verifiable technical documentation.

2025–2027

TLPT, Advanced Penetration Testing

Significant entities must complete their first cycle of Threat-Led Penetration Testing (TLPT) under the TIBER-EU framework. Evidence of the tests and their results must be recorded and retained.

Regulatory Obligations

Articles that require technical evidence, and what specific records they request

DORA does not require statements of intent. The Regulation and the resulting RTS specify the types of technical records that supervisory authorities will request during an inspection. These are the articles directly covered by the V-PROOF architecture:

From the ICT incident to the review by the supervisorWhat record is left of each step

DORA Cycle with V-PROOF

1. Art. 10RecordingThe event is recorded with the date and fingerprint
2. Art. 17ClassificationThe decision on the severity—who made it?
3. Art. 11Response and RecoveryEvidence, Participants, and Outcome sealed
4. Art. 13LearningChanges to critical systems, commit by commit
5. Art. 9Verification by the SupervisorVerifiable without access to your systems

Beyond the scope of V-PROOF: advanced penetration testing (TLPT, Art. 26), which requires certified testers.

Article 9, ICT Risk Management

Protection and Prevention: Controls with Verifiable Traceability

Organizations must have protection and prevention mechanisms in place based on documented security policies, with technical records that verify that these controls exist and function—not merely that they are outlined in a policy document.

V-PROOF Evidence V-Seal Core generates a verifiable cryptographic record of the controls implemented: what configuration was set, who approved it, when, and in what status. The SHA-256 hash anchored to Base L2 can be verified by any auditor without access to internal systems.

Article 10, Detection

Mechanisms for detecting anomalous activity with verifiable records

Organizations must implement robust mechanisms to detect anomalous activity, including network performance issues and ICT incidents. The RTS specify that these logs must be complete and tamper-proof—exactly what the blockchain architecture at V-PROOF provides.

V-PROOF Evidence Every security event or anomaly recorded through V-PROOF is assigned a timestamp on the blockchain. The integrity of the log is cryptographically verifiable: any subsequent tampering with the record results in a detectable divergence from hash.

Art. 11, Response and Recovery

Evidence of ICT Incident Response Procedures

Entities must document their response and recovery capabilities, including evidence that procedures have been tested. Supervisors may request records of the business continuity and recovery exercises that have been conducted.

Evidence V-PROOF V-PROOF generates cryptographically secured records sealed for each recovery test performed: date, participants, systems tested, result, and verifiable human approval. The traceability of the exercises is beyond the scope of internal manipulation.

Art. 13, Learning and Development

Code Traceability and Critical ICT Systems

Organizations must learn from past incidents and evolve their IT systems in a documented manner. This includes maintaining a change history for critical systems—a requirement that the Git Integration module of V-PROOF natively supports for internally developed software.

Evidence V-PROOF Git Integration cryptographically seals every commit in the lifecycle of critical financial software. The history of changes to trading, risk management, or compliance systems is recorded with the developer’s identity, the exact date, and verifiable integrity.

Art. 17, Classification of Serious Incidents

Article 17 and the related Technical Regulatory Standards (RTS) establish specific criteria for classifying ICT incidents as serious (impact on customers, duration, geographic scope, impact on reputation). Entities must maintain a classified incident log with evidence of the classification applied. V-PROOF enables seal the classification of each incident using timestamp blockchain, creating an immutable record that documents when the incident was identified, how it was classified, and who made the decision.

Coverage Matrix

V-PROOF Coverage V-PROOF DORA

DORA Article	Obligation	Coverage	V-PROOF Module
ICT Risk Management, Articles 5–16
Art. 9Protection and Prevention	Verifiable records of implemented ICT controls	✓ Complete	V-Seal
Art. 10 Detection	Verifiable records of anomalous activities and ICT incidents	✓ Complete	V-Seal
Art.11 Response and Recovery	Evidence of response procedures and recovery exercises	✓ Complete	V-Seal
Art.12 Backup Policy	Verifying the Integrity of Backups	◐ Midterm	V-Seal
Art. 13Learning and Development	Traceability of Changes in Critical ICT Systems	✓ Complete	Git Integration
Incident Reporting, Articles 17–23
Art.17 Classification of Incidents	Verifiable Record of the Classification of Serious ICT Incidents	✓ Complete	V-Seal
Articles 19–20:Notification to Supervisors	Initial, interim, and final notifications to EBA/ESMA/EIOPA	Customer Responsibility	Internal Regulatory Process
Resilience Tests, Articles 24–27
Articles24–25: Basic Tests	Evidence of periodic resilience testing (vulnerability assessments, penetration tests)	◐ Midterm	V-Seal
Art.26 TLPT	Certified Threat-Led Penetration Testing	External Certified Executors	Outside the scope of V-PROOF
DORA + EU AI Act Convergence, For organizations that use AI in financial decision-making
DORA, Art. 9+ EU AI Act. 14	Verifiable Human Oversight in High-Risk Financial AI Systems	✓ Complete	AI Orchestrator V-Proof
DORA, Art. 13+; EU AI Act. 12	Logging of AI Model Events in Critical Financial Environments	✓ Complete	AI Orchestrator

◐ Partial = V-PROOF the evidence of the process; the operational action (performing the backup, contracting the penetration test) is the responsibility of the entity.

Dual Obligation

The Convergence of DORA and the EU AI Act: The Risk No One Is Accounting For

There is a regulatory overlap that very few financial institutions have correctly identified: those that use AI systems in financial decision-making are subject to both DORA and the EU AI Act. And neither regulation accepts compliance with the other as sufficient.

Credit scoring models, fraud detection systems, algorithmic trading algorithms, and risk assessment systems that use machine learning are high-risk AI systems under Annex III of EU AI Act. This means that, in addition to the DORA requirements for operational resilience, these entities must comply with Articles 9, 12, 13, 14, and 16 of EU AI Act: AI system risk management, event logging, traceability of training data, verifiable human oversight, and technical documentation.

One integration, two regulatory frameworks

V-PROOF helps document both obligations using a single infrastructure. The AI Orchestrator module generates cryptographic evidence of the entire lifecycle of ML models—from training data to production decisions covered by the integration—meeting the traceability requirements of DORA (Art. 13) and the event logging requirements of the EU AI Act (Art. 12) through the same integration. The AI V-Proof module records human intervention in critical decisions covered by the workflow, simultaneously supporting Article 14 of the EU AI Act and DORA’s control requirements.

The EBA has already published specific guidelines on the use of AI models in the financial sector that reinforce this convergence. Institutions that lack verifiable technical evidence of how their AI models operate—not just internal policies, but cryptographically verifiable records—face a dual regulatory risk: penalties under the Data Protection Regulation (DORA) for a lack of IT traceability and penalties under the General Data Protection Regulation ( EU AI Act ) for a lack of verifiable AI governance.

Data Sovereignty · DORA Relevance

Why the ICT Provider's Registered Office Matters Under DORA

DORA introduces a new concept in financial regulation: the risk of concentration among third-party ICT providers. Articles 28–44 require financial institutions to assess the legal risks associated with their ICT providers, including the risk that third-party jurisdictions may gain access to the data managed by those providers.

Here, the CLOUD Act (18 U.S.C. § 2713) creates a specific regulatory friction: any U.S.-based ICT provider can be compelled by a U.S. court order to hand over European customer data, regardless of where that data is stored. This includes large U.S.-based GRC and AI Governance platform providers operating in the European market.

V-PROOF It has its registered office in Spain. It cannot be subject to any U.S. court order. Its European financial clients have the legal assurance that their DORA compliance records remain under EU sovereignty—not only technically, but also legally.

Full protection against the CLOUD Act also depends on the infrastructure on which the customer deploys V-PROOF. Full sovereignty is achieved by combining V-PROOF with cloud infrastructure based in the European Union (OVHcloud, IONOS, Deutsche Telekom, etc.).

Strategic Analysis

V-PROOF DORA

Strengths, Regulatory Use Cases, and Scope Limitations

F

Strengths · What V-PROOF to DORA

• Verifiable records of implemented IT controls that a supervisor can verify without access to internal systems Art. 9, Protection and Prevention
• Event logs using blockchain- timestamp : integrity is cryptographically verifiable; any tampering results in a detectable divergence from hash Art. 10, Detection
• sealed evidence of response and recovery tests: date, participants, systems, and results with verifiable human approval Art. 11, Response and Recovery
• Commit-by-commit code traceability for critical financial systems; an unalterable history for IT evolution audits Art. 13, Git Integration
• A provider with its registered office in Spain and two deployment options: on the organization’s own infrastructure, where the records never leave the premises; or in a hosted mode, where they are stored within the EU Articles 28–44 · ICT Provider Risk
• Dual coverage of DORA and the EU AI Act in a single integration for institutions using AI models in financial decision-making Regulatory Convergence 2025–2027

↗

Where It Applies · Regulatory Use Cases

• Banks, savings banks, and credit unions subject to full DORA compliance starting in January 2025 Credit institutions, Articles 5–16
• Investment firms and fund managers (UCITS, AIFs) that use cloud-based ICT providers or AI models ESMA scope, Art. 2.1
• Fintechs and neobanks with automated decision-making systems (scoring, fraud detection, KYC) subject to simultaneous DORA and AI Act requirements DORA + EU AI Act Convergence
• ICT providers of critical services to the financial sector who want to demonstrate their resilience to clients and regulators Articles 28–44 · CTPP framework
• CISOs and CROs preparing technical documentation for inspections by the Bank of Spain, the CNMV, or the DGSFP in 2026 Regulatory Inspections · 2026

⊘

Out of scope · Client's responsibility

• Advanced TLPT Penetration Tests (Art. 26): These require certified testers under the TIBER-EU framework. V-PROOF can seal the results, but does not conduct the tests. Art. 26, TLPT
• Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP): The entity is responsible for their design. V-PROOF provides verifiable evidence that they exist and are tested. Art. 11, Continuity
• Formal notification of serious incidents to the EBA, ESMA, or EIOPA (Arts. 19–20): internal regulatory process. V-PROOF generates a time-stamped record of the classified incident. Articles 19–20, Notification
• SIEM, EDR, and operational cybersecurity tools: V-PROOF does not replace active threat detection; it generates verifiable evidence of the events detected by those tools. Art. 10, Scope Limitation

DORA Diagnosis

Does your organization have the records that a regulator would require tomorrow?

V-PROOF a 48-hour strategic assessment that maps the DORA requirements applicable to your organization, identifies existing gaps in technical evidence, and defines the necessary scope of integration.

Request a DORA Strategic Assessment

Sources and Regulatory References

1. Regulation (EU) 2022/2554 of the European Parliament and of the Council of December 14, 2022, EUR-Lex CELEX:32022R2554
2. EBA, Final Report on Draft RTS on the ICT Risk Management Framework (Batch 1), January 2024, eba.europa.eu
3. EBA, Final Report on Draft RTS under DORA (Batch 2), July 2024, eba.europa.eu
4. ESMA, Guidelines on the DORA ICT Risk Management Framework for Investment Firms, esma.europa.eu
5. Bank of Spain, Supervisory Communication on DORA, First Quarter 2025, bde.es
6. EBA, Opinion on the Use of Machine Learning for Internal Ratings-Based Models (Convergence of the AI Act and DORA) · eba.europa.eu
7. ENISA, DORA Supervisory Convergence Report, 2025, enisa.europa.eu

V-PROOFPROTOCOL

The Trust Layer for the AI Economy

This article is for informational purposes only and does not constitute legal or regulatory advice. For specific application to your organization, consult with legal advisors specializing in financial regulation and European ICT regulations. V-PROOF Protocol, Registered office: Spain, European Union.