Register Data and Locations

Data and location entries record two linked facts about each ICT arrangement: what data the service touches, and where the relevant activity happens. Data might include customer records, transaction records, internal operational records, or other information the service needs to function. Location might cover where data is stored, where processing takes place, and where the provider's relevant operations sit. Together, those facts let a reader follow a service beyond the provider's name and see the flow of information and the geography of dependence that sit underneath a contract.

These entries are sometimes treated as background detail, added last and checked least. That is a mistake. Data and location shape supervisory interest, incident response, and exit planning in ways that provider names alone cannot. A service that processes customer data in one place raises different questions from a service that only carries anonymised operational data elsewhere. This guide explains what to record, how to describe data without overstating precision, and why location changes deserve the same register discipline as provider changes.

Data in the register means the information the ICT service handles in order to do its job. That could be data the entity supplies to the provider, data the provider generates while delivering the service, or data that passes through the service on its way elsewhere. The register should describe the categories involved in terms a reader can understand, such as customer account information, payment transaction information, or internal risk information, rather than using internal system labels that mean nothing outside one team. The aim is a faithful summary, not a data inventory at field level.

Location matters because ICT services are not placeless, even when they feel that way to users. Data may be stored in one place, processed in another, and supported from a third. Each location can affect which supervisory questions arise, which legal and operational arrangements apply, and how quickly support can respond. A service whose operations sit far from the entity's own teams may still work perfectly well day to day, but an incident response that assumes nearby support will be slower than expected if that assumption is wrong.

Location also matters for concentration. Several apparently separate arrangements may share a location, a facility, or a regional operation, so a local disruption affects more than one service at once. The register makes that shared exposure visible only if location entries are consistent enough to compare. That consistency is a format discipline as much as a content discipline, and the guide on format and templates explains how consistent location descriptions support comparison across entries.

Data movement is often the hardest part of this section to keep accurate, because movement can change without a new contract. A provider may re-route processing, add a support location, or change a hosting arrangement within the scope of an existing agreement. If the register only records the original setup, it will miss those shifts. The remedy is to treat location and data changes as register events in their own right, triggered by provider notifications and by the entity's own change process, rather than as details to catch up at reporting time.

Checking data and location entries means comparing them with the contract, with provider documentation, and with what the service actually does. A sample check can ask, for a set of arrangements, whether the recorded data categories match the contract's data description, whether the recorded locations match the provider's stated hosting and support arrangements, and whether any recent provider notification has been reflected. Discrepancies should be corrected and, where the pattern repeats, the update process should be fixed at its source.

A second check is internal consistency. Entries for the same provider should describe locations in comparable terms, and entries for the same function should not contradict each other about where its data sits. Inconsistency does not always mean error, since different services from one provider may genuinely operate differently, but unexplained inconsistency deserves a question. When data and location entries pass both checks, the register gains a quiet strength: it can answer, for any arrangement, what information is at stake and where it lives, without a separate investigation.