---
title: 5 Pillars of DORA Compliance, Penalties, and Best Practices
date: 2026-09-17T14:39:34Z
modified: 2026-09-17T14:39:35Z
permalink: "https://www.venn.com/learn/dora-compliance/"
type: knowledge
status: publish
excerpt: ""
wpid: 7790
featured_image: "https://www.venn.com/wp-content/uploads/2026/09/Dora-compliance-scaled.jpg"
parent: ""
ancestors: []
children: []
timestamp: 2026-09-17T14:39:35Z
tags:
  - Compliance Frameworks
---

## What Is the Digital Operational Resilience Act (DORA)? 

The Digital Operational Resilience Act (DORA) is a European Union regulation that applies to banks, insurance companies, crypto-asset providers, and critical third-party tech suppliers. DORA compliance requires financial entities and their technology vendors in the European Union to meet strict digital operational resilience standards.

**DORA compliance covers five core pillars:**

- **ICT risk management:** Establish governance, asset visibility, monitoring, response, recovery, and continuity controls for ICT risks.
- **ICT-related incident management and reporting:** Detect, classify, manage, and report major ICT incidents through initial, intermediate, and final reports.
- **Digital operational resilience testing:** Perform risk-based resilience testing, vulnerability assessments, and, where required, threat-led penetration testing.
- **ICT third-party risk management:** Assess, document, monitor, and contractually control ICT suppliers, subcontractors, concentration risk, and exit arrangements.
- **Information and intelligence sharing:** Participate in trusted cyber threat-sharing arrangements to strengthen prevention, detection, and response capabilities.

**Consequences for failing to meet DORA requirements include:**

- **Administrative and financial penalties:** Regulators may impose monetary penalties and other sanctions under applicable Member State law.
- **Orders to correct violations:** Authorities can require organizations to remediate deficiencies, stop non-compliant practices, and prevent recurrence.
- **Public disclosure of violations:** Competent authorities may publish final penalties, including the organization, breach, and sanction imposed.
- **Management accountability:** Management-body members or responsible individuals may face remedial measures or penalties under national law.
- **Possible criminal penalties:** Member States may establish criminal penalties for certain DORA violations.

**This is part of a series of articles about compliance frameworks**

Achieve HIPAA Compliance on Unmanaged Laptops

Learn how to keep sensitive data secure and HIPAA compliant when contractors and remote workers use personal laptops.



 





![](https://www.venn.com/wp-content/uploads/2025/09/How-to-Secure-contractor-access-on-unmanaged-endpoints.png)







## In this article:

- [What Is the Digital Operational Resilience Act (DORA)? ](#h-what-is-the-digital-operational-resilience-act-dora-nbsp)
- [When Did DORA Go Into Force? ](#h-when-did-dora-go-into-force-nbsp)
- [Who Needs to Comply With DORA? ](#h-who-needs-to-comply-with-dora-nbsp)
- [What Are the Main Pillars of DORA Compliance Requirements? ](#h-what-are-the-main-pillars-of-dora-compliance-requirements-nbsp)
- [What Happens if an Organization Does Not Comply With DORA: Enforcement and Penalties ](#h-what-happens-if-an-organization-does-not-comply-with-dora-enforcement-and-penalties-nbsp)
- [DORA Compliance Best Practices ](#h-dora-compliance-best-practices-nbsp)
- [How Venn Helps Financial Firms Meet DORA Requirements on BYOD and Unmanaged Devices](#h-how-venn-helps-financial-firms-meet-dora-requirements-on-byod-and-unmanaged-devices)



## When Did DORA Go Into Force? 

The Digital Operational Resilience Act (DORA) became applicable on January 17, 2025. From this date, financial entities and relevant ICT third-party service providers within its scope were required to comply with DORA’s operational resilience requirements.

DORA was formally adopted as Regulation (EU) 2022/2554 on December 14, 2022, and entered into force on January 16, 2023. The nearly two-year period before its application date gave organizations time to prepare for requirements covering areas such as ICT risk management, incident reporting, resilience testing, and third-party ICT risk.

Because DORA is an EU regulation, its requirements are directly applicable across EU Member States without each country needing to separately transpose the regulation into national law.

## Who Needs to Comply With DORA? 

DORA applies to a broad range of EU financial entities and, in some cases, the ICT providers that support them. Covered organizations must manage ICT risk, prepare for disruptions, test resilience, report major incidents where required, and oversee technology providers.

- **Banks and credit institutions:** Must manage ICT risks across payments, online banking, lending, transaction processing, and customer data systems, including incident response, recovery, and third-party controls.
- **Insurance and reinsurance companies:** Must protect systems used for underwriting, policy administration, claims, customer service, and reporting, with oversight from management bodies.
- **Investment firms:** Must control ICT risks affecting trading platforms, portfolio tools, market data, order management, and client services, including risks from cloud and software vendors.
- **Payment and electronic money institutions:** Must ensure resilience for payment processing, account access, authentication, and customer fund availability, including incident classification and reporting.
- **Crypto-asset service providers:** MiCA-authorized providers must manage ICT risks for platforms, wallets, transaction systems, customer data, and external technology dependencies.
- **ICT third-party service providers:** Cloud, software, hosting, data, and infrastructure providers may be subject to DORA-related oversight, especially if designated as critical ICT third-party providers.

**_Related content: Read our guide to_**[ _PCI DSS compliance_**](https://www.venn.com/wp-content/uploads/wp-mfa-exports/knowledge/pci-dss-compliance.md)**_._**

## What Are the Main Pillars of DORA Compliance Requirements? 

### 1. ICT Risk Management

DORA requires financial entities to establish and maintain a comprehensive ICT risk management framework. The framework should define how the organization identifies, protects against, detects, responds to, and recovers from ICT risks. It covers ICT systems, networks, applications, data, physical infrastructure, security controls, and dependencies on external services.

Organizations must identify and classify ICT assets and understand which systems support critical or important functions. They must continuously monitor threats, vulnerabilities, configuration changes, and other factors that could affect the availability, authenticity, integrity, or confidentiality of data and services.

Business continuity is also part of ICT risk management. Financial entities need documented response and recovery plans, backup procedures, restoration processes, and crisis communication arrangements. DORA assigns the management body responsibility for defining, approving, overseeing, and periodically reviewing the ICT risk management framework.

### 2. ICT-Related Incident Management and Reporting

Financial entities must have a documented process for detecting, recording, managing, and resolving ICT-related incidents. The process should define responsibilities, escalation procedures, communication channels, and methods for determining the cause and impact of an incident.

DORA requires organizations to classify ICT-related incidents using defined criteria. These include the number and relevance of affected clients or transactions, duration and service downtime, geographic spread, data losses, economic impact, and whether critical or important functions were affected.

Incidents classified as major must be reported to the relevant competent authority. DORA’s reporting framework includes an initial notification, an intermediate report, and a final report. Organizations must therefore have processes for collecting accurate incident information quickly while technical investigation and recovery activities are still underway.

After an incident, organizations should analyze its root cause and identify improvements to controls and recovery procedures. This makes incident management part of an ongoing resilience process rather than only an immediate response to system failures or cyberattacks.

### 3. Digital Operational Resilience Testing

DORA requires financial entities to maintain a risk-based testing program for assessing the resilience of their ICT systems. Testing helps determine whether security controls, recovery processes, and technical safeguards work as intended before a real disruption occurs.

Depending on the organization’s risk profile and applicable requirements, testing can include vulnerability assessments, open-source analyses, network security assessments, physical security reviews, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, and penetration testing. Vulnerabilities discovered through testing should be prioritized and remediated.

Certain financial entities identified by competent authorities must conduct advanced threat-led penetration testing (TLPT) at least every three years, unless the authority adjusts the frequency. TLPT uses realistic attack scenarios based on current threat intelligence and targets live production systems supporting critical or important functions.

DORA also addresses the involvement of ICT third-party providers in advanced testing when their services support functions within the test scope. This helps organizations assess resilience across the technology dependencies that actually support their operations, rather than testing only internally managed infrastructure.

### 4. ICT Third-Party Risk Management

Using an external ICT provider does not transfer responsibility for operational resilience away from the financial entity. DORA requires organizations to incorporate ICT [third-party risk](https://www.venn.com/wp-content/uploads/wp-mfa-exports/knowledge/third-party-risk-management.md) into their overall ICT risk management framework and assess relevant risks before entering into contractual arrangements.

Financial entities must maintain a register of information about contractual arrangements with ICT third-party service providers. Before contracting for services supporting critical or important functions, they must consider factors such as concentration risk, provider suitability, security requirements, subcontracting arrangements, and the ability to exit the relationship without unacceptable disruption.

Contracts must contain relevant provisions covering areas such as service descriptions, service and data locations, data protection, availability and recovery, incident assistance, cooperation with authorities, access and audit rights, and termination. Agreements supporting critical or important functions are subject to additional requirements.

DORA also establishes an EU oversight framework for ICT third-party providers designated as critical. A Lead Overseer can assess these providers’ ICT risk controls and issue recommendations where weaknesses could create risks for financial entities or the wider EU financial system.

### 5. Information and Intelligence Sharing

DORA permits financial entities to exchange cyber threat information and intelligence through trusted information-sharing arrangements. This can help organizations identify attacks and vulnerabilities that have already been observed elsewhere in the financial sector.

Shared intelligence can include indicators of compromise, attacker behavior, tactics, techniques and procedures, security alerts, vulnerabilities, and recommended defensive measures. For example, information about malicious infrastructure observed by one organization can help other participants update monitoring or blocking controls before they are targeted.

Information-sharing arrangements must protect sensitive information and operate according to rules covering confidentiality, data protection, and appropriate business conduct. Participation should focus on information that can improve organizations’ ability to prevent, detect, or respond to ICT threats.

Financial entities must notify their competent authorities when they participate in these arrangements and when their participation ends. Information sharing complements DORA’s mandatory controls by helping organizations use sector-wide threat knowledge to improve their own defenses.

## What Happens if an Organization Does Not Comply With DORA: Enforcement and Penalties 

Organizations that fail to comply with the Digital Operational Resilience Act (DORA) can face regulatory enforcement, financial penalties, corrective measures, and reputational consequences. DORA requires EU Member States to give competent authorities sufficient supervisory, investigatory, and sanctioning powers, with penalties designed to be effective, proportionate, and dissuasive.

Potential consequences include:

- **Administrative and financial penalties:** National regulators can impose monetary penalties and other measures according to the applicable Member State’s legal framework.
- **Orders to correct violations:** Regulators can require an organization to stop non-compliant practices, remediate deficiencies, and prevent the violation from recurring.
- **Public disclosure of violations:** Final administrative penalties may be published by competent authorities, including information about the organization, the nature of the breach, and the penalty imposed.
- **Management accountability:** Depending on national law, penalties and remedial measures may also apply to members of an organization’s management body or other individuals responsible for a breach.
- **Possible criminal penalties:** EU Member States may establish criminal penalties for certain DORA violations under their national laws.

For critical ICT third-party service providers, DORA also gives the Lead Overseer specific enforcement powers. Failure to comply with required measures can result in periodic penalty payments of **up to 1% of the provider’s average daily worldwide turnover** from the preceding business year, calculated for each day of non-compliance.

The exact penalty for a financial entity is therefore not a single EU-wide fixed fine. Regulators consider factors such as the severity and duration of the breach, whether it was intentional or negligent, financial strength, losses caused to third parties, cooperation with regulators, and previous violations.

## DORA Compliance Best Practices 

### Establish Clear Governance and Accountability

Define who is responsible for ICT risk across management, security, IT, compliance, procurement, and business teams. The management body should approve and oversee the ICT risk management framework and remain informed about major ICT risks, incidents, and remediation activities.

Document responsibilities and escalation paths so teams know who makes decisions during normal operations and incidents. Regular reporting should give management enough information to evaluate resilience, significant risks, third-party dependencies, and unresolved control weaknesses.

### Maintain a Complete Inventory of ICT Assets and Dependencies

Maintain an up-to-date inventory of ICT assets, including hardware, software, applications, data stores, network components, cloud resources, and relevant third-party services. Record ownership, location, purpose, and relationships between assets where practical.

Asset inventories should also show dependencies. For example, a customer-facing application may depend on an identity provider, cloud platform, database, and external API. Mapping these relationships helps teams understand how a failure in one component could affect financial services and recovery.

**_Related content: Read our article about_**[ _unified endpoint management_**](https://www.venn.com/wp-content/uploads/wp-mfa-exports/knowledge/unified-endpoint-management.md)**_._**

### Map Critical and Important Business Functions

Identify the business functions whose disruption would materially affect customers, financial performance, regulatory obligations, or the organization’s ability to provide services. Then map the people, processes, ICT assets, data, and third parties required to operate those functions.

This mapping supports several DORA activities, including risk assessments, resilience testing, business continuity planning, and third-party oversight. It also helps teams prioritize recovery efforts and security investments based on business impact rather than treating every system as equally critical.

### Continuously Assess ICT and Cybersecurity Risk

ICT risk assessments should be updated as systems, threats, vulnerabilities, and business processes change. Monitor areas such as software vulnerabilities, misconfigurations, unsupported systems, cyber threats, third-party dependencies, and changes to critical infrastructure.

Connect identified risks to specific controls, owners, remediation actions, and deadlines. Continuous monitoring can help detect changes between formal assessments, while periodic reviews determine whether existing controls remain effective and whether residual risk is acceptable.

### Enforce Strong Access Controls and Least Privilege

Limit access to ICT systems and data according to business requirements and job responsibilities. Use role-based or attribute-based controls where appropriate, apply strong authentication, and restrict privileged accounts to users who require administrative capabilities.

Access rights should be reviewed regularly and removed promptly when employees change roles or leave the organization. Privileged activity should be logged and monitored because compromised administrator accounts can give attackers broad access to systems supporting critical or important functions.

### Secure BYOD and Unmanaged Devices

Personal and [unmanaged devices](https://www.venn.com/wp-content/uploads/wp-mfa-exports/knowledge/unmanaged-devices.md) can create additional risk when they access corporate applications or sensitive financial data. Organizations should define which resources these devices can access and enforce controls based on device security, user identity, and the sensitivity of the requested resource.

Controls can include multifactor authentication, conditional access, encryption, endpoint or mobile device management, and restrictions on local data storage. High-risk or noncompliant devices can be blocked from critical applications or given limited browser-based access that reduces exposure.

### Apply Data Loss Prevention Controls to Remote Work

Remote work can move sensitive information outside networks and devices directly controlled by the organization. [Data loss prevention controls](https://www.venn.com/wp-content/uploads/wp-mfa-exports/knowledge/dlp.md) can identify and restrict activities such as copying regulated data to personal storage, uploading files to unauthorized cloud services, or sending sensitive information through unapproved channels.

Apply controls according to data classification and business context rather than blocking all transfers. Combine data loss prevention with encryption, access controls, endpoint monitoring, and audit logs. This provides visibility into how sensitive data is handled while allowing authorized remote work to continue.

## How Venn Helps Financial Firms Meet DORA Requirements on BYOD and Unmanaged Devices

DORA holds financial entities responsible for the resilience and security of the systems their people actually work on, including the personal and unmanaged laptops used by remote employees, independent advisors, and contractors. Venn’s Blue Border™ is a secure workspace for remote employees and contractors on any device, without VDI and without fully managing the endpoint. Work runs inside a firm-controlled enclave where company data and applications stay isolated from personal use on the same computer, so firms can keep client data controlled even on devices they don’t own.

**Key capabilities of Venn Blue Border™:**

- **Compliance-supporting controls on remote and BYOD devices:** Blue Border provides data isolation, DLP, and clean off-boarding controls that support SEC, FINRA, PCI DSS, and SOC 2 obligations on remote and BYOD devices.
- **Robust DLP enforcement inside the enclave:** Copy/paste, download, upload, screenshot, print, and AI use are governed inside the enclave on any device, including the personal laptops advisors and contractors already use.
- **Sanctioned application control:** Business runs inside a firm-controlled workspace using sanctioned apps, while unsanctioned tools are blocked from firm data.
- **AI governance:** IT can allow sanctioned AI tools and block the rest, so client non-public personal information doesn’t leak into unsanctioned models.
- **Native application performance:** Unlike VDI, where hosted desktops add latency to client calls, market data feeds, and heavy Excel models, applications inside Blue Border run locally at native speed.
- **Visibility without device takeover:** IT has visibility and control only inside the enclave; everything outside it stays private, an important boundary for independent advisors who aren’t employees and won’t accept full-device management.
- **No laptop shipping or VDI overhead:** Firms avoid the cost and complexity of VDI/DaaS along with the expense of purchasing, managing, and shipping company-owned computers.

See how Venn secures client data on the devices your remote advisors, analysts, and contractors already use –[ explore Venn for financial services](https://www.venn.com/wp-content/uploads/wp-mfa-exports/solution/financial-services.md).

 Securing contractors and remote employees doesn’t have to be a pain. For years, IT teams were stuck choosing between virtual desktops that are slow, complex, and expensive. Or buying, locking down, and shipping laptops across the globe. Thankfully, there’s a better way. Introducing Venn, a breakthrough in remote work security. Venn creates a secure enclave on any unmanaged PC or Mac used by contractors and remote employees. No VDI, no need to fully manage the device, and no compromise on security and compliance. Work applications run locally within the enclave, visually indicated by Venn’s blue border, protecting and isolating work from personal activity on the same computer. Both browser and installed apps run locally, natively, and securely. No hosting and no virtualization whatsoever. This approach preserves full app performance and user experience, while ensuring your organization’s DLP policies are always enforced. No file transfers, copy paste screenshots, or any other actions that could lead to data loss or compromise. Ready to see the future of remote work? Well, on behalf of all of us at Venn, we invite you to step inside the blue border. Find out more at Venn dot com.