DORA Telemetry Retention: What EU Banks Must Know

The Digital Operational Resilience Act (DORA) represents the most comprehensive ICT risk management regulation that European financial services has seen. Effective January 17, 2025, DORA applies to virtually every regulated financial entity in the EU, banks, investment firms, insurance companies, payment institutions, crypto-asset service providers, and their critical ICT third-party service providers.

DORA's requirements extend well beyond traditional cybersecurity compliance. The regulation mandates that financial entities maintain operational resilience across their entire ICT landscape, which includes specific, enforceable requirements for how telemetry and log data is captured, retained, and made accessible.

For telemetry infrastructure, DORA changes the calculus. What was previously a best-practice recommendation becomes a regulatory obligation. And the obligations are more demanding than most institutions' current architectures can satisfy.

What is DORA and why it changes log retention requirements

DORA is an EU regulation (not a directive, it applies directly without national transposition) that establishes a unified framework for ICT risk management across financial services. Its scope includes credit institutions, investment firms, insurance and reinsurance undertakings, payment institutions, electronic money institutions, crypto-asset service providers, and central securities depositories, among others.

The regulation is organized around five pillars: ICT risk management, ICT-related incident management, digital operational resilience testing, ICT third-party risk management, and information-sharing arrangements. Each pillar has specific implications for telemetry retention.

DORA changes log retention requirements in three ways that matter operationally.

First, it makes retention an explicit regulatory obligation rather than an implied best practice. Financial entities must maintain records, logs, and audit trails that support incident detection, classification, reporting, and post-incident review. This is not guidance, it is enforceable regulation.

Second, it extends the scope of retention to include ICT third-party services. Entities must demonstrate monitoring coverage and incident response capability across their third-party ICT ecosystem, cloud providers, SaaS platforms, managed service providers, and critical technology vendors. Telemetry from these third-party services must be retained alongside internal telemetry.

Third, it imposes specific timelines for incident reporting that create implicit requirements for data accessibility. Major ICT-related incidents must be reported to competent authorities within defined timeframes, initial notification within 4 hours, intermediate report within 72 hours, and final report within one month. Meeting these timelines requires immediate access to the telemetry needed to classify, scope, and analyze the incident.

DORA's ICT risk management requirements: what log data must be kept

DORA's ICT risk management framework (Articles 5-16) establishes the foundation for telemetry retention requirements.

Article 6 requires financial entities to establish an ICT risk management framework that includes "policies on arrangements, protocols, and tools necessary for the protection of information assets and ICT assets." This includes logging and monitoring capabilities that detect anomalous activities and ICT-related incidents.

Article 9 requires entities to implement "capabilities and staff to gather information on vulnerabilities and cyber threats, ICT-related incidents, in particular cyber-attacks, and analyse the impact they are likely to have." This requires retained telemetry that supports threat analysis and impact assessment, not just real-time alerting.

Article 10 mandates "detection mechanisms" that "enable the prompt detection of anomalous activities" across network performance, ICT-related incidents, and material single points of failure. Detection at this scope requires telemetry from all ICT systems, network infrastructure, compute platforms, applications, identity systems, and third-party services.

Article 12 requires "backup policies and procedures" and "restoration and recovery procedures and methods" that ensure operational continuity. Telemetry that supports incident reconstruction and root cause analysis is essential for verifying that restoration and recovery are complete and effective.

The practical translation of these articles is that entities must retain telemetry from all ICT systems, internal and third-party, that supports detection, incident analysis, impact assessment, and recovery verification. The scope is comprehensive, the expectation is completeness, and the data must be accessible for these purposes throughout the retention period.

Retention periods under DORA: what the regulation actually specifies

DORA's retention requirements are specified in the regulation and its regulatory technical standards (RTS), which are developed by the European Supervisory Authorities (ESAs, EBA, EIOPA, and ESMA).

The regulation requires entities to retain ICT-related incident records, audit trails, and supporting data for periods sufficient to support regulatory review, post-incident analysis, and supervisory examination. The RTS provide more specific guidance on retention periods, aligned with supervisory review cycles.

For ICT incident records, the practical expectation is retention for five or more years. This aligns with the regulatory review cycle, supervisory authorities may request historical incident data spanning multiple examination periods. The incident record includes not just the incident report itself, but the supporting telemetry that enables reconstruction of the incident timeline.

For audit trails and access logs, retention expectations follow similar multi-year horizons. Entities must demonstrate, over time, that their ICT risk management framework is operating effectively. This requires longitudinal access to audit data that shows monitoring coverage, detection capability, and response effectiveness across years, not months.

For the most recent data, the telemetry needed for active incident response and ongoing monitoring, the accessibility requirement is immediate. Data from the last 12-24 months must be searchable in seconds to low minutes. This supports the incident reporting timelines (4-hour initial notification, 72-hour intermediate report) and enables ongoing threat detection and analysis.

