Written by: Michał Sobieraj, Operations Manager, Digital Colliers
DORA has been in force since 17 January 2025, and the register of information is the piece most mid-market banks are still quietly panicking about. Not because the requirement is unclear. Because when a supervisor asks "list every ICT third party you rely on, with the contract, the criticality rating, the sub-outsourcers, and the exit plan," most banks can't answer from a single source. They answer by emailing four teams and hoping.
That's the tell. If assembling the register is a project, you don't have a register. You have a snapshot that's stale the day you file it.
The register is a feed, not a document
Think about what changes in a given month at a mid-market bank. Procurement signs two new SaaS contracts. Someone in the trading desk starts a trial of a market-data plugin. A cloud provider adds a region. A vendor gets acquired. A key subprocessor changes. The security team onboards a new pen-test firm.
Every one of those is a register event. If your process is "we refresh the spreadsheet once a quarter," you're filing a document that was wrong before it was signed.
The operators getting this right treat the register as a materialized view over live sources. The sources are boring: your contract lifecycle system, your IAM provider, your cloud billing exports, your expense system, your vendor security questionnaires. The register itself is downstream. It gets rebuilt every night from the sources of truth.
Who actually holds the pieces
The reason the register is hard isn't that the data doesn't exist. It's that the data lives in seven places and nobody owns the join.
A rough map of where the fields actually live:
- Vendor identity, legal entity, contract dates: procurement or legal ops, usually in a CLM tool or SharePoint.
- What the vendor actually does for you: the business owner, usually in their head.
- Criticality rating: risk team, usually in a separate GRC tool.
- Data categories processed: DPO, usually in a ROPA spreadsheet.
- Sub-outsourcers: buried in the contract PDF, sometimes in an annex.
- Actual usage and spend: finance, in the GL and expense system.
- Shadow SaaS nobody told procurement about: SSO logs, cloud egress, corporate cards.
The last one is the killer. A large share of the ICT third parties a bank uses were never procured formally. They came in on a credit card, or through a free tier that got upgraded, or as a feature inside another vendor's product. Your register is wrong until you're reconciling against SSO and card spend.
The shadow-SaaS join that makes it defensible
The reconciliation is a join across three systems you already have. The expense and card system: every transaction with a software MCC, plus recurring charges under £100 a month that nobody thinks of as "a vendor". The identity provider: every third-party app anyone has logged into with a work identity, with OAuth grants especially revealing. The contract repository: what you formally signed, with which entity, under which data processing terms.
Join those three and the picture gets uncomfortable fast. Vendors in the expense feed with no contract. SSO grants to tools nobody expenses, because someone signed up on a free tier that quietly started processing client data. Contracts auto-renewing for tools nobody uses. The join key is usually the vendor domain, normalised; names in expense feeds are messy, but the domain resolves cleanly most of the time, and the residuals get human review. New card charge to an unknown domain triggers a ticket; new SSO grant to an un-contracted vendor triggers a ticket. Monthly, with named owners for the exceptions.
Your AI model vendors belong in the register too
A foundation model provider is a third-party ICT provider, full stop. If it is domiciled outside the EU, subject to export controls, or funded by capital your compliance team cannot trace, that goes in the register too. And supervisors treat concentration on a single provider as a finding in itself, which means substitutability has to be demonstrable, not a slide.
Practically, that means a thin internal gateway between your applications and any external model API, prompts stored as versioned artefacts rather than string literals, an evaluation harness that runs the same test set against more than one provider on a schedule, and structured logs that capture which model version produced which output. Done properly, swapping a provider is a config change plus a re-run of the evaluations, and your register entry for the vendor is truthful when it says "substitutable".
The audit question is the design spec
Stop designing the register from the DORA field list. Design it from the questions a supervisor will actually ask.
- Show me every vendor processing customer PII, ranked by criticality, with the current contract exit clause.
- Show me every vendor whose parent company changed in the last 12 months.
- Show me every critical vendor without a tested exit plan.
- Show me every vendor that shares a subprocessor with another critical vendor, because that's your concentration risk.
If your data model can answer those in SQL in under a minute, you have a register. If answering means three analysts and a week, you have a compliance theatre exercise. The penalty regime around EU financial and data rules is not gentle. GDPR alone runs up to €20M or 4% of global turnover, and DORA sits alongside it, not instead of it.
What a good data model looks like
A workable schema is smaller than people expect. Vendors as entities with stable IDs. Contracts as time-bounded relationships between your legal entity and theirs. Services as the thing the contract actually delivers, tagged with criticality, data categories, and jurisdiction. Subprocessors as edges in a graph, not a text field. Incidents and assessments as events attached to services, with timestamps.
The trick is not the schema. The trick is the ingestion. You need a nightly job that pulls from CLM, IAM, cloud billing, expense, and the GRC tool, and reconciles them against a canonical vendor list. When a new SSO app appears without a matching contract, it flags. When a contract expires without a renewal or a documented exit, it flags. When a subprocessor changes, it flags.
That's the shape. The register is the output. The system underneath is a small, boring data pipeline that runs every night and never lies to you when the supervisor calls.