Designing Citizen Services That Handle Highly Sensitive Data Safely

A citizen service that collects passports, bank statements and photographs. "Easy to use" and "safe" is a real tension, not a given.

It's worth sitting with that tension rather than waving it away, because a lot of poor design comes from pretending it doesn't exist. Some public services genuinely cannot do their job without collecting the most sensitive information a person holds. Verifying someone's identity to issue, say, a National Insurance number means asking for address proofs, a passport, a driving licence, bank statements, a photograph — the exact set of documents that, in the wrong hands, would enable identity theft against that person. The service has to be easy enough that a citizen can actually use it, and safe enough that handing over all of that is not a risk. Those two goals genuinely pull against each other. Good design is what reconciles them.

Why "we'll secure it later" is the most expensive sentence in the project

The single most damaging pattern in building sensitive services is treating security as a phase near the end — build the thing that works, then "lock it down" before launch. It fails because security that's retrofitted is security with gaps. By the time the service is built, sensitive data is already flowing through it in ways that are hard to re-architect, and the late security pass becomes a scramble to patch over decisions that should never have been made that way.

The alternative is to make security a design input from the very first decision, not a checkpoint at the end. Before a single field is collected, you ask: where will this live, who can see it, in what form, and what happens if any one component is compromised? When those questions shape the architecture from the start, security stops being a constraint bolted onto a finished product and becomes the shape of the product itself. That's what "by design" actually means.

The layers that contain the damage

No serious engineer promises a system can never be breached. What good design promises is something more honest and more useful: that if something does go wrong, the damage is contained rather than catastrophic. A few principles do most of that work — described here at the level of what they achieve, not how they're configured.

• Encrypt everything, everywhere. Data is protected both at rest and in transit, so that intercepting it or reaching the storage underneath doesn't hand anyone usable information. Encryption is the floor, not the ceiling — but a service handling passports and bank statements without it isn't a debate worth having.

• Mask and obfuscate the sensitive fields. This is the principle that most distinguishes a mature design. Even legitimate internal access should not routinely expose raw identity data — National Insurance numbers, full identifiers, document contents. By masking and obfuscating sensitive fields, the system is built so that the people and processes touching the data day to day work with protected versions of it, and the raw values are exposed only where genuinely, narrowly necessary. The effect: a compromised account or process leaks far less than it otherwise would.

• Control access tightly, and by default deny. Access is granted on the principle of least privilege — people and systems get the minimum they need and nothing more — so that the blast radius of any single compromised credential is small. Who can reach what is a deliberate, auditable decision, not an accident of how the system grew.

• Align to a recognised framework, don't invent your own. Sensitive public services should be built against an established security framework — for example, the NIST Cyber Security Framework — rather than a home-grown checklist. A recognised framework brings a structured, tested way of thinking about identify-protect-detect-respond-recover, and gives assurance teams and auditors a common language to hold the design to account.

Assume you got something wrong — then go looking for it

Even a service designed carefully against all of the above will have weaknesses its builders can't see, because builders are too close to their own work. That's why the design isn't finished when it's built — it's finished when it's been deliberately attacked. Penetration testing, run with cyber-resilience specialists, exists precisely to find the gaps before an adversary does. The right posture for any team building a sensitive service is humility: assume you're wrong somewhere, and pay someone skilled to prove it, on your terms, before launch rather than after.

Why this is a Sovereign-by-Design story

Handling citizens' most sensitive data isn't only a security question — it's a trust-and-control question, which is what sovereignty is really about. A citizen handing over their passport and bank statements is extending trust to the state, and the design of the service is where that trust is either honoured or quietly betrayed. Building it so the data is encrypted, masked, tightly controlled and tested — and so control over that data stays clearly in the right hands — is how a public service earns the right to ask for sensitive information in the first place. Convenience that comes at the cost of that control isn't convenience; it's a liability waiting to surface.

Where this leaves us

The tension between "easy to use" and "safe" never fully disappears, and any vendor who tells you it does should worry you. What disappears, with good design, is the false choice between them. You don't trade safety for usability or usability for safety — you engineer a service where the security is invisible to the citizen using it and uncompromising underneath. The work that makes that possible is unglamorous: encryption, masking, access control, framework alignment, testing. It's also the entire difference between a citizen service people can trust and a breach with a date on it.

Build the safety in from the first decision. Then prove it. Sovereign by design, secure by design — in practice, they're the same instinct.