The Cost of a Check You Never Priced

We strengthened a verification scheme. The build took an afternoon.

It invalidated 367 existing approvals the moment it landed.

Not because they were wrong. Because they had been issued under the old standard, and the new one cannot confirm them. Every one of those items now had no valid approval, and the only way to get one was to redo the work that produced it.

That is the cost nobody prices when raising a standard, and it is usually larger than the build.

Why we could not simply re-sign them

The obvious shortcut is to take the existing approvals and reissue them under the new scheme. It is one loop. It would have taken minutes.

It would also have been a lie.

The new scheme’s entire purpose is to establish that an approval was produced by the checking process, not written by hand. Re-signing an old record asserts exactly that — and it would be false, because what actually happened is that a script stamped it. The signature would be real and the claim it makes would not.

Doing that once destroys the value of every signature afterwards, including the honest ones, because the scheme no longer distinguishes what it exists to distinguish.

So the options were: redo the work, or accept that 367 items are unapproved.

We redid the work.

★ Insight ───────────────────────────────────── There is a general principle here worth naming: a stronger standard cannot be applied retrospectively by assertion. If the new control verifies something the old process did not record, then no amount of reprocessing the old records can produce it — the information was never captured. The only routes are to redo the work or to mark the old items as holding a weaker assurance. Any third option is a claim about evidence that does not exist. ─────────────────────────────────────────────────

The three ways organisations handle this, and what each really costs

When a standard rises — a new control, a new regulation, an acquired policy — everything already done under the old one is suddenly in an awkward state. There are three responses.

Redo the work. Expensive, honest, and the only option that leaves you with a uniform standard. Ours cost several days of machine time and a delayed publishing schedule.

Grandfather explicitly. Old items keep their old status, marked as such, and the new standard applies going forward. Cheap and defensible, provided the marking is real — the record has to say which standard each item was assessed under, and anyone reading it has to be able to see that.

Grandfather silently. Old items keep their status and nothing records that they were assessed differently. Free today, and it means your register contains two populations that look identical and are not. The day somebody needs to know which is which, the information is gone.

The third is the default, because it requires no decision. It is also the one that produces the worst outcome in an incident, when “were these checked?” is answered with “the system says approved” and nobody can say against what.

What should have happened before the build

The question we did not ask, and would ask next time:

How many existing items does this control apply to, and what is our answer for them?

Thirty seconds of thought, before writing any code. It would have produced the same decision and it would have produced it as a decision, with the cost visible in advance, rather than as a discovery afterwards.

That question generalises to any raised standard:

• A new data retention policy — what about the records already held?
• A new supplier assessment requirement — what about the existing suppliers?
• A new approval threshold — what about the things approved under the old one?
• A new code standard — what about the existing codebase?

In every case the answer is one of the three above, and in most organisations it is silently the third.

The two costs, separated

It helps to name them separately, because they are funded differently and only one is usually estimated.

The build cost is the control itself. Ours was an afternoon. It is visible, it is what gets estimated, and it is almost always the smaller number.

The migration cost is what happens to everything the control now applies to. Ours was several days of machine time and a delayed schedule. It is invisible until somebody asks, and it scales with how long you have been operating without the control.

That second property is the uncomfortable one: the longer you wait to raise a standard, the more expensive raising it becomes, because the population of items assessed under the old standard keeps growing. A control introduced at 50 items costs a fraction of the same control introduced at 400.

Which argues for raising standards earlier than feels necessary, and it is the opposite of the usual instinct — to wait until the volume justifies the effort. By the time the volume justifies it, the volume is the cost.

Why the honest option is worth the cost

Two reasons, and the second matters more.

The register means something. After redoing the work, every item carries an approval issued by the checking process under the current standard. There is one population, not two, and a question about any item has a single answer.

The precedent holds. The first time you reissue an approval that was not earned, you have established that approvals can be issued that way. The next raised standard will be cheaper to absorb the same way, and the one after that. Within a few cycles the control is ceremonial, and nobody will be able to point at the decision that made it so, because each individual shortcut was reasonable.

That second one is the actual argument. The cost of doing this properly is paid once, visibly. The cost of the shortcut is paid permanently, invisibly, by everything that depends on the signal afterwards.

The question for a board

When a control is proposed — a new check, a new policy, a new assessment — one question belongs in the paper alongside the implementation cost:

What happens to everything we have already done?

If the paper does not answer it, the answer is silent grandfathering, and the organisation is about to acquire two standards and one label.

The cheapest moment to decide that is before the control exists. The most expensive is eighteen months later, when someone asks what the approvals actually mean and the honest answer is that it depends when they were issued.

---

Control design, assurance standards and the migration costs underneath them are part of the governance work we do through Ganda Tech Services, with engineering practice through Cloud Geeks.