DORA Register of Information: 3 Ways to Map 3rd-Party Lineage

The 2024/1774 Schema

Commission Delegated Regulation (EU) 2024/1774 decouples lineage obligations from enterprise topology by anchoring them to the Register of Information's per-contract schema. The regulation defines the register as a collection of discrete records for Critical-or-Important Function ICT Contractual Arrangements (CTAs) and Other ICT Arrangements (OTAs). Each record contains specific fields for the ICT service description, provider identifiers, and data characteristics. This structure means lineage requirements attach to individual contracts rather than flowing from a centralized enterprise model. CIOs attempting to build a unified graph before mapping these contract-level attributes are solving the wrong problem; the RTS template demands attribute completeness per arrangement, not topological continuity across the organization.

The subcontracting-chain mechanism in Article 28(3) DORA requires financial entities to contractually mandate disclosure of downstream services, but the RTS operationalizes this with precise depth limits. The register must list subcontracting chains only down to the level where the primary provider relies on subcontractors for the service. In practice, this caps the required lineage at Tier 1 and Tier 2 subcontractors. Mapping beyond this threshold yields no compliance value because the schema has no fields for Tier 3 or deeper dependencies. Software supply chain security has escalated to a critical organizational priority due to the prevalence of indirect and transitive dependencies, yet DORA's register deliberately ignores those outer rings. The obligation ends where the primary provider's direct reliance ends, allowing entities to defer tooling for deeper chains until after the January 2027 submission.

Data-residency fields within the schema create implicit lineage without requiring explicit flow diagrams. The register mandates location(s) where data is processed and stored, including the distinction between EEA and third-country locations under Article 28(2) DORA. These fields force the entity to trace which datasets flow to which provider processing sites, effectively generating a lineage map scoped strictly to the registered service. An entity can satisfy this requirement by populating the location fields correctly; the schema does not ask for a visual graph or a continuous path. The lineage emerges from the intersection of the dataset identifier and the residency location, reducing the burden to attribute validation rather than graph construction.

The identifier resolution burden scales linearly with the number of arrangements and disclosed subcontractors. Each register entry requires the provider's Legal Entity Identifier (LEI) or European Unique Identifier (EUID), and the same identifiers apply to each listed subcontractor. For an entity managing 200 registered ICT arrangements with an average of three disclosed subcontractors per chain, the submission requires resolving roughly 800 legal-entity identifiers before the January 2027 deadline. This calculation assumes the standard depth of Tier 1 and Tier 2 coverage. Entities should prioritize LEI/EUID acquisition for these specific nodes rather than investing in enterprise-wide identity resolution tools that attempt to cover non-regulated assets.

Submission mechanics reinforce the contract-centric approach. Registers are submitted annually to the designated National Competent Authority (NCA) in the European Supervisory Authorities' harmonized machine-readable format. The first submission was completed by April 2025, establishing a baseline. The January 2027 submission represents the second full cycle, a point at which NCAs are expected to escalate quality findings from the initial wave. Entities that mapped bottom-up from the register entries will have clean, auditable data aligned with the schema. Those attempting enterprise-wide lineage often face delays reconciling unstructured internal graphs with the rigid RTS fields, increasing the risk of rejection during this escalation phase.

Finally, the register must be distinguished from the pre-contractual disclosure duties in Article 28(1)-(2) DORA. Providers are obligated to disclose all locations and subcontractors before contract signature, meaning the lineage process must already exist contractually. The register serves as downstream evidence of a lineage process that was established during procurement, not as the mechanism that creates the obligation. The register exposes whether the contractual obligation is being met through accurate field population. Relying on the register to generate lineage from scratch is a structural error; the schema validates existing contractual disclosures. According to research on software supply chain security, organizations must secure against risks posed by indirect dependencies, but DORA's register explicitly excludes those deeper layers. The pass condition depends on the accuracy of the disclosed Tier 1 and Tier 2 data, not on the completeness of a broader dependency map.

11,000 Registers In

