Your Board Is About to Ask About This

What the letter actually said

At the end of August, ahead of the G20 meetings, Bailey wrote to finance ministers and central bank governors in his capacity as FSB chair. He described frontier AI models as showing increasingly sophisticated autonomy, problem-solving and threat capability, and warned that they could materially alter the speed, scale and economics of cyber risk across a highly interconnected financial system. He noted that many jurisdictions have no protocols governing how advanced models are developed, released and deployed, and asked authorities to treat safe and responsible model release as a priority.

I would encourage people to read the framing rather than the headline. The headline is “regulator worries about AI.” The framing is considerably more specific, and more consequential.

‍

Concentration risk is a different question than control failure

Financial regulators have a particular way of thinking about risk, and it is not the way security programs think about it.

A security program asks: are our controls adequate? A stability regulator asks: what happens to the system if a large number of participants fail in the same way at the same time?

Those questions have different answers even when the facts are identical. A firm can be entirely within its risk appetite, fully compliant, and still be a contributor to a systemic problem — because the thing that makes it systemic is not any individual firm’s posture. It is a correlation. Everyone running the same stack, exposed to the same flaw, with the same inability to close it quickly, is a synchronized failure waiting for a trigger.

Frontier AI matters here for a very specific reason: it compresses the interval between a vulnerability becoming known and being exploitable at scale. When exploitation was slow and artisanal, a long remediation window mostly exposed you. When exploitation becomes fast and cheap and broad, the same long window across many firms at once becomes the transmission mechanism. Correlated exposure plus compressed attacker timelines is the definition of simultaneous disruption.

Which is why remediation speed has quietly stopped being an internal efficiency metric and started being a supervisory one.

The number your board is going to ask about

Here is the practical translation for a security leader.

Under a compliance frame, “our median time to remediate a critical is several weeks” is a perfectly normal sentence. It benchmarks fine. Industry data has high-and-critical fixes running past fifty days on average, so a few weeks is defensible in almost any room.

Under a stability frame, that same sentence is an exposure duration. It is the length of time during which your firm is a known-state, unclosed participant in a correlated risk. Nobody is asking whether it is good relative to peers. They are asking how long the window stays open and what happens inside it, because peers having the same number is the problem, not the excuse.

Our own research says 60% of organizations need more than seven days to remediate a critical vulnerability and 65% run the process at least half manually. Those are not scandalous numbers. They are ordinary. Ordinary is precisely what makes them systemic.

So the question is going to arrive, and it will not arrive as “are we compliant.” It will arrive as some version of: if a serious flaw dropped in something we all run, how fast could we actually close it, and what is our answer if the honest number is “not fast enough”? That question does not have a policy answer. It has an operational one.

Why this arrives ahead of regulation, not behind it

There is a temptation to file this under “something to watch” and wait for a rule. I would not.

Supervisory attention almost always precedes formal requirements, and it shapes behavior long before anything is written down. Boards read the same coverage regulators do. Audit committees ask about what their supervisors are asking about. Insurers reprice against it. Large customers write it into third-party risk questionnaires, which is usually where it reaches the rest of the market — a financial-stability concern becomes a procurement question becomes a contractual obligation, and the sequence takes about eighteen months.

By the time a formal expectation exists, the firms that will meet it comfortably are the ones that changed their operating model beforehand — not because they were prescient, but because they happened to be solving the same problem for their own reasons.

What actually closes the gap

The uncomfortable part is that this is not a governance problem, and governance is the instrument most organizations reach for first.

You cannot close a throughput gap with a policy. Writing down a shorter SLA does not create remediation capacity; it creates a documented pattern of missing your own SLA, which is a worse position than not having written it. You cannot close it with more headcount at any realistic rate, because the intake side scales with software and the human side does not. And you cannot close it with better prioritization, because prioritization is a rationing scheme — it decides what to leave open, which is exactly the thing a stability regulator is worried about.

What actually changes the number is capacity: validating findings deterministically so that the ones that matter are unambiguous, executing fixes without a human in every loop, and holding exposure with compensating control during the interval when a change window genuinely cannot be skipped. That is an architecture problem, and it is solvable. It is just not solvable by the governance function.

What I would do now

Three things, none of which require a budget cycle.

Know your real number — not your SLA, your actual distribution, including the tail. The tail is what a supervisor will ask about.

Know your correlated exposure. Which of your critical dependencies are also everyone else’s? That list is your contribution to systemic risk, and it is the list that will be asked about first.

Be able to describe your closure capacity as a rate, not a process. “We have a mature vulnerability management program” is an answer from the old frame. “We can close N criticals per week, here is what happens when the queue exceeds that, here is what holds the exposure meanwhile” is an answer from the new one.

The supervisory frame has already changed. Compliance asks whether you knew. Stability asks how long it stayed open. Those are different questions, and only one of them has an answer you can write a policy for.

‍

‍

‍

‍