DORA logging requirements and log retention, what to keep

What DORA logging requirements and log retention actually ask for

If your organization is a financial entity or an ICT provider working under DORA, which has applied since 17 January 2025, you need logging evidence that an assessor can follow. The short answer is this: Article 12 of Delegated Regulation (EU) 2024/1774 names the categories of events you must log, which cover access control and identity management, capacity management, change management, ICT operations and network traffic. It also requires you to protect logs against tampering and deletion, to detect logging failures, and to synchronize clocks to a documented reliable time source. Beyond those named categories, the Regulation leaves the detail to you. Under Article 12(2), you define which events are logged, how long logs are kept and how they are protected, all in line with your ICT risk assessment.

The supplied material does not give a fixed retention period, and you should not look for one in DORA itself. The number is yours to set. A defensible retention period starts from the criticality of the functions each log source supports, the evidence you expect to need for investigations and for your own incident records, and any legal retention duties that apply in your member state and sector. Article 22 adds a related constraint for incident evidence: keep it no longer than necessary, store it securely, and make the period proportionate to the criticality of the affected functions. Document the reasoning in your risk assessment and get management body sign-off, because a retention decision with no recorded rationale is hard to defend. Confirm the detailed expectations with your competent authority and with the auditor or supervisor who will review your framework, since they judge whether your choice holds up in practice.

Treat the logging design as a set of decisions you can show. For each log source, record the events captured, the retention period, the protection measures (such as write-once storage or restricted administrator access), the time source and the alert that fires if collection stops. Article 23 of the same Regulation requires alerting for ICT assets that support critical or important functions, including rule-based alerts for gaps in log collection and integrity. Open-source tools such as Wazuh can collect and analyze logs from endpoints and syslog sources, and chrony can keep system clocks synchronized to NTP or reference clocks, but tooling only produces evidence once your retention and protection choices are written down and tested. Confirm each tool's current capabilities against its own documentation before you rely on it in a control description.

Which events DORA logging must cover

Article 12 of Delegated Regulation (EU) 2024/1774 names the categories of activity a financial entity must record. The entity decides the detailed event list under Article 12(2), based on its own ICT risk assessment, so each card below describes what a reviewer expects to find in that list and why it matters when an incident has to be reconstructed.

Access control and identity events

Record every authentication attempt, successful or failed, along with privilege grants, role changes, account creation and deletion, and changes to access policies. A reviewer will ask whether you can answer who had access to a critical system on a given date and how that access was granted. Check that identity events come from every system that holds identities, including the directory, VPN, privileged access tooling and the applications themselves, not only the central identity provider.

Capacity management events

Log changes to capacity thresholds, resource exhaustion warnings, scaling actions and events where systems reach limits on compute, storage or network throughput. Capacity events often appear before an outage, so they give incident responders a timeline of degradation. Confirm that alerts on these events are tied to the critical or important functions the entity has identified, and that the entity can show who reviewed them.

Change management events

Record each change to production systems with its requester, approver, implementer, timestamp and outcome, including emergency changes and rollbacks. Auditors use these records to match an incident to a recent change and to test whether approvers were separate from implementers. Check that change records written in the ticketing tool match the actual configuration events captured on the systems themselves.

ICT operations events

Capture job runs, batch failures, service restarts, backup and restore operations, scheduled maintenance and operator actions on systems that support critical or important functions. Operational events show whether a documented procedure was followed during an incident and whether recovery steps ran as designed. Confirm that operator sessions on production hosts are logged at the level of commands or actions, not only at login.

Network traffic events

Log connections and denied flows at network boundaries, including firewalls, proxies and segmentation points between zones of different criticality. Network records are often the first evidence that an intrusion attempt reached the entity and how far it moved. Check that traffic logs cover the administration network and connections to ICT third-party providers, since these are common paths for lateral movement and data exfiltration.

Entity-defined event list

