What are the signs that a cross-border arrangement is not a transfer under the GDPR?

How to tell when Chapter V is not engaged

The key question is whether the scenario contains a transfer from an EU exporter to a separate recipient outside the EU/EEA, or whether the data subject is disclosing directly to a foreign controller. If the arrangement is simply remote access within one controller, or another structure without a distinct export step, the cross-border element alone does not make it a transfer under GDPR.

A practical way to test the boundary is to trace who is actually disclosing the data, who is receiving it, and whether the receiving party is a separate controller or processor in the transfer chain. The same fact pattern can look cross-border operationally while still falling outside Chapter V because the legal transfer criteria are not satisfied.

For the underlying rule set, the general GDPR text remains the primary reference, especially the provisions that distinguish ordinary processing from transfer-specific obligations: EU General Data Protection Regulation (GDPR).

Common fact patterns that do not amount to a transfer

Direct collection from the individual is the clearest example. If a person in the EU sends data directly to a controller abroad, the operation may be international in reach, but it is not the classic Chapter V transfer scenario because there is no EU exporter handing data off to a foreign recipient.

Remote access is the other common pattern. An employee or contractor may view or process data from outside the EEA while still acting for the same controller, so the disclosure remains inside one organisation. In that case, the location of the user does not, by itself, turn the access into a transfer. The legal analysis turns on organisational structure and disclosure path, not geography alone.

That boundary is why records, notices, and internal maps should describe the processing chain, not just the network path. A cross-border session can be operationally real while still being legally ordinary access rather than a transfer event.

For related governance and control expectations around data handling, classification, and access management, CIS Controls v8 and the NIST Privacy Framework are useful complements.

Practitioner checks for boundary cases

When the pattern is unclear, focus first on the legal roles and the direction of disclosure. If the foreign party is not receiving data from an EU exporter, or if the access is merely remote administration by personnel acting within the same controller, the transfer analysis may stop there. If, however, data is being sent to a separate foreign entity for its own purposes or to a processor in a true transfer chain, Chapter V analysis resumes.

What to verify: confirm who decides the purposes and means, whether the data is disclosed or merely accessed, and whether the foreign party is a separate controller, processor, or just a remote user within the same controller. That distinction should be visible in contracts, internal processing maps, and privacy notices.

Common mistake: treating every offshore login or every overseas recipient as a transfer. That shortcut overstates Chapter V in some cases and can obscure the real compliance question, which is whether a transfer relationship exists at all.

Practitioner takeaway: classify the arrangement by disclosure path and legal relationship first, then apply Chapter V only if there is a real exporter-to-recipient transfer structure.

Related resources from NHI Mgmt Group

• What are the signs that a cross border data transfer process is too weak?
• What breaks when cross-border transfer controls are not mapped to data flows?
• Who is accountable for cross-border signature governance under eIDAS 2.0?
• How should organisations respond when a cross-border transfer framework is invalidated and existing transfers suddenly rely on contractual safeguards instead?