DORA Article 28 explained: what it actually means for your suppliers

If you sit at the top of an FCA-regulated company and you supply services to EU-regulated financial institutions, you have started receiving supplier audit questionnaires that reference DORA Article 28. The framing is not "do you comply", it is "how do you support our compliance?" This piece explains what Article 28 actually requires, what good evidence looks like, and how to talk to your board about it without overstating exposure or under-estimating the work.

In short: Article 28 requires EU financial entities to manage the risk from their ICT third-party providers: a management-approved strategy, a register of every ICT third-party arrangement, risk-based due diligence before contracting, audit and termination rights, and tested exit plans for arrangements that support critical or important functions. Articles 29 and 30 add the assessment of concentration risk and the clauses every contract has to contain. A UK firm usually meets these rules as the supplier, when an EU financial institution passes them down through its contract and supplier audit.

What is DORA Article 28 and why is it landing on UK desks?

The Digital Operational Resilience Act (DORA) is an EU regulation that came into force on 17 January 2025. It applies directly to in-scope financial entities: banks, insurers, investment firms, payments and e-money firms, MiFID firms with EU authorisation. UK companies are not in scope of DORA from a UK regulator perspective. The FCA has its own operational resilience regime (PS21/3) which is conceptually similar but legally separate.

So why is DORA landing on UK desks? Two routes. First, if your company has a sister or parent entity inside the EU that is itself a financial entity, that entity has obligations and your services to it sit inside its compliance. Second, and more commonly, you supply an EU financial entity that is in scope, and it pushes the requirements down through supplier audits. Article 28 is the part of the regulation that makes it do this: it requires in-scope entities to manage ICT third-party risk to a specified standard, and where the service you provide is an ICT service supporting their business functions, you are the third party in question.

It is worth being precise about what does not pull you in, because the misconception is common and expensive. Clients who happen to be resident in the EU are irrelevant to DORA. An individual is not a financial entity, so a private client in Frankfurt creates no obligation, for you or for anyone. What matters is whether the counterparty is an EU-regulated institution and whether you provide it with ICT services.

The practical upshot: even though no UK regulator is asking you about DORA, your EU institutional clients are. A 200-strong wealth manager that runs a sub-advisory mandate for a German insurer, and delivers it through its own reporting portal and data feeds, is an ICT third party in that insurer's register. It can find itself answering a 60-question DORA supplier audit that materially changes how it manages contracts and incidents. The same firm, with the same technology but only private clients, would never see the questionnaire.

What does Article 28 actually require?

Article 28 is the headline ICT third-party risk article inside DORA. The obligations sit at four levels.

Governance. Companies must have a documented ICT third-party risk strategy approved by the management body. Not a slide, but a policy with version control and a sponsor. The strategy must include criteria for what makes an arrangement "critical" and what controls apply at each tier.

Register. Companies must maintain a register of all ICT third-party arrangements. The register has to capture enough detail that the competent authority could understand the dependency, the data flows, the sub-contractors, and the exit plan, without a follow-up phone call. The register is submitted to the competent authority each year, and planned arrangements supporting critical or important functions have to be notified in advance.

Lifecycle. Risk-based due diligence before contracting. Specific contractual provisions: audit rights, sub-contracting transparency, exit assistance, data location, termination triggers. Ongoing monitoring through the contract life. A documented exit plan that has been tested at least notionally.

Concentration risk. Companies must assess and manage concentration risk: the risk that too much critical capability sits with too few suppliers, or that several "different" suppliers all run on the same cloud region. The RTS guidance on this is the area most companies find hardest because the dependencies are not always visible.

If you want the regulatory text, ESMA, the EBA and EIOPA jointly published the level-two Regulatory Technical Standards in late 2024. The version that matters most to mid-market companies is the RTS on ICT third-party risk management.

Articles 28, 29 and 30: which covers what?

Supplier audits and contract negotiations tend to cite all three articles together, so it helps to know where each obligation lives:

• •Article 28, general principles. The ICT third-party risk strategy, the register of information, due diligence and risk assessment before contracting, audit rights, termination rights, and documented exit strategies.
• •Article 29, concentration risk. Assessing whether a new arrangement would leave too much depending on one provider, or on providers that are hard to replace, including the risks of long sub-contracting chains.
• •Article 30, key contractual provisions. The clauses every ICT services contract must contain, with additional ones where the service supports a critical or important function: service descriptions and levels, data location, access and recovery of data, cooperation with regulators, audit and inspection rights, notice periods and exit assistance.

The detailed requirements sit in the Regulatory Technical Standards and Implementing Technical Standards published by the European Supervisory Authorities.

Which suppliers count as critical, and how do you classify them?

The regulation does not hand you a list. The expectation is that you classify every ICT third-party arrangement against the function it supports, the data it processes, the substitutability of the supplier, and the impact on the company if the service became unavailable or compromised.

In practice, most companies we work with end up with three tiers: critical, important, and standard.

