Learn
This article is the step-by-step guide I wish someone had given me the first time I tried to build a DORA-compliant ICT third-party register. It would have saved me about six weeks and a lot of frustration.
Here’s what most firms don’t realise until they’re deep into the process: DORA doesn’t just want you to know who your vendors are. It wants you to understand the full dependency chain - what services each provider delivers, which of your business functions depend on those services, what happens if that provider fails, and whether you could replace them if you had to.
That’s not a vendor list. That’s an operational map of your entire ICT supply chain.
And building it requires a fundamentally different approach than what most procurement and compliance teams are used to.
Step Zero: Finding All Your ICT Providers (The Part That Takes Longer Than You Think)
Before you can build a compliant register, you need to know who’s in it. And I guarantee you don’t know all of them yet.
Every firm I’ve worked with goes through the same discovery arc:
Week 1: “We have about 30 ICT providers.” This is the number from the procurement system. The ones with formal contracts.
Week 3: “Actually, it’s closer to 60.” Someone checked the corporate credit card statements. Turns out various teams have been subscribing to SaaS tools independently. The design team uses Figma. The data team uses Snowflake. HR uses three different tools for recruitment, performance management, and benefits administration.
Week 5: “It might be 90.” IT did a network scan and found services nobody in procurement had heard of. An old integration with a payment processor that was “decommissioned” in 2022 but is still receiving API calls. A monitoring tool that a former CTO set up and nobody remembers the credentials for.
This discovery process is humbling. It’s also essential. Because DORA’s scope of “ICT third-party service provider” is broad: any undertaking that provides digital and data services through ICT systems, including hardware, software, cloud, and data analytics. If it’s technology and you’re paying for it (or using a free tier - yes, that counts too), it’s in scope.
My advice: don’t try to build the perfect list before you start building the register. Start with what you know, make it structurally sound, then expand. You’ll keep finding new providers for months. The register needs to accommodate that.
What DORA Actually Requires in a Vendor Register
Articles 28 and 30 are the heart of DORA’s third-party risk requirements. Let me translate them from regulation-speak into actionable requirements:
| Data Category | What You Need | Why It Matters |
|---|---|---|
| Provider identity | Legal name, LEI code, headquarters jurisdiction, EU/non-EU classification | NCA needs to identify providers across the sector and assess systemic concentration |
| Contract details | Start/end dates, renewal terms, termination rights, audit clauses, DORA Article 30 provisions | Proves contractual protections exist and are enforceable |
| Service mapping | Specific services delivered, linked to contracts and business functions using ESA taxonomy codes | Maps your operational dependencies at the service level, not just the provider level |
| Criticality assessment | Whether each service supports a critical or important business function | Determines the level of oversight, contractual requirements, and exit planning needed |
| Data locations | Processing and storage locations per service, including jurisdictions | Required for data sovereignty assessment and cross-border risk evaluation |
| Sub-outsourcing | Sub-contractors used by your provider for the services delivered to you | Reveals hidden dependencies and concentration risk (spoiler: it’s usually AWS or Azure) |
| Substitutability | Assessment of how easily each provider could be replaced, with estimated timeframes | Forces honest evaluation of vendor lock-in and exit readiness |
The Relational Challenge (Or: Why Excel Fails at This)
Let me paint a picture that will be familiar to anyone who’s attempted this.
Provider A (let’s call them “CloudCorp”) delivers three services to your organisation: email hosting, document storage, and identity management. These services are covered by two contracts - one for the productivity suite and one for the IAM platform, signed two years apart with different terms. The email hosting and document storage support four business functions across two legal entities. The identity management supports every business function across every entity.
CloudCorp processes your email data in Frankfurt, your documents in Dublin, and your identity data in both. They sub-outsource their infrastructure to a hyperscaler that has presence in twelve jurisdictions. Your email is critical. Your document storage is important. Your IAM is critical.
Now model that in a spreadsheet.
You can’t. Not without duplicating rows, creating cross-reference tabs that break when someone inserts a column, and ending up with a file that nobody except the person who built it can understand.
This is a relational data problem. The Register of Information’s 15 templates exist precisely because the relationships between providers, contracts, services, functions, entities, and data locations are many-to-many. They form a graph, not a table.
You need a tool that natively supports these relationships. That’s not a luxury. It’s a structural requirement of the regulatory format you’ll be submitting in.
Building It: The Practical Steps
Here’s the approach that works, based on what I’ve seen succeed at firms ranging from 50-person payment institutions to mid-tier banks:
Phase 1: Get Your Provider Inventory Right (Weeks 1-3)
Pull from every source: procurement records, accounts payable, corporate card statements, IT asset management, network monitoring, browser extension inventories. Send a survey to every department head asking “what technology tools does your team use?” Compare results against your existing vendor list. You will find duplicates, orphans, and surprises.
For each provider, gather: legal name, LEI code (search the GLEIF database), headquarters jurisdiction, and EU/non-EU classification. This sounds simple until you realise that half your SaaS providers are Delaware LLCs with European subsidiaries and you need to decide which entity to list.
Phase 2: Map Contracts to Services (Weeks 3-6)
For each provider, identify every contract and every service delivered under those contracts. This requires collaboration between procurement (who have the contracts) and IT (who know what services are actually being consumed). These two groups often have surprisingly different views of the same provider relationship.
Classify each service using the ESA’s taxonomy codes, not free text. This forces precision. “They do our IT stuff” becomes “ICT services supporting payment services” or “ICT services supporting data analytics,” and that precision matters for both your filing and your risk analysis.
Phase 3: Link Services to Business Functions (Weeks 6-8)
This is where the register becomes genuinely useful. For each ICT service, identify which business functions it supports and how critical that support is. A business function is “critical or important” under DORA if its disruption would materially impair the financial entity’s ability to comply with regulatory requirements, its financial performance, or the continuity of its activities.
This exercise often reveals dependencies that nobody had mapped before. The treasury function doesn’t just depend on the treasury management system - it depends on the market data feed, the connectivity provider, the authentication platform, and the email system that sends confirmation notifications. All of those are ICT services.
Phase 4: Assess Data Locations and Sub-Outsourcing (Weeks 8-12)
Send due diligence questionnaires to your providers asking: where is our data processed? Where is it stored? Do you use sub-processors for the services you deliver to us? If so, who are they and where are they located?
Large providers will have this information ready. Smaller ones won’t. Some will refuse to answer. That refusal is itself valuable information - it tells you something about their transparency posture, and a refusal to disclose sub-outsourcing arrangements is a red flag under DORA’s contractual requirements.
Phase 5: Perform Concentration Risk and Substitutability Analysis (Weeks 12-14)
Now look at the picture holistically. Which providers are non-substitutable? Where is concentration risk building (hint: look at the sub-outsourcing data - how many of your providers ultimately depend on the same three cloud platforms)? Where are your exit options weakest? This analysis feeds directly into your ICT risk management framework and your board reporting. It also populates the substitutability template (B.15) in your RoI filing.
Concentration Risk: The Hidden Problem in Every Register
Let me share a pattern I’ve seen at nearly every firm I’ve assessed.
On the surface, the register looks diverse: 70 different ICT providers, spread across multiple jurisdictions, no single provider accounting for more than 8% of total ICT spend. Looks healthy. No concentration, right?
Wrong. Follow the sub-outsourcing chains. 45 of those 70 providers run on AWS. Another 15 run on Azure. If AWS eu-west-1 has a major outage - and it has happened - your “diversified” ICT supply chain experiences correlated failure across 45 providers simultaneously.
That’s concentration risk. DORA cares about it deeply. The ESAs are collecting RoI data across the entire financial sector precisely to identify these systemic concentrations. When they find that 60% of European banks depend on the same three cloud providers, the regulatory response will be significant.
Your register should explicitly identify concentration risks, not just list providers. Which providers are single points of failure? Where are your business functions dependent on providers with no viable alternative? What would happen if your most critical provider was unavailable for 72 hours? These questions should be answerable from your register data.
Contract Remediation: The Slowest Part of the Process
Building the register will expose contract gaps. Lots of them. Most contracts signed before 2024 don’t include the provisions that DORA Article 30 requires: audit rights for regulators, incident assistance obligations, exit strategies, performance targets with quantitative metrics.
Renegotiating contracts with large technology providers is slow. Microsoft, AWS, Google, Salesforce - these companies have standardised terms, and getting DORA-specific amendments can take 6-18 months, if they agree at all.
Practical advice:
- Prioritise by criticality. Contracts supporting critical functions first. Non-critical contracts can wait.
- Use addenda. A DORA-specific contractual addendum is faster and less contentious than a full renegotiation. Many providers have developed standard DORA addendum templates by now.
- Document the attempts. If a provider refuses to negotiate, document that refusal. It’s evidence of your due diligence, and it may support a risk-based decision to retain the provider with documented mitigating controls.
- Plan for transitions. For providers who are both critical and uncooperative, start developing exit plans. You may never execute them, but having them demonstrates the risk management maturity your regulator expects.
Your register should track contract remediation status for each arrangement: compliant, partially compliant (with gap description), or non-compliant (with remediation plan and target date). This turns the register from a static inventory into a risk management tool.
Keeping It Alive: Ongoing Maintenance That Doesn’t Require a Full-Time Job
The register isn’t a project with an end date. It’s a permanent operational process. But it doesn’t need to consume your life. Here’s a maintenance rhythm that works:
Trigger-based updates: New contract signed? New provider onboarded? Contract terminated? Provider acquired? These events trigger immediate register updates. Build this into your procurement and vendor management workflows so updates happen as part of existing processes, not as separate compliance exercises.
Quarterly reviews: Once a quarter, review the register for completeness. Check for expired contracts, providers that have been offboarded but not removed, and any changes in data processing locations (providers love to change these without telling you).
Annual deep dive: Before your RoI filing, do a comprehensive review. Verify all data with providers. Update substitutability assessments. Refresh concentration risk analysis. This is the big one, but if you’ve been maintaining the register throughout the year, it’s a validation exercise rather than a rebuild.
Platforms like Venvera make this considerably easier by structuring the data relationally from the start, providing ESA entity code lookups, and generating xBRL-CSV exports natively. The ongoing maintenance becomes data entry rather than structural engineering.
The Honest Truth About Vendor Registers
A compliant vendor register under DORA is not just a compliance exercise. Done well, it’s the single most useful artefact your compliance team will produce.
It tells you where your critical dependencies are. It reveals concentration risks you didn’t know you had. It identifies contracts that need strengthening and providers that need replacing. It gives your board the information they need to make informed decisions about ICT risk.
Done badly, it’s a spreadsheet that nobody trusts, nobody maintains, and that fails validation every filing cycle.
The difference between those two outcomes isn’t budget or headcount. It’s approach. Treat it as a relational data problem. Use tools that support relational data. Build maintenance into existing workflows. And start now, because no matter how many providers you have, it always takes longer than you expect.
Build Your Vendor Register the Right Way
Venvera’s ICT third-party risk module structures provider data relationally, includes ESA entity codes and taxonomy lookups, and generates valid xBRL-CSV exports. Across 13 frameworks, starting at €399/month.
See It in Action →Last updated: March 2026. DORA requirements referenced from Regulation (EU) 2022/2554 and associated RTS/ITS.
