DORA and the ICT third-party problem

What DORA actually requires

The Digital Operational Resilience Act (Regulation EU 2022/2554) covers financial entities in the EU and, in practice, a great many UK firms who serve EU clients or sit in an EU group. Chapter V governs ICT third-party risk.

Article 28(1)

Manage ICT third-party risk as an integral part of your risk framework, proportionate to the criticality of the service. Not as a procurement formality.

Article 28(3)

Maintain a register of information on every contractual arrangement, distinguishing those supporting critical or important functions. Regulators can ask for it.

Article 28(4)

Before contracting, assess whether the arrangement covers a critical function, whether supervisory conditions are met, and identify conflicts of interest.

Article 28(7)

Have an exit strategy for every critical arrangement, and be able to exit without disrupting the business or breaching regulatory requirements.

Article 29

Assess concentration risk, including subcontracting chains. Not just your vendor, but who your vendor depends on.

Article 30

Specific contractual provisions: service descriptions, data locations, access and audit rights, incident assistance, termination rights.

Where point-in-time assessment fails it

Article 28(1) says third-party risk is managed "throughout" the relationship. That single word is what breaks the annual questionnaire model.

• The register goes stale on day two. Article 28(3) wants a register of information that is current. A spreadsheet compiled at onboarding describes the vendor you signed, not the one you have.
• Subcontracting changes without telling you. Article 29 asks about concentration through the chain. Your vendor adding a sub-processor is exactly the event an annual cycle misses, and it is often visible publicly the day it happens.
• Attestations expire quietly. A SOC 2 report covers a period that ended. Nothing alerts you when the coverage window closes, so a control you rely on becomes unevidenced without any event occurring.
• Exit plans are written once. Article 28(7) wants a workable exit. A plan that names a system your vendor has since retired is not one.

What continuous assurance looks like against DORA

A register that maintains itself

Every arrangement carries its criticality, its data locations and its current attestation status, re-checked on a schedule rather than at renewal.

Change detection, not change reporting

Public signals are re-read continuously. A new sub-processor, a lapsed certificate, a relaxed mail policy or a new certificate outside the declared estate raises a finding the day it appears.

Dated evidence

Every check is recorded with what was observed and when. That record is what satisfies "throughout the relationship" in a way a questionnaire response cannot.

Concentration made visible

Where several of your providers depend on the same upstream, that is a fact about your resilience, and it is usually discoverable from public infrastructure records.

Exit readiness that is reviewed

Exit plans get a review date and an owner, and the review is prompted rather than remembered.

Practical first steps

1. Split your supplier list into critical or important, and everything else. DORA's heavier obligations attach to the first group only.
2. For that group, record what you actually hold today: attestation, its period end date, data locations, subcontractors.
3. Count how many of those attestations have already expired. In our experience this number surprises people.
4. Put the public-signal checks on a schedule so the register stops decaying between reviews.

You can start the fourth step for free: the vendor check runs the passive DNS half of it against any domain, and the sample report shows the output format.