The regulation (EU) 2022/2554 - Digital Operational Resilience Act (DORA) - has been in force since January 2025. If you are a CISO, IT Risk lead, or Compliance Architect at a regulated financial entity, you are already informed. The question most firms have not yet answered is deceptively specific: what does verifiable data integrity demand of your ICT stack? A survey found that 96% of firms across EMEA consider their current level of digital resilience insufficient.
Here you can reinforce and learn:
- what DORA's integrity standard says - in its own language;
- where standard systems fall short;
- what a technically defensible integrity control looks like;
- and which operational tools address the availability and continuity obligations that run alongside it.
What DORA Actually Says About Data Integrity
DORA uses integrity as a specific, recurring obligation - not a general principle. Article 9(2) establishes the baseline:
"Financial entities shall design, procure and implement ICT security policies, procedures, protocols and tools… to maintain high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use or in transit."
Article 12(7) sets the ceiling:
"When recovering from an ICT-related incident, financial entities shall perform necessary checks, including any multiple checks and reconciliations, in order to ensure that the highest level of data integrity is maintained."
That reconciliation obligation requires a fixed reference point - an independently verifiable integrity baseline against which recovered data can be checked. Article 18(1)(d) ties integrity to incident classification. Article 30(2)(c) extends the obligation to third-party ICT contracts. Data integrity is a systemic requirement across your operations and your supply chain.
The Gap Most Firms Have Not Named
Most regulated entities already have SharePoint, Salesforce, Dynamics 365, Google Workspace, Microsoft 365, or equivalent platforms producing access logs, version histories, and timestamps. The assumption is that this constitutes adequate integrity control. It does not.
ENISA's technical standards mapping under the EU Cyber Resilience Act framework states that data integrity "should be ensured using current non-deprecated technology," and that systems must be designed with "evidence protection in mind" - because if access to logs is compromised, an attacker can erase their tracks.
An internal log stored within the same system can be altered. It is not tamper-evident. When a regulator asks you to prove a file existed in a specific state at a specific time and has not been altered since, an internal timestamp does not answer that question independently. GDPR Article 5(2) places the burden of proof on the controller: demonstrate compliance - not assert it.
What Verifiable Integrity Actually Looks Like
DORA does not prescribe a technical method. It prescribes an outcome: data that is authentic, traceable, tamper-evident, and independently verifiable across its full lifecycle.
One technically defensible path is cryptographic hash anchoring. A fingerprint of the file is generated at the point of creation or last authorised modification and anchored to an immutable public ledger. The document content never enters the chain - confidentiality is preserved by design. Any subsequent modification produces a different hash. The divergence is mathematically certain and independently verifiable without access to sensitive content.
The Bank of England's 2024 Financial Stability Paper on operational resilience noted that financial firms "are exploring the potential of distributed ledger technology to bring efficiencies to financial processes and transactions… it will likely have applications in the traditional financial system as well."
Truth Enforcer operationalises this: hash anchoring to a public blockchain, instant tamper detection, independent verification without content exposure, and integration with SharePoint, Salesforce, Google Workspace, and others. It converts DORA's integrity obligation from a policy statement into a provable and auditable fact.
Integrity in Operational Resilience & Risk Governance
DORA Article 5(2) places ICT risk governance at board level. The management body must approve, oversee, and review business continuity policy and recovery plans. Deloitte frames the mandate directly: firms must demonstrate they "can withstand, respond to, and recover from all types of ICT-related disruptions and threats."
Hash-anchored integrity records and real-time sync continuity logs are not technology preferences. They are documented evidence of compliance with obligations the board is legally required to oversee. GDPR's accountability principle closes the argument: the burden of proof is on your organisation, and it must survive scrutiny.
DORA's integrity standard is direct and already in force. Most financial institutions have access logs. Most do not have independently verifiable, tamper-evident integrity records. That is the gap.
Your ICT risk framework should be able to produce an independently verifiable integrity record for a specific file at a specific point in time, that’s the standard level you want – the highest.
.
Contact us for DORA integrity standard: https://www.connecting-software.com/truth-enforcer-sign-up/
OR
Try it for FREE:
Truth Verifier for IP Creators: https://truth-verifier.com/landing
Truth Verifier for Journalists: https://truthverifier.news/landing
.
Explore Microsoft Synchronization for business continuity and availability: https://www.connecting-software.com/microsoft-synchronization/
By Francisco Rodrigues, Product Manager
"I write about how software integrations can adapt to business environments and respond to industry-specific demands. I want to show enterprises the road to streamline processes, eliminate bottlenecks, and ensure compliance by empowering teams and C-suite executives with the right tools."