AI is reducing your response time to cyber incidents. How resilient are you?

The situation made the bigger picture very clear: organisations have increasingly less time to respond to (potential) cyber incidents. The vulnerabilities could, under the right circumstances, enable an unauthenticated attacker to execute code on an affected server. PHP, the technology involved, forms the foundation of a huge proportion of websites and applications worldwide. Its administrators urged users to install patches immediately.

But the detail that should concern directors more is the role that artificial intelligence (AI) played in discovering and demonstrating vulnerabilities. According to analyses of the event, AI models contributed throughout the entire lifecycle: from discovering vulnerabilities and developing exploits to recovery analyses and the validation of the final patches.

Why AI means less time to react

In other words: The weaknesses were not new. What changed is how quickly they can be found and shown to work. AI-assisted security research played a significant role in uncovering and demonstrating them.

That leaves organisations far less time to react. PwC warned about this earlier: frontier AI does not create a new kind of threat, but it makes existing threats move faster.

Why faster patching is not the answer

The obvious response is to treat speed as a technical problem: automate the patch pipeline and close the gap. This is unequivocally necessary, but not sufficient.

Automation, they argue, answers only one question: how quickly can we fix it? It does not answer the question that directors face under pressure: what must remain functional if we cannot fix everything in time? When a vulnerable dependency sits with an external supplier, when it is safer to deliberately scale down part of operations, or when the level of exposure is simply unknown, the decision becomes a matter of trade-offs. But such a trade-off is poorly made if it must be made for the first time during a crisis.

That exposes an uncomfortable gap. Many directors assume that their business continuity plans and their compliance with regulations such as DORA and NIS2 mean they are prepared. But they are prepared for a slower pace. Regulation determines a minimum level; it does not define an organisation's critical core.

Research suggests that few organisations have bridged that gap. PwC's Global Digital Trust Insights 2027 shows that only 39 per cent of leaders in security, risk and operations have a fully formalised and integrated continuity plan that specifically addresses cyber risks. In an era when response times are measured in hours, that shortfall is harder to dismiss as a technical detail.

From security problem to board decision

Cyber resilience comes down to how quickly you can get to safety. Three measures help:

• Time to know: can we quickly tell whether our critical operations are exposed?
• Time to contain: can we isolate the risk without needlessly disrupting everything else?
• Time to recover safely: can we fix the problem and restore operations with confidence?

None of these matters falls solely within the responsibility of the CISO. Cyber resilience spans IT, the business and Risk, cutting across the entire organisation. Therefore, the answer to the question ‘are we still viable after an attack?’ is ultimately a matter for the board.

The practical starting point here is defining a minimum viable company (MVC): the critical outcomes, services, processes, technology, data, people and third parties that must remain available to keep the organisation viable during severe disruptions. By defining this core, you as a director get a clear answer to a simple question: what absolutely must keep running?

An MVC reveals risks that directors often underestimate, with concentration risk being the most important. Outsourcing transfers activities, but not responsibility. One cloud provider or software supplier can form the foundation for multiple critical processes; if that fails, the disruption cascades through the entire organisation. Defining an MVC forces directors to determine in advance which external dependencies are acceptable and what it will do when one of them fails.

Decide before the crisis

The question now is not whether a new major disruption will occur, but when. The decisions that matter cannot be made well for the first time under great pressure. That is why it is important to test your MVC from end to end: what happens in a ransomware attack, the failure of a critical supplier or loss of access through geopolitical or regulatory decisions? Realistic tests show whether your priorities are achievable within the agreed timescales and where strategic intent and operational reality quietly diverge.

Three questions for your next leadership dicussion

1. Have we clearly defined which activities, systems and third-party dependencies are essential to maintaining operations and to our Minimum Viable Company?
2. Do we have sufficient visibility to determine immediately whether these critical components are vulnerable when a new risk emerges?
3. Are our controls and recovery capabilities sufficient to ensure continuity without causing a disproportionate impact on our business operations?

PHP2Shell will not be the last time you are confronted with these questions at short notice. Now that cyber risks move at machine speed, resilience will depend less on how quickly you can patch. But more on one decision that only you can make when the clock stands still.