Article 12(2) leaves it to the entity to decide, in line with its ICT risk assessment, which events are logged, how long logs are kept and how they are protected. A reviewer will expect a written event catalogue that maps each category to named systems, justifies gaps and links back to the risk assessment. Ask whether the catalogue is approved by the people accountable for ICT risk and reviewed when systems or risks change.

How to set log retention from your risk assessment

Article 12(2) of Delegated Regulation (EU) 2024/1774 leaves the retention period to you. The entity decides, in line with its ICT risk assessment, how long logs are kept, so the work is to write that decision down and show how it was reached. An assessor will not accept a retention figure that has no stated reasoning behind it. Start by listing the ICT assets that support critical or important functions, then record for each asset class which event types are logged, the retention period chosen, and the risk the period addresses, such as the time needed to detect a slow intrusion, to reconstruct an incident, or to meet a supervisory request.

Your retention periods must also respect legal retention duties that apply in your jurisdiction and sector. These can come from financial services law, tax and accounting rules, employment records, and data protection rules that limit how long personal data in logs may be kept. Those duties sit outside DORA, and the obligations differ between member states and between types of financial entity, so the reader should not infer a period from this page. Ask counsel to confirm each applicable duty in writing, and record the source of every legal period next to the risk-based period in the same register. Where the two conflict, document which one governs and who approved the choice.

Review the retention decision on a defined schedule and after any material change, such as a new critical function, a new cloud region, or a change in the incident reporting process. Keep the rationale, the approval record and the review dates together, because the reasoning is itself evidence. If you use a platform such as Wazuh to store alerts and archives, check with the vendor documentation and your own tests how retention is configured, how old data is archived or deleted, and whether deletion is logged, rather than assuming the default matches your decision. Confirm these settings in your own environment before you record them as the retention standard.

Protecting logs, catching logging failures and keeping clocks aligned

Article 12 of Delegated Regulation (EU) 2024/1774 requires the entity to protect logs against tampering and deletion. The entity decides the method, but the protection has to hold up when someone with administrative access tries to alter or erase records. Assessors usually ask who can read, write and delete log data, whether those rights are separated, and whether any change to the record leaves a trace. The retention period and the protected events come from the entity's own ICT risk assessment, so the same controls also need to match what that assessment says must be kept.

Write-once or separated storage: Send logs to a central store that local administrators cannot modify, such as a dedicated log server or immutable object storage.
Restricted deletion rights: Limit delete permissions to a small named group and record every retention or purge action.
Integrity checks: Use hashing or signing of log files so that alteration can be detected during review.
Access logging for the log store: Record who queries, exports or changes the log platform itself.
Protection of anomaly records: Under Article 23, records of anomalous activity need the same protection against unauthorised access.

Confirm in your own environment that a Wazuh server or equivalent platform can keep forwarded logs out of reach of endpoint administrators, and test whether a deletion attempt is itself logged.

How long incident evidence is kept under Article 22

Article 22 of Delegated Regulation (EU) 2024/1774 sets the rule for incident evidence: keep it no longer than necessary, store it securely, and size the retention to the criticality of the affected functions and to any legal retention duties. The regulation does not give a number of years. The organization must define the period itself, record the reasoning in its ICT risk assessment, and be able to show an assessor how that period was chosen. Treat this as a decision with an owner, not a default inherited from the logging platform.

The incident evidence schedule and the general log retention schedule are related but not identical. Routine logs from access control, change management or network traffic may be kept for one period, while the subset of records tied to a major incident, including the detection and classification timeline, the containment steps and the data used to justify reporting to the competent authority, may need a longer or differently protected period. Confirm with legal counsel which national or sectoral retention duties apply to each record type, and confirm with the incident response lead how long reports, forensic images and correspondence with authorities must remain available for follow-up questions after a report is filed.

