A hundred organisations offline because of a PHP flaw: a free NIS2 drill

On 21 October, the National Cyber Security Centre (NCSC) reported two critical vulnerabilities in PHP, the programming language on which a large part of the Dutch and global web runs. Through the flaws, malicious actors could in theory attack any vulnerable PHP site or web server. As a precaution, over a hundred organisations took their websites offline, including government services such as DigiD and MijnOverheid.

At that point there were no signs of active abuse yet, but the NCSC urgently advised owners to make their own risk assessment. A patch appeared that same afternoon, and from 23 October most sites came back online. The NCSC is now investigating the first signs of possible exploitation. At the time of writing, it has not been established how widespread abuse actually was.

Since 15 August 2026, the Cybersecurity Act has been in force, the Dutch implementation of the European NIS2 directive. That law obliges some 8,000 organisations in eighteen sectors to a duty of care, meaning appropriate technical and organisational measures to control risks, and a reporting obligation, with an early warning within 24 hours and an initial report within 72 hours of a significant incident. A critical, actively exploited vulnerability in your web software is exactly the kind of event that can fall under that reporting obligation.

The difference between organisations that could respond within hours and organisations that were not even sure whether they used PHP was not down to chance. It was down to preparation: an up-to-date overview of your own software stack, a designated owner per system, and a rehearsed process to switch quickly as soon as the NCSC issues a warning.

This is exactly the same lesson we draw with AI tools, only one layer deeper in the technical stack. Do you know which software you use, who is responsible for it, and do you have a process to respond quickly when something goes wrong? With PHP it concerned a language running under thousands of websites without administrators always being aware of it. With AI it concerns tools that teams add themselves without IT or compliance knowing. Our AI Inventory module is built on that same principle: you can only respond quickly to a new risk if you already know what is running, before things go wrong.

Compare two similar SMB companies. Company A keeps an up-to-date overview of all software in use and has appointed a responsible person per system. They saw the NCSC warning, checked within an hour which of their sites used PHP, and had the patch rolled out the same day. Company B was not sure whether their webshop platform ran on PHP, first had to call their hosting party to find out, and therefore lost two days. Two days in which their site was an unnecessarily long open target. Neither company did anything wrong at the moment the news broke; the difference had been made weeks earlier, in the preparation.

Do not treat an NCSC warning as something that only concerns IT, but as a test of your broader compliance readiness. Keep an up-to-date overview of your software and suppliers, appoint an owner per system, and rehearse the process at least once a year: who decides to take something offline, who informs the supervisory authority, and within what timeframe. Then the next warning is no longer a crisis, but a routine action.