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 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.