The ESAs' first horizontal assessment of Register of Information submissions, published in 2025, captured a landscape defined by volume rather than precision: approximately 11,000 financial entities across the EU submitted registers covering hundreds of thousands of individual ICT contractual arrangements. This scale confirms that the regulatory baseline is not a niche compliance exercise but a mass data-collection event where NCAs will prioritize structural defects over architectural perfection. The assessment revealed widespread gaps in subcontracting-chain completeness; entities routinely registered direct providers while leaving Tier 1 and Tier 2 subcontractor fields empty or populated them with unidentifiable entries. The ESAs attributed these gaps to limited visibility into provider supply chains, a finding that directly invalidates the persistent belief among CIOs that DORA requires a complete, tool-generated data-lineage graph across the enterprise. In reality, the RTS schema asks for contract-level attributes per ICT arrangement, and no field in the Commission Delegated Regulation (EU) 2024/1774 template demands a lineage graph at all. Attempting to resolve every supply-chain blind spot before submission invites unnecessary cost without improving the pass condition.

Machine-readability failures present a more immediate risk than missing links. The ESAs reported that a material share of submitted register entries lacked valid LEI/EUID identifiers or used free-text provider names, degrading the harmonized format's utility. This creates a concrete, checkable defect that NCAs can flag without interpretation. When an entity submits a critical-function service with a free-text vendor name instead of a structured identifier, the NCA cannot validate the subcontracting depth required by Articles 3(3) and 28(3). The mechanism for failure is binary: the entry fails validation rules regardless of whether the underlying business relationship exists. Furthermore, the first-wave data showed heavy market concentration among a small set of ICT third-party providers serving EU financial entities. The ESAs flagged this as a systemic-concentration concern, meaning NCA scrutiny will focus on entities dependent on the same top providers, where lineage gaps are most visible. If your organization relies on one of these concentrated providers, the NCA will expect precise Tier 1/Tier 2 mapping for that specific dependency; enterprise-wide lineage efforts for non-critical services offer zero defensive value against this targeted scrutiny.

The forward signal from the ESAs is unambiguous: the first submission was primarily a data-collection exercise, and subsequent cycles will move toward supervisory use of the data. This trajectory establishes January 2027 as the first graded submission rather than another dry run. Entities that invest heavily in enterprise-wide lineage now face diminishing returns because the pass condition is defined by the delegated regulation's data fields, not lineage completeness. By mapping third-party data lineage only for the ICT services supporting critical or important functions—and capturing Tier 1 and Tier 2 subcontractors with LEI/EUID identifiers as specified—you align resources with the actual supervisory focus. The ESAs' concentration findings confirm that NCAs will drill down on high-risk dependencies where identifier quality and subcontracting transparency are verifiable. Deferring any enterprise-wide lineage tooling until after the January 2027 submission preserves capital while ensuring you meet the rigorous expectations for the services that matter.

Three Ways to Build the Map

The persistent belief among CIOs that DORA's Register of Information requires a complete, tool-generated data-lineage graph across the enterprise is a costly hallucination. The RTS schema asks for contract-level attributes per ICT arrangement; no field in the 2024/1774 template demands a lineage graph at all. This misconception drives organizations toward Approach C—dedicated lineage platforms like Collibra, Solidatus, or Manta—which generate column-level graphs and derive register fields from them. While strongest for ongoing data governance, this approach requires six to twelve months of implementation before producing register-grade output and incurs six-figure annual licensing costs. For the January 2027 submission, deploying such platforming is irrational when the pass condition depends solely on populating specific contractual attributes for critical-or-important-function services.

A more efficient mechanism exists: Approach A, register-first scoped mapping. This method extracts Critical Third-Party Arrangement (CTA) entries from your existing register, interviews each named provider specifically for Tier 1 and Tier 2 subcontractor details and data-location fields, and stores lineage as structured attributes attached directly to those register entries. Typical tooling consists of the register template plus a contract repository, yielding near-zero incremental license cost. According to Resultsense, building a dependency register for a mid-sized company requires approximately two to three weeks of dedicated personnel time, plus engineering and procurement workshops. This timeline aligns with the one-year preparation window active in 2026, allowing teams to produce register-grade output in weeks rather than months. Every field traces to a named contract or provider disclosure, satisfying auditability requirements without inferring relationships through automated scanning.

Approach B attempts to reuse ITSM or CMDB infrastructure, such as ServiceNow configuration items and dependency records, to auto-populate register fields. While this reduces manual entry, CMDB dependency data is inherently infrastructure-oriented. It typically lacks the legal-entity identifiers (LEI/EUID) and data-residency attributes the RTS mandates. Relying on CMDB-sourced data creates an audit gap where the source of a subcontracting tier cannot be verified against a contract or provider disclosure, risking rejection during NCA review despite technical accuracy in asset tracking.

