Reviews Security Unified Communications

DORA Regulation: Requirements, Risks and Compliance

The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, establishes EU-wide requirements for the digital operational resilience of financial entities. It covers ICT risk management, major ICT-related incident reporting, resilience testing, ICT third-party risk, and voluntary information sharing, with additional oversight applying to designated critical ICT third-party service providers.

DORA has applied since 17 January 2025. As an EU regulation, it is directly applicable across Member States, while supervision and sanctions are carried out by the competent authorities identified under DORA and relevant national frameworks.

DORA places responsibility for the ICT risk-management framework on the management body of the financial entity, making digital operational resilience a governance responsibility rather than an IT-only issue.

Communication infrastructure can form part of this framework when it supports financial services, incident response, or critical or important functions.

Article 14 of DORA requires financial entities to maintain crisis communication plans for responsible disclosure of major ICT-related incidents or vulnerabilities to clients, counterparts, and the public as appropriate. Communication channels used for crisis coordination should therefore be assessed within the institution’s ICT risk and continuity planning.

DORA does not automatically classify every communication platform as critical infrastructure. The applicable controls depend on how the platform is used, whether it supports a critical or important function, and whether it is provided under a contractual arrangement with an ICT third-party service provider.

Executive Summary: DORA at a Glance

Question	Direct Answer
What is DORA?	Regulation (EU) 2022/2554, a directly applicable EU law requiring financial entities to manage ICT risk, report major ICT-related incidents, test resilience, and manage ICT third-party risk; it also establishes an oversight framework for designated critical ICT third-party service providers
When did DORA become applicable?	It entered into force on 16 January 2023 and has applied across the EU since 17 January 2025
Who does DORA apply to?	The financial entities listed in Article 2, including banks, insurers, investment firms, payment institutions, electronic money institutions, and certain crypto-asset market participants
What are the five core areas?	ICT risk management, ICT incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing arrangements
Who is accountable?	The management body remains responsible for defining, approving, overseeing, and implementing the ICT risk-management framework
Why do communication platforms matter?	Video conferencing and messaging platforms should be assessed when they are used as ICT services by a financial entity, with additional requirements applying where they support critical or important functions
Does self-hosting remove DORA third-party risk?	No. Deployment architecture can change the dependency model, but contracted software, support, maintenance, updates, and integrations can remain relevant ICT third-party dependencies

DORA Compliance Responsibilities by Role

DORA becomes easier to interpret when responsibilities are separated between governance, operational teams, and external ICT providers. Outsourcing an ICT service does not transfer the financial entity’s responsibility for managing the associated risk.

Role	Primary Responsibility	Communication Platform Relevance
Management body	Defines, approves, oversees, and remains responsible for the ICT risk-management framework	Ensures communication infrastructure is governed according to its role, risks, and criticality
ICT and security teams	Implement risk controls, monitoring, incident response, testing, recovery, and technical safeguards	Assess architecture, access controls, logs, dependencies, resilience, and recovery procedures
Procurement and legal teams	Manage contractual ICT-service requirements and exit provisions	Review hosting, support, maintenance, data locations, audit rights, service levels, and transition clauses
ICT third-party provider	Fulfils contractual obligations and provides information required by the financial entity	May provide messaging, video conferencing, maintenance, cloud hosting, support, or related ICT services
Critical ICT Third-Party Provider	Subject to the DORA oversight framework after designation	Additional ESA oversight applies at provider level

Insight 1. Outsourcing infrastructure does not outsource DORA accountability.

A financial entity can outsource hosting, messaging, conferencing, or other ICT services, but the management body’s responsibility for the ICT risk-management framework remains. Vendor selection changes how risk is managed, not who ultimately owns the governance obligation.

Understanding DORA’s Regulatory Architecture and Jurisdictional Reach

Data security

Unlike a directive, DORA does not require transposition into national law to become applicable. Its core requirements apply directly across the EU, although national competent authorities remain responsible for supervision and Member States provide the applicable national rules for penalties and remedial measures where DORA requires them.

