DORA Article 28-30: Operationalizing the ICT Third-Party Register of Information
A practitioner build guide for the register financial entities must maintain and submit under DORA
Proactive Security for the AI Era
NodeZero continuously and autonomously pentests infrastructure, identity, cloud, and now web applications, chaining weaknesses across every domain the way real attackers do. Every finding ships with replayable proof showing exploitable business impact, not theoretical risk.
DORA (Regulation (EU) 2022/2554) has applied across the EU since January 17, 2025. Most in-scope financial entities have by now worked through the headline obligations: ICT risk management frameworks, incident classification and reporting, and resilience testing. The obligation that catches teams off guard later is Article 28's register of information, because it is not a policy document or a risk assessment. It is a structured data asset with a defined schema, and national competent authorities expect it populated, accurate, and submittable on a recurring basis. Building it as a one-time spreadsheet exercise before a deadline is how entities end up rebuilding it from scratch the following year. This guide walks through what Articles 28-30 and the ESAs' Implementing Technical Standards (ITS) actually require, how to classify providers as supporting a critical or important function, and how to run the register as a continuously maintained system rather than a compliance artifact.
Problem statement: what Articles 28-30 actually require
DORA applies to a broad population of EU financial entities, including banks, payment and e-money institutions, investment firms, insurers and reinsurers, crypto-asset service providers, trading venues, and central counterparties, along with the ICT third-party providers designated as critical under the oversight regime. Articles 28-30 form the ICT third-party risk management chapter, and each covers a distinct obligation:
Article 28 sets the general principles: financial entities must manage ICT third-party risk as an integral part of their ICT risk management framework, perform due diligence before contracting, and maintain a register of information covering every contractual arrangement with an ICT third-party service provider, not only the ones supporting critical or important functions. Article 28(3) is the specific register mandate, and the register must be kept at entity level and, where relevant, at consolidated and sub-consolidated group level.
Article 29 requires an assessment of ICT concentration risk before entering into a new arrangement, including exposure to a single provider across the entity or group, and cross-sector concentration where many financial entities in the market rely on the same provider.
Article 30 specifies the mandatory contractual provisions that must appear in every ICT third-party contract (service descriptions, locations of data processing, service level agreements), plus a materially deeper set of provisions required specifically where the arrangement supports a critical or important function: audit and access rights for the entity and its competent authority, defined exit strategies, and provider cooperation obligations during ICT incidents.
The practical consequence is that the register is not optional documentation. The Joint Committee of the European Supervisory Authorities (EBA, ESMA, and EIOPA) published final draft Implementing Technical Standards specifying the exact templates, and national competent authorities require in-scope entities to submit the register, in the specified format, on an annual basis and on request. Deadlines and the exact submission mechanism are set by each national competent authority, and several regulators (Luxembourg's CSSF among them) have run dedicated portals for the annual intake, so confirm your own authority's current-year timeline directly rather than assuming an EU-wide single date.
Prerequisites
Before building the register itself, confirm these are in place. Skipping them is the single most common reason register projects stall midway.
An existing third-party or vendor inventory
You need a starting list of every ICT service relationship, not just the ones procurement or security already track. Shadow IT, business-unit-procured SaaS, and legacy contracts inherited through mergers are the usual gaps. If no central inventory exists, the first real step is building one, not skipping to field mapping.
Ownership of the DORA scoping decision
Confirm, in writing, which legal entities in your group are in DORA's scope and at what consolidation level (entity, sub-consolidated, or group). This determines whether you maintain one register or several, and who signs off on submission.
A working definition of 'critical or important function'
Article 3(22) of DORA defines a critical or important function as one whose disruption would materially impair the entity's financial performance, the soundness or continuity of its services, or its continuing compliance with its regulatory obligations. This designation happens at the function level first, then gets attached to the ICT providers supporting that function. Legal, risk, and business-unit leads need to agree on this list before the register can be classified correctly.
A named data owner per contract
Every field in the register needs a source of truth: legal owns contract terms, procurement owns vendor identity data, IT/security owns data location and subcontractor visibility. Without assigned owners, the register decays the moment the project team disbands.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Implementation procedure
The register template published under the ITS is organized as a set of related tables covering entities, contractual arrangements, and ICT third-party providers, cross-referenced by identifiers so a single provider or contract can be traced across the whole structure. Work through it in this order.
1. Inventory every ICT third-party arrangement, not just the critical ones
Article 28 requires the register to cover all contractual arrangements with ICT third-party service providers, including intra-group arrangements. Pull from contract management, accounts payable, cloud billing, and SaaS discovery tools in parallel; no single source captures everything. Reconcile duplicates where the same provider appears under different legal entity names or resold through an intermediary.
2. Map each arrangement to the required register fields
Per the ESAs' Register of Information ITS, each entry needs, at minimum: the ICT third-party provider's legal identity (including its Legal Entity Identifier, where one exists), the type and description of the ICT service provided, the business function the service supports, the country and specific location where data is processed and stored, whether the service is provided directly or through a subcontractor chain, and the contract's start date, renewal terms, and termination provisions. Do not paraphrase or summarize these into free-text notes; the submission format expects discrete, structured values per field, and vendor GRC platforms and the ESAs' own templates enforce this structure at the schema level.
3. Classify critical or important status per provider arrangement
For each arrangement, determine whether it supports a function your entity has already designated as critical or important (per Article 3(22), assessed against financial performance, service continuity, and regulatory compliance impact). This is a distinct flag in the register, not a separate list, because the same provider can support both critical and non-critical functions under different contracts. Providers flagged this way trigger the deeper Article 30 contractual requirements and heavier ongoing due diligence.
4. Trace subcontractor and fourth-party chains for critical arrangements
Where a provider supporting a critical or important function subcontracts part of the service, the register needs to capture that chain, not just the direct contractual counterparty. This is the field practitioners underestimate: cloud and managed-service providers routinely subcontract infrastructure, support, or data processing to further parties, and your due diligence obligation under Article 28 extends to understanding that chain, even though you have no direct contract with the subcontractor.
5. Run the concentration risk assessment required by Article 29
Before entering any new arrangement, and periodically for existing ones, assess exposure to a single provider across the entity and group (single point of failure) and, where visibility allows, exposure shared with the broader financial sector (systemic concentration, such as reliance on a small number of hyperscale cloud providers). Document the assessment outcome against each affected register entry, since this is what a supervisor will ask to see justified, not just the raw provider list.
6. Choose a maintenance approach and update cadence
A dedicated GRC or third-party risk management platform (vendors including Bitsight, UpGuard, and SureCloud market modules that map directly to the ITS template structure) buys you validation rules, workflow triggers when a contract changes, and often a built-in export to the required submission format. A spreadsheet-based approach is workable for a small provider population, but only if it has enforced dropdowns for controlled fields, a defined update trigger tied to procurement and legal workflows (new contract, renewal, amendment, termination), and a named quarterly review owner. Whichever approach you pick, the register update needs to be triggered by procurement and contract events, not by a pre-submission fire drill once a year.
7. Prepare for annual submission and on-demand regulator requests
National competent authorities require the register submitted at least annually in the specified structured format, and may request it on demand outside that cycle, including during a supervisory review or after an ICT incident. Confirm your specific national competent authority's current submission mechanism, format, and deadline directly (these are set and communicated at the member-state level and have varied by jurisdiction), and build a submission runbook that names who assembles the extract, who validates it against the schema, and who has sign-off authority before it goes to the regulator.
Validation: confirming the register is actually audit-ready
A register that exists is not the same as a register that will survive supervisory scrutiny. Validate it against these checks before treating it as complete.
Reconciliation against independent sources
Cross-check the register against accounts payable records, cloud billing, and active contract counts from legal. A material gap between what finance is paying for and what the register lists is the fastest way to find missing entries.
Schema and referential integrity checks
Every provider referenced in a contractual arrangement entry should resolve to a single, consistent provider entity elsewhere in the register, with consistent identifiers. Duplicate or inconsistent provider records are a common finding when the register was built by merging spreadsheets from multiple business units.
Critical/important classification defensibility
For each function flagged critical or important, confirm there is a documented rationale tied to the Article 3(22) criteria, signed off by risk or the business owner, not just an inherited label from a prior assessment cycle.
A dry run of the submission extract
Generate the actual export in the format your competent authority expects and have someone outside the register team review it for completeness and internal consistency before the real submission window opens. Several competent authorities have published test or dry-run facilities; use them if available rather than discovering formatting problems for the first time on the live deadline.
Failure cases: where registers actually break down
These are the recurring gaps that turn up when a register meets real audit or supervisory scrutiny.
Subcontractor and fourth-party blindness
The register captures the direct contractual provider but stops there. When a critical function depends on a subcontracted data center or a downstream API dependency the entity never negotiated directly, that chain is invisible until an incident or a supervisor's question exposes it.
Stale data from unmanaged renewal and amendment events
A register built once during a project and never reconnected to procurement's contract lifecycle drifts within a quarter. Auto-renewed contracts, scope amendments, and quiet subprocessor changes on the provider's side are the most common sources of drift.
Missing or superficial concentration risk analysis
Many registers list providers without ever completing the Article 29 assessment, or complete it once at onboarding and never revisit it as the provider footprint grows. Concentration risk is a property of the whole register, not a per-contract checkbox, and it needs to be reassessed as new arrangements are added.
Business-unit-procured SaaS never entering the register
Cloud services procured outside central IT or procurement (marketing analytics tools, HR SaaS, a business unit's own AI vendor) commonly never reach the register at all, because no single intake process catches every ICT third-party relationship a materially decentralized organization creates.
Free-text fields where structured values were required
Register entries built by copying contract summaries into notes fields fail structured validation. The submission format expects discrete values per field; free-text approximations of the required data are not a substitute and will fail schema validation at submission time.
Security tradeoffs: operational overhead versus regulatory and systemic risk exposure
Maintaining an accurate, continuously updated register is genuine ongoing operational cost: a named data owner per contract, a workflow trigger on every procurement and legal event, and either a licensed GRC platform or a disciplined spreadsheet process with a real review cadence. For an organization with hundreds of ICT vendor relationships, that is not a trivial line item, and it competes for the same GRC and vendor-management staff time as every other compliance obligation on the calendar.
The other side of that tradeoff is what the register is actually for. It is not paperwork for its own sake; it is the mechanism by which a financial entity, and its regulator, can see where a single ICT provider failure would cascade into a materially impaired critical function, and where the same provider dependency is concentrated across the wider financial sector. An incomplete or stale register does not just create supervisory exposure at the next audit. It means the entity itself does not actually know its own concentration risk, which is the exact operational resilience gap DORA's third-party chapter exists to close. Treating the register as a living operational asset, tied into procurement and contract lifecycle events, is more expensive up front than a pre-deadline spreadsheet exercise, but it is the only version of the register that is still accurate the day an ICT incident actually happens.
The bottom line
The DORA register of information under Articles 28-30 is a structured data obligation, not a documentation exercise: map every ICT third-party arrangement to the ITS-defined fields, classify critical or important status at the function level, trace subcontractor chains for critical arrangements, run the Article 29 concentration risk assessment, and tie register updates to procurement and contract lifecycle events so the register stays accurate between annual submissions rather than being rebuilt from scratch each time a deadline approaches.
Frequently asked questions
What is the DORA register of information?
It is the structured inventory required under DORA Article 28 that financial entities must maintain covering every contractual arrangement with an ICT third-party service provider, including provider identity, service type, function supported, data location, and subcontractor use, submitted to the national competent authority annually and on request.
Who has to maintain a DORA register of information?
Financial entities in DORA's scope, including banks, payment and e-money institutions, investment firms, insurers, reinsurers, crypto-asset service providers, and trading venues, must maintain the register at entity level and, where applicable, at consolidated or sub-consolidated group level.
How do you determine if an ICT provider supports a critical or important function?
Under DORA Article 3(22), a function is critical or important if its disruption would materially impair the entity's financial performance, the soundness or continuity of its services and activities, or its continuing compliance with its regulatory obligations. The designation is made at the function level first, then applied to the providers supporting that function.
What data fields does the DORA register of information require?
Per the ESAs' Implementing Technical Standards, required fields include the ICT third-party provider's legal identity (including its Legal Entity Identifier where one exists), the type and description of the service, the function it supports, whether that function is critical or important, the location of data processing and storage, subcontractor use, and key contract terms including dates and termination provisions.
Should a company use a GRC platform or a spreadsheet for the DORA register?
A dedicated GRC or third-party risk platform adds schema validation, workflow triggers on contract changes, and often a direct export to the required submission format, which matters more as provider count grows. A well-governed spreadsheet can work for a small provider population, but only with enforced field values, a defined update trigger tied to procurement events, and a named review owner.
How often must the DORA register of information be submitted to regulators?
Financial entities must submit the register to their national competent authority at least annually and on request outside that cycle, such as during a supervisory review or after an ICT incident. The specific deadline and submission mechanism are set by each national competent authority, so confirm the current-year timeline directly with your own regulator rather than assuming a single EU-wide date.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.