This is the gold.
It is the thing we hold that is worth something. A person's record. A reading from a machine. A number a nurse typed in.
The gold came with a promise.
Whoever gave it to us was told things.
The boxes are what we do with the gold.
The boxes are the computers. They sort the gold, move it about, and let the right people use it. Without them the gold just sits there.
We like the boxes.
Right now we count the boxes first.
We ask which boxes the hospital cannot run without. Then we ask how strong each one should be.
The gold gets a mention as the thing inside the important boxes.
We ask the wrong person.
We ask the people who look after the boxes. How strong does your box need to be?
The people who look after the gold made the promise. They know what it needs. Nobody asks them.
The box people are in a hurry.
They are told: make more boxes, and make them fast. That is their job, and it is not a bad job.
Keeping the gold safe slows the boxes down. So when you ask the box people how strong a box should be, the answer is strong enough to keep going.
Nobody speaks both languages.
The gold people know the promise. They do not know boxes.
The box people know boxes. They do not know the promise.
So when a box changes, nobody can tell whether the promise just broke.
A strong box can still break the promise.
The box passed its check. The box is fine. Nobody was checking the promise. They were checking the box.
The rulebook already knows.
The rules have a line that says: if the gold is about a person, its box counts. It does not matter how small the box is or how often it is used.
That line is on the last page. The counting comes first. So people count the boxes and never turn the page.
Your turn.
A box is only needed once a month. It is full of people's records. Is it in or out?
Write the promise down so the box people can read it.
Not as a feeling. As things anyone can check. Then every time a box changes, the box people tick which lines they touched, and the gold people say yes before the box closes.
Start with the promise, written down.
Ask what was promised for this gold. Write it as things anyone can check. Then ask what any box holding it has to be.
You still get your list of boxes. You get it in the right order. And you get the boxes the counting missed.
For grown-ups.
The gold is information. The promise is the set of obligations on it. The boxes are systems. The counting is the CAF-aligned DSPT scoping exercise. The written promise is a conditions register: one line per obligation, stated as a checkable fact, owned by the information side, checked by cyber at every change. Wording below is quoted from the pages linked so you can check it.
IT COUNTS BOXES FIRST
The scoping exercise identifies essential functions, then "all information, systems and networks which support your essential functions" whose compromise would hit continuity of the service. NHS England, Scoping essential functions
BOXES ARE COUNTED OUT BY TOLERANCE
The same page allows systems to fall out of scope where disruption would only matter after "days, weeks or months, rather than hours". That is a tolerance, and a promise is not a tolerance.
THE RULEBOOK ALREADY HAS THE PROMISE IN IT
The same page says that where data is subject to UK GDPR and the DPA 2018, the underlying information, system or network "should be included in your DSPT assessment". For example: a research team's spreadsheet of patient records, used a few times a year, is in scope. This clause is written after the function scoping and the tolerance paragraph does not refer back to it.
IT ASKS THE BOX OWNERS
A1.b lists the key roles: DPO, SIRO, Caldicott Guardian, IG lead, cyber lead. Structuring teams is "a local decision". A1.c says the teams conducting cyber and IG activity are best placed to decide, under a risk appetite set "regarding the essential function(s)". No role for the owner of a particular set of information is named. NHS England, A1 Governance
THE BOX OWNERS HAVE A COMPETING GOAL
Engineering is measured on delivery. From that seat every obligation is a constraint. That is the incentive the role is built on, not a flaw. Put the "how strong" question to that seat and the floor is negotiated down. Put the "what does the gold need" question to the obligation holders and engineering gets a fixed floor to build to.
TWO LANGUAGES
A1.b requires "clear and well-understood channels for communicating and escalating risks". A2.a indicator A#7 requires DPIAs to be updated on technical change to systems. Neither defines what a relevant change looks like from cyber's side. The register is the definition. NHS England, A2 Risk management
THE PROMISE ITSELF
UK GDPR Article 5(1)(f) requires personal data to be processed in a manner that ensures appropriate security. The ICO calls this the security principle. For example: a discharge letter emailed to the wrong GP practice breaks it, and no system was involved. ICO, Principle (f)
STRONG BOX, BROKEN PROMISE
Principle B3 protects data "important to the operation of your essential function(s)". A leak from a system the function does not depend on is outside that sentence. NHS England, Principle B3
THE DPO CAN SEE THE REGISTER
Under UK GDPR Article 39 the DPO must monitor the DPIA's ongoing performance. For example: a new sharing route to a supplier opened with no system change is exactly what the DPO is meant to catch, and a register line makes it visible. ICO, How do we do a DPIA
SCOPE. This page makes one argument: the conditions on the information should be the first step in scoping, written as checkable facts, not the last. It does not say the CAF-aligned DSPT is wrong and it does not replace the scoping template or a DPIA. Quotes checked against the linked pages on 27 August 2026. The A1 and A2 pages showed a last-edit date of 26 August 2026, so re-check before publishing. Nothing on this page is recorded or sent anywhere.