DORA requires every EU financial entity to maintain a live Register of Information mapping all ICT third-party dependencies. Fifteen templates, 100+ fields, 116 validation rules. The current approach: a compliance officer emails department heads asking them to fill in a spreadsheet. The department heads forward it to someone junior. That person guesses. The Register passes because the format is correct. The content is fiction.
ICT dependency graph federated from live systems. Third-party and fourth-party relationships traversed automatically. Concentration risks — like four critical paths converging on a single data centre provider — surfaced from the actual dependency graph, not from self-reported assessments.
This is the Soviet archetype in action. The centre demands the Register. The edge fills it in to survive the audit, not to tell the truth. The centre can't verify because they don't have visibility into the actual systems. Everyone knows the Register is incomplete. The game rewards submission over accuracy.
Template B_05.01 — the ICT Third-Party Service Provider master list — is where most organisations fail. It requires valid LEIs checked against the GLEIF database, parent undertaking chains, country-of-data-processing for every provider, annual expense figures, and subcontractor flags. 60% of all validation failures occur here. Most organisations don't even know who their fourth-party providers are, let alone their LEIs.
Your organisation uses Microsoft 365. Your payment processor uses Azure. Your CRM runs on Azure. Your data warehouse runs on Azure. Your third-party risk platform runs on Azure. You've reported five separate ICT arrangements — but you have one concentration risk: Microsoft.
Now go deeper. Microsoft's data centres are hosted by Equinix. Your backup provider also uses Equinix. Your disaster recovery site uses Equinix. Three apparently independent providers share a single fourth-party dependency that nobody mapped because nobody looked past the first tier.
Article 28(5) requires concentration risk assessment. You can't assess what you can't see. A spreadsheet can list your vendors. Only a federated system can traverse the graph and show you where they converge.
Instead of asking humans to fill in spreadsheets, ZQL federates the Register of Information from the systems that already contain the data. Read-only adapters connect to contract management, CMDB, vendor portal, and procurement systems. The DORA lens maps each system's native data onto the 15-template structure. Where data is missing or inconsistent, ZQL surfaces the gap rather than hiding it — because a known gap is manageable, while an unknown gap is a liability.
The Register isn't generated once and filed. It's a live federation — every query pulls current data from source systems. When a contract changes, the Register reflects it. When a subcontractor relationship shifts, the concentration risk map updates. When an LEI lapses, the validation catches it.
When the ESAs review your Register, they won't just check format compliance. They'll ask five questions: Have you documented ALL ICT third-party arrangements? Have you mapped subcontractor chains with rank-in-chain? Have you identified concentration risks where multiple arrangements converge? Is this Register current or was it accurate six months ago? And — can you show where each data point came from?
A spreadsheet can answer the first question, badly. Only a federated system can answer the other four.
The Register becomes what DORA intended: a live map of ICT dependency. Not a compliance document. A management instrument. The difference isn't format — it's whether you can stand behind the answer when the auditor asks "where did this come from?"
Weeks 1–2: System mapping. Identify which systems contain contract data, provider information, and service dependencies. Map to DORA template structure. Identify gaps before touching any technology.
Weeks 3–4: Adapter deployment. Read-only connections to contract management, CMDB, vendor portal, and procurement systems. No data moves — ZQL queries in place.
Weeks 5–6: Register federation. DORA lens maps source data to all 15 templates. Validation rules applied. Gaps surfaced. Concentration risk graph computed.
Weeks 7–8: Compliance review. Live Register demonstrated to compliance team. Gap remediation prioritised. Export to ESA submission format. Ongoing federation maintained.
Compare: traditional approach takes 6–12 months, produces a spreadsheet that's outdated on delivery, and needs to be repeated every reporting cycle. Federation is live and continuous.
We'll show you what a federated Register of Information looks like — read-only, no data movement, live in weeks.
We'll walk through a question from your organisation and show you what federation reveals. Thirty minutes. No slides.
Book a Call