The decision matrix for January 2027 hinges on four criteria: time to register-grade output, coverage of RTS-specific fields (LEI/EUID, data location, subcontracting tier), auditability of each field's source, and total cost through the submission deadline. Approach A wins because it produces the required fields in weeks, ensures every attribute traces to a contract or provider disclosure, and costs a fraction of Approach C. Approach C becomes the rational choice only after 2027, when lineage reuse across multiple regulations—including GDPR Article 30 and operational-resilience reporting—justifies platform investment. Until then, deferring enterprise-wide tooling preserves capital while meeting regulatory obligations.

What the Data Doesn't Tell You

The convergence of the Register of Information schema and NCA review criteria creates a structural asymmetry that most governance programs misread. The evidence base for the bottom-up mapping rule rests on the mechanical pass/fail logic of the 2024/1774 template, not on empirical audits of lineage graph fidelity. This distinction matters because the data does not prove that sparse lineage is superior; it proves that the regulator's validation engine cannot penalize you for missing edges outside the critical function perimeter. The limitation here is epistemic: we lack horizontal assessment data on entities that submitted enterprise-wide graphs versus those that submitted targeted maps. We only know the submission volume (~11,000 entities) and the general variance in acceptance rates across NCAs, but we do not have a controlled dataset isolating cost savings from topology choices. Consequently, the one-third cost advantage cited in the thesis is a derived estimate based on tooling licensing models and labor hours, not an observed audit outcome. You are betting on regulatory behavior, not proven efficiency.

Variance across cases emerges primarily from how different National Competent Authorities interpret "data-residency" and "subcontractor depth" when the RoI entry is ambiguous. The RTS requires LEI/EUID identifiers and residency fields, yet the schema allows free-text elaboration for complex supply chains. In practice, this creates a wedge where two entities with identical critical-function ICT services may face divergent review outcomes depending on whether their NCA prioritizes strict contractual hierarchy or operational dependency visibility. For example, an entity mapping a Tier 2 cloud provider via a Tier 1 managed service might pass a German BAFIN review if the LEI chain is intact, while a French ACPR reviewer could flag the same map for insufficient granularity on data flow directionality. The variance is not random; it correlates with the NCA's historical enforcement posture on third-party risk. Entities in jurisdictions with aggressive digital operational resilience mandates should expect tighter scrutiny of the boundary between Tier 1 and Tier 2, even if the formal requirement stops at the former. This means your bottom-up map must be calibrated to the specific risk appetite of your primary supervisor, not just the letter of the regulation.

The canonical rule breaks when the definition of "critical or important function" shifts dynamically during the year, or when cross-border data flows trigger secondary jurisdictional claims that the RoI schema cannot capture. The rule assumes a static classification of functions as of the January 2027 submission date. If your entity reclassifies a function from "important" to "critical" in Q3 2026 due to a merger or regulatory directive, the deferred enterprise tooling becomes a liability. You will need to retroactively map lineage for the newly elevated function, potentially incurring rush costs and exposing gaps in your subcontractor intelligence. Furthermore, the rule fails for entities operating under the EU-US Data Privacy Framework transition arrangements, where data residency assertions may require supplementary technical documentation beyond the RoI fields. In these edge cases, the cost of remediation can exceed the savings of deferring tooling. The decision to defer enterprise lineage is valid only when your function taxonomy is stable and your cross-border dependencies are fully documented within the RTS fields. If either condition is uncertain, the premium for early tooling deployment is justified to avoid post-submission remediation cycles that delay your registration approval.

What the Register Cannot See

The Register of Information is a legal artifact, not an operational mirror. Its architecture creates structural blind spots that no amount of enterprise-wide lineage tooling can resolve before the January 2027 submission. CIOs who conflate register compliance with supply-chain visibility are misallocating capital toward graphs that the NCA review criteria do not require and cannot validate. The mechanism here is simple: the RTS schema anchors obligations to contract-level disclosures per ICT arrangement, not to technical topology. Consequently, the register passes or fails based on field completeness for Tier 1 and Tier 2 subcontractors, leaving fourth-party exposures and temporal drift entirely outside the pass condition.

