Blog

Beyond the Buzz: What It Takes to Be DORA Compliant

How to Turn DORA From a Compliance Burden Into a Resilience Advantage

Cover image for CyberDesk blog article titled 'What It Takes to Be DORA Compliant,' highlighting how to turn DORA compliance into a resilience advantage.

Yeah, we’ve all heard of DORA by now. Yet it is more than another acronym in the alphabet soup of regulations. The Digital Operational Resilience Act (DORA) is a tectonic shift in how financial entities—and the tech ecosystem that supports them—must approach digital risk, continuity, and cybersecurity. With enforcement beginning January 17, 2025, DORA sets the tone for a new era of operational resilience in the EU’s financial sector.

But here’s what many headlines miss: DORA is not just a compliance exercise. It’s an identity, access, and risk governance challenge at its core. Security leaders should rethink traditional IAM and GRC silos, and shift toward integrated, auditable access governance frameworks that can stand up to real-time threats and regulator scrutiny.

Why DORA Matters More Than You Think

DORA applies to almost all regulated financial entities in the EU: banks, insurers, investment firms, crypto-asset providers, payment service providers, and many more. But its reach doesn’t stop there—critical ICT providers (cloud, core banking, data analytics, etc.) even outside EU will also come under the microscope. And alarmingly, 43% of UK financial firms remain unprepared even months into enforcement — a delay that leaves them at serious risk of regulatory penalties and operational exposure.

The regulation mandates that financial entities:

Implement a robust ICT risk management framework
Report major cyber incidents within tight timeframes
Conduct threat-led penetration tests
Enforce stringent third-party risk oversight
Guarantee operational continuity, even under severe digital disruptions

These aren’t tick-box tasks. They require clear visibility, centralized control, and scalable governance.

Figure 1: Entities in Scope of DORA

Not in the Financial Sector? You Might Be Obliged to NIS2

If your organization doesn’t fall under DORA, that doesn’t mean you're off the regulatory hook. The NIS2 Directive applies to a much broader range of sectors—covering critical infrastructure, digital services, healthcare, energy, public administration, and more.

💡 If you're a medium or large enterprise in any of these sectors, there’s a good chance you’re in scope for NIS2 compliance.

🔍 Want to understand what NIS2 means for your business? 👉 Check our full NIS2 guide here

Comparison table between DORA and NIS2 across categories such as Scope, Legal Hierarchy, Regulator, Approach, Incident Reporting, Third-Party Risk, and Resilience Testing. DORA focuses on financial institutions with prescriptive standards and mandatory resilience testing, while NIS2 applies broadly with a risk-based approach and general guidance.

Table 1: DORA vs. NIS2: Key Differences

Achieving and Maintaining DORA Compliance: Identity-Centric Best Practices

To comply with the Digital Operational Resilience Act (DORA) and ensure ongoing resilience, financial institutions and their ICT providers must implement a blend of technology, governance, and operational practices. Below are the essential pillars of a DORA-aligned security strategy—with a special focus on identity and access governance:

📋 1. ICT Risk Management Framework

Establish a documented, enterprise-wide risk framework that includes:

Regular risk assessments
Inventories of ICT assets
Data flow mapping and policy controls
Clear governance structures (e.g., risk committees, senior accountability)

📚 DORA Regulation - Article 5-16

🔐 2. Identity & Access Management (IAM)

Strong IAM is foundational to DORA resilience. Implement:

Lifecycle management (onboarding/offboarding, RBAC, access recertification)
Multi-Factor Authentication (MFA) and privileged access controls (e.g., PAM)
Monitoring and anomaly detection using SIEM or identity analytics
Forensic-ready logging of all access events

📚 DORA Regulation - Article 9, 10

🕵️ 3. Monitoring & Detection

DORA demands real-time awareness. Organizations must:

Detect unusual access behavior (e.g., late-night data scraping)
Generate tamper-proof logs
Be ready for regulator inquiries post-incident

📚 DORA Regulation - Article 10, 17, 20

🖥️ 4. Endpoint & Network Security

Protect the infrastructure supporting critical data with:

Endpoint detection & response (EDR), anti-malware
Firewalls, IDS/IPS, network segmentation
Patch & vulnerability management
Encryption in transit and at rest

📚 DORA Regulation - Article 10

🚨 5. Incident Response & Recovery

Prepare for the inevitable with:

Incident playbooks, reporting workflows, CSIRT setup
Tabletop drills and simulations
Secure, tested backups and failover plans
Business continuity integration beyond IT

📚 DORA Regulation - Article 11-13, 17-20

🎯 6. Threat-Led Testing

DORA expects continuous testing—including:

Regular pen testing
Threat-Led Penetration Testing (TLPT) for significant entities (e.g., TIBER-based red teaming)
Scenario testing for large-scale outages

📚 DORA Regulation - Article 24, 25

🤝 7. Third-Party Risk Management

DORA places heavy emphasis on outsourced ICT risk:

Maintain a full vendor inventory
Enforce DORA-compliant contracts (e.g., audit rights, support, exit clauses)
Conduct ongoing due diligence, including concentration risk mitigation
Monitor service performance and incidents continuously

📚 DORA Regulation - Article 28-30

🧠 8. Governance & Training

Resilience is a leadership and cultural issue. Ensure:

