What is DORA, and why does it matter for email infrastructure?
DORA (Regulation (EU) 2022/2554 — Digital Operational Resilience Act) entered enforcement on 17 January 2025 and applies to financial entities across the EU: credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers, insurance and reinsurance undertakings, and others. It mandates a uniform framework for ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. For an email infrastructure provider serving DORA-regulated entities, the most operationally relevant articles are Article 28 (ICT third-party risk management framework), Article 30 (key contractual provisions), and Article 31 (Critical ICT Third-Party Provider — CTPP — designation).
Our CTPP status.
Article 31 establishes a process for the European Supervisory Authorities (ESAs) to designate ICT third-party service providers as "Critical" based on systemic-importance criteria: substitutability, concentration risk across financial entities, severity of potential impact on continuity of services. We are not currently a CTPP and we do not anticipate designation at current scale — the threshold for CTPP designation requires significantly larger market presence than our EU financial-sector customers. Customers do not need us to be a CTPP for them to use us under DORA; Article 30 contractual provisions apply to all ICT third-party arrangements, CTPP or not.
Which Article 30 contractual provisions do you include?
Article 30(2) prescribes specific contractual provisions for ICT services supporting "critical or important functions" of a financial entity. Our standard Enterprise DPA addendum for financial-sector customers includes each: (a) complete description of all services with locations of data and operations; (b) detail of data accessed, types of data, locations of processing; (c) availability and integrity provisions including SLA; (d) access to data in case of insolvency or resolution; (e) accessibility, recovery, return of data in structured format on termination; (f) service-level descriptions with monitoring and corrective action; (g) assistance with ICT incidents at no additional cost; (h) cooperation with competent authorities including resolution authorities; (i) termination rights including assistance during transition; (j) participation in our ICT-security training (when applicable); (k) audit and inspection rights; (l) exit strategy supporting orderly transition.
Where does DORA enforcement stand in 2026?
DORA has applied since 17 January 2025, and 2026 is the year supervision turned from guidance into examination. On 18 November 2025 the three European Supervisory Authorities published the first official list of nineteen Critical ICT Third-Party Providers, naming the hyperscale cloud providers AWS, Microsoft Azure, and Google Cloud alongside platforms such as IBM, Bloomberg, the London Stock Exchange Group, Tata Consultancy Services, and Orange. Those firms now sit under direct oversight by Joint Examination Teams led by one of the ESAs. The posture for everyone else is enforcement-oriented: regulators are examining financial entities for evidence of compliance rather than accepting remediation plans, and the first Register of Information submission cycle in the first quarter of 2026 was the first hard test. The cautionary figure comes from the 2024 dry run, where only about 6.5% of nearly a thousand firms passed all of the data-quality checks, and national authorities are now cross-referencing submissions automatically, flagging providers that appear in incident histories but are absent from the register and sub-outsourcing chains claimed not to exist. We are not a Critical ICT Third-Party Provider and do not approach the designation threshold, but we are an ICT arrangement that a financial customer has to enter in its register correctly, and the value we add is supplying the exact fields so the customer's submission survives the cross-check rather than becoming a supervisory follow-up.
What is the Register of Information, and how is your data cross-checked?
Article 28(3) requires every financial entity to maintain a register of its ICT third-party arrangements and submit it annually to its national competent authority, and DORA standardized the format down to fifteen templates rendered in xBRL-CSV. The 2026 cycle covers arrangements as they stood on 31 December 2025, and the submissions face more than a hundred automated data-quality checks. What changed the stakes is that authorities are no longer reading these registers in isolation: they cross-reference them against incident-reporting history and against each other, so a provider that shows up in a breach notification but not in the register, or a sub-outsourcing chain a firm claims is empty when the provider clearly relies on subcontractors, surfaces as an inconsistency that invites a closer look. We make our entry easy to get right by exporting the specific register fields — contract type, the services provided, the categories of data, the locations of processing, the criticality classification, the term dates, and the subcontracting summary — in a form a customer can fold straight into its register. The register is meant to describe reality, and the email leg is one row in it; our job is to make that row accurate enough that it passes the quality checks rather than triggering the follow-up that an incomplete submission now reliably produces.
Critical Third-Party Provider designation, and what it means that we are not one.
Article 31 lets the ESAs designate an ICT provider as critical based on the systemic impact of its failure, the degree of financial-sector dependence on it, its substitutability, and the concentration of reliance across firms. The first nineteen designations went to the providers the sector cannot easily route around, and a non-EU provider that gets designated has to establish an EU subsidiary to be overseen. A lead overseer — the EBA, EIOPA, or ESMA — can then request information, run investigations, carry out on-site inspections under Article 35, and impose periodic penalty payments of up to 1% of average daily worldwide turnover for non-cooperation. We are nowhere near that threshold, with eleven EU financial-sector customers spread across eight member states, and we do not anticipate designation at our scale. The part that matters for a customer is the inheritance effect: a financial entity relying heavily on a designated provider has to document that dependency in its register and assess the concentration risk, and it may receive information requests from the ESAs as part of overseeing that provider. Keeping the email leg on a non-designated EU provider keeps that leg outside the CTPP oversight chain, which is one fewer dependency a financial customer has to carry into the concentration-risk analysis its supervisor will scrutinize.
Which Article 30 clauses do customers actually negotiate?
Article 30(2) prescribes the contractual provisions a financial entity must secure for ICT services supporting critical or important functions, and our Enterprise financial-sector addendum includes each of them as standard. The clauses that draw real negotiation are a predictable few. Audit and inspection rights get tightened so the financial entity and its competent authority can examine the arrangement directly rather than relying on a summary. Subcontracting controls get sharpened, often into a specific veto right over the addition of a US-headquartered sub-processor, which DORA permits and which the ESAs reinforced through the March 2025 amendments to the subcontracting technical standard. The data-access provisions for insolvency or resolution get scrutinized, because a resolution authority needs to reach the data if the financial entity fails. And the exit strategy with transition assistance is examined closely, since a clause promising orderly exit is only as good as the migration path behind it. We hold these positions in standard language rather than treating them as concessions, because a financial-sector legal team that has to redraft the basics from scratch is a procurement that runs months longer than it needs to, and the clauses DORA mandates are not the place to be creative.
Exit strategy and the tested transition plan DORA now expects.
DORA does not let an exit clause sit on paper untested. For critical or important arrangements a financial entity is expected to maintain a documented and tested transition plan, so the question a supervisor asks is not whether the contract permits exit but whether the firm has demonstrated it can actually leave. That shifts the burden onto the provider to make exit credible rather than theoretical. We support it concretely: structured data export in JSON or CSV through the portal and the API at any time, a ninety-day post-termination grace period during which access continues, and active migration assistance through the Migration Service, including validated paths back to the providers a customer might return to. The same bridge-migration discipline that brings a customer onto the platform without losing reputation works in reverse to take them off it, which is the point — an exit that would crater deliverability is not a real exit. A financial customer can therefore enter the arrangement having seen how it would leave, and document that tested transition for the register rather than promising one it has never rehearsed. The credibility of the exit is part of what a supervisor weighs when judging whether the dependency is well governed.
How does incident reporting differ under DORA versus NIS2?
DORA sets its own incident regime, and for a financial entity it governs rather than the NIS2 cascade. Articles 18 and 19 require a financial entity to classify ICT-related incidents against criteria of severity — clients affected, data losses, duration, geographic spread, economic impact — and to report a major incident to its competent authority in stages: an initial notification, an intermediate report as the picture firms up, and a final report with root cause. The timelines and the templates differ from the NIS2 24-hour early warning, and because DORA is lex specialis a financial entity follows the DORA route for the obligations the two frameworks share. Our part is to supply the technical and operational facts your team needs to classify an incident and populate each report: what happened, what data and which services were touched, the timeline, and the active mitigations. For Performance and Enterprise customers we coordinate the incident response directly, sharing a forensic timeline your analysts can lift into the regulatory report. The classification decision and the filing remain yours, because the significance threshold is judged against your client base and your function, but the facts that decision rests on come from our incident documentation rather than from guesswork under deadline pressure.
Personal liability and public disclosure raise the procurement bar.
DORA carries consequences that reach individuals and reputations, not only corporate balance sheets. Financial entities face penalties up to 10% of annual global turnover or €10 million for serious breaches, individual senior managers can be fined up to €1 million in personal liability, and non-compliance decisions can be publicly disclosed, which adds a reputational cost on top of the financial one. That combination is why financial-sector procurement of an email provider runs long and asks hard questions: the people signing off carry personal exposure, and a vague vendor answer is a risk they own individually. We meet that scrutiny with evidence rather than reassurance — the Article 30 addendum in standard form, the register-field export, the annual operational-resilience attestation describing the prior year's incidents and continuity tests, and the incident-coordination commitment. The attestation matters because it lets a financial customer show its supervisor a dated, written account of how the email dependency behaved over the year rather than a snapshot assembled the week before an audit. When the downside includes a named manager's personal liability, the provider that hands over documentation a person can stand behind is the one that clears procurement, and the provider that offers confidence without artifacts is the one that stalls in legal review.
Threat-led penetration testing against shared infrastructure.
Larger financial entities are subject to threat-led penetration testing under Articles 26 and 27, run to the TIBER-EU framework on a multi-year cycle, and that testing reaches the providers their critical functions depend on. The complication for any multi-tenant platform is that a test scoped to one customer's account inevitably touches infrastructure other customers rely on, so it cannot be allowed to run unbounded. We coordinate with the customer's testing provider — typically a firm certified under TIBER-EU or an equivalent national scheme — to scope the engagement to the account-specific surface, agree the testing windows in advance, and operate inside the authorization framework the financial entity holds from its competent authority or the relevant ESA. The controls exist so that a legitimate resilience test does not become an availability incident for unrelated customers, and so that the financial entity gets a real assessment of the parts of the platform its functions actually use. We have supported this cooperation for two financial-sector customers without disruption, which is the kind of reference a procurement team values more than a policy statement, because it shows the process has survived contact with an actual test rather than living only in a contract clause.