DORA audit logging requirements and how to satisfy them
DORA (the Digital Operational Resilience Act) requires EU financial entities and their critical ICT third-party providers to log and be able to investigate ICT operations, including access, system changes, and administrative actions. This page covers exactly what that means for audit logging, what a regulator asks for as evidence, and how AuditRails' hash-chained logs satisfy it.
The control
DORA ICT Risk Management: Logging of ICT Operations
Regulation (EU) 2022/2554, effective January 2025
“Record and log ICT activities and operations, including access to data, system changes, and administrative actions, in a manner that allows investigation and audit.”
DORA also expects third-party ICT risk to be logged and traceable, not just internal activity: if you're a vendor selling into EU financial services, your own audit trail for that relationship is part of what your customer's regulator will ask to see.
What an auditor asks for
A DORA auditor or your customer's own risk team will want a continuous, tamper-evident record of ICT operations across the audit window: who accessed what, what changed, and whether the record itself is provably unaltered, not a policy stating that logging happens.
Retention requirement
AuditRails retains DORA audit logs for a minimum of 5 years by default. Retention extends automatically if you're also subscribed to a framework with a longer requirement.
What AuditRails captures
Access events capture the third-party/vendor context DORA's ICT third-party risk provisions expect, not just a bare access record.
import { AuditRails } from '@auditrails/node';
const audit = new AuditRails({ apiKey: 'at_live_...' });
await audit.log({
action: 'access.granted',
actor_id: '...', // required
resource: '...', // required
metadata: {
role: '...', // optional
scope: '...', // optional
is_third_party: '...', // optional
contract_register_ref: '...', // optional
}
});What you hand your auditor
Generate an evidence bundle for your audit window and you get a zip containing a PDF summary report, the full event log as NDJSON, and a manifest with SHA-256 checksums of both files plus a hash-chain proof: evidence you can hand directly to a regulator or your customer's risk team, not a policy claim they have to take on faith.
Common ways teams fail this control
- Logging system access but not distinguishing third-party/vendor access from internal access. DORA's ICT third-party risk provisions specifically expect that distinction to be visible in the record.
- No incident-detection events logged at all, only after-the-fact incident reports written by hand. DORA expects operational logging to be the source the incident report is built from, not the other way around.
- Logs stored on the same infrastructure as the ICT systems they describe, with no independent integrity guarantee, an auditor asking "can this have been altered after the fact" gets no good answer.
- Retention shorter than 5 years, missing DORA's own documentation-retention expectation.
- No link between logged events and the specific contract or third-party register entry they relate to, making it hard to demonstrate the concentration-risk oversight DORA also expects.
Frequently asked questions
Does AuditRails make us DORA compliant?
No single tool does. AuditRails gives you the tamper-evident ICT operations logging evidence DORA's audit trail requirements need: the rest of your DORA scope (ICT risk management framework, third-party risk register, incident classification and reporting, resilience testing) is separate.
Where is my data actually hosted?
AWS eu-central-1 (Frankfurt, Germany) for the durable audit-log store, an explicit EU-first choice.
How long do I need to keep DORA audit logs?
A minimum of 5 years is what AuditRails retains by default for this framework.
Can I verify the logs haven't been tampered with, independent of AuditRails?
Yes: we publish an open-source CLI that independently recomputes the hash chain from an export. It doesn't call our API or trust our infrastructure.
This page describes regulatory obligations for information purposes and does not constitute legal advice. Whether they apply to your organisation should be confirmed with your own advisers.