An EU-based SaaS product runs entirely in Frankfurt. Its 24-hour support rota includes engineers in a country without an adequacy decision, who can view customer records to diagnose issues. Legal flags this as a cross-border transfer. Which control best addresses the finding?

The deciding property

Remote access is a transfer. Data does not have to move for a transfer to occur: making it viewable from a third country is enough, which is why an architecture diagram showing one region does not settle the question. Once that is accepted, the engineering question becomes what is actually visible from there, and that is a design decision rather than a legal one.

The second deciding fact is that most support work does not need the personal data. A diagnosis usually requires the error, the timeline, the configuration and the shape of the record — not the customer's name, address or transaction detail. Reducing what support sees by default addresses the transfer at its source and improves security at the same time, which is why it beats purely paper-based controls.

The design

• A diagnostic view by default: identifiers, status, timestamps, error codes, structural metadata. Enough to answer most tickets.
• Case-based elevation for the exceptions, time-boxed, approved, and logged with the ticket reference, so access is an event with a reason rather than a standing capability.
• Elevation fulfilled inside the region. The case that genuinely needs the full record is handled by an in-region engineer during their hours, which turns a continuous transfer into a small number of documented ones.
• Legal instruments underneath it all. Standard contractual clauses still apply and are necessary; the point is that the technical measures reduce what they have to carry.
• Evidence by design. Access logs that show who saw which record, when, and under which case are what a transfer impact assessment actually needs.

The numbers usually support the design rather than merely permitting it: in most support organisations something like 80-90% of tickets are resolved without the personal fields, so the continuous transfer is replaced by perhaps 10% of cases handled in-region. Choose full in-region support instead when minimisation cannot reduce the exposure enough — special category data such as health records, where even the structural metadata is revealing — and accept the cost of duplicating the rota rather than pretending a paper control closes the gap.

Why the other options fail

• Contractual clauses and carry on. Necessary, not sufficient. The supplementary-measures expectation following the 2020 Schrems II judgment is precisely that the clauses be backed by technical measures where the destination's legal environment permits access that the clauses cannot prevent. A paper control against a legal power is the gap that was found.
• Move the team into the EU. Genuinely compliant, and usually the most expensive option on the list: it ends 24-hour coverage or duplicates a team to restore it. Reach for it when the data is sensitive enough that minimisation cannot reduce the exposure — health records, for example — not as the default response.
• Encryption at rest. Addresses a different threat. Support staff read through the application, which decrypts on their behalf, so storage-layer encryption is invisible to this access path. It is a control for stolen disks and backups, and citing it here suggests the access path has not been traced.

When this is the wrong answer

If the product is in a sector where the sector rules, rather than general data protection law, prohibit third-country access outright — some health and public-sector arrangements do — then no technical measure helps and the only options are in-region support or not serving that market. Check whether the constraint is a risk-based one or an absolute one before designing anything, because minimisation is a good answer to the first and irrelevant to the second.