Title

The recent discovery of two critical vulnerabilities in PHP is a timely reminder that cyber risk does not stay neatly within the ICT department.PHP sits behind many websites and online services. An attacker could use them to make a vulnerable server run malicious code, without a username or password. Leading to disruption, loss of information, or an entry point into other systems. The National Cyber Security Centre advised organisations to identify affected systems, prioritise those exposed to the internet, update them and, where that cannot be done quickly, consider taking them offline. Which plenty did.This sounds like a technical response, but the decisions it creates are organisational. • If a council portal supporting payments, housing, benefits or another essential service is exposed, who decides whether it remains available? • Who weighs a controlled outage against the risk of compromise? • Who speaks to residents, regulators, and partners if service or data is affected?These questions cannot be left to technical teams alone. In my work advising councils and public-sector organisations, I encourage leaders to treat a serious vulnerability as a service continuity and information risk event from the start. Where to start?There should be a named senior owner, supported by ICT and cyber specialists, able to bring together service managers, information governance, communications, procurement and suppliers. Emergency decision-making must be clear enough to act at pace. 3 lessons and 1 thing to remember1. Know what you depend onA council may not knowingly operate PHP itself. It might sit inside a hosted service, third party product, or network appliance. Asset records must cover more than devices and applications. They should connect each service to its technical components, business owner, supplier, information held and importance to residents. When the next issue appears, leaders need to know quickly which services could be affected and whom to contact. 2. Prioritise by service impact, not by noiseInternet-facing systems need early attention, as do services supporting vulnerable people, payments, identity or sensitive information. Teams should patch promptly, but normal change controls must not create unnecessary delay. You need an agreed emergency route for testing, authorising and recording urgent changes. Sometimes the safest decision will be uncomfortable. If a vulnerable system cannot be patched or protected, restricting access or taking it offline could be the responsible choice. A planned interruption, with clear communications and alternative arrangements, can be preferable to an uncontrolled compromise. That judgement belongs with accountable leaders and service owners, not just ICT.3. Your suppliersCouncils need written answers, not general reassurance: is the vulnerable component present, which versions are involved, is the service affected, what remediation has been applied and when was it completed? Contracts and supplier-management arrangements should make those answers available quickly, including for subcontractors and embedded technologies. And remember: patching is not the end of your response. Councils should preserve and review logs, monitor for signs of compromise and be ready to activate incident arrangements. Afterwards, update your asset records, contracts and risk registers, and review what slowed action. What's next?This PHP incident will not be the last. The real test is not whether councils can eliminate every flaw. It's whether they can see their exposure, make informed service decisions and act quickly with clear accountability. For me, that readiness should be discussed and rehearsed before the next alert arrives. Cyber resilience is a leadership responsibility and a core part of protecting public services and public trust. Dr. Mark Brett is Socitm's cyber and resilience adviserSocitm has practical guidance and governance resources, case studies more to support cyber security and resilience. They're in Cyber@Socitm.

Title

CYBER SECURITY

When a software flaw becomes a council wide concern

By Mark Brett | 02 November 2026

SUBSCRIBE TO CONTINUE READING