Data beyond the 12-24 month immediate accessibility window may be retained in warm storage with slightly longer query times, but cold archive, where restoration takes hours or days, does not satisfy DORA's expectations for data that supports incident analysis and regulatory reporting.

The 'audit trail' standard: what DORA auditors will ask to see

DORA auditors, whether from competent national authorities or the European Supervisory Authorities themselves, will evaluate telemetry retention along several dimensions.

They will ask to see coverage. Does the entity's telemetry capture activity from all ICT systems within scope, including cloud platforms, SaaS applications, identity providers, and critical third-party services? Gaps in coverage represent gaps in the ICT risk management framework.

They will ask to see completeness. Is the retained telemetry complete, or has it been sampled, filtered, or aggregated? DORA's emphasis on incident reconstruction and impact assessment implies full-fidelity retention, the ability to see every relevant event, not a statistical subset.

They will ask to see accessibility. Can the entity produce specific telemetry data for specific time periods within the examination timeline? If the examiner requests authentication logs for a particular system over the last 18 months, can the entity deliver them in hours rather than days?

They will ask to see integrity. Is the retained telemetry immutable? Can the entity demonstrate that the data has not been altered since capture? Integrity controls, write-once storage, cryptographic verification, and access audit trails, are essential for telemetry that may be used as evidence in regulatory proceedings.

They will ask to see governance. Who can access the retained telemetry? Is access controlled and logged? Are there policies governing data access, and are those policies enforced through technical controls?

Entities that can demonstrate all five properties, coverage, completeness, accessibility, integrity, and governance, will satisfy DORA's audit trail requirements with minimal examination friction. Entities that fall short on any dimension face potential findings, remediation requirements, and increased supervisory scrutiny.

Hot storage vs. cold archive: what DORA compliance requires in practice

DORA's incident reporting timelines and the expectation for accessible audit trails create specific requirements for storage architecture.

The 4-hour initial notification timeline for major ICT incidents means that the entity must be able to detect, classify, and begin analyzing the incident within hours, not days. This requires that detection-relevant telemetry is in hot storage, queryable in real time. If the telemetry that would reveal the incident's scope is in cold archive, the entity cannot meet the notification timeline.

The 72-hour intermediate report timeline requires that the entity can provide a detailed analysis of the incident, including root cause, impact assessment, and containment measures, within three days. This analysis requires correlation of telemetry across multiple sources and time periods. If historical data requires restoration from cold storage, the correlation work cannot begin until restoration is complete, consuming days of a 72-hour window.

The one-month final report timeline is more forgiving for data restoration, but the depth of analysis expected in the final report, including lessons learned, effectiveness of response measures, and remediation completeness, still requires comprehensive access to historical telemetry.

The practical architecture for DORA compliance is hot storage for the most recent 12-24 months of telemetry (supporting incident detection, classification, and analysis) and warm storage for older data within the multi-year retention window (supporting regulatory review and historical analysis). Cold archive, where restoration takes hours to days, is inadequate for any data that might be needed during an active incident or within a regulatory reporting timeline.

The ideal architecture eliminates the tiering complexity entirely: all retained data in hot storage, queryable at the same speed regardless of age. This approach satisfies the most stringent interpretation of DORA's accessibility requirements and eliminates the operational risk of cold storage restoration delays during an active incident.

How Bloo supports DORA-compliant telemetry retention

Bloo's architecture is designed to satisfy the most demanding telemetry retention requirements, including DORA, by default rather than through configuration.

Coverage. Bloo captures telemetry from all ICT sources without volume limits or ingestion penalties. Adding a new data source, a cloud platform, a SaaS application, a third-party service, is an operational decision, not a financial one. This eliminates the coverage gaps that arise when cost constraints force selective ingestion.

Completeness. Bloo retains all captured telemetry in full fidelity. No sampling. No aggregation. No filtering. Every event that enters the system is retained as captured, enriched with metadata and entity resolution, and stored for the full retention period.

Accessibility. All data in Bloo is hot, queryable in seconds regardless of age. There is no warm tier. There is no cold archive. Telemetry from one month ago and telemetry from one year ago are equally accessible. This satisfies DORA's incident reporting timelines and audit trail accessibility requirements without the operational complexity of tiered storage.

Integrity. Bloo stores telemetry immutably within the customer's own cloud environment. The data cannot be modified or deleted during the retention period. Access to the data is logged and auditable, providing the integrity chain that regulators require.

Governance. Data remains under the customer's governance and control, in their cloud, in their region, under their access policies. Bloo does not require data to leave the customer's environment, supporting data residency requirements and regulatory expectations around data sovereignty.

Predictable cost. Bloo's pricing is independent of data volume. The cost of retaining 5 TB per day for five years is predictable and budgetable, eliminating the cost pressure that drives institutions toward retention compromises.

For European financial institutions subject to DORA, Bloo provides a telemetry architecture that is compliant by design, addressing coverage, completeness, accessibility, integrity, and governance through architectural choices rather than operational workarounds.