On 1 May the National Cyber Security Centre (NCSC) told organisations to prepare for a “vulnerability patch wave”. Its Chief Technology Officer wrote that AI is showing the ability to exploit technical debt “at scale and at pace”, and that he expects a “forced correction” across all types of software.
Technical debt is a polite name for the shortcuts, unfinished work and ageing parts that build up in any system. It rarely appears in board papers by that name. I think the reason has less to do with technology than with how systems get delivered.
How a system gets signed off
Much of the technology in smaller organisations is built or installed by someone else: a supplier, a contractor, a partner brought in for the project. They are paid to deliver, and delivery is judged by whether the thing works. The website goes live. The new system takes its first bookings. Acceptance is signed.
Security testing usually sits near the end of the plan. On a long project with many changes, the end is where time runs out. Testing gets shortened, or its findings arrive after go-live with nobody contracted to fix them. None of this needs anyone to behave badly. The supplier did what the contract rewarded, and the project team did well to get it live at all.
Why nobody went back
Then the people who built it move on to their next project. Day-to-day care passes to an internal team or a different supplier, who did not design it and may not know how parts of it were set up. For them, a working system is something to leave alone. Changing it risks breaking it, and nobody wants to explain an outage caused by an improvement.
That is the real meaning of “if it ain’t broke, don’t fix it”. It was rarely a decision. It was the absence of one.
What has changed
For years that absence was survivable. Finding a weakness in an old system took skill and time, and most attackers had easier targets. The NCSC’s point is that AI tools now make finding and using those weaknesses quicker and cheaper. Systems left alone because they worked are the ones most likely to hold old, unfixed flaws.
The current rush to patch is welcome. But patching fixes what has been found. It does not change how the gap was created, and a board that only asks “are we patched?” will be asking the same question again in two years.
What a board might ask
For our most important systems, what did acceptance actually test? Did it include security testing, and were the findings fixed before go-live?
Who looks after each of those systems now, and do they understand how it was set up?
Where we live with a known weakness, who decided, and is that decision recorded?
In contracts signed this year, is security testing a condition of acceptance, with time set aside to fix what it finds?
Getting a system live is an achievement. Whether it can be safely looked after for the next ten years is a separate question, and that one belongs to the board.
