Reviews Security Unified Communications

Digital Operational Resilience Act (DORA) Explained 2026

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.

Key Takeaways at a Glance

Question	Direct answer
What DORA is?	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 it entered into force and became applicable?	Entered into force 16 January 2023, fully applicable 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. ICT third-party service relationships are governed through separate DORA third-party risk requirements
Five core areas commonly used to summarize DORA	ICT risk management, ICT incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing arrangements
Current implementation and oversight status	DORA has applied since 17 January 2025. The ESAs published the first list of designated Critical ICT Third-Party Providers on 18 November 2025 and the oversight framework is operational
Why communications infrastructure matters here?	Video conferencing and messaging platforms should be included in DORA scoping when they are used as ICT services by a financial entity. Enhanced requirements apply where an ICT service supports a critical or important function

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 1.

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.

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 (TLPT) 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

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 are set by Commission Implementing Regulation (EU) 2024/2956 and 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 regulation, 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.

Insight 2.

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 the concentration and systemic-dependency considerations assessed by the ESAs, but designation is not based on market success alone.

Self-hosting can reduce dependence on vendor-operated shared cloud infrastructure and therefore reduce one form of concentration risk. It does not automatically eliminate ICT third-party risk: software licensing, support, updates, maintenance, integrations, and other contracted services may still create relevant third-party dependencies that need to be assessed under DORA.

DORA in 2026: Implementation and Oversight

DORA has been applicable since 17 January 2025. By 2026, 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 ESAs have stated that oversight examinations and related activities will follow under the Lead Overseer framework.

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.

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 3.

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.

Self-hosting can reduce exposure to shared-cloud concentration and give the institution more control over hosting and data location. It does not by itself remove software-vendor dependencies or DORA obligations associated with contracted ICT services. The relevant risk posture should therefore be assessed from the actual architecture, contracts, support model, integrations, and functions supported.

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 (Digital Operational Resilience Act) Regulation?

DORA (Digital Operational Resilience Act), Regulation (EU) 2022/2554, establishes EU-wide digital operational resilience requirements for financial entities. It has applied since 17 January 2025 and covers ICT risk management, major ICT-related incident reporting, resilience testing, ICT third-party risk management, and voluntary information sharing. Communication platforms may fall within these processes depending on how they are used and whether they are supplied as ICT services.

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 under the framework established by DORA, while the ESAs operate the oversight framework for designated Critical ICT Third-Party Providers. The first CTPP list was published on 18 November 2025.

What distinguishes DORA from previous regulatory initiatives?

DORA gives the management body responsibility for the financial entity’s ICT risk-management framework and introduces a Union-wide oversight framework for ICT third-party service providers designated as critical. A self-hosted architecture can reduce dependence on vendor-operated cloud infrastructure, but it does not automatically remove software-vendor or other ICT third-party relationships.

Why does secure communication infrastructure matter under DORA?

Article 14 requires financial entities to maintain crisis communication plans for major ICT-related incidents or vulnerabilities. Communication platforms used for incident response or critical or important functions should therefore be included in relevant ICT risk, continuity, and testing decisions. A platform capable of operating without a persistent internet connection can support architectures designed to maintain internal communications during loss of public connectivity.

Why is it important that DORA is a regulation rather than a directive?

Because DORA is an EU regulation, its core requirements apply directly without national transposition. Supervision and penalties can still involve national competent authorities and national legal frameworks, so implementation and enforcement should be assessed in the relevant jurisdiction.

Which entities does DORA cover?

DORA covers the financial entities listed in Article 2, including credit institutions, insurance and reinsurance undertakings, investment firms, payment institutions, electronic money institutions, and certain crypto-asset market participants. Communication platforms used by those entities should be assessed according to their role in the ICT environment and any relevant ICT-service contractual arrangement.

Does DORA extend oversight to third-party ICT service providers?

Yes. DORA establishes an oversight framework for ICT third-party service providers designated as critical under Article 31. A provider of communication or collaboration services could fall within that framework if it meets the designation criteria. Self-hosting can reduce reliance on shared vendor-operated infrastructure, but contracted software, support, maintenance, updates, or integrations may still constitute relevant ICT third-party dependencies.

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

The Register of Information is the structured record financial entities maintain for contractual arrangements on the use of ICT services provided by ICT third-party service providers. A video conferencing or messaging service can belong in the register when it is obtained through such an arrangement. Whether the service supports a critical or important function affects additional DORA requirements. An on-premises deployment should be assessed based on the actual licensing, support, maintenance, update, integration, and hosting arrangements rather than assumed to be outside the register.

What happens if a communications vendor is designated a Critical ICT Third-Party Provider?

A vendor designated as a Critical ICT Third-Party Provider becomes subject to the DORA oversight framework led by the relevant European Supervisory Authority, including examinations, information requests, recommendations, and follow-up. A self-hosted architecture can reduce dependence on a shared vendor-operated cloud service, but any remaining contracted ICT services should still be included in the institution’s third-party risk assessment.

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.

Connect with Diana on Facebook