The regulation is intended to harmonize ICT risk-management and digital operational resilience requirements across the EU financial sector.

DORA’s scope encompasses an extensive range of financial entities, including:

Credit institutions authorized under the Capital Requirements Directive
Insurance and reinsurance undertakings operating within Solvency II frameworks
Investment firms regulated by MiFID II
Payment institutions governed by PSD2
Electronic money institutions
Crypto-asset service providers and issuers of asset-referenced tokens operating under the Markets in Crypto-Assets regulation

DORA also establishes a Union-level oversight framework for ICT third-party service providers that the European Supervisory Authorities designate as critical under Article 31.

ICT third-party services used by financial entities can include:

Major cloud infrastructure providers
Managed security service organizations
Software vendors delivering core banking or trading systems
Communication and collaboration services used by financial entities, depending on the contractual arrangement and role of the service

The regulation establishes an oversight framework in which national competent authorities supervise financial entities and the European Supervisory Authorities directly oversee ICT third-party service providers designated as critical under Article 31.

Communication platform vendors serving financial entities may face contractual requirements imposed under DORA by their financial-sector customers. Vendors designated as Critical ICT Third-Party Providers are additionally subject to direct ESA oversight. The exact obligations depend on the service relationship and whether the service supports a critical or important function.

Insight 2. Productivity software can still be operationally critical.

Communication and collaboration tools should not be excluded from DORA scoping merely because they are categorized internally as productivity applications. If they are provided as ICT services under a contractual arrangement, they should be assessed within the institution’s ICT third-party risk framework.

Article 28 requires financial entities to maintain a Register of Information for contractual arrangements on the use of ICT services provided by ICT third-party service providers. Whether a communication platform supports a critical or important function affects the depth of additional contractual and risk-management requirements, but the Register is not limited only to critical services.

DORA vs. NIS2: What Is the Difference?

DORA and NIS2 both address cybersecurity and operational resilience, but they have different scopes and legal structures. Financial entities can encounter both frameworks, although DORA contains sector-specific ICT risk requirements designed specifically for the financial sector.

Area	DORA	NIS2
Primary scope	Financial entities and ICT third-party risk within the financial sector	A broader range of essential and important entities across multiple sectors
Legal instrument	EU regulation that applies directly	EU directive implemented through national legislation
Main emphasis	Digital operational resilience, ICT risk, resilience testing, incident reporting, and ICT third-party risk	Cybersecurity risk-management measures, incident reporting, governance, and supply-chain security
Third-party framework	Includes detailed contractual requirements, the Register of Information, and direct oversight of designated CTPPs	Requires appropriate supply-chain and supplier-security risk management
Resilience testing	Contains a dedicated digital operational resilience testing framework and TLPT requirements for selected entities	Requires cybersecurity risk-management measures but does not use the same DORA-specific testing structure

For financial entities, DORA acts as the more specific framework for the ICT risk areas it harmonizes. Organizations should still map their wider regulatory obligations rather than assuming that compliance with one framework automatically satisfies every requirement of the other.

Five Core Areas Commonly Used to Summarize DORA

DORA is commonly summarized through five core operational areas. This editorial structure helps explain how the regulation affects ICT governance, incident reporting, resilience testing, third-party risk, and information sharing, including the use of communication and collaboration tools.

Pillar	What It Requires?	Implications for Communication Platforms
ICT risk management	A governance framework covering identification, protection, detection, response, and recovery for ICT risk, with the management body responsible for defining, approving, overseeing, and implementing the framework	Communication platforms within scope should be assessed against the institution’s ICT risk-management framework, with controls proportionate to their role, risks, and the functions they support
ICT incident management and reporting	Classification and reporting of major ICT-related incidents according to DORA and the applicable classification criteria and reporting requirements	An outage or breach affecting a communication platform may become reportable if it meets DORA’s criteria for a major ICT-related incident; crisis communication planning should also account for loss of the primary channel
Digital operational resilience testing	A risk-based resilience testing programme; certain financial entities identified under Article 26 must perform Threat-Led Penetration Testing at least every three years, with the competent authority able to adjust the frequency	If a communication platform underlies a critical or important function, it may fall within the systems and ICT services considered for the relevant resilience testing or TLPT scope
ICT third-party risk management	A Register of Information for contractual arrangements on ICT services, baseline contractual clauses for ICT services, enhanced requirements for services supporting critical or important functions, and exit strategies where Article 28 requires them	This pillar can apply to video conferencing and messaging services when they are supplied to a financial entity as ICT services; enhanced requirements depend on the criticality of the supported function
Information sharing	Voluntary arrangements between financial entities to share cyber threat intelligence, indicators of compromise, and lessons learned from incidents	Where threat intelligence is exchanged through communication tools, the institution should apply confidentiality and access controls appropriate to the sensitivity of the information shared

