How should financial institutions start building DORA compliance when their ICT assets and suppliers are poorly documented?

They should begin with asset discovery, then map those assets to supported business functions, ownership, and third-party dependencies. DORA compliance depends on knowing what exists, where it sits, and which services rely on it. Without that foundation, incident reporting, testing, and supplier oversight remain fragmented, and contracts cannot be updated in a way that supports ongoing resilience.

Start with inventory discipline, not policy drafting

For a financial institution with poorly documented ICT assets and suppliers, the first compliance problem is not wording the policy. It is establishing a reliable inventory that can support impact analysis, ownership, supplier classification, and resilience decisions. DORA expects firms to understand the ICT landscape well enough to govern it, test it, and respond to it. The European supervisory guidance on the EU Digital Operational Resilience Act (DORA) makes that dependency explicit for firms that need to prove operational control rather than simply assert it.

This matters because undocumented assets usually hide the very services that matter most: obsolete systems that still support production, supplier-hosted platforms with unclear boundaries, and shadow integrations that sit outside standard procurement records. If teams start with control writing instead of discovery, they tend to create a compliance shell that cannot be reconciled to actual operations. In practice, many financial institutions discover their real ICT exposure only after an incident, a renewal cycle, or a regulatory request forces the organisation to reconcile records that were never aligned.

How to build the baseline when records are incomplete

The practical starting point is to create a minimum viable register that captures what the institution can defend today, then iteratively improve it. That register should identify the asset or service, its business owner, its technical owner, its location or hosting model, the critical business function it supports, and the supplier or internal team responsible for it. dora compliance becomes tractable when the institution can connect each ICT dependency to a business service and a decision-maker.

A useful way to sequence the work is:

Inventory the highest-value business services first, then work backwards to the systems, suppliers, and data flows that sustain them.
Separate confirmed assets from inferred assets so the register does not mix verified facts with assumptions.
Tag third-party dependencies by contract, service scope, and concentration risk so supplier oversight can be prioritised.
Record evidence of ownership, because an unowned asset is usually the first control gap that blocks remediation.

That approach aligns well with broader control discipline, including the inventory and asset-management expectations reflected in NIST Cybersecurity Framework 2.0, even though DORA remains the primary compliance driver here. The point is not to build a perfect catalogue on day one. The point is to create a governed baseline that can support incident reporting, resilience testing, and supplier remediation without collapsing under uncertainty. Where the institution cannot yet confirm exact configuration or ownership, it should mark the record as provisional rather than leaving the dependency invisible.

This guidance breaks down when the firm has no reliable source systems at all, or when business units and procurement records are so fragmented that the organisation cannot establish a credible ownership chain.

Where documentation gaps create the biggest DORA problems

Tighter control over undocumented assets often increases operational overhead at first, because teams must reconcile conflicting records and chase ownership across business, technology, and procurement functions. That overhead is the price of reducing blind spots, and it is usually justified because DORA failure modes tend to emerge where dependencies are assumed rather than verified.

The hardest edge cases are usually legacy systems, outsourced services, and shared platforms. Legacy systems may still support critical services while lacking a current owner or vendor record. Outsourced services can look simple in the contract register while hiding subcontracted infrastructure, regional hosting differences, or support dependencies that matter during an incident. Shared platforms are especially difficult because one infrastructure component may support multiple business lines, which makes it harder to assign risk, testing scope, and restoration priorities.

There is also a practical trade-off between completeness and speed. Waiting for perfect documentation can delay compliance progress, but over-accelerating the register with unverified entries can produce false confidence. The sensible middle ground is to establish confidence levels for each record, then increase verification where the business impact is highest. For financial institutions, the risk-based approach is not a shortcut; it is the only way to make the programme operational while the documentation gap is still being closed.

When the register cannot distinguish between direct ownership and downstream dependency, the institution will struggle to prove that resilience testing, incident handling, and supplier oversight are actually covering the right services.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the technical controls, while DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
DORA	ICT Risk Management Framework — ICT Risk Management Framework	The question is about starting DORA compliance from poor ICT and supplier visibility.
Recommendation — Establish a governed ICT risk baseline tied to critical services and supplier oversight.
CIS Controls v8	1 — Inventory and Control of Enterprise Assets	Asset discovery and ownership are the first practical gap in the scenario.
	15 — Service Provider Management	Supplier documentation and third-party dependence are central to the question.
Recommendation — Inventory assets and ownership before attempting control uplift or resilience testing. Classify service providers and track contractual and operational dependencies.
NIST CSF 2.0	ID.AM — Asset Management	The issue is building a defensible asset baseline from incomplete records.
	ID.SC — Supply Chain Risk Management	Third-party and supplier oversight must be established alongside the asset baseline.
	GV.RM — Risk Management Strategy	The work should be prioritised by service criticality and risk, not documentation perfection.
Recommendation — Map ICT assets to business services, owners, and dependencies to close visibility gaps. Identify and govern supplier dependencies that affect operational resilience. Prioritise remediation using service criticality and risk-based governance.

Practitioner Guidance

What to prioritise: Build the inventory around critical business services, not around technical elegance. If a system or supplier cannot yet be tied to a material service, its compliance value is lower than the dependencies that could interrupt customer-facing or regulated operations.

What to verify: For each high-priority item, verify three things before trusting it as a compliance record: who owns it, which service it supports, and whether the supplier boundary is contractual or merely assumed. Where any of those are missing, treat the entry as incomplete and track it as remediation work rather than settled fact.

Common mistake: Teams often confuse procurement visibility with operational visibility. A signed contract does not prove that the institution understands hosting, sub-service dependence, exit constraints, or control responsibility, and that gap becomes visible when testing or incident response needs the missing detail.

Practitioner takeaway: DORA readiness starts when the institution can explain its ICT exposure in operational terms that withstand challenge, because compliance becomes much harder once the first test, incident, or supervisory review exposes gaps that were never made explicit.