When you configure the retention policy in a self-hosted stack, document each data store, its retention setting, the access list and the deletion method, and test that deletion removes data from indexes, archives and backups. For example, an illustrative Wazuh deployment may hold alert data in its indexer for a short operational window while exporting a sealed copy of incident-related records to a restricted, write-once store with its own retention clock. Ask your implementation partner to show how each copy is encrypted, who can read it, and how legal holds stop deletion. The organization owns this schedule, and its auditor will test whether the schedule matches the risk assessment and the reporting record.

How logging readiness moves from gap check to supervisor-ready evidence

The sequence turns an unstructured logging estate into a documented, tested set of controls whose records an entity can show a competent authority. Each phase produces a named output that the next phase depends on.

Scope the in-scope ICT assets and functions
The entity's ICT risk owner and the teams that run critical or important functions list the ICT assets that support those functions, using the asset inventory and the function mapping already held for the ICT risk management framework. Scope covers systems, network devices, identity services and the monitoring tools themselves. The output is a signed scope register that names every asset, its owner and the function it supports. The step is complete when each asset in scope has a named owner and a documented link to a function.
Map current logging against Article 12
The security engineering team compares what each in-scope asset logs today with the event categories Article 12 of Delegated Regulation (EU) 2024/1774 names: access control and identity management, capacity management, change management, ICT operations and network traffic. Engineers check log sources, formats, timestamps and forwarding paths, and record gaps per asset and per category. The output is a gap register with a severity and an owner for each gap. The step is complete when every in-scope asset has a row for every category, including explicit 'not logged' entries.
Set retention and protection rules
The entity's risk function, with information security and legal counsel, decides which events are logged in detail, how long each log class is kept and how logs are protected against tampering and deletion. Article 12(2) leaves these choices to the entity, tied to its ICT risk assessment, so the rationale should cite the risk assessment directly. The output is a logging and retention standard approved by the management body or its delegate, with access rights for log stores and deletion rules. The step is complete when each retention period has a stated reason and a named approver.
Configure alerting for log and data gaps
Engineers configure alerting tools for the in-scope assets, with automated rules that fire when log collection stops, when data sources are incomplete or when integrity checks fail. Article 23 of the RTS requires alerts to be prioritized during and outside working hours, and anomaly records to carry the date and time the anomaly occurred and was detected, along with its type. Tooling such as the Wazuh agent can collect logs from endpoints, but the entity must confirm which rules and integrations its own estate needs. The output is a tested alert rulebook with routing and escalation paths. The step is complete when each alert type has an owner and a documented response path.
Test clock synchronization and alert paths
The platform team confirms that every in-scope asset syncs to the documented reliable time source, using a service such as chrony where it fits the estate, and checks drift on a sample of hosts and network devices. The same team then simulates a log source going silent, a tampered record and an out-of-hours failure, and confirms that each alert fires and reaches the right person. The output is a test record with timestamps, results and remediation for any failure. The step is complete when every test has a recorded pass or a tracked fix.
Assemble evidence for supervisory review
The compliance lead packages the outputs of earlier phases into a single evidence pack: the scope register, the gap register and its closure records, the logging and retention standard, the alert rulebook, the clock and alert test results and sample log extracts showing retained and protected records. Incident evidence is held under the retention rule in Article 22 of the RTS, stored securely and kept no longer than necessary. Because only an independent auditor issues assurance reports, the pack is prepared for the entity's own supervisor and for any external reviewer the entity engages. The output is an indexed evidence set that a team member can retrieve within a single working session. The step is complete when a reviewer can trace each Article 12 category from the standard to a live record.

What to have in place before an assessment

An assessor testing DORA logging will look for a chain of documents and records that agree with each other: the policy sets what is logged, the asset list defines where, the retention schedule follows from the risk assessment, and the test records prove the controls worked. Use the items below to check your own position before anyone else does.

Documented logging policy

Article 12(2) of Delegated Regulation (EU) 2024/1774 leaves you to decide which events are logged, how long logs are kept and how they are protected, so that decision must be written down. Check that the policy names the event categories in Article 12 (access control and identity, capacity, change, ICT operations and network traffic), states who owns each log source, and is approved by the body that owns ICT risk. An assessor will ask who signed it and when it was last reviewed.