Board-level involvement in ICT risk and DORA compliance
Cybersecurity awareness programs at all staff levels
A security-first culture embedded into day-to-day operations

📚 DORA Regulation - Article 5, 13, 15, 16

🌐 9. Threat Intelligence Sharing

While voluntary, DORA encourages participation in industry threat intelligence networks (e.g., ISACs).

Join financial-sector sharing communities
Notify regulators if participating
Handle shared intelligence responsibly

📚 DORA Regulation - Article 26

CyberDesk: Built for DORA-Grade Resilience

As a SaaS platform built for identity-centric data access governance, CyberDesk helps you align with DORA’s core operational expectations — and demonstrate real resilience under scrutiny.

Here’s how:

✅ 1. Map Data to Identities

CyberDesk auto-classifies sensitive data (e.g. customer records, transaction data) and maps access down to every user and system identity — internal or third-party.

🧠 Example: Know which service account or contractor still has access to your payments engine or client vault — and why.

🔹 Article 9 & 10: Requires clear access rights tied to roles, and controls to prevent unauthorized access.

🔹 Article 28: Mandates third-party ICT risk controls — you must track external identities accessing critical systems.

Dashboard interface from CyberDesk showing a data inventory table with metadata like provider, type, alerts, region, and data owner. It includes categorized tags such as ‘Personal’, ‘IT & Security’, ‘Health’, and ‘Financial’. Two visual overlays show data access distribution by category (Restricted, Sensitive, Internal) and a horizontal bar chart highlighting data volume by category type, emphasizing visibility and classification of sensitive information.

Figure 2: CyberDesk's Classification Engine Categorizes Your Organizations Data & Identities Based on Data Types and Sensitivity Levels

✅ 2. Access Graph = Real-Time Risk Visibility

CyberDesk’s Access Graph provides a live, visual map of how users and apps interact with sensitive data. It helps identify hidden admin paths, toxic permission combinations, and legacy access risks.

🧠 Example: Detect that a long-departed contractor still holds API-level access to production backups.

🔹 Article 9(2): Only authorized users should access ICT systems, based on role and operational need.

🔹 Article 17–20: Access logs and visibility are vital to detecting, reporting, and containing ICT-related incidents.

CyberDesk interface showing an interactive Access Graph mapping users to data stores through groups, roles, and permissions. The flow visualizes how internal users connect to data like ‘Finance_Results’ and ‘Production_Data’ with permissions such as Create, Read, Update, and Delete. Overlays highlight access categories including full admin access, delete capabilities, API tokens, and service principals, enabling visibility into over-permissioned users and high-risk access paths.

Figure 3: CyberDesk's Access Graph Provides Identity & Data Level Visibility

✅ 3. Prevent Over-Permissioning

Set and monitor for least privilege. With automated alerts when access exceeds policy. You can block high-risk access in real time or flag it for review.

🧠 Example: A junior staff member suddenly gains access to regulatory filing databases? That’s flagged before it becomes an incident.

🔹 Article 10: Requires real-time monitoring and anomaly detection.

🔹 Annex III (RTS): Calls for mechanisms to detect abnormal or excessive permissions and risky privilege escalations.

CyberDesk dashboard showing a list of open security alerts with severity levels labeled Critical, High, and Medium. Alerts include issues such as admin access, stale service principals, GDPR exposure, and MFA inactivity. A sidebar titled ‘Top Identities at Risk’ highlights users and service accounts with elevated risk levels, including a critical-level AWS service account and external/internal users flagged as High or Medium severity. A 'Create New Policy' button is visible in the interface.

Figure 4: CyberDesk's Alerts Dashboard Facilitates Breach Risk Mitigation

✅ 4. Automated Access Reviews

Run quarterly (or ad hoc) access reviews with full audit trails. Managers get intelligent prompts, and reviews are stored securely for inspection.

🧠 Example: Auto-trigger a review for all admin-level cloud accounts every 30 days — no spreadsheets required.

🔹 Article 9(3): Requires regular review of access rights, especially after offboarding, role changes, or contract terminations.

🔹 Article 10: Logging, traceability, and documentation must support ICT risk governance and audits.

CyberDesk interface displaying a privileged user access review dashboard. A selected user’s access to multiple data stores is shown, categorized by sensitivity, data type (e.g. Personal, Financial, IT & Security), and permissions (A, C, R, U, D). Action icons indicate approval or revocation status. A side panel shows ‘Access Reviews’ with 19 total, divided into pending and completed. The interface includes an 'Executive Report' download option and a completion status bar indicating 12% progress.

Figure 5: CyberDesk's Access Review Frees You Up From Time-Consuming Manual Processes and Helps You Stay Compliant

Let's Talk Resilience

Ready to assess your access governance maturity and prepare for DORA? Schedule a free demo session with our experts.

Want to See CyberDesk in Action?

Learn how CyberDesk can help you to adaptively control who can take what actions on what data.

Founders

Dr. Tobias Lieberum & Prabhakar Mishra

Year of foundation

2022

Headquarters

Munich, Germany

About CyberDesk

Founded in 2022 and based in Munich, Germany, CyberDesk is led by Dr. Tobias Lieberum and Prabhakar Mishra. In their previous careers in sensitive environments in banking and consulting, the founders firsthand witnessed the challenges of securing data access in the cloud. In lack of a satisfactory solution, they decided to solve this global threat themselves.