What DORA Does Not Require?

DORA sets outcomes and governance requirements for digital operational resilience, but several common assumptions go beyond what the regulation actually requires.

DORA does not require every ICT system to be self-hosted. Organizations may use cloud, on-premises, or hybrid architectures provided the applicable ICT risk and third-party requirements are addressed.
DORA does not make every communication platform a critical service. Criticality depends on the role of the ICT service and the function it supports within the financial entity.
DORA does not classify every major technology vendor as a Critical ICT Third-Party Provider. CTPP status follows the formal designation process under Article 31.
DORA does not create a universal product certification called “DORA compliant.” Compliance applies to the financial entity’s governance, processes, controls, testing, contracts, and ICT-service management.
DORA does not eliminate responsibility when ICT operations are outsourced. Financial entities remain responsible for managing ICT third-party risk.

Insight 3. DORA regulates resilience outcomes and governance, not one preferred deployment architecture.

Cloud and self-hosted environments can both form part of a DORA-aligned ICT architecture. The relevant question is whether risks, dependencies, continuity, testing, contractual obligations, monitoring, and exit scenarios are understood and controlled.

DORA Requirements by Communication Platform Function

A communication platform can interact with several DORA requirements at the same time. The relevant assessment depends on how the platform is actually used inside the financial entity.

Platform Function	DORA Relevance	Practical Control to Evaluate
Internal messaging	ICT risk, incident coordination, retention, third-party risk	Access control, message retention, audit logs, identity integration
Video conferencing	Business continuity, incident response, service availability	Redundancy, media routing, fallback communication, recording governance
File exchange	Data protection, ICT risk, incident investigation	Storage location, permissions, retention, malware controls
Directory integration	Access management and operational governance	Provisioning, deprovisioning, role management, authentication dependencies
Crisis communication	Article 14 communication planning and operational continuity	Availability during incidents, alternate channels, defined escalation paths
External integrations	ICT third-party dependencies and operational risk	Dependency mapping, contractual ownership, failure scenarios, exit planning

ICT Third-Party Risk Management and the Register of Information

Third-party risk management

ICT third-party risk management is a major part of DORA. Article 28 of DORA requires financial entities to maintain a Register of Information covering contractual arrangements on the use of ICT services provided by ICT third-party service providers. The detailed templates capture information about the financial entity, provider, contractual arrangement, service, locations, and whether the supported function is critical or important.

The European Supervisory Authorities use Register of Information data as part of the designation process for Critical ICT Third-Party Providers. On 18 November 2025, the ESAs published the first list of designated CTPPs after assessing providers against the criteria in Article 31 and the related delegated framework, including systemic impact, support for critical or important functions, and substitutability.

Designated CTPPs are subject to direct oversight by a Lead Overseer within the ESA framework, including examinations, information requests, recommendations, and follow-up activities provided for by DORA.

Article 30 sets baseline contractual requirements for ICT services and additional clauses where the service supports a critical or important function, including detailed service levels, reporting obligations, security and contingency requirements, audit and access rights, and transition provisions.

Separately, Article 28 requires documented exit strategies for ICT services supporting critical or important functions so that contractual arrangements can be exited without undue disruption.

What Belongs in a DORA ICT Service Assessment?

