When granularity becomes noise in the DORA register of information

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 https //eur lex europa eu/legal content/en/txt/html/?uri=oj\ l 202402956 is explicit on this, and faq 60 https //www eba europa eu/activities/direct supervision and oversight/digital operational resilience act/preparation dora application confirms it for financial entities building their register, the first impulse is understandable follow the letter of the its https //eur lex europa eu/legal content/en/txt/html/?uri=oj\ l 202402956 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 regulation (eu) 2022/2554 (dora) https //eur lex europa eu/legal content/en/txt/html/?uri=celex 32022r2554 — the digital operational resilience act implementing regulation (eu) 2024/2956 https //eur lex europa eu/legal content/en/txt/html/?uri=oj\ l 202402956 — the its with templates for the register of information eba — preparation for dora https //www eba europa eu/activities/direct supervision and oversight/digital operational resilience act/preparation dora application — faqs and supporting documents