Consider the fourth-party blind spot. The RTS depth stops at the tiers a provider contractually discloses. A Tier 2 subcontractor's own cloud supplier—a fourth party—remains invisible in the register. As the ESAs noted regarding supply-chain opacity, a register that satisfies NCA review criteria can still leave an entity exposed to undisclosed concentration risk. This is not a failure of the register; it is a feature of its design. The regulation demands LEI/EUID identifiers and data-residency fields for disclosed tiers only. Mapping beyond this depth consumes engineering hours without improving the probability of a favorable supervisory outcome. The cost differential emerges because entities attempting to map fourth parties must build tooling that ingests metadata the RTS does not ask for, inflating costs by roughly two-thirds compared to the bottom-up approach anchored to critical-or-important-function entries.

Temporal dynamics introduce a second asymmetry. The register captures a snapshot as of the reference date. Subcontracting chains shift continuously. If a provider migrates processing from an EU data center to a US region between submissions, the register will not reflect this residency breach until the next annual cycle. Entities that invest in real-time lineage platforms assume these tools mitigate this risk, but vendor case studies and practitioner accounts reveal a different reality. Auto-generated lineage requires manual reconciliation against contracts because technical metadata lacks the register's legal fields—contract dates, specific identifiers, and function classifications. Automation does not eliminate mapping work; it shifts the bottleneck from discovery to validation. The register's pass condition depends on the accuracy of the submitted fields, not the freshness of the underlying graph.

Enforcement uncertainty further distorts the cost calculus. As of the first cycle, NCAs have not published consistent penalty practices for register-quality deficiencies. A poor January 2027 submission may trigger only supervisory dialogue, or, under Article 50 DORA, administrative penalties. Entities cannot price this risk precisely, yet they often over-invest in "perfect" lineage to hedge against worst-case scenarios. The rational strategy is to align investment with the pass condition: ensure Tier 1 and Tier 2 entries for critical functions are complete, accurate, and defensible. Defer enterprise-wide tooling until after the submission window closes.

Variance by entity class complicates the narrative. Exempted entities (small, non-interconnected investment firms, certain payment institutions) face no full register obligation, making the "map everything" instinct wasteful. Conversely, G-SIBs encounter proportionality challenges in reverse; their NCAs apply heightened expectations that may demand deeper scrutiny than the RTS minimums provide. For these entities, the "minimum viable register" may be insufficient if the NCA interprets the submission through a systemic-risk lens. However, even here, the baseline remains the register fields. Any additional mapping should be justified by specific NCA guidance, not by a generic belief that completeness equals safety.

Action: Audit your current lineage investments against the table above. Eliminate tooling that targets fields absent from the 2024/1774 template. Redirect resources to ensuring LEI/EUID coverage and residency accuracy for all Tier 1 and Tier 2 subcontractors supporting critical functions. This alignment reduces cost while maximizing the likelihood of a clean NCA review.

Worked Case

A composite mid-tier EU insurer, modeled on first-wave submission data consistent with 2025 ESAs ho

Frequently Asked Questions

How deep must we map our subcontracting chains to satisfy the RTS schema?

The register caps required lineage at Tier 1 and Tier 2 subcontractors because the schema contains no fields for Tier 3 or deeper dependencies.

What is the exact deadline for the second full submission cycle where NCAs will escalate quality findings?

The January 2027 submission represents the second full cycle, a point at which NCAs are expected to escalate quality findings from the initial wave.

Can we avoid building visual data-flow diagrams by relying on other schema fields?

Data-residency fields within the schema create implicit lineage without requiring explicit flow diagrams by mandating the location(s) where data is processed and stored.

How many legal-entity identifiers should a mid-sized entity expect to resolve before the next deadline?

An entity managing 200 registered ICT arrangements with an average of three disclosed subcontractors per chain must resolve roughly 800 legal-entity identifiers before the January 2027 deadline.

What specific machine-readability defect causes immediate binary validation failures during NCA review?

A material share of submitted entries lacked valid LEI/EUID identifiers or used free-text provider names, creating a concrete defect that fails validation rules regardless of whether the underlying business relationship exists.

Does the DORA register require us to secure against indirect software supply chain dependencies?

DORA's register deliberately ignores outer rings and explicitly excludes indirect dependencies, meaning the pass condition depends solely on the accuracy of disclosed Tier 1 and Tier 2 data.

Quick answers

Also worth reading: Data Retention: 3 Governance Models vs. Time-to-Market: Data Retention: 3 Governance Models · Un-Siloing Eng & Sales Data: 38% Faster Launches (Forrester): Un-Siloing Eng & Sales Data: · Federated Data Catalogs: 40% Discovery Gain and Hidden Risks: Federated Data Catalogs: 40% Discovery