AI and cyber risk: the case for faster decisions

Treat the warning as an operating question

In a letter published today, the FSB Chair warns that frontier AI could materially change the speed, scale and economics of cyber risk. The letter highlights the implications of common technology dependencies and the need for response and recovery capabilities that can withstand severe disruption. This policy warning should be assessed alongside evidence of what threat actors can currently do. FSB Chair's August letter (opens in a new tab)

The NCSC's assessment published in May 2025 similarly anticipated that AI would improve aspects of cyber intrusion and increase pressure on systems that fail to keep pace with security improvements. Its assessment distinguished the automation of parts of an attack from fully automated, advanced attacks. That distinction matters when evaluating claims about new capabilities. NCSC assessment of AI and the cyber threat to 2027 (opens in a new tab)

For an executive committee, the useful response is to examine the firm's capacity to act on a serious exposure. A sophisticated detection tool offers limited benefit if the organisation cannot identify the affected service, obtain a decision or implement a remedy safely.

Find where the response loses time

Take a recent vulnerability requiring urgent attention and reconstruct the sequence of events. Establish when the organisation became aware of it, when affected assets were identified, when the service owner was informed and when the exposure was reduced. Look for delays caused by missing information or unclear authority.

The exercise may show that a technical fix was available while the business debated whether it could accept an interruption. That decision needs an owner who understands the service and the consequences of both action and delay. An escalation process should make that judgement possible outside the normal committee calendar.

Prepare an emergency change route with clear testing, approval and recovery arrangements. Faster action still needs safeguards against an unsuccessful change. The team should understand what can be tested quickly, what evidence is required and how to reverse the change if the result is unacceptable.

Management information should help leaders distinguish delays that protect the service from delays caused by process failure. A long queue of overdue actions can conceal very different exposures. Show which important services remain affected, what temporary measures are in place and who has accepted the residual risk for a defined period.

Test recovery when shared services fail

The FSB letter draws attention to disruption spreading through shared providers and to the need for stronger recovery capabilities. It also identifies the operational strain that faster vulnerability remediation could place on change and testing processes. FSB letter, frontier AI discussion (opens in a new tab)

Translate that concern into scenarios specific to the business. Consider the loss of a shared identity service, a provider supporting several important processes or the administrative access needed to restore systems. The organisation should know how recovery would proceed when its usual tools are themselves unavailable.

Test the usability of the records and instructions needed for recovery. Establish who can reach them, how authorised staff would gain access and what dependencies are required to restore a minimum service. Recovery evidence should show that a business process can resume with trustworthy information, including the handling of transactions that accumulated during disruption.

Supplier exercises should cover competing demands during a widespread incident. Ask how the provider would communicate with the firm, what assistance could reasonably be expected and which tasks remain the firm's responsibility. Use the answers to identify where internal capability or an alternative arrangement is needed.

Apply the same discipline to defensive AI

AI may help security teams analyse information and prioritise work, but adoption should begin with a defined task and evidence of usefulness. Specify the decision the tool will support, the information it can access and the action it is permitted to take. The owner should be able to explain the consequences of an incorrect result.

For a pilot, compare performance against a relevant baseline and include cases that are difficult or ambiguous. Measure the work transferred to human reviewers as well as the apparent reduction in processing time. A tool that generates more alerts may increase the team's workload unless it improves the quality of the decisions that follow.

Where a tool can change a system or initiate a response, use permissions and oversight appropriate to that authority. Record the actions taken and provide a practical way to intervene. Changes to the tool, its data or its access should prompt a review of whether the original assessment remains valid.

These questions connect AI investment to operating capacity. Leadership can then compare the benefit of a new tool with other priorities, such as improving asset information, removing a slow approval step or strengthening recovery arrangements. The appropriate choice depends on the weakness limiting the organisation's response.

At the next executive review, ask where a serious cyber exposure would wait for a decision, which shared dependencies could obstruct recovery and what evidence supports the proposed use of defensive AI. Those answers provide a more useful investment agenda than a general instruction to respond to the latest threat headline.