Critical is the small set, typically four to eight suppliers in a mid-market regulated company. Core platform providers (your portfolio management system, custody platform, settlement venue), your Microsoft 365 tenant if all client work runs through it, and any supplier whose failure would prevent you from delivering an important business service. Critical arrangements get the full treatment: pre-contract risk assessment, prescribed contractual terms, regular oversight, regulator notification.

Important is the middle tier, usually 15 to 30 suppliers. Things that would degrade rather than stop operations: managed security providers, email security platforms, secondary case management tools, data feeds, professional services suppliers with privileged access.

Standard covers everything else. The bar is lower but the principles still apply: you should know what they do, what data they touch, and how you would replace them.

The classification logic itself needs to be defensible. A register that says "all suppliers are critical" answers nothing. A register that says "this is critical because the service supports IBS X and there are only two providers in the UK market" is exactly the kind of evidence audits look for.

What does the register actually look like?

The DORA register is the single most useful artefact the regulation produces. Built well, it answers most supplier audit questions in one place and makes every other obligation easier.

The columns we recommend for mid-market companies: supplier legal entity name and registration; contract reference and term dates; function supported (mapped to your important business services); criticality classification and reasoning; data categories processed and jurisdictions; sub-contractors used and their data exposure; key contract terms (audit rights, exit assistance, sub-contracting controls); incident history and last security assessment date; exit plan reference; business owner; security owner; renewal calendar; last review date.

The register is meant to be operationally useful, not a drawer artefact. The companies that get most value are the ones who use it weekly: at procurement review, renewal preparation, incident scoping, board reporting. The companies that build it as a one-off compliance exercise typically find it out of date within six months and have to rebuild it before the next audit.

If you are starting from a fragmented view across procurement, InfoSec and DP, building a single canonical register is the right first move. It pays for itself the first time a client supplier audit lands.

If you would like a working register template tuned for UK companies, book a call, we share ours with prospects who are mid-DORA-readiness.

What does the board paper look like?

The mistake most companies make is presenting DORA as a project with a budget ask. The better framing is a two-page board paper that answers four questions:

What is the exposure? A short description of which client relationships pull DORA into the company, how much revenue they represent, and what the practical demands look like (supplier audits, contract changes, evidence packs).

Where are we against the standard? A traffic-light view of the four obligation levels above. Critical to be honest here: overstating readiness in a board paper means understating it to a client at the worst possible moment.

What does ‘done’ look like? A target state described in operational terms: register live and maintained, ten critical contracts updated, exit plans tested for top three suppliers, incident reporting playbook live, supplier audit response pack ready.

How long, and what's involved? A phased plan, with a six-month version that covers the highest-exposure relationships first and a 12-month version that gets the company fully aligned. We scope the work to your supplier estate and quote it fixed on a call rather than against a list price.

Boards respond well to the honest version of this paper. They respond badly to the version that frames DORA as urgent without context, or as cost-only without describing what good looks like.

What about FCA operational resilience, is this duplicated effort?

Mostly no, and where they overlap the work is mutually reinforcing.

The FCA regime (PS21/3) is about your operational resilience as a company: identifying important business services, setting impact tolerances, mapping dependencies, testing under severe-but-plausible scenarios. DORA Article 28 is about your management of third-party ICT risk. They overlap most heavily in the dependency mapping piece: your IBS mapping for the FCA needs to identify the same suppliers your DORA register lists, and the criticality classifications should align.

The companies that have already done their IBS mapping thoroughly find DORA readiness about 40% faster, because the underlying dependency graph is already in place. The companies that have been thinly evidencing both regimes find it slower: DORA forces a level of supplier register quality that retroactively exposes gaps in the IBS mapping.

There is a third regime worth mentioning briefly: the FCA’s critical third party (CTP) regime, which gives the FCA powers over the small set of third parties that matter systemically to the UK financial system. That is a regulator-to-CTP relationship: most companies do not need to do anything specific in response, but should know that HM Treasury may designate their critical cloud and platform providers as CTPs.

How long does DORA readiness actually take?

For a mid-market FCA-regulated company with limited current discipline around supplier management, a credible DORA readiness programme runs six to nine months. Three months of register-building and classification, three months of contract review and renegotiation on the critical tier, and a parallel two-month workstream on the policy framework and reporting playbook.

The variables that move you within that range: how good your current procurement records are, how many critical contracts need renegotiation, whether your important business service mapping is current, and how distracted the company is by other regulatory work in the same window.

Companies that already run their procurement off a half-decent register and have current IBS work can do meaningful DORA readiness in three months. Companies starting from very little can extend to twelve.

The work we run typically takes one of two shapes: a three-month focused readiness engagement that produces the register, the policy framework, and a roadmap for contract renegotiation; or a six-month programme that adds the contract renegotiation execution and the incident reporting playbook. We scope it to your situation and quote it fixed on a call.

If you would like to talk through where your company sits and what the first useful next step would be, book a 30-minute call. We will tell you whether your situation actually needs DORA-aligned work yet. Sometimes the answer is "not really, your clients have not asked, do not pre-emptively build it."

Further reading

• •Regulation (EU) 2022/2554 (DORA), EUR-Lex
• •PS21/3: Building operational resilience, FCA