DORA turns logging, monitoring and incident reporting into directly- applicable EU law for financial entities. You must detect anomalies and incidents quickly, keep the evidence, and report major incidents on a tight 4-hour / 72-hour / 1-month clock. This guide explains where logging fits in DORA, what to capture, how long to keep it, and how the detection and reporting duties connect.
Not legal advice
This is general guidance to help you scope your logging and monitoring programme. The binding requirements are in Regulation (EU) 2022/2554 and its Regulatory and Implementing Technical Standards (RTS/ITS); confirm the specifics with your compliance function and competent authority.
What is DORA, and where does logging fit?
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is the EU's framework for the digital operational resilience of the financial sector. Unlike NIS2, DORA is a regulation — it applies directly across the EU rather than through national transposition — and it has been in application since 17 January 2025.
DORA is built on five pillars:
- ICT risk management — governance, controls, and protection.
- ICT incident management, classification and reporting.
- Digital operational resilience testing.
- ICT third-party risk management.
- Information sharing on cyber threats.
Logging and monitoring underpin the first two. You cannot detect anomalous activity (Article 10), or manage and report an ICT-related incident (Article 17), without records of what happened — which makes a credible logging and monitoring capability effectively mandatory.
Who must comply with DORA?
DORA covers a broad range of financial entities — including banks and credit institutions, payment and e-money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, trading venues, and many others. It also reaches critical ICT third-party providers (for example major cloud and software vendors), which fall under a dedicated oversight regime.
If you supply ICT services to financial entities, expect DORA obligations — including monitoring, logging and incident cooperation — to flow down to you through contracts.
What does DORA require you to log and monitor?
Article 10 (Detection) requires financial entities to devote sufficient resources to monitor user activity, ICT anomalies and ICT-related incidents — particularly cyber-attacks — and to detect them promptly. Detection mechanisms must enable multiple layers of control, define alert thresholds and criteria that trigger incident-response processes, and include automatic alerting for the staff responsible for response. In practice, a defensible DORA logging baseline captures:
- User and access activity — authentication, privileged access, session and account changes.
- ICT anomalies and performance issues — errors, saturation, and signals of single points of failure.
- Security events — IDS/IPS, endpoint, malware and network telemetry, especially around cyber-attacks.
- Changes — configuration, system and control changes across critical or important functions.
- Transactions and critical application events supporting critical or important functions.
The ICT risk-management RTS expects a logging policy that identifies the events to be logged, the retention period for logs, and the measures used to secure and handle log data.
How long must you keep logs under DORA?
DORA does not set a single statutory retention period for logs. Instead, the technical standards require you to define the retention period in your logging policy, justified by the nature of the events and your need to reconstruct, investigate and report incidents — and to keep logs long enough to support the incident-reporting and resilience-testing obligations.
Because major-incident final reports and root-cause analysis can run weeks after detection, and because financial entities frequently sit under overlapping regimes (the GDPR, national financial record-keeping rules, and sometimes PCI DSS), most firms land on a multi-month-to-multi-year window with a hot tier for active investigation and a cheaper archive tier for forensic reconstruction. See the log retention requirements by regulation guide for how the different regimes stack up.
Detection and monitoring requirements
Article 10 makes monitoring an active duty, not passive storage. Your monitoring should:
- Continuously monitor user activity, ICT anomalies, and incidents across the estate.
- Operate multiple layers of control rather than a single detection point.
- Define alert thresholds and criteria that automatically initiate the incident-response process.
- Automatically alert the staff responsible for response, with enough context to act.
- Help identify material single points of failure.
This is the functional definition of a SIEM with anomaly detection. DORA does not name a product, but meeting continuous monitoring, thresholds, and automatic alerting at scale is hard without one.
Incident classification and reporting timelines
DORA (Article 17 and the incident-reporting standards) sets a strict clock for major ICT-related incidents. An incident is generally classified as major when it meets at least two primary criteria, or one primary criterion plus the economic-impact threshold. Your logs are the evidence base at every stage:
| Stage | Deadline | What you submit |
|---|---|---|
| Initial notification | Within 4 hours of classifying the incident as major — and no later than 24 hours after detection | First report to your competent authority that a major incident has occurred. |
| Intermediate report | Within 72 hours of the initial notification | Updated status, including once regular activities are recovered. |
| Final report | Within 1 month of the latest intermediate report | Root-cause analysis and full impact assessment. |
The 4-hour clock starts at classification
The 4-hour deadline runs from the moment you classify an incident as major — capped at 24 hours after detection. That makes fast detection and searchable logs decisive: you cannot classify, let alone report, what you cannot see.
Securing and protecting your logs
DORA's protection and integrity expectations apply to the log store itself, because logs are both evidence and an attacker target:
- Integrity — tamper-evident, append-only storage so records cannot be silently altered.
- Access control — restrict and log who can read and administer logs.
- Availability — keep logs off-host and centralised so they survive the compromise of the systems that produced them.
- Confidentiality and the GDPR — handle and, where appropriate, redact personal data in logs.
A practical DORA logging checklist
- Centralised collection of user-activity, anomaly, security, change and critical-application logs.
- Continuous monitoring with multiple layers of control and defined alert thresholds.
- Automatic alerting that initiates the incident-response process.
- A written logging policy: which events, the retention period, and how logs are secured.
- Tamper-evident, access-controlled, centralised log storage.
- Incident classification mapped to DORA's primary/secondary criteria.
- A reporting workflow that can hit the 4h / 72h / 1-month deadlines.
- Evidence and forensic capability to support root-cause and final reports.
How LogPulse supports DORA logging
LogPulse centralises your logs on one engine and monitors them in real time — search, anomaly detection, and a risk-based Security Monitoring (SIEM) layer on the same data — so continuous detection, thresholds and automatic alerting do not require a separate security stack. Detections map to DORA, NIS2 and ISO 27001 controls, and log data stays in the EU (GDPR-compliant by default).
See the DORA compliance overview for how this maps to the regulation, and the NIS2 logging guide if you also fall under NIS2. LogPulse supports your compliance programme and produces evidence; it is not itself a certification.