Business impact analysis gets all the attention, and then it stalls, because half the workshop is spent arguing about what the function actually consists of. That argument is a symptom: the mapping that should precede the analysis was never done. DORA puts it first for a reason.

Identification comes before analysis

Article 8 sits in the ICT risk management framework under identification. Before you assess anything you are expected to identify and document the business functions supported by ICT, the information assets and ICT assets that support them, and the dependencies between them. It is the least glamorous obligation in Pillar 1 and the one that quietly determines whether everything downstream holds together.

Skip it and the failure mode is predictable. The business impact analysis is run against application names rather than business processes, so the answers describe technology outages instead of business harm. The designation that follows inherits the same confusion, and the register ends up listing contracts against services nobody can trace back to a function.

The four layers you need on paper

1. Business functions and processes

Written in the language the business uses, not the language of the service catalogue. "Retail payment initiation" is a function. "PaymentHub" is an application that supports it. If your top layer is full of product names, the mapping has started one level too low.

2. ICT services

The services consumed to deliver each function, whether internal or bought. This is the layer that will later have to reconcile with the services listed in your register, so the naming you choose here is the naming you live with at submission.

3. ICT assets

Applications, systems, data stores and the infrastructure beneath them. Most entities already have a configuration database that covers part of this. The gap is usually the link upwards: the CMDB knows what exists, but not which business function stops when it does.

4. Dependencies

Both directions, and this is where the work actually is. Which assets does a function depend on, and which functions depend on a shared asset. Shared components are where concentration hides: one authentication service quietly sitting under nine functions, four of which you intend to call critical.

Getting the granularity right

Too coarse and the map says nothing useful; too fine and it will never be maintained. A workable test: a function is at the right level if you can state a single tolerance for it and name one accountable owner. If a candidate function needs three different tolerances, it is really three functions. If two candidates share a tolerance and an owner, they are one.

The same test applies downward. Decompose an ICT service only as far as the point where a different provider or a different contract could supply it. Decomposition beyond that produces rows nobody can source and reconciliation work nobody can finish.

What the map has to survive

  • Reconciliation with the register. The functions in your mapping must be the functions your register refers to. Two vocabularies is the most common cause of an inconsistent submission, and it is entirely self-inflicted.
  • A shared-asset question. A reviewer picks one asset and asks which functions rely on it. If the map only runs top-down, that question has no answer.
  • Change. A mapping produced once for a project is stale within a quarter. It needs an owner and a trigger, typically change management, so that a new integration updates the map when it goes live rather than at the next audit.
  • Annual review. The framework is reviewed at least annually (Article 6(7)), and the mapping is the part of it most likely to have drifted.

A sequence that works

Start from the business side, not from the asset inventory. Interview process owners and write the function list first, ten to forty entries for most mid-sized entities. Then ask each owner which services they consume, and only then join to the existing configuration data. Teams that start from the CMDB produce a technically complete map that no business owner recognises, and the workshops that follow spend their time translating instead of deciding.

Record dependency direction as you go. It is nearly free at capture time and expensive to reconstruct later, and it is what turns a list into something that can answer a cascade question: if this provider is unavailable, which functions degrade, in what order, and how long before any of them crosses its tolerance.

Where this connects

The mapping is the input to three things you will build next: the impact analysis that puts numbers on disruption, the critical or important designation that those numbers support, and the register of information that records which contracts carry those functions. Every one of them assumes the map exists. Building them in the other order is why so many registers fail their consistency checks.

Frequently asked questions

Is a CMDB enough to satisfy Article 8?

Rarely on its own. A configuration database usually records assets and their technical relationships but not the business functions above them or the tolerances attached to those functions. It is a strong foundation and an incomplete answer.

How detailed does the dependency mapping need to be?

Deep enough to answer which functions fail when a given asset or provider does. Multi-layer cascade modelling is useful for complex estates, but a single layer that is accurate and maintained beats three layers that are neither.

Do we map intra-group services too?

Yes. An intra-group provider is still an ICT third-party arrangement for register purposes, and functions supported from inside the group fail exactly like functions supported from outside it.

Who should own the mapping?

One owner for the model, usually operational resilience or ICT risk, with the function rows owned by the business and the asset rows owned by ICT. Split ownership without a single custodian is how two vocabularies appear.