DORA Pushes Operational Resilience Past the Contract. ICT Provider Evidence Is Technical.
The European Union Digital Operational Resilience Act, Regulation 2022/2554, took effect across the EU on January 17, 2025. DORA establishes operational resilience requirements for financial entities and reaches Information and Communications Technology third-party service providers that support those entities. The reach extends to non-EU vendors that serve EU financial entities under cross-border contracts. Tier 1 supervisory examinations against the largest ICT providers are ramping through 2026 under the joint oversight of the European Banking Authority, the European Securities and Markets Authority, and the European Insurance and Occupational Pensions Authority.
The regulation organizes obligations across five pillars: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing arrangements. The pillar that has received the most legal attention is the ICT third-party risk management pillar, which establishes contract requirements between financial entities and their ICT providers. The pillar that examiners are increasingly focused on, based on the Joint European Supervisory Authorities published Technical Standards through 2025 and 2026, is the technical evidence behind the contracts.
Where the evidence question actually binds
DORA Article 28 sets out the contract requirements between a financial entity and an ICT third-party service provider. The contract has to cover scope, location of data, accessibility, security, performance metrics, and termination rights. The contract terms are necessary. The contract terms are not sufficient.
DORA Article 30 sets out the supervisory authority's expectations against critical ICT third-party providers. The expectations include the demonstration of operational resilience under simulated stress, the maintenance of incident records meeting reporting expectations, and the production of evidence supporting the contract commitments. The evidence has to be technical evidence, not contract attestations.
The EBA's Final Report on Draft Regulatory Technical Standards on ICT Risk Management (March 2024) and the Joint ESAs Final Report on Draft Implementing Technical Standards on ICT-related Incident Reporting (December 2023) and subsequent revisions through 2025 and 2026 specify the technical evidence categories. Data classification and data flow inventories. Cryptographic protection traceable to the data category. Access control bound to identifiable attributes. Audit logs sufficient to support incident reporting within the regulation's tight reporting windows.
Where the contracts fall short on their own
A contract clause requires the ICT provider to protect data. A contract clause does not protect data. A contract clause requires the provider to report incidents within specified windows. A contract clause does not generate the incident telemetry. A contract clause requires the provider to terminate access on contract termination. A contract clause does not enforce the termination.
In every case, the contract establishes the obligation. The technical architecture establishes whether the obligation is met. The supervisory examination is the moment at which the gap between the two becomes operational. An examiner asks the financial entity to produce evidence supporting a specific contract clause. The financial entity asks the ICT provider. The ICT provider produces logs, certifications, and process documentation. The examiner evaluates whether the artifacts are evidence of compliance or evidence of process.
The 2025 and 2026 examination outcomes published in summary form by the ESAs suggest a consistent pattern. ICT providers that produced architecture-derived evidence (cryptographic enforcement, data lineage, attribute-bound access logs) achieved cleaner outcomes than ICT providers that produced process-derived evidence (policy documents, attestations, vendor questionnaires). The technical evidence carries the examination.
What data-centric architecture supplies
A data-centric architecture in which every data object carries its own encryption, every access decision runs through a policy enforcement point, and every release event writes a lineage record produces direct evidence against multiple DORA requirements simultaneously.
The data classification is the property set on the object. The cryptographic protection is the wrapped key on the object. The access control is the ABAC evaluation at the PEP. The audit log is the Merkle-tree lineage chain. The incident reporting timeline is shortened from log-stitching reconstruction to a query against the lineage. The contract termination is the revocation of the requesting principal's attribute claim, after which subsequent reads fail closed and generate denial records.
Lattix Technologies implements this pattern through attribute-based access control (ABAC) at the policy enforcement point, post-quantum key encapsulation under ML-KEM-768 and ML-KEM-1024, and Merkle-tree lineage in tamper-evident audit storage. The architecture maps directly to DORA Articles 7 through 16 on ICT risk management, Articles 17 through 23 on incident reporting, and Articles 28 through 30 on third-party risk management. The mapping produces examination-ready evidence.
What ICT providers should be doing in the next 90 days
Three operational priorities matter for ICT providers serving EU financial entities under DORA.
The first is a data flow inventory against the DORA data categories. The inventory identifies which data the provider receives from the financial entity, which data the provider stores, which data the provider processes, and which downstream services see the data. The inventory bounds the compliance scope.
The second is the architectural posture decision. ICT providers operating with contracting controls alone face an evidence gap that examiners reach. ICT providers operating with data-centric architecture produce evidence by construction. The decision made in 2026 determines the examination outcome in 2027 and beyond.
The third is incident reporting capability. DORA Article 19 sets a 4-hour initial classification window and a 24-hour notification window for major ICT-related incidents. The reporting window is shorter than the incident reconstruction window in most legacy architectures. Lineage-based incident analysis closes the gap.
How the architecture aligns with the broader regulatory direction
DORA aligns operationally with NIS2 Directive (EU 2022/2555), the Cyber Resilience Act, the EU AI Act high-risk requirements, and the supervisory direction emerging from ECB, EBA, ESMA, and EIOPA joint guidance through 2025 and 2026. The architectural pattern that satisfies DORA Article 30 expectations is also the pattern that satisfies NIS2 risk management and incident reporting, AI Act Article 10 data governance, and the cross-border data control expectations under GDPR Chapter V.
The investment in data-centric architecture for DORA compliance compounds across the EU regulatory portfolio. The architectural decision in 2026 is one decision, not five.