When granularity becomes noise in the DORA register of information

by

The DORA register of information requires location data per ICT service: where the service is provided, where data is stored, where data is processed. At first glance a logical requirement. But anyone who starts populating these fields with more than one country per dimension quickly discovers that the register does not add rows — it multiplies them. The question is whether all those extra rows produce a sharper risk picture. They do not. It is noise.

The register requires location data per service across three dimensions

Template B_02.02 of the DORA register of information contains three location fields per ICT service: the country of service provision (0130), the country of data storage (0150), and the country of data processing (0160). For a contract covering multiple ICT services, these fields must be completed per service. The ITS for the register of information is explicit on this, and FAQ 60 confirms it.

For financial entities building their register, the first impulse is understandable: follow the letter of the ITS strictly and populate as granularly as possible. Take an MSP delivering managed workplace and managed infrastructure under a framework contract. The service desk operates from Budapest, the account team sits in Amsterdam, engineers work from Frankfurt and Warsaw. Monitoring data is stored in AWS eu-west-1 (Ireland) with a backup in eu-central-1 (Frankfurt), and tickets are processed in a SaaS platform hosted in the US. That amounts to three countries of service provision, two countries of data storage, and two countries of data processing. The register accommodates it. The question is what happens next.

Multiple countries per dimension multiply rows rather than adding them

As soon as a financial entity enters multiple countries per dimension, the register generates a Cartesian product. This means every combination of country of service provision, country of data storage, and country of data processing becomes a separate row. Not added — multiplied.

Back to the MSP. Three countries of service provision, two countries of data storage, and two countries of data processing does not produce seven rows, but 3 x 2 x 2 = 12. Per service. That MSP delivers both managed workplace and managed infrastructure under the framework contract, so 24 rows. Add a third service and it becomes 36. And that is for a single provider. With larger providers offering integrated services and infrastructure across multiple regions, this escalates to hundreds of records. The register quickly becomes a spreadsheet no one reads anymore.

This is not a theoretical scenario. Financial entities working with SaaS providers or with providers that distribute their infrastructure across multiple regions encounter this in practice. The question that then arises is not how to technically populate the register, but whether all those rows actually help with what DORA intends: assessing and managing ICT risks that affect operational resilience.

For risk assessment, the set of countries per dimension matters — not the combinations

The purpose of the register is not to capture every conceivable combination. The purpose is to support an adequate risk assessment of parties that materially support critical or important functions. And for that assessment, the distinction is fundamental.

From an information security and operational resilience perspective, the relevant information is the set of countries per dimension, not the combinations between them. The risk lies in the fact that data is stored in a particular country, not in the specific combination of country of service provision, country of data storage, and country of data processing. Measures are formulated at the dimension level.

Is data stored outside the EU? Then a GDPR transfer mechanism is required. Does processing take place in a jurisdiction without an adequacy decision? Then a DPIA is warranted. Is the service delivered from a country with elevated geopolitical risk? Then you assess operational continuity for that location.

None of these measures require knowledge of the specific combination. No risk committee says: "the combination of service from the Netherlands, storage in the US, and processing in Ireland requires different measures than service from the Netherlands, storage in Ireland, and processing in the US." The measure follows from the dimension, not from the intersection.

The flat format of the DORA data point model (DPM), which writes out all combinations as individual rows, is a reporting requirement. It is how the supervisory authority wants to receive data in a structured manner. That is legitimate and understandable. But a reporting requirement is not the same as a risk management requirement. The register is a means, not an end. When the granularity of the input leads to a volume that undermines the usability of the register, the instrument works against itself.

Location data at contract level, with an exception route for outliers

Financial entities that recognise this make a deliberate choice: location data at contract level, automatically inherited by all services within that contract. The reporting output complies with the DPM format, but the granularity serves risk management — not the other way around. For the vast majority of contracts, this is sufficient and defensible.

For the exception — the contract where country of service provision, country of data storage, and country of data processing materially differ per service, and where that distinction is materially relevant to the risk assessment — an exception route is needed. Not as a standard workflow, but as a deliberate exception that is documented and substantiated.

The test is always the same: does the additional granularity produce a sharper risk picture that leads to different measures? If yes, the breakdown is justified. If no, you are adding rows to a register that is already complex enough.

Sources

Originally published on DORA Solutions Insights.