DORA Article 28 in plain English: what it actually means for your suppliers

If you sit at the top of an FCA-regulated company and your clients have any EU footprint, 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.

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 entity has obligations and your services to it are in scope of their compliance. Second, and more commonly, your EU clients are themselves in scope and are pushing the requirements down through supplier audits. Article 28 is the part of the regulation that makes them do this: it requires them to manage ICT third-party risk to a specified standard, and you are the third party.

The practical upshot: even though no UK regulator is asking you about DORA, your largest EU clients are. A 200-strong wealth manager with a single Frankfurt-based UHNW client can find itself answering a 60-question DORA supplier audit that materially changes how it manages contracts and incidents.

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. Critical arrangements must be reported to the regulator on a defined schedule.

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.

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 their critical cloud and platform providers will be 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."