Why DORA Is More Than a Compliance Project
Since 17 January 2025, the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) has been binding on banks, insurers, payment service providers and their ICT service providers. For the first time, the regulation imposes a Europe-wide holistic resilience approach that goes far beyond classical IT security: operational stability, incident management, testing under real-world conditions and the end-to-end management of third parties are at the centre.
A recent assessment by a PwC expert in IT-Finanzmagazin makes one thing clear: anyone who treats DORA as a mere paper exercise and merely formally touches up their control chain risks substantive findings at the very first audit. Today, the biggest gaps are not in the periphery but in access security — precisely the area where attackers have been systematically successful in recent years.
DORA obliges financial firms to demonstrate verifiable digital operational stability. Audits cover, among other things, ICT risk management, incident reporting, resilience testing and the third-party register. The IAM architecture touches several of these areas simultaneously and therefore becomes a central audit subject.
This analysis summarises the key statements, places them in their regulatory context, and shows — using the four critical levers (IAM architecture, recertification, log depth and third-party management) — which measures will realistically hold up.
IAM Architecture: From an Entitlement Thicket to Controlled Access
In many institutions, entitlement models grown over years are the everyday reality: shared accounts, permanently elevated rights for admins, service identities without owners, and roles manually maintained across several directories. DORA requires — among other things, via Article 9 (Protection and Prevention) — a least-privilege model, watertight identity binding, and traceable access decisions across the entire lifecycle.
Automate the identity lifecycle
Trigger joiner, mover and leaver processes end-to-end from the authoritative HR system. Manual maintenance is the most common cause of orphaned accounts.
Separate privileged access
Route administrative sessions through dedicated bastions or access bridges — no direct access from standard workstations to productive core systems.
Just-in-time entitlements
Time-limit elevated rights and tie them to tickets or change records. Permanent admin roles are hard to justify in a DORA audit.
MFA throughout
Design multi-factor authentication to be phishing-resistant (FIDO2/passkeys, smart cards) — especially for admins, remote access and third parties.
In many institutions, historically grown shared accounts with high privileges exist, without a clear owner and without a current recertification. These accounts are the preferred target of ransomware operators and a near-certain DORA finding the moment auditors take samples.
Recertification: A Process, Not a Box-Ticking Exercise
Recertifications are established in most institutions — but not infrequently as an annual mass sign-off by overburdened managers. DORA and the associated Regulatory Technical Standards, however, demand risk-based, auditable decisions, demonstrably linked to the sensitivity of the application.
Sequence of a robust recertification
- 1Classify applications by protection need and criticality (e.g. following BAIT/MaRisk logic).
- 2Set the frequency: highly critical systems quarterly, standard applications semi-annually, mass data at least annually.
- 3Name decision-makers unambiguously — the business owner, not IT operations.
- 4Launch the campaign with context: which role, which activity in the last 90 days, which segregation-critical combination?
- 5Implement revocations or adjustments immediately at the technical level — no "accepted" without a ticket-backed consequence.
- 6Store results signed and retain them for audit for at least the retention period required by regulation.
What matters is the chain of consequence: whoever revokes a right must be able to verify whether the change has actually taken effect in Active Directory, Entra ID, databases and SaaS platforms. Without this closing loop, certification remains paper.
Log Depth: What Auditors and Forensic Analysts Actually Expect
DORA requires the detection of anomalous activity and the forensic analysability of incidents. Pure logon logs are not sufficient for this. What is examined is whether the log chain — from authentication, through the exercise of rights, to data manipulation — can be reconstructed and whether the logs are stored in a tamper-resistant manner.
| Area | Often present | DORA expectation |
|---|---|---|
| Authentication | Login events (success/failure) | + MFA factor, device and context data, risk score |
| Privileged sessions | Sudo/RunAs events | Full session recording, command logs, four-eyes approval |
| Data access | Aggregated read counters | Object-level auditing, bulk exports alerted, DLP correlation |
| Retention | 30–90 days online | Multi-year WORM archiving, hash chain, separate storage tier |
A pragmatic minimal configuration for Windows servers, which passes muster in most DORA audits, looks roughly like this:
# Cleanly capture privileged actions & logon sessions
auditpol /set /subcategory:"Sensitive Privilege Use" /success:enable /failure:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
auditpol /set /subcategory:"Authentication Policy Change" /success:enable /failure:enable
# Enable command line in 4688 events
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" \
/v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /fTreat the central SIEM/logging as a critical system in its own right, with its own contingency plan. Anyone who has no logs during an incident cannot report it either — and DORA incident reports are time-bound.
Third-Party Management: Identity Does Not End at the Corporate Boundary
Chapter V of the regulation — and in particular Articles 28 et seq. — turns the management of ICT third parties into a standalone mandatory programme. In practice this means: every external provider that accesses data or systems must be cleanly modelled in the IAM world — with its own identity, clear entitlement boundaries and monitored sessions.
External consultants or maintenance teams often work with shared VPN accounts, shared admin passwords or unmoderated RDP jump servers. In an incident, it is impossible to trace who did what — a finding that is not only DORA-relevant but also raises civil liability questions.
The sensible approach is a clear architecture that isolates external identities both technically and organisationally, without slowing down day-to-day operations:
Dedicated identities
Externals receive personalised accounts with a clearly distinguishable marker, tied to a contractually named owner.
Time windows & tickets
Access only within approved change/maintenance windows; automatic deactivation via the IAM workflow once the window closes.
Session brokering
Privileged activities exclusively via an access bridge with recording, instead of direct RDP/SSH into the network.
Register & reporting
Complete representation in the DORA third-party register including criticality classification and concentration analyses.
These measures bring a twofold benefit: they meet DORA's requirements for third-party management and, at the same time, close the attack path that has been repeatedly exploited in the major supply chain incidents of recent years.
What to Do Now: From Finding to Robust Resilience
Institutions that have so far ticked DORA off formally should use the time before the first in-depth audit to harden access security in substance. The pragmatic path consists of three phases — each of which delivers auditable value and immediately reduces real risk.
Roadmap in three phases
- 1Stocktake (4–8 weeks): inventory identities, privileged accounts, external access and critical data paths; document gaps against DORA Art. 9 and Art. 28.
- 2Quick wins (2–4 months): enforce MFA for all privileged accounts, dissolve shared accounts, harmonise the audit policy, channel third parties through an access bridge.
- 3Structural hardening (6–12 months): fully automate the identity lifecycle, establish just-in-time entitlements, put SIEM use cases for DORA incident reporting to the competent EU authority into production.
An audit is rarely passed on the level of detail of a policy, but on the question: Can the institution reconstruct the actual course of an incident within hours — including all identities and external suppliers involved? Anyone who can credibly answer this question with “yes” has grasped the core of DORA.
We support financial institutions and their service providers on exactly this journey — with a focus on access security, logging and third-party management. Further information can be found in our DORA consulting offering.