If your bank, insurer, or investment firm uses video conferencing to talk to clients, colleagues, or regulators, that tool is an ICT service under the Digital Operational Resilience Act, and it falls under the same third-party risk regime as the rest of your technology estate. DORA doesn't name conferencing specifically; it regulates by function, not by product category, and a live video channel that supports a critical or important business service falls squarely inside its scope. This is not an academic question: it determines whose contracts need rewriting, whose register entries need updating, and whose incident-response processes need testing before the next supervisory review. This article sets out what that means in practice, article by article, and includes a vendor-neutral checklist for testing whether your own conferencing tool is ready.
This article is general information, not legal advice, so make sure to confirm specific obligations with your legal or compliance advisers.
Table of contents
The Digital Operational Resilience Act (DORA) is Regulation (EU) 2022/2554, which entered into application on 17 January 2025 across the EU. Unlike a directive, it is a regulation: it applies directly in every member state without national transposition, which is one reason it has moved so quickly from legal text to audit checklist.
DORA's obligations sit on five pillars: ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk management, and information-sharing arrangements. It applies to a wide range of financial entities, such as banks, insurers, investment firms, payment and e-money institutions, and, notably, crypto-asset and crowdfunding providers that earlier EU financial rules didn't reach.
It also applies indirectly to the ICT vendors those entities rely on. Chapter V requires financial entities to manage their third-party technology relationships as part of their own regulatory obligation, not as something they can delegate away.
A video conferencing platform used for client onboarding calls, board meetings, trading desk communication, or regulatory interviews is, in DORA's language, an ICT service, and the company supplying it is a DORA ICT third-party service provider the moment a regulated financial entity relies on it.
The baseline register and contract obligations apply to any ICT third-party arrangement, whatever it supports. Whether the reinforced Article 30(3) clauses apply on top of them depends on whether the service supports a 'critical or important function'. That is not a loose, client-facing-equals-critical test. DORA Article 3(22) defines it as a function whose disruption would materially impair the entity's financial performance, or the soundness or continuity of its services, or its continuing compliance with its authorisation conditions, and it's the financial entity's own documented business-impact assessment under Article 8 that decides it, not an industry-wide default. A trading-desk line or a regulated video-KYC onboarding flow is a strong candidate for that label. A routine client call or a board meeting is a weaker one, and needs an actual assessment against your own business-impact criteria rather than an assumption either way. Size and brand recognition are not the test, regardless of whether the vendor itself is a bank, a cloud provider, or a specialist video API. Functional dependency, assessed and documented, is.
Most conferencing vendors will sit under the ordinary third-party risk framework rather than the enhanced oversight regime. That narrower, EU-level designation is made jointly by the European Supervisory Authorities under Article 31, based on four criteria: the systemic impact of the provider's potential failure, the systemic importance of the financial entities that depend on it, the extent of that reliance across the sector, and the substitutability of its services. The ESAs published their first designated list in November 2025, dominated by hyperscale cloud and core infrastructure providers rather than individual conferencing vendors.
That said, a video conferencing platform embedded deeply enough into critical functions across many institutions isn't automatically exempt from future consideration. The Article 31 criteria above, not a vendor's own marketing, are what determine it, and the assessment gets documented in your Register of Information, the inventory of ICT third-party arrangements every financial entity has to maintain, described in more detail below.
Video banking, meaning identity verification calls, advisory sessions, and remote onboarding, raises a specific question: who carries the DORA obligation when a bank embeds a third-party conferencing API into its own app? The answer is the financial entity itself. DORA places the third-party risk management duty on the regulated firm, not on the underlying technology vendor, so a bank cannot outsource its compliance obligation simply by outsourcing the infrastructure.
In practice, this means the bank's compliance and procurement teams need visibility into the conferencing vendor's sub-processors, data locations, and incident-handling processes, even where the vendor's brand never appears to the end customer. This obligation sits with the deploying institution, which is exactly why the underlying vendor's contractual terms, documentation, and transparency matter as much as its technical feature set.
DORA is an EU regulation and doesn't bind UK-only firms directly. The UK has its own parallel framework: the FCA and PRA operational resilience rules, in force since 2022, requiring firms to map important business services, set impact tolerances, and test against severe-but-plausible scenarios. Alongside that sits the Bank of England's own Critical Third Parties regime, but like the EU's CTPP list, this is a narrow, small-population designation: HM Treasury names a small number of systemically important technology providers as Critical Third Parties, on regulator recommendation, and it isn't a regime a video conferencing vendor would realistically fall under.
So DORA applies to the UK not automatically, but often in practice. A UK-headquartered firm with an EU-authorised subsidiary, EU branch, or EU clients has a DORA-obligated entity somewhere in its structure, regardless of where the parent is based. UK firms providing ICT services to EU financial entities can also find DORA's contractual requirements arriving via their EU customers' Article 30 clauses, even without being directly supervised themselves.
Once a conferencing tool is logged as an ICT dependency, several requirements follow directly from the text: contract terms, the register entry itself, incident reporting, resilience testing, data residency, and how DORA interacts with the other rules that might also apply.
Article 30 sets out two tiers of mandatory contract clauses. Every ICT contract needs a baseline set, regardless of how critical the service is:
Where the service supports a critical or important function (client-facing video banking often does), the contract needs a reinforced set on top of that:
A conferencing vendor that cannot commit to audit rights or a genuine exit plan is not simply inconvenient to work with. It is a contract that cannot be made compliant as written, however polished the rest of the service looks. In practice, that audit right is rarely exercised as a full onsite audit every year: firms typically rely on the vendor's control documentation, an independent certification, or a shared audit, with a full audit held in reserve for cause. But the contractual right itself still has to be unrestricted, on paper, regardless of how often it's actually used.
Article 28 requires financial entities to maintain a continuously updated Register of Information covering every ICT third-party contract, submitted at least annually to the competent authority in a harmonised format. A video conferencing tool used for anything client-facing or business-critical needs its own entry: who the provider is, what function it supports, where data is processed, and how the arrangement was assessed for concentration risk, the danger of leaning too heavily on one provider. This isn't paperwork the vendor can complete on the firm's behalf, but a vendor that clearly documents its own sub-processors, hosting locations, and service scope makes the exercise considerably faster for the compliance team populating the register.
If a video conferencing tool suffers a major outage or a data breach, the financial entity's own DORA incident reporting clock starts, not the vendor's. Once an incident is classified as major, the firm has to send an initial notification within 4 hours of that classification and no later than 24 hours from first becoming aware of it, an intermediate report within 72 hours of that initial notification, and a final report within one month of the intermediate report. Meeting those deadlines depends entirely on the vendor: a firm cannot classify or describe an incident it doesn't yet understand, which is why Article 30's incident-assistance clause, a baseline requirement in every ICT contract, matters in practice as much as in theory. The vendor worth choosing is one whose status page, support escalation path, and incident communications are fast and specific enough to feed a 4-hour clock, not one that only confirms an outage once it has already been resolved.
DORA requires financial entities, other than microenterprises, to run a structured testing programme under Articles 24 to 27, such as vulnerability scans and scenario-based tests, with periodic threat-led penetration testing required at least every three years for entities identified by their competent authority. These obligations also apply proportionately: Article 4's general principle of proportionality runs through this and the rest of DORA's risk-management chapters, scaling what's expected to a firm's size, risk profile, and the nature of its activities.
A conferencing tool supporting a critical function should be included in that programme: can the firm actually fail over, recover, or route around the tool if it goes down mid-trading-day or mid-onboarding? Article 29 separately requires firms to assess concentration risk: the danger of depending on a single provider, or a single provider's single region, for a service with no readily available substitute. Standards-based media transport, protocols like WebRTC and SRTP, makes that concentration-risk question easier to answer, because the calls themselves aren't locked into one vendor's proprietary format. But a real exit plan has to go further than the media protocol: it also means being able to export your data (recordings, transcripts, summaries) and rebuild your integration (webhooks, room configuration, SDK code) against a new vendor. No protocol standard solves that part, so a genuine exit strategy has to cover both.
Client financial data discussed on a call, typed in chat, or captured in a recording is exactly the kind of data DORA's underlying ICT risk management framework expects firms to protect through appropriate encryption, access controls, and data-location transparency. For EU financial entities in particular, knowing precisely where call metadata, recordings, and transcripts are stored and processed isn't a nice-to-have. It feeds directly into the due diligence and concentration-risk assessments described above, and it's the kind of detail that gets asked for at contract renewal even when it was never queried at initial sign-up.
These regimes don't compete; they layer, and in one case, they replace each other outright. GDPR governs how personal data on a call is processed and where it can lawfully be transferred. Accessibility rules under the European Accessibility Act (EAA) may also apply to the conferencing interface and live communication channel, depending on the service and the entity, though this is a narrower question that turns on the specific case. DORA governs whether the financial entity using the tool has adequately managed the operational risk of depending on it, from contract terms through to incident response and exit planning.
NIS2 (Directive (EU) 2022/2555) sits differently again. Financial entities that also count as essential or important entities under NIS2 might expect a fourth layer of compliance stacked on top of DORA, GDPR, and the EAA, but that's not how the two regimes interact. Article 1(2) of DORA makes it a sector-specific EU law for the purposes of NIS2's Article 4, so for in-scope financial entities, DORA displaces NIS2's cybersecurity risk-management measures (Article 21) and incident-reporting rules (Article 23), rather than adding to them. If your organisation already runs a NIS2 risk register and incident-response process, DORA takes over that ground for your financial-services entity rather than sitting alongside it.
A single conferencing vendor decision still has to satisfy a data-protection question, an operational-resilience question, and potentially an accessibility question. That's precisely why financial-services procurement of conferencing tools tends to take longer and involve more stakeholders than the equivalent decision in an unregulated sector.
Getting this right starts with the register entry and the contract, not the feature list. Run any conferencing vendor, existing or prospective, through these questions before adding them to your register.
A vendor that struggles with the audit-rights or exit-strategy questions is the one most likely to turn into a finding at your next supervisory review.
Digital Samba's video conferencing API and SDK run on EU-hosted infrastructure with clear, documented data-processing locations, which is the starting point most financial-services due diligence teams ask for first. Our standard contract covers the baseline Article 30 terms, including a clear service description, defined sub-processor arrangements, and cooperation during incident response.
Two of the reinforced Article 30(3) terms are available on request for regulated customers rather than built into our standard contract: unrestricted audit rights running to you, your appointed third party and your competent authority, and an exit strategy with a mandatory transition period. If your entity needs them, raise it during procurement rather than assuming they're already built in.
On certifications: Digital Samba runs an information security management system built around the ISO 27001:2022 framework. We don't yet hold accredited ISO 27001 certification or a completed SOC 2 Type II audit, and we're working towards that.
No vendor can hand a financial entity a finished DORA compliance certificate: the regulatory obligation sits with the regulated firm itself, not its suppliers. What we can offer is an infrastructure and contracting foundation that makes populating a Register of Information, negotiating Article 30 terms, and answering a concentration-risk question more straightforward than building on infrastructure designed primarily for consumer or SMB use.
Yes. DORA regulates by function rather than by naming product categories, so any conferencing tool a regulated firm relies on counts as an ICT service, and the baseline register and contract obligations apply to it. Whether the tougher Article 30(3) rules apply on top depends on whether the tool supports a critical or important function. That is a materiality test under Article 3(22), and your own business-impact assessment under Article 8 has to settle it. It does not follow automatically from a call being client-facing.
Yes. Any external technology vendor supplying digital or IT services to a financial entity is an ICT third-party service provider under DORA, and the financial entity has to manage that relationship under Articles 28 to 30 regardless of the vendor's size.
At minimum, a clear service description, data-location transparency, data protection and security provisions, incident assistance from the vendor, and termination rights. Where the service supports a critical or important function, the contract also needs measurable SLAs, unrestricted audit rights, tighter sub-contracting limits, participation in your threat-led penetration testing, and an exit strategy with a transition period.
A CTPP is an ICT provider designated by the European Supervisory Authorities as systemically important to the EU financial system, based on the scale of potential failure, the importance of dependent entities, sector-wide reliance, and substitutability. CTPPs face direct EU-level oversight rather than being managed only through individual client contracts.
DORA doesn't mandate EU-only hosting outright, but it requires transparency about data location as part of contractual and due-diligence obligations, and that transparency feeds directly into a firm's concentration-risk and exit-planning assessments.
The financial entity's own DORA incident-reporting obligations are triggered, not the vendor's. Once an incident is classified as major, the firm must notify its competent authority within 4 hours of that classification and no later than 24 hours from first becoming aware of the incident, follow up with an intermediate report within 72 hours of that notification, and submit a final report within one month of the intermediate report. Meeting those deadlines depends heavily on fast, accurate information from the vendor.
Not directly, unless the UK firm has an EU-authorised entity, EU branch, or EU clients. UK-only firms remain under the FCA and PRA's own operational resilience regime, though many UK firms encounter DORA indirectly through EU customers or subsidiaries.
National competent authorities supervise ordinary financial entities and their third-party arrangements. Critical ICT third-party providers face direct oversight from the European Supervisory Authorities: the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA), and the European Securities and Markets Authority (ESMA), acting through a Lead Overseer: the ESA appointed to directly supervise that provider.