Why the region decision is bigger than it looks
Picking a cloud region feels like a dropdown. You choose UK South, you move on, and the decision looks closed.
It is not closed, because everything you add afterwards has its own region setting, and the defaults rarely match yours. Six months later a system that is nominally hosted in the UK is emitting data to four other places, and nobody made a decision to allow it. They just accepted defaults.
This is why the region belongs in the first week rather than the first sprint. It is one of the six architectural decisions we make before writing application code, and the reason it comes first is that everything else inherits from it.
What the region choice actually propagates into
The last row surprises people. Support access is a real data flow, and it is worth knowing what your provider's support tier can reach before you need to open a ticket during an incident.
The harder question is access, not storage
You can point at a region on a map. That makes storage feel like the whole problem, and it is why teams answer the residency question by naming a region and stopping there.
Access is the other half. If a developer three time zones away can open a production console and read patient records, the location of the disk describes only part of what is happening. Any honest answer to "where does this data go" has to cover people as well as infrastructure.
This is not an argument against distributed teams. It is an argument for deciding, deliberately and early, what your own engineers can see.
How we handle it, as a team outside the UK
We are based in Wrocław and a large part of our work is for clients in the UK. The question of who on our side can reach production data comes up in every serious conversation, and it deserves a concrete answer rather than a reassuring one.
What we set up:
No standing access to production data
Not as a policy sentence, as a configuration. The default state for an engineer is that production data is not reachable.
Non-production environments get synthetic or anonymised data
This is the change that removes the most risk for the least effort, and it is the one most often skipped because it takes work upfront and delivers nothing visible.
Break-glass access, with approval and a record
Sometimes someone genuinely needs to see production to fix something. That path exists, it requires approval, it is time-bound, and it leaves a trail that answers the question afterwards.
Support tooling that redacts by default
If your error tracker captures request payloads, it is a patient data flow, and it needs the same treatment as the database.
All of it written into the DPA rather than described in a call
The contractual position and the technical reality should be the same document's worth of truth.
What about the legal side?
Briefly, and with a boundary.
The EU adopted renewed adequacy decisions for the UK in December 2025, valid until December 2031, so transfers from the EEA to the UK currently rest on that basis rather than on additional safeguards. Adequacy is subject to ongoing monitoring, which means it is a condition to keep an eye on rather than something to design as permanent.
Beyond that, we are engineers and not lawyers. Whether a specific arrangement is lawful is a question for your DPO or counsel. What we can tell you is that the architecture decisions above determine how easy that question is to answer. A system where you can enumerate every place data lands and everyone who can reach it is a system where the legal question takes an afternoon. A system where you cannot is one where it takes a project.
What to decide in week one
Four things, none of which take longer than a conversation:
- The region, and the list of every service that will inherit it. Write the list down. It is the artefact you will be asked for later.
- Where backups and disaster recovery land, checked rather than assumed.
- What your observability stack captures, and whether payload capture is on.
- What your own team can see by default, and what the exception path looks like.
None of these are expensive now. All of them are awkward to change once you have users, and the last one is awkward to change once you have habits.
