DORA Article 8

What Article 8 Requires in Practice

DORA Article 8 is an inventory-and-dependency rule, not just a recordkeeping exercise. It requires financial entities to know which business functions rely on ICT, what assets support them, who owns them, and how those parts depend on one another so the organisation can assess resilience in a structured way.

The practical value is that the inventory becomes the bridge between policy and operational reality. If a function, system, supplier relationship, or role is missing from the register, the firm can misjudge impact, overlook a hidden dependency, or fail to update resilience decisions after a material change.

That is why Article 8 works best when it is treated as a living source of truth, not a one-off compliance artefact. For a broader view of the regulation and its related obligations, the EU Digital Operational Resilience Act (DORA) page is the authoritative starting point.

What Must Be Identified and Documented

The article focuses on four linked layers: the business function, the ICT assets that support it, the roles and responsibilities around it, and the interdependencies that connect it to other services and providers. Those dependencies may be technical, organisational, or third-party based, and the control only works if all three are visible together.

In practice, this means the register should show more than system names. It should capture ownership, criticality, upstream and downstream dependencies, and the points where a change in one layer can affect another. The point is to support analysis of operational resilience, not to create a static asset catalogue.

Because DORA is a financial-sector regime with multiple overlapping obligations, mapping Article 8 into a larger compliance model is often useful. NHIMG’s Financial Services Cyber Regulation Map helps situate DORA alongside other financial cyber rules, while the Regulations and Frameworks Guide shows how control mapping can be organised across regimes.

Why the Inventory Must Stay Current

Article 8 is especially sensitive to change. A stale inventory can quickly become misleading if a function is migrated, a supplier changes, an application is retired, or a support model shifts. In resilience terms, outdated documentation is dangerous because decisions made from it may be technically correct for last quarter and wrong today.

Major changes matter because they can alter criticality, restore order, dependency chains, and who is accountable for response. This is where Article 8 connects directly to operational resilience management: the inventory must evolve as the environment changes, or the organisation loses visibility into what it actually depends on.

That is also why firms often pair the register with broader change and third-party governance. The Regulatory Change Management Guide is useful for the process side, and the DORA ICT Third-Party Risk and Register of Information Guide is useful where supplier and subcontracting data form part of the evidence base.

How Article 8 Supports Resilience Assessment

The real purpose of the article is to make resilience measurable. When firms can trace a service to its enabling assets, owners, and dependencies, they can assess what would fail first, what must be restored first, and where a single weak link could create a wider outage or governance problem.

That also makes the inventory useful for testing, scenario analysis, and board-level oversight. A well-maintained Article 8 register does not eliminate risk, but it reduces blind spots and gives the organisation a defensible basis for prioritising remediation, continuity planning, and dependency management.

For linked operational resilience work, the Disaster Recovery Plan Template is a natural companion because recovery sequencing depends on the same dependency map that Article 8 expects firms to maintain.

Risk and Threat Considerations

Article 8 fails when the inventory is incomplete, outdated, or too shallow to expose real dependencies. That creates a resilience risk because hidden ICT links, unclear ownership, and untracked changes can delay impact analysis, weaken testing, and make recovery decisions dependent on assumptions rather than evidence.

Failure mechanism: If business functions, assets, roles, or interdependencies are missing or stale, the firm may misclassify criticality, overlook concentration risk, or restore services in the wrong order after disruption.

Impact: The result can be longer outages, incomplete incident response, weaker governance over third parties, and a poor basis for supervisory review or internal accountability.

Practitioner Guidance

Why practitioners should care: Article 8 works only when ownership and update discipline are explicit. Assign clear accountability for each business function and its supporting ICT dependencies so the register remains current as systems, suppliers, and operating models change.

What to watch for: The biggest warning signs are orphaned records, unclear mapping between functions and supporting assets, and dependency data that is not refreshed after major change. Those are the conditions that most often turn a compliance inventory into a false comfort document.

Related resources from NHI Mgmt Group

• Guide: DORA Guide
• How should financial organisations implement data discovery to meet DORA Article 8 requirements?
• What does the article say is missing from MCP deployments?
• How should security teams prove DORA compliance for AI agents that act autonomously?
• When does just-in-time access help most in DORA evidence collection?