Where Should Your Users' Most Sensitive Data Live?

A scanned passport is not “just a file attachment.” A single image exposes a full name, a date and place of birth, a nationality, a document number, and a face. Under the EU’s GDPR, a facial image used to identify someone is special-category data — the kind that carries the strictest legal duties — and the same record is a textbook target for identity fraud the moment it leaks. The instant your product accepts one, you’ve crossed a line: from “handle with care” to “handle like it could end the company.”

Plenty of teams never notice they’ve crossed it. The upload field looks the same whether it’s holding a meme or a birth certificate. So this is a short, practical guide to the decisions that actually matter once sensitive data enters your system — starting with the one most teams get wrong: where the data should physically live.

Not all data is equal

The first move is to stop treating “personal data” as one bucket. A shipping address and a scanned national ID card are both personal data, but they are not in the same risk class. Most privacy regimes single out a tier of especially sensitive information — health records, biometric and facial data, financial details, government identity documents — and attach heavier obligations to it.

If your product touches that tier, two things follow. Encryption, isolation and auditing stop being “nice to have” and become the baseline. And the question of where that data is stored, and who can be compelled to hand it over, becomes a design decision you make on purpose — not a side effect of whichever hosting checkbox was fastest.

The no-code trap

When a sensitive-data product needs to ship quickly, the tempting shortcut is a no-code or low-code SaaS builder. Drag a form, connect a database, done. For an internal tool or a marketing microsite, that’s a perfectly good trade. For passports and medical records, it’s the wrong foundation — for one structural reason.

With most no-code platforms, your users’ documents sit on infrastructure you don’t control, and the platform itself can usually read them. That’s not a bug you can patch. It’s the architecture.

Few of these builders offer true end-to-end encryption, which means the vendor — and anyone who compromises the vendor, or subpoenas it — can see the raw files. You inherit their breach history, their data-handling practices and their jurisdiction, whether you understand them or not. For the most sensitive class of data, convenience tooling isn’t a shortcut; it’s a liability you’ve quietly taken onto your own balance sheet.

Where the data physically sits matters

Here’s the part that surprises people: encrypting your data and choosing a “reputable cloud” is not the end of the story. Two different things are in play.

Data residency is where the bytes physically live — which country’s data centre holds them. Data sovereignty is whose laws govern them, which is not always the same answer. A US-headquartered provider can be compelled, under laws such as the US CLOUD Act, to hand over data it controls — even when those bytes physically sit on a server in another country. Residency in Frankfurt doesn’t help if the company holding the keys answers to a court in another hemisphere.

The practical consequence: for genuinely sensitive workloads, you want the data hosted in the jurisdiction it should answer to (often the EU, or another strong-privacy jurisdiction), on infrastructure operated under that jurisdiction’s law — and, ideally, with the encryption keys held by you rather than the platform. That combination is what keeps a foreign subpoena from quietly becoming your problem.

Often, two regimes at once

It’s rarely one rulebook, either. The moment you serve users in the EU from a company based elsewhere, you’re likely subject to more than one regime at the same time — your local data-protection law and the GDPR, each with its own definitions, its own duties and its own penalties.

This is not theoretical. European regulators have issued well over €6 billion in GDPR fines across thousands of cases, the largest single penalty north of a billion euros — and some national laws go further, attaching personal liability to the individuals responsible, not just the company. “We didn’t realise the platform stored it that way” has never been a successful defence.

Build it right the first time

None of this requires heroics. It requires deciding these things deliberately, early, instead of discovering them during an incident. The checklist we hold ourselves to for any system handling sensitive data:

• Isolation at the database and API layer, not just the UI — one tenant can never reach another’s records, even with a crafted request.
• MFA on every account, with encryption in transit (TLS) and at rest as table stakes.
• Keys you control, wherever the threat model justifies it — so the platform operator can’t read the data.
• A full audit trail of every access, change and approval, with retention and deletion rules that match the law you operate under.
• Deliberate data residency — host where the data should legally live, not where signup was fastest.
• A real security review and penetration testing before launch, not after the first breach disclosure.
• Self-hosted over no-code for the sensitive core, so the architecture is yours to reason about.

What this means for you

The uncomfortable truth is that the expensive moment isn’t the breach — it’s the original decision to treat sensitive documents like ordinary attachments. Everything downstream, from the fine to the lost trust to the emergency re-platforming, flows from that one shortcut.

Building it right the first time costs more than the no-code demo and far less than any of the alternatives. If your product is about to start collecting identity documents, health data or anything in that top tier, the time to make these calls is now — while they’re still architecture decisions, not incident-response ones. That’s exactly the kind of system we’re built to design and run.