Quick answer: DORA (Regulation (EU) 2022/2554, in application since 17 January 2025) requires EU financial entities to keep a register of information covering every ICT third-party provider they rely on, and the provider that delivers your payment OTP, strong customer authentication (SCA) challenges, and fraud alerts is a row in that register, not a footnote to it. By 2026 supervisory attention has moved from whether registers exist to whether they are complete down the subcontractor chain, which is why query volume around register-of-information deadlines keeps climbing among banks, payment institutions, and e-money firms. This explainer compresses DORA's ICT third-party risk scope into one page, shows where a communications provider lands in a bank's register, lists the evidence artefacts a procurement team should demand or assemble, and closes with a 12-month preparation timeline. It is an industry explainer, not a product announcement: every control referenced below is tenant-owned, and the criticality judgment it all serves is yours, made to your regulator.
1) DORA scope in one page
Three obligations do most of the work for a financial firm that buys communications infrastructure:
- ICT third-party dependency (Articles 28-29). Firms remain fully responsible for what their ICT third-party providers do, and must manage that risk proportionately: know the provider, know the data locations, know the subcontractor chain, and hold contractual rights that match, covering audit access, security obligations, and termination.
- Register of information (Article 28(3) and the implementing standards). Every contractual arrangement with an ICT third-party provider, and the subcontractors behind it, is documented in a register the firm maintains and reports to its competent authority. The supervisors aggregate these registers to see which providers sit underneath the whole sector.
- Exit strategies (Article 30). For ICT services supporting critical or important functions, the firm needs a documented, tested exit plan: what happens at termination, how data and configuration extract, who supports the transition, and how long that support lasts. An untested exit plan reads as no exit plan.
The through-line is that DORA does not regulate your provider directly in the first instance. It regulates your management of the dependency, and the register is the artefact that proves the management is real.
2) Where a communications provider lands in a bank's register
Payment messaging is not a marketing line item. Payment OTP and SCA challenge messages are part of the authentication chain for transactional banking; fraud alerts are part of fraud operations; servicing and outage notifications are part of customer communication for regulated products. When the firm identifies those functions in its own criticality assessment, the provider that carries the messages enters the register as an ICT third-party provider supporting functions the firm has already called critical or important.
The register row then asks for more than a company name and a contract reference. It reaches into:
- The service description. Which functions the provider supports: OTP delivery, SCA challenges, fraud alerting, servicing traffic, and the channels used for each.
- Data location. Where message content, metadata, and contact data are processed and stored. This is the row your configured data-residency posture answers.
- The subcontractor chain. Terminating carriers, number providers, and infrastructure operators behind the platform, and the ICT service each one supplies. A register is only as complete as this chain.
- Substitutability and exit. Whether the service can be replaced, how quickly, and what extraction looks like at termination.
A useful scoping note: the same provider relationship can produce more than one row if it supports more than one function, and shared services (a single platform carrying both payment OTP and marketing traffic) still enter the register through their most sensitive use.
3) Evidence artefacts to demand and assemble
Before signature, and again at each renewal, four artefacts turn the register row from an assertion into evidence:
- The subcontractor and subprocessor list. The register wants the names of subcontractors and the ICT service each supplies, so a provider that maintains a published subprocessor inventory with change notification hands you a register-ready input instead of a questionnaire round-trip. Devotel Orbit publishes exactly this on its subprocessors page, with a subscription for changes, and the same artefact is what your own Art. 28 records need from any provider in the chain.
- Audit evidence export. DORA sits on top of the same evidence your GDPR and payment-scheme reviewers ask for: processing records, subprocessor contracts, retention posture, incident history. The GDPR audit evidence checklist lists the artefacts a reviewer actually requests and where each lives, and the compliance bundles hub covers assembling them into a single exportable pack. A provider whose evidence arrives as a maintained export, rather than a bespoke email attachment per audit, is a provider whose register row stays current.
- Data residency posture. The register records where data is processed, so residency must be a posture you configure and can state, not a default you discover. Demand a provider where the processing region is a tenant setting you control, and write the configured posture into the register row verbatim.
- Termination and exit extraction. Article 30 exit strategies want the practical path, not the clause number: number portability through standard porting processes so sender identities and MSISDN ranges follow you, extraction of message history and configuration through export interfaces, a contractual transition-assistance period after termination, and a tested run of the extraction before you need it for real.
The pattern across all four is the same division of responsibility as the rest of Orbit's compliance lane: the platform maintains the artefact, and the posture it records is tenant-owned. Your residency setting, your retention window, your termination plan. The provider's job is to make each one documentable.
4) A 12-month preparation timeline
| Window | Work | Output |
|---|---|---|
| Months 1-2 | Inventory functions and providers, including communications; draft the register rows for each arrangement | Function-to-provider map; register draft |
| Months 3-4 | Gap-analyse contracts against Articles 28-30: audit rights, subcontractor approval, termination, transition assistance | Redlines or renewal plan per provider |
| Months 5-6 | Collect the subcontractor list and audit evidence exports; confirm and record the data-residency posture | Evidence file per provider; residency statement |
| Months 7-8 | Write exit strategies for critical or important functions; plan the porting and extraction test | Exit plan per function, with owner and trigger |
| Months 9-10 | Dry-run the register submission end to end; verify the subcontractor chain is complete to the terminating carrier | Dry-run register with gaps closed |
| Months 11-12 | Submit or update the register with the competent authority; fold the register into the annual review cadence | Submitted register; recurring review date |
The timeline assumes the register already exists in some form, which for most firms it does since DORA entered application in January 2025. The work above is what turns a first-pass register into one that survives supervisory examination: complete subcontractor chains, evidenced rather than asserted rows, and an exit strategy someone has actually rehearsed.
5) Criticality is your regulator-facing judgment
One boundary matters more than any checklist row: whether a function is critical or important, and therefore which providers sit in the register's most examined tier, is the firm's own assessment, made against its competent authority's expectations and defended to that authority. No vendor, including us, can designate criticality for you, and a provider that offers to has misunderstood the regulation. The ESAs' separate designation of critical ICT third-party providers is a different instrument aimed at the providers themselves and does not substitute for your assessment. Nothing in this article is legal or regulatory advice; confirm the current position of the Level 1 text, the implementing standards, and your national competent authority's expectations before you rely on a row of it for a submission.
Frequently asked questions
Is our OTP messaging provider automatically "critical" under DORA?
Not automatically, and not by anyone else's say-so. The firm assesses whether the function the provider supports is critical or important for its own operations, and the ESAs' critical-ICT-provider designation process runs separately at sector level. In practice, an authentication chain that stands between a customer and a payment instruction tends to assess as critical or important at most firms, which is exactly why the messaging provider's register row gets examined.
What goes into the register row for a communications provider?
The arrangement's identifying details, the function supported, data locations, the subcontractor chain with the ICT service each subcontractor supplies, and the exit-strategy reference. The four artefacts in section 3 are the inputs: subprocessor list, evidence export, residency posture, and termination plan.
Does DORA change how OTP and fraud-alert messages are sent?
No. DORA governs how the dependency is managed, documented, and made exitable, not the transport path. Messages flow exactly as they did the day before application; what changes is the register row, the contract, and the exit plan behind them. That is also why this post is an explainer rather than an announcement: the controls it points to are tenant-owned configuration and documentation, not a platform change.
The takeaway
DORA's register of information converts a bank's ICT dependencies from a contract folder into a supervised artefact, and the provider behind payment OTP, SCA challenges, and fraud alerts is one of the first rows an examiner will look for. Scope the regulation in three obligations, place the communications provider honestly in the register, demand the subcontractor list, evidence export, residency posture, and exit path before signature, and rehearse the extraction once before you need it. Firms that do this treat the register as an annual review; firms that do not treat it as a surprise.
For the vertical context, see our financial services messaging page. For the supplier-side economics that usually trigger this review, see the CPaaS vendor consolidation business case.