Outsourcing and Data Location

Outsourcing and data location concern where the data behind a service is stored, where it is processed, and from where it can be accessed, when any of those steps involve an outside party. A provider may describe a service as hosted in one place while copies, backups, support access, or analytics processing touch other places. Under DORA, a financial entity needs to understand that full picture for the data that supports its services, because location affects recovery, regulatory access, and the legal position of the data. A region label on a sales page answers only the first question, where the main store sits. It does not answer where a backup can be restored from, where support staff can view data, or where a sub-provider processes it.

Three kinds of location are often confused. Storage location is where data rests, including primary stores and backups. Processing location is where data is transformed, analysed, or used to make a decision, which may differ from storage when a service calls another tool. Access location is where people or systems can view or retrieve data, including provider support, managed service staff, and sub-providers. A wealth management service, for example, might store client records in one area, run portfolio calculations through a tool hosted elsewhere, and allow provider support engineers in another area to view records while resolving an incident. Each location needs to be known and governed. A map that records only storage will miss the processing and access routes through which data actually moves.

Location also shapes recovery in ways that are easy to miss. If primary data and its backup sit in the same area, a wide failure affecting that area can remove both the service and its means of recovery. If backup data sits elsewhere but in a form that cannot be loaded quickly, or without the keys and configuration needed to use it, recovery is delayed even though a copy exists. If data is replicated to another area but replication lags behind live writing, recovery from that copy may lose recent transactions or produce inconsistent records. Recovery planning therefore needs to treat location, freshness, and usability together, and to rehearse restoring from the actual copy that would be used, rather than assuming that a backup setting implies a recoverable service.

Changes to location are a particular risk because they can happen without a visible change to the service. A provider may move a workload, add a support centre, change a sub-provider, or introduce a new analytics feature, each of which can shift where data is processed or accessed. Contract terms on notification and consent for location changes are therefore part of resilience, not merely part of data protection. The firm needs to know what changes require notice, what changes require agreement, and what information will accompany a change, so that its data map stays current. A map that was accurate at signing and never updated is a historical document. It will not help during a disruption that involves a location the firm no longer knows about.

Sub-providers extend the location question further. A provider that outsources part of its own service, such as hosting, support, or a specialised processing step, creates a chain of locations that the firm may not see directly. DORA's approach to ICT third party risk recognises that chain, expecting the firm to understand material sub-contracting and its effect on the service. The practical response is not to demand a map of every minor component, but to identify the sub-providers that touch important data or a critical step in the service, to record their locations and roles, and to ensure that contract and governance arrangements reach far enough to preserve information, access, and recovery across the chain.

The evidence for sound data location governance is a living data map, tied to services rather than to vendors in the abstract. For each service, the map records the data involved, where it is stored, processed, and accessed, which parties are involved at each point, and when the map was last confirmed. It also records location changes, the decisions taken about them, and the recovery implications of the current arrangement. That record supports incident handling, because the firm can say quickly where affected data sits. It supports exit, because the firm knows what must be retrieved and from where. Above all, it prevents the most common failure in this area: discovering the location of important data for the first time during a disruption.