Log source asset list

Every logged event has to trace back to a system, so you need an inventory that shows which ICT assets produce logs and which of them support critical or important functions. Check that each in-scope asset appears with its log source, collection method and owner, and that the list matches what your collection tool actually receives. Gaps between the inventory and the collector are the first thing a reviewer will test.

Retention schedule tied to risk

Retention periods are not fixed by the RTS. They must follow from your ICT risk assessment, so the schedule should cite the risk assessment entry that justifies each period. Check that periods differ by log type where the risk differs, that legal retention obligations are recorded alongside them, and that deletion actually runs as scheduled. A single retention number applied to everything usually signals that no risk-based decision was made.

Tamper protection evidence

Article 12 requires logs to be protected against tampering and deletion, and Article 23 extends that to records of anomalous activity. Gather evidence of the controls in place: restricted write and delete rights, separate administration of the log store, integrity checks or hashing, and access logs for the log platform itself. Ask whether an administrator can alter logs without leaving a trace, because that answer shapes the whole design.

Alert test records

Article 23 requires alerting for critical or important ICT assets, including rule-based alerts for gaps in data source completeness and log collection, with prioritisation during and outside working hours. Keep dated test records showing that a deliberately stopped log source or a missing feed produced an alert, who received it and how it was handled. Untested alert rules are assumed not to work until shown otherwise.

Clock synchronisation configuration records

Article 12 requires clock synchronisation to a documented reliable time source, and log timestamps are only useful if the clocks agree. Keep the configuration of your time service, the list of upstream sources, and periodic checks showing that hosts are within the tolerance your policy sets. If you use chrony, retain the relevant configuration file and the output of its tracking and source status commands from a sampled set of hosts.

Incident evidence samples

Article 22 requires incident evidence to be kept no longer than necessary, stored securely and proportionate to the criticality of the affected function. Prepare a small set of real or exercise incident records showing the logs preserved, where they are stored, who accessed them and when they were destroyed under the schedule. Assessors often ask for these samples before reading any policy, so having them ready shortens the review.

Who owns logging controls, who prepares evidence and who assesses it

The financial entity owns the logging controls. DORA places responsibility for the ICT risk management framework on the management body and the entity itself, so the entity decides which events are logged, how long logs are kept and how they are protected. Article 12(2) of Delegated Regulation (EU) 2024/1774 leaves these choices to the entity, tied to its own ICT risk assessment. A partner can propose settings, but the decisions and their justification belong to the entity.

Event scope: Decide which access, change, operations, capacity and network events are logged for each critical or important function.
Retention periods: Set log retention from the risk assessment and legal retention duties, and record the reasoning.
Alert ownership: Name who receives alerts for log collection gaps and who acts outside working hours.
Incident evidence: Define how long incident evidence is kept, under Article 22, and who approves disposal.
Policy approval: Have the management body approve the logging policy and review it as part of the framework.

Before relying on any partner's configuration, confirm that the decisions are written down, approved and traceable to the entity's own risk assessment.

Common questions about DORA logging and retention

Does DORA set a fixed log retention period?

No. DORA does not set one number of days or years for log retention. Article 12(2) of Delegated Regulation (EU) 2024/1774 leaves the financial entity to decide how long logs are kept, in line with its own ICT risk assessment. Incident evidence follows a related rule in Article 22: it must be kept no longer than necessary, stored securely, proportionate to the criticality of the affected functions, and consistent with legal retention requirements that apply to the entity. In practice, the retention period is a documented decision that you must justify. Confirm the periods that apply in your member state and sector with your competent authority and legal team, and record how each period was derived from your risk assessment so an examiner can follow the reasoning.

Who decides which events a DORA logging programme must capture?

The financial entity decides, using its own ICT risk assessment. Article 12 of Delegated Regulation (EU) 2024/1774 names the categories that must be logged, including access control and identity management, capacity management, change management, ICT operations and network traffic. Within those categories, the entity defines the specific events, sources and fields. The management body owns that decision, and the ICT risk function should be able to show how each logged event maps to an asset that supports a critical or important function. An implementation partner can draft the event catalogue and configure collection, but the entity must approve it and keep it current as its risk assessment changes.

Do Wazuh and chrony satisfy DORA logging requirements?

Neither tool satisfies DORA on its own, because DORA assesses your controls and evidence, not a product. Wazuh can collect and forward system and application logs from endpoints, receive syslog and API data, and run rule-based analysis, which covers much of the collection and detection work. chrony synchronizes the system clock to NTP servers or reference clocks, which supports the documented reliable time source that Article 12 expects. You still need to configure event coverage, tamper protection, retention, alerts for gaps in log collection, and a documented time source, then prove each one works. Confirm current Wazuh capabilities against the Wazuh log data collection documentation for your version.

What does DORA logging work cost, and what drives the price?

No researched figure is available for logging costs, so treat any number you see as unverified until a quote is built from your scope. Cost usually splits into four parts: the open-source software itself, the infrastructure to store and search logs, the staff time to design and configure logging, and the ongoing effort to review alerts and keep the programme current. Software licence fees may be zero for some GPL-licensed components, but storage volume, retention length, number of endpoints and the depth of rule tuning move the total substantially. Ask any provider for a written scope that lists in-scope assets, event categories, retention periods, storage assumptions, alert handling, and which costs are one-time and which recur.

How long does it take to implement DORA-compliant logging?

No supplied fact gives a duration, so the timeline depends on your starting point. The main variables are how many ICT assets support critical or important functions, whether logging already exists, how far your retention and tamper-protection decisions have progressed, and how many systems need new collection paths. A fixed-scope engagement agrees deliverables and timelines in writing before work starts, which lets you check the schedule against your own change calendar. Ask for milestones covering the event catalogue, collection deployment, time synchronization, alert rules, and a test that shows logs survive a tampering attempt. Your internal audit or assessor will need evidence over a period of operation, so start early enough to build that history.

Can our own team implement DORA logging without an outside partner?

Yes, if your team has the skills and capacity. DORA does not require a partner, and the entity owns its controls and evidence either way. Your team needs experience with log collection, SIEM-style rule design, time synchronization, access control for log stores, and incident response, since alerts must be prioritized during and outside working hours. An outside partner is useful when the team is stretched, when the scope spans many systems, or when you need a documented, repeatable build. Independent auditors and competent authorities assess the result; no implementation partner issues reports or certificates. Decide early which parts you will own, such as retention decisions and alert triage, and which you may delegate.

How DeployOpen prepares logging systems and evidence

DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For logging, that means deploying the collection, storage and alerting components in the client's environment, configuring them to capture the events the entity has chosen to log under its ICT risk assessment, and writing down how each setting was decided. The organization keeps ownership of its log scope, retention periods and protection rules. DeployOpen's role is to build those decisions into working systems and to record them so the organization can show how they operate.

Engagements are fixed-scope. Before work starts, the parties agree in writing which log sources are in scope, which platform components will be deployed or changed, how retention and tamper protection will be configured, which alert rules will cover logging failures and clock drift, and which documents and evidence will be delivered. Typical evidence for an assessor includes configuration exports, a log source inventory, retention settings with their justification, access records for the log store, alert test results and a documented reliable time source. Confirm with the implementation partner exactly which artifacts are included, who maintains them after handover and how they are updated when the environment changes.

DeployOpen does not issue audit reports, attestations or certifications. Those come only from the competent authority or from an independent assessor the financial entity appoints, and whether a given logging setup meets the entity's obligations is for that assessor and the entity's own governance to judge. Ask any partner to confirm in writing what it will deliver, what it will not deliver, and which parts remain with the entity's own staff, including ongoing review of logs and sign-off of retention decisions. No implementation partner can guarantee an assessment outcome.

DORA logging requirements and log retention