Assessment Area	What to Record or Verify	Why It Matters
Service purpose	How the messaging or conferencing platform is used	Determines business relevance and criticality
Supported function	Whether the ICT service supports a critical or important function	Triggers additional risk, contractual, testing, and exit-planning considerations
Provider relationship	Hosting, licensing, maintenance, support, updates, managed services	Identifies the actual third-party dependency model
Data locations	Relevant processing and storage locations	Supports dependency and concentration assessment
Subcontracting	Relevant subcontractors and supply-chain dependencies	Extends the risk picture beyond the primary vendor
Exit path	Data portability, transition period, alternative system, migration dependencies	Reduces disruption if the service must be replaced

Insight 4. Critical provider status and individual service criticality are different concepts.

CTPP designation is based on DORA’s Article 31 criteria, including systemic impact, the importance of the functions supported, and substitutability. Broad use across the financial sector can therefore contribute to concentration and systemic-dependency considerations, but designation is not based on market success alone.

Separately, each financial entity must determine whether a particular ICT service supports one of its own critical or important functions. Procurement teams should not infer the importance of an internal service solely from the regulatory status or market position of its vendor.

DORA Implementation and Oversight Status

DORA has been applicable since 17 January 2025. The regulatory framework includes the operational Register of Information process, adopted technical standards and implementing acts, and an active ESA oversight framework for designated Critical ICT Third-Party Providers. The first CTPP list was published on 18 November 2025, and the oversight framework provides for examinations and related activities under the Lead Overseer structure.

For financial entities, competent authorities have the supervisory, investigatory, sanctioning, and remedial powers set out in Article 50. DORA does not establish one uniform EU-wide maximum administrative fine for financial entities; Member States provide the applicable penalty rules.

Separate periodic penalty-payment provisions apply to Critical ICT Third-Party Providers in the context of ESA oversight. Financial entities should therefore be able to evidence how ICT services are recorded, risk-assessed, contracted, tested, and monitored in accordance with the requirements applicable to the specific service and supported function.

Five Steps to DORA Compliance for Communication and Collaboration Tools

A practical review of communication and collaboration tools can follow the sequence below, while the institution’s full DORA programme should address all applicable requirements across the regulation.

Inventory every communication and collaboration tool actually in use, including tools adopted informally by individual desks or departments outside a formal procurement process, since an unlisted tool is an unlisted risk regardless of how it was acquired.
Determine how each tool is used and whether it supports a critical or important function, using the institution’s DORA classification process rather than assuming that data sensitivity alone determines criticality.
Populate the Register of Information for relevant contractual ICT-service arrangements using the required templates and data fields. Where the service supports a critical or important function, apply the additional risk-management, contractual, and exit-planning requirements.
Build and rehearse an incident response and alternate communication plan that assumes the primary communication platform itself is the thing that has failed, not just a system it happens to report on.
Include relevant communication services in resilience testing where they support the functions being tested. For entities identified under Article 26, TLPT must cover several or all critical or important functions and the relevant underlying ICT systems and services, with a baseline frequency of at least every three years that the competent authority may adjust.

Primary Communication Failure: A DORA Scenario Often Missed

Many incident-response plans assume that corporate chat, email, or conferencing will remain available during a cyber incident. DORA’s resilience logic makes that assumption worth testing.

A ransomware event, identity-provider failure, cloud outage, denial-of-service attack, network isolation event, or compromised collaboration environment can remove the exact channel the incident team planned to use.

Failure Scenario	Operational Impact	Resilience Question
Cloud collaboration outage	Incident team loses its primary chat or meeting environment	Is there an independently available fallback channel?
Identity provider failure	Users cannot authenticate to multiple dependent services	Can emergency communications operate without the failed identity path?
Public connectivity loss	External cloud tools become unavailable from affected sites	Can internal teams continue communicating inside the corporate network?
Compromised collaboration environment	Primary communication channel becomes untrusted	Is there a separate trusted environment for incident coordination?
Vendor service termination	Access or functionality may be lost during transition	Does the exit strategy include communication continuity?

Insight 5. The communication platform can be both an incident-management tool and the failed ICT service.

