Author: lpm_admin

Most information governance problems in data programmes are architecture problems that were left to the governance team to solve at the end.

The pattern that avoids the largest share of them is pseudonymisation at source. It is well documented, it is not new, and it is still skipped — usually because it is seen as a compliance step rather than a design decision. Patterns I designed on this basis have been running in live NHS services for more than a decade.

What it means

Identifiers are replaced with pseudonyms at the point the data leaves the source system, before it reaches the analytical platform. The key that would let you reverse it stays with the source, held separately, under different access control. The analytical environment never holds identifiable data at all.

The distinction that matters is where it happens. Pseudonymising on arrival into the warehouse — which is what most implementations actually do — means identifiable data has already crossed the boundary, been logged, been backed up, and landed in whatever staging area the pipeline uses.

Why it changes the governance conversation

• The DPIA gets simpler. You are assessing a flow that does not carry identifiers, rather than arguing about controls on one that does.
• The risk surface shrinks to something you can describe. A breach of the analytical platform does not expose identifiable records.
• Data minimisation stops being an assertion. It is structurally true, and you can demonstrate it to an auditor in the architecture rather than in a policy document.
• Re-identification becomes an explicit, controlled act. Where clinical care genuinely requires it, that is a deliberate authorised step with its own audit trail — not the default state of the platform.

Where implementations go wrong

The pseudonym is derived from the identifier without a secret. A plain hash of an NHS number is reversible by anyone who can generate hashes of candidate numbers. It needs a keyed function with the key held separately.

Consistency is not thought through. If you need to link the same person across sources or over time, the pseudonym has to be stable and consistent across them. That is a design decision with real consequences, and retrofitting it is painful.

The key ends up in the same trust boundary. If the key is held by the same team, in the same environment, under the same credentials as the pseudonymised data, you have documentation of separation rather than separation.

Free-text fields are forgotten. Structured identifier columns get handled; clinical notes containing names and addresses go through untouched. This is the most common failure I see.

If you are retrofitting

Most organisations are not starting clean. The sequence that works: map the flows and find where identifiers actually cross the boundary; fix the highest-volume flow first to prove the pattern and the linkage design; move the key out of the analytical trust boundary; then work through the tail. Do not try to do all flows at once, and do not start with the politically hardest one.

If a data-sharing or analytics programme has stalled on information governance, it is often this. Get in touch.

A data platform bill that climbs every quarter is not usually a pricing problem. It is a design problem that shows up on an invoice.

I took a platform from £1.8M a year to £900K without reducing what it could do. Here is what actually moved the number, roughly in order of how much it returned for the effort spent.

1. Find out what you are actually paying for

Almost every organisation I have done this with started in the same place: nobody could attribute spend to workloads. Consolidated invoices, shared resource groups, no tagging discipline. You cannot negotiate or optimise what you cannot attribute, so the first job is unglamorous cost allocation — by workload, by team, by dataset.

This step alone usually finds something embarrassing. Mine found a development cluster that had been running continuously for fourteen months.

2. Separate storage decisions from compute decisions

These get conflated and they have completely different economics. Storage is cheap and grows predictably; compute is expensive and spikes. Most of the runaway cost in the platforms I have reviewed was compute — idle clusters, oversized warehouses, and scheduled jobs that no longer had a consumer.

Tiering cold storage is worth doing. It is rarely where the money is.

3. Kill the pipelines nobody reads

At portfolio scale there is always a tail of datasets and refreshes built for a report that somebody stopped opening two years ago. Instrument consumption, publish the list of unread outputs, and give owners a deadline to claim them. Most are never claimed.

This is a governance intervention wearing a cost-saving hat, and it improves the platform beyond the saving — less to maintain, less to explain, less to break.

4. Right-size on evidence, then commit

Once workloads are attributed and the dead weight is gone, right-size against actual utilisation rather than the sizing somebody guessed at procurement. Only then commit to reserved capacity or a discount agreement — committing early locks in your own waste at a discount, which feels like a saving and is not.

5. Make cost a design review criterion

The saving decays unless something structural changes. Put a cost question into architecture review: what will this cost at expected volume, who owns that budget, and what is the decommission trigger. It takes ten minutes and it is the difference between a one-off saving and a platform that stays affordable.

What I would not do

I would not lead with a vendor migration. Moving platforms to save money is a large, risky programme that usually costs more than the disciplined version of the five steps above, and it defers the governance work that caused the problem. Sometimes migration is right — but not as a cost-reduction tactic, and not first.

If your platform spend is climbing and you cannot say which workloads are driving it, that is a two-to-five day piece of work. Get in touch.