Data residency and remote support: where the traffic actually goes

Why remote support traffic is not always local

Direct device-to-device remote access is not always practical because of firewalls, network address translation and the need for connections to work reliably from any location. Most commercial remote support tools solve this by routing the connection through a relay server operated by the vendor, and by storing session metadata, and sometimes recordings, in the vendor's own cloud infrastructure.

This is a normal and sensible engineering approach, and it does not automatically create a compliance problem. What it does create is a question worth answering: where, physically and legally, does that relay and storage infrastructure sit, and does that location matter for your organisation's own obligations.

UK GDPR and international transfers

UK GDPR restricts transferring personal data to a country outside the UK unless that country has been assessed as providing adequate protection, or an appropriate safeguard, such as the UK's International Data Transfer Agreement or the UK Addendum to the EU's Standard Contractual Clauses, is in place. If a remote support vendor's relay or storage infrastructure sits in a country without a UK adequacy decision, and no other safeguard has been agreed, that could constitute a restricted transfer requiring further action.

It is worth being precise about what counts as the personal data in question here. Session metadata, showing who connected to what and when, is personal data in its own right, so the transfer question applies to logs and audit trails even in situations where no full session content is captured or stored.

• Check whether the vendor's infrastructure location has a UK adequacy decision or equivalent
• Confirm what safeguard, such as an International Data Transfer Agreement, applies if it does not
• Remember that metadata and logs count as personal data for this purpose, not only screen recordings

Sector and contract requirements beyond data protection law

Data protection law sets a floor, not necessarily the whole picture. Some sectors, contracts or specific clients impose stricter residency requirements than UK GDPR alone would require, for example a requirement that all data remain within the UK regardless of adequacy status elsewhere, often driven by sector-specific risk appetite, national security considerations, or a particular client's own contractual demands.

Public sector and health and care organisations in particular may find that their own contracts, or frameworks such as those from the Crown Commercial Service, specify residency expectations that go beyond the general data protection baseline. Checking the specific contract or framework terms that apply to your organisation, rather than assuming general data protection compliance is sufficient, avoids an unwelcome surprise later.

Questions to ask a remote support vendor

Ask, specifically, which country or countries the vendor's relay infrastructure and data storage are located in, and whether that can vary depending on how the connection routes, since some global services dynamically select the nearest available server, which can mean traffic sometimes leaves the country you expect. Ask whether a UK-only or EEA-only hosting option exists if that matters to your organisation.

Ask, too, which subprocessors the vendor relies on, since a vendor's own infrastructure being UK-based does not necessarily mean every subprocessor in the chain is. A vendor able to name its subprocessors and their locations, and provide a data processing agreement reflecting that, is giving you the information needed to make an informed decision rather than an assumption.

• Where is the vendor's relay infrastructure physically located, and can this vary by connection
• Is a UK-only or EEA-only hosting option available if required
• Which subprocessors are involved, and where are they located

What good practice looks like

Good practice is not necessarily insisting that every remote support vendor must be UK-only; it is having a clear, documented answer to where data goes, checked against your organisation's actual obligations, rather than an unexamined assumption. For many organisations, a vendor with clearly stated UK or EEA hosting and a named list of subprocessors will meet the requirement comfortably; for others, particularly those with specific contractual residency clauses, more scrutiny will be needed.

A tool that is explicit about its infrastructure and provides a data processing agreement, alongside features such as encrypted sessions and audit logging, of the kind associated with 247connect, gives an organisation the documentation to answer a data residency question directly rather than by inference. The underlying assessment of whether that location meets your specific obligations is still one you or your data protection adviser need to make.