Could anyone in your organisation explain how your website is set up? Not what it does, but how it is put together, what it depends on, and what would break if one part were updated?
In many organisations the people who could have answered left when the project finished.
Two different jobs
Building a system and looking after one are different jobs, often done by different people. The builders work to a deadline and a specification. When the work is accepted, they move on. Those who inherit it get a system that works, some documentation of varying quality, and an instruction to keep it running.
A system you don’t fully understand is one you are reluctant to change. Updates get postponed. Old components stay because removing them feels risky. Over time the system becomes something everyone relies on and nobody dares touch.
Tolerated, not accepted
In June the NCSC’s chief executive, Richard Horne, said that “the many vulnerabilities that organisations tolerate today will be exploited in conflict tomorrow.” He was speaking about attacks on the UK’s critical national infrastructure, but the word “tolerate” applies far more widely.
A risk a board has accepted is different from one the organisation has simply tolerated. An accepted risk has an owner, a reason and a date to look at it again. A tolerated one has none of those. It is just still there. Most unsupported software, missing updates and undocumented set-ups sit in the second group, and they rarely reach the board.
When support ends
Software also has a shelf life. When a supplier stops issuing security updates, every weakness found afterwards stays open. The government’s Software Security Code of Practice, aimed at software vendors, asks them to give customers at least a year’s notice before support ends.
A year is enough time to plan a replacement, but only if someone reads the notice and has the budget and the authority to act on it. The NCSC’s advice for systems that are out of support is plain: replace them, or bring them back within support.
What a board might ask
Which of our systems are out of support, or will be within two years? Who owns each one, and when will it be replaced?
For each critical system, who could explain how it is set up today? If the answer is one person or one supplier, what happens if they go?
When our last major project finished, what was handed over, and to whom?
Which known weaknesses are we tolerating rather than accepting, and when will the board see that list?
None of these questions needs a board member to understand the technology.
They need the board to insist that someone understands what the organisation relies on.
Department for Science, Innovation and Technology, Software Security Code of Practice, May 2025.
National Cyber Security Centre, “Preparing for a ‘vulnerability patch wave’”, 1 May 2026.
