A DORA third-party risk register is the single record of every ICT vendor your financial entity relies on, mapped against the risk they carry and the contract terms that govern them. Building one in 2026 means starting from your existing supplier list, not a blank template, and layering DORA's specific fields on top.
Why this matters
DORA — the EU's Digital Operational Resilience Act — has applied since 17 January 2025. It requires financial entities to maintain a register of information covering all contractual arrangements with ICT third-party service providers, under Article 28.
UK firms aren't automatically off the hook. If you serve EU clients, sit inside a group with EU-regulated entities, or your ICT providers serve EU financial firms, DORA reaches you indirectly through contract flow-down clauses. Get this wrong and the gap shows up during a regulator request or a client due-diligence questionnaire, not before.
A proper dora third party risk register isn't a compliance nicety. It's the artefact auditors ask for first, and the one most firms scramble to reconstruct from memory and old email threads.
What you'll need
- A full list of active vendors and sub-processors touching your ICT estate
- Current contracts, MSAs, and data processing agreements for each vendor
- A criticality framework — which vendors are "critical or important" under DORA versus general suppliers
- Named owners inside your business for each vendor relationship
- A register template with fields for entity name, service type, data location, sub-outsourcing chain, and exit provisions
- Time: expect 15-25 hours for the first pass across 20-40 vendors, less if you already run vendor risk management software
The steps
1. Pull your full vendor inventory
List every third party touching data, infrastructure, or a client-facing system — cloud hosting, payment processors, KYC tools, email, ticketing, even the outsourced helpdesk. Miss a vendor here and the whole register is incomplete from day one.
Cross-check against finance's supplier payments list, not just what IT remembers. Companies House filings and invoice records catch vendors nobody thought to mention. Expected outcome: a raw list, usually 30-60% longer than the first mental tally.
Common mistake: stopping at direct vendors and ignoring their sub-processors, which DORA's register explicitly wants captured.
2. Classify criticality
Mark each vendor as "critical or important" or standard, based on what breaks if they go down — client fund movement, trading systems, core banking rails sit at the top. This classification drives how much scrutiny and documentation each vendor needs.
Use a simple three-tier scale: critical, important, standard. Don't overengineer it into a ten-point matrix nobody maintains past month one.
Expected outcome: roughly 10-20% of vendors land in the critical tier for most mid-sized financial firms — the rest are lower-touch.
3. Collect the contract data DORA wants
For every vendor, pull: legal entity name and jurisdiction, service description, start and renewal dates, data location, sub-outsourcing arrangements, and exit or termination clauses. Article 28 register fields expect this level of detail, not a vendor name and a one-line description.
This is the step spreadsheets fall apart on past 20 vendors — someone updates one tab, forgets three others, and the register drifts out of sync with reality.
Common mistake: relying on the sales contract instead of the current signed MSA, which often has different terms after renegotiation.
4. Map the sub-outsourcing chain
Ask every critical vendor who they outsource to. A payments processor running on a third-party cloud region is a sub-processor DORA expects in your register, not an invisible layer.
Request this in writing as part of onboarding or annual review — most vendors have it documented for their own compliance and will share it on request. Expected outcome: at least one or two hidden sub-processors surface per critical vendor, more if the vendor is itself a smaller SaaS provider.
5. Score risk against your existing framework
Run each vendor through your risk assessment process — data sensitivity, access level, and business impact if the service fails. If you don't have a documented process yet, build a vendor risk assessment process before finalising register entries, otherwise the criticality tags in step 2 won't hold up to audit questions.
Common mistake: scoring vendors once at onboarding and never re-scoring after a contract renewal or ownership change.
6. Assign owners and review cadence
Every register entry needs a named internal owner and a review date — annually for standard vendors, every six months for critical ones is a reasonable default given how fast SaaS vendors change hands or sub-processors. An unowned register entry is the first thing that goes stale.
Expected outcome: a review calendar with entries spread across the year, not all due in December.
7. Automate the evidence trail
Manually chasing SOC 2 reports, penetration test summaries, and Cyber Essentials certificates from 30+ vendors twice a year eats real hours. Automate evidence collection for audits so renewal reminders, document requests, and expiry alerts run without someone tracking it in a shared inbox.
Common mistake: treating evidence collection as a once-a-year fire drill instead of a running process — regulators increasingly expect continuous evidence, not a snapshot.
8. Validate against Companies House and public records
Cross-check vendor legal entity names, registration status, and ownership structure against public filings before finalising the register. Vendor due diligence checks using Companies House data catches dissolved entities, shell company structures, or recent ownership changes your contract team might have missed.
Automate your DORA register upkeep
Stop chasing vendor evidence by email — automate collection and renewals.
Troubleshooting
- Vendors won't share sub-processor lists. Add a contract clause at next renewal requiring disclosure — until then, flag the gap in the register rather than leaving it blank.
- Register is out of date within a quarter. Move off a static spreadsheet; assign a monthly five-minute check per critical vendor instead of a full annual rebuild.
- Can't tell which vendors count as "critical or important." Default to critical if a 24-hour outage would stop client-facing operations or fund movement — err toward inclusion, not exclusion.
- Evidence documents keep expiring unnoticed. Set expiry alerts 60 days ahead of renewal, not on the day the certificate lapses.
- Multiple entities in your group each keep separate registers. Consolidate into one shared register with entity tags — DORA reviewers expect group-level visibility, and managing this across group structures is a documented pain point for holding companies with several regulated subsidiaries.
- Register looks complete but nobody's tested the exit plan. A register entry without a tested exit or transition plan for the critical vendor is incomplete under DORA's expectations, not just under best practice.
Tools and resources
- A vendor risk assessment framework built for fintech-scale vendor counts
- Vendor risk management software to track renewals without manual chasing
- Companies House data for entity verification during due diligence
- Evidence automation to keep SOC 2, ISO 27001, and Cyber Essentials documents current
- OneClickComply's compliance automation platform, which handles evidence collection and renewal tracking end-to-end so the register doesn't rot between audits
What to do next
Once the register is built, the harder job is keeping it current every renewal cycle. The register fits into wider DORA obligations — incident reporting, resilience testing, and information-sharing arrangements sit alongside it, not apart from it. Work through the full DORA breakdown before treating the register as finished.
Frequently asked questions
One last thing
The register itself rarely fails an audit — the exit plan does. Reviewers consistently probe whether you've actually tested what happens if a critical vendor disappears overnight, not just whether you've documented that the vendor exists. Seriously Simple Cyber Compliance means the register maintains itself, so you focus on growing.