Privacy Enhancing Technology — policies, the token vault, watermarking and the audit trail

Written for a Caldicott Guardian and an information governance lead. Every route data can leave by is a written policy carrying its lawful basis, its recipient, the categories it covers, how long it’s kept and when it’s next reviewed. Direct identifiers are swapped for tokens held in a vault that stores no identifiers. Every registered export carries a fingerprint, so a leaked extract traces back to the organisation that released it. And every access is audited, including the ones that were refused. Reached at /privacy-pet.

1 Every route data can leave by is a written policy

Ask most organisations to list the ways patient data leaves them and you get a pause, then a partial answer. A statutory return here, a shared-record connection there, a claims feed, a research extract, a social services bridge. Each was signed off by somebody, at some point, on a legal basis recorded in a document nobody can find. The PET layer at /privacy-pet makes that list a live register.

A policy is one row and it holds what an information governance file should hold: the purpose in a sentence, the recipient and whether they’re a controller, a processor or a plain recipient, the lawful basis, the categories of data, the roles allowed to use the route, the retention period in days, whether consent is required, whether pseudonymisation is required, and the date the policy is next due for review. The tiles above the table count what is active and, more usefully, what is overdue for review — in the demonstration estate that’s six of six, which is the honest state of a register nobody has touched since it was seeded.

2 Identifiers become tokens, and the vault holds no identifiers

An NHS number is the most useful column in any dataset and the most dangerous. Analysts need a stable key to join on; nobody outside direct care needs the number itself. Tokenisation gives the first without the second.

Send a value and a type to the vault and you get a token back. What is stored is a keyed hash of the value, computed with the service’s own secret, together with the token, the type, how many times it has been used and when it was last touched. The original never lands in the table. Keying the hash matters more than it sounds: an NHS number is a ten-digit space and a date of birth is smaller still, so a plain hash of either can be reversed by a laptop in an afternoon. A keyed hash can’t, without the secret.

Ask for the same value twice and you get the same token back, which is what makes a token useful as a join key across two extracts. Ask the platform to turn a token back into a person and there’s nothing to ask: no reverse lookup exists in the API. That’s a limit by design and it’s also a ceiling: this is one-way pseudonymisation and can’t act as a reversible linkage service, so a study that needs to return a finding to a named patient can’t be served by this vault alone. The vault itself is admin-only.

3 Every export carries a fingerprint that names who took it

The hardest breach to investigate is the one where a file turns up somewhere it shouldn’t be and forty people had access to something like it. A fingerprint per export turns that from an interview exercise into a lookup.

Registering an export mints a fingerprint identifier and a secret seed, and returns watermark bits derived from the two by a keyed hash. The registry then holds who took it, for which organisation, under which policy, in what format, and how many records. When an extract turns up where it shouldn’t, the console marks that fingerprint leaked with the source, flips its status, and writes a flagged entry into the access audit in the same action — so the investigation starts with a name, an organisation and a policy instead of a mailing list.

4 The audit is the product

Article 30 of the UK GDPR wants records of processing activity. What an information governance lead needs is narrower and harder: who touched what, under which policy, how many records, and what happened — including the attempts that were refused.

Each event joins three things a normal system keeps apart: the person, the policy the access ran under, and the fingerprint of the export it produced. Outcomes are allowed, denied or flagged, and the denied ones are the interesting half. The seeded trail shows a de-tokenisation attempt refused for want of the right role, and an export that was allowed at the time and later flagged when its fingerprint surfaced in a public channel. Both are the record telling the truth about itself.

5 What sits around it, and what commvita doesn’t claim

The PET layer is the governance surface. The controls that shape a research dataset itself, the secure data environment, the anonymisation tiers, k-anonymity and cell suppression, and the extract ledger recording every dataset released, live in the research module and are described in the research and secure data environment explainer instead of restated here.

Two claims worth refusing, because both are commonly made. There’s no differential privacy in this platform. No noise is added to a query result and no privacy budget is spent or accounted for, so nothing here should be described as differentially private — a wrongly accounted budget gives false assurance, which is worse than no budget at all. And cell suppression, which is real and does run on the federated query path, uses a single organisation-wide threshold instead of a different threshold per data domain. Both of those are stated here so nobody has to discover them in an assurance review.

Where it lives in commvita