IT EN
Start a trial

Operational notes Observatory

Who can actually read the data? The DPIA said one thing, the permissions said another

8 min read

A wall of numbered lockers along a corridor, with keys left in some of the locks and sticky notes on the doors, in black and white
The number on the door says who the locker belongs to. The key left in the lock says who can open it.

On 28 July 2026 the National Data Guardian for health and social care in England — Dr Nicola Byrne, the independent figure who advises the health service on the use of patient data — updated a statement first published on 3 June about the Federated Data Platform, the English NHS data platform whose supplier is Palantir. The update sets out NHS England’s answer to a request for clarification. The substance takes two lines: the data protection impact assessment the office had reviewed said access to identifiable patient information was limited to NHS staff; staff working for external suppliers have that access too.

This is not a penalty and it is not a finding of breach. It is something that matters more to anyone buying technology: proof that a compliance document and a system’s actual configuration can diverge for months without anyone noticing — not even the people whose job was to read that document.

The facts, in order

  • 3 June 2026 — the National Data Guardian publishes the statement, prompted by members of the public who contacted the office through the “Not With My NHS Data” campaign. It records that the office reviewed the programme’s data protection impact assessment (DPIA) “alongside the Information Commissioner’s Office”, as part of its advice on information governance.
  • The point at issue — the DPIA reviewed “stated that access to identifiable patient information would be limited to NHS staff with a legitimate need”. Media reporting and subsequent confirmation from the programme team indicate instead that “some external contractor staff also have access to identifiable patient information within the National Data Integration Tenant (NDIT) environment”, associated with the platform. Verbatim: “We were not aware of this. We have therefore written to the programme to seek clarification on this inconsistency.”
  • 28 July 2026 — the statement is updated with the response. NHS England says “some external supplier staff supporting the platform can access identifiable patient information for specific technical purposes, under its direction”, and that this access is “technically necessary”. It also accepts that “the original data protection impact assessment that we reviewed did not accurately reflect the operational arrangements in place”; the National Data Guardian records that NHS England “has accepted that this was an error, for which it has apologised, and committed to correcting it”. On technical necessity the National Data Guardian adds: “As an independent body not involved in the platform’s operation we are not in a position to independently verify that assessment.”
  • 29 July 2026 — The Register (Lindsay Clark) picks up the story, recalling the £330 million contract awarded in 2023 and £60 million of covid-era contracts let without competition. An NHS England spokesperson: “We recognise that the DPIA contained an error in how it described supplier access to data so we are correcting that error, and we apologise for any confusion this has caused.”

Two clarifications most of the coverage skips. The National Data Guardian’s statement refers to “external contractor staff” and does not name Palantir as the holder of that access: the identification is made by the press, and it is plausible because Palantir is the platform’s supplier, but it remains an attribution step distinct from the source. And the Information Commissioner’s Office reviewed the DPIA jointly with the National Data Guardian’s office: no enforcement action or rebuke from the data protection authority is recorded on this point. The finding is the National Data Guardian’s.

The document describes; the permission matrix decides

A DPIA is not a control. It is a photograph. It describes which processing takes place, on what data, for what purposes, and who has access. The control — the thing that actually decides who reads what — lives somewhere else: in roles, groups, grants on tables and views, tenant configuration. When photograph and configuration diverge, the photograph does not govern.

The second-order consequence is more awkward than the first. An inaccurate description does not merely produce a wrong document: it produces unfounded assurance in everyone who relies on it. The board that approves, the regulator that reviews, the citizen who reads the privacy notice. All of them read the same sentence and drew the same conclusion. None read the list of entitled users, because none of them has the mandate or the tooling to do so. That is what the National Data Guardian puts in writing when it says it cannot independently verify. The assurance chain breaks at one identifiable point: the reviewer reads documents, and the documents are written by the party being reviewed.

“Technically necessary” is an assertion, not evidence

The phrase NHS England uses is the most common in supplier relationships and the least verifiable as it stands. Making that assertion verifiable means writing down other things: which concrete operation requires the access (a migration, a defect investigation, rebuilding a pipeline), for which named roles, over which tables and fields, whether identifiers are visible in the clear or masked at the query layer, for how long, with what session logging, and who reads the logs back. None of this is published.

And then the question that is always missing: what would replace that access. Pseudonymisation at the query layer, a reproduction environment on synthetic data, time-limited access granted case by case with a traceable approval. If no alternative has been assessed in writing, “necessary” means “this is how it was built”, which is not the same statement.

Under the GDPR this scene has article numbers

The case is British; the structure is the same wherever the GDPR applies. If an organisation’s impact assessment, record of processing and privacy notice all say “internal staff only” while the permission matrix says otherwise, the number of wrong documents is not one but three:

  • Article 35(7)(a) — the impact assessment must contain a systematic description of the envisaged processing. Systematic description, not intended description.
  • Article 30(1)(d) — the record of processing must state the categories of recipients to whom data are disclosed. A supplier with access to the environment is a recipient, even “for technical purposes only”.
  • Article 13(1)(e) — the privacy notice must state the recipients or categories of recipients. This is the document on which the data subject builds their expectations: here European law says, in different words, what the eighth Caldicott Principle says in the UK — the “no surprises” principle, which the National Data Guardian cites expressly.
  • Article 28(3) — the processor contract requires documented instructions from the controller (point a) and a confidentiality undertaking from the persons authorised to process the data (point b). “Under its direction” is exactly this, and it is demonstrated by a written act, not by operational custom.

Above all of them, Article 5(2): the controller must be able to demonstrate compliance. Demonstrate, not assert. The buyer is the controller, and the duty to keep documents and configuration aligned does not transfer with the contract — who does what between the party selling and the party using is the first thing to put in writing.

What to do, before somebody else asks

  1. Attach the actual permission matrix to the DPIA, not a description of it: role, environment, reachable tables and fields, visibility of identifiers, who grants and who revokes. A system-generated extract, dated.
  2. Treat every supplier access as processing to be authorised in writing: documented instructions, a list by role of the persons authorised, a confidentiality undertaking, a duration, and the procedure for closing it.
  3. Date the review. An impact assessment is not a start-up document: reread it at every change of environment, tenant, sub-processor or support arrangement.
  4. Make three texts agree — impact assessment, record of processing, privacy notice. If they disagree with each other, the disagreement is already the finding: it does not take an inspection to discover it.
  5. Require evidence instead of a statement: an extract of permissions from a live environment, session logs for supplier access, and the ability for someone other than the supplier to read them back.

We have looked at the same platform from two other angles — how you measure whether a system actually worked and who answers for the benefit figures — and in both the subject was the measurement of outcomes. This is a different matter: who opens the door. It is the same question that surfaced when London called the supplier “an unacceptable point of weakness” in its public infrastructure.

The architectural point

The fewer external people who need to enter the environment, the fewer documents have to describe their entry — and the fewer opportunities there are for description and configuration to drift apart. That is why we work in two delivery modes, and only two: on-premise, with the AI installed in the client’s own environment, or on a dedicated cloud reserved for the single client, with a dedicated VPN, a data centre in Italy and premises staffed directly by us. In both, the permission matrix is readable by the client at any time, and the list of who has access is a document the client signs rather than receives. Where the models run and who owns the infrastructure is the other half of the same question: we have written it down.

Want to know whether your impact assessment still describes the system you are actually running? Half an hour with one of our specialists to compare the documents against the real permissions.

Sources