A DORA-oriented continuity plan should therefore test not only how teams communicate during failures elsewhere in the infrastructure, but also how they coordinate when their normal communication system is unavailable or untrusted.

How On-Premises Communication Infrastructure Can Affect DORA Risk?

On-premises deployment

A financial institution running video conferencing and messaging on TrueConf Server on infrastructure it operates directly has a different dependency model from an institution using a vendor-operated shared cloud service. This can reduce reliance on external hosting, but it does not remove the need to assess any ICT services obtained from the software vendor or other providers.

Self-hosting may simplify some data-location, hosting, and subprocessor dependencies because communication data can remain on infrastructure controlled by the institution. However, an on-premises software deployment can still involve contractual ICT services such as licensing, support, maintenance, updates, or integrations.

Those arrangements should be assessed for Register of Information and third-party risk requirements based on their actual scope. Exit-strategy obligations also depend on whether an ICT service supports a critical or important function and on the contractual relationship involved.

An on-premises deployment can give the institution direct access to its own platform logs and infrastructure during an incident, which may support investigation and continuity planning. TrueConf Server can also operate without a persistent internet connection, allowing an organization to design an internal communication path that does not depend on public internet availability.

Whether a particular incident is reportable still depends on DORA’s major-incident classification criteria.

Insight 6. Self-hosting changes concentration risk rather than eliminating third-party risk.

DORA requires financial entities to plan how they can exit ICT-service arrangements supporting critical or important functions without undue disruption. For a self-hosted deployment, the transition risk may differ from that of a vendor-operated cloud service because hosting and data custody can remain under the institution’s control.

The relevant risk posture should therefore be assessed from the actual architecture, contracts, support model, integrations, and functions supported rather than from the deployment label alone.

Public Cloud vs. Self-Hosted Communication Under DORA

Assessment Area	Vendor-Operated Cloud	Self-Hosted Communication
Hosting dependency	Core service depends on provider infrastructure	Core application can run on infrastructure controlled by the institution
Data location	Depends on provider architecture and available regions	Defined by the institution’s infrastructure design
Operational responsibility	More responsibility delegated to provider	More responsibility retained by internal IT
Incident access	Depends on provider tooling, logs, and cooperation	Direct access to locally operated infrastructure can be available
Public internet dependency	Normally required for service access	Can be reduced where the platform supports private-network operation
Third-party risk	Hosting, software, support, operations, and subprocessors may be bundled into the service	Hosting dependency can be reduced, but software, support, updates, and integrations may remain third-party services
Exit strategy	May require data export and migration away from provider infrastructure	Hosting and some data custody can remain under customer control, although software transition still requires planning

Evaluating TrueConf in a DORA-Oriented Communication Architecture

TrueConf is not a DORA compliance product, and deploying TrueConf does not make an organization DORA compliant. Its relevance comes from the architecture available to financial institutions that want messaging and video communication to operate on infrastructure they control.

Best for: financial institutions that need customer-controlled video conferencing and messaging, private-network operation, direct infrastructure administration, or an internal communication path that can continue without persistent access to a public communication cloud.

Strengths: on-premises deployment, messaging and conferencing in one system, local control over platform infrastructure, internal operation without persistent public internet connectivity, direct access to customer-operated infrastructure and logs, and integration with enterprise communication environments.

Limitations: self-hosting transfers more infrastructure responsibility to the financial institution. Capacity planning, redundancy, backup, monitoring, patch management, disaster recovery, and administrative security still need to be designed and operated correctly. Software support, licensing, updates, and integrations may also remain relevant ICT third-party relationships under DORA.

Boost your team’s productivity with TrueConf Server Free!

Dowload

Insight 7. A lower external dependency footprint can increase internal operational responsibility.

Moving communications from a provider-operated cloud to customer infrastructure changes the location of operational risk. Some external hosting dependencies may decrease, while internal requirements for patching, resilience, backup, monitoring, and recovery become more important. DORA evaluation should account for both sides of that tradeoff.

DORA Communication Platform Buyer Checklist

Is the communication service recorded in the organization’s ICT-service inventory and Register of Information where required?
Does the platform support a critical or important function?
Where are messages, files, recordings, logs, and user data processed and stored?
Which vendor, hosting, support, maintenance, update, and integration dependencies exist?
Can administrators obtain sufficient logs and evidence during an ICT incident?
Can communication continue if public internet connectivity, a cloud provider, or the primary identity system becomes unavailable?
Has the platform been included in relevant continuity and resilience testing?
Are audit, access, notification, service-level, contingency, and transition obligations addressed contractually where applicable?
Is there an alternate communication method if the primary platform itself fails?
Is there an exit strategy for relevant ICT-service arrangements supporting critical or important functions?

Conclusion: DORA and Resilient Communication Planning

DORA requires financial entities to treat ICT resilience as an ongoing governance, risk-management, testing, incident-management, and third-party-risk discipline.

Communication systems are relevant when they form part of the ICT environment used to support financial services, incident response, or critical or important functions. Their treatment under DORA depends on the role they play, the architecture in which they operate, and the contractual ICT-service relationships involved.

For financial institutions evaluating communication platforms, the practical questions are therefore whether the service can be inventoried and governed, how incidents can be investigated and communicated, how continuity is maintained, what third-party dependencies exist, and how the platform fits into the institution’s resilience-testing and exit-planning framework.

Empower your video conferencing experience with TrueConf!

Learn more

FAQ

What is the DORA regulation?

DORA, Regulation (EU) 2022/2554, establishes EU-wide digital operational resilience requirements for financial entities. It covers ICT risk management, major ICT-related incident reporting, resilience testing, ICT third-party risk management, and voluntary information sharing. TrueConf can form part of a DORA-oriented communication architecture when its messaging or conferencing services are included in the institution’s ICT governance framework.

When did DORA become applicable across the European Union?

DORA has applied across the EU since 17 January 2025. National competent authorities supervise financial entities, while the European Supervisory Authorities operate the oversight framework for designated Critical ICT Third-Party Providers. If TrueConf is used by a financial entity, its role should be assessed under the requirements relevant to the service and supported function.

How is DORA different from NIS2?

DORA is a directly applicable EU regulation focused on digital operational resilience in the financial sector, while NIS2 is a directive covering cybersecurity risk across a broader range of sectors. A financial institution using TrueConf should assess the platform against the specific ICT and communication requirements that apply under its overall regulatory framework.

Does DORA apply to messaging and video conferencing platforms?

Communication platforms can fall within DORA-related ICT risk and third-party risk processes when they are used as ICT services by a financial entity. If TrueConf supports incident response or a critical or important function, its architecture, dependencies, continuity, logs, and relevant contractual arrangements should be included in the appropriate assessment.

What is the DORA Register of Information, and can it apply to video conferencing platforms?

The Register of Information is the structured record financial entities maintain for contractual arrangements involving ICT services provided by ICT third parties. A video conferencing or messaging platform such as TrueConf can be relevant where licensing, support, maintenance, hosting, updates, or other ICT services form part of the contractual arrangement.

Does DORA require financial institutions to use self-hosted communication platforms?

No. DORA does not prescribe one mandatory deployment model for communication systems. TrueConf can be relevant where a financial institution prefers customer-controlled infrastructure, but the organization still needs to evaluate risk management, continuity, testing, operational responsibility, and third-party dependencies.

Can TrueConf make an organization DORA compliant?

No single communication product can make a financial institution DORA compliant. TrueConf can support a customer-controlled communication architecture, but DORA compliance also depends on governance, ICT risk management, incident processes, resilience testing, contracts, third-party risk management, documentation, and organizational controls.

About the Author
Diana Shtapova is a product specialist and technology writer with three years of experience in the unified communications industry. At TrueConf, she leverages her deep product expertise to create clear and practical content on video conferencing platforms, collaboration tools, and enterprise communication solutions. With a strong background in product research and user-focused content development, Diana helps professionals and businesses understand core product features, adopt new technologies, and unlock the full potential of modern collaboration software.

Connect with Diana on Facebook

Diana Shtapova Date published: 08.06.2026

Previous article Next article