Your Risk Framework Is Lying to You
Most board risk registers treat cyber threats as they were five years ago — a static landscape where the primary variable is how quickly your IT team responds. That model is broken, and the Five Eyes just said so publicly.
Last week, the Five Eyes cyber security agencies issued a joint call-to-action warning that AI is accelerating “the speed, scale, and sophistication of cyber threats.” The plain reading of that statement is this: the assumptions baked into your current risk appetite — including any that treat time-to-patch as a meaningful buffer — no longer reflect the threat environment your organisation actually operates in.
This is not an IT problem. It is a governance problem, and it lands on the board.
The Window Boards Were Counting On No Longer Exists
Risk frameworks across Australian organisations have long treated vulnerability management as a timing exercise. A critical CVE drops, the IT team has days or weeks to assess, prioritise, and patch before exploitation becomes likely. That assumption gave boards and risk committees something comfortable to approve: a process with a reasonable runway.
AI has closed that runway. Open-weight models — freely available, increasingly capable — have reached the point where they are genuinely useful in orchestrating offensive cyber security tasks. Vulnerability discovery, exploitation scripting, target reconnaissance: these are tasks that previously required skilled threat actors and meaningful lead time. They no longer require either. The gap between a vulnerability becoming public and a working exploit being deployed against real targets has compressed dramatically, and it will keep compressing.
When the Five Eyes — five governments whose intelligence agencies spend their careers not overstating things — tell you the genie is out of the bottle, that is not a talking point. That is a material change to your operating environment.
The Governance Exposure Is Specific
For Australian organisations operating under APRA CPS 234 or the SOCI Act, this creates a precise and defensible liability exposure — not a hypothetical one.
CPS 234 requires that information security capabilities be maintained commensurate with the size and extent of threats to information assets. It also requires that boards be satisfied those capabilities are sufficient. A risk framework that assumes weeks of exploitation runway, when the actual window is now hours or days, is not commensurate with the threat. It is not a matter of interpretation. The framework is simply wrong about the facts.
SOCI Act obligations around critical infrastructure risk management programs carry similar logic. A risk management program is only as good as the threat model it’s built on. If that threat model is outdated — and a framework that ignores AI-accelerated exploitation timelines is outdated — then the program does not satisfy the obligation in substance, even if it satisfies it on paper.
The practical consequence: if your organisation experiences a breach involving a recently disclosed vulnerability, and the board-approved risk framework assumed a mitigation window that no longer exists, that is a governance failure with a paper trail. Regulators will ask whether the risk framework reflected the known threat environment. The Five Eyes just made “known” very hard to argue around.
This Is Not an IT Resourcing Request
The instinct, when this kind of risk is raised, is to treat it as an ask for more budget — more staff, faster patching cycles, better tooling. That framing lets boards off the hook too easily.
The real question is whether your risk appetite statement is accurate. Risk appetite is a board instrument. It describes what level of risk the organisation accepts and under what assumptions. If those assumptions are wrong, the appetite statement is not a governance document — it is a liability document.
Boards need to ask a direct question of their CISO or risk function: does our current risk framework account for AI-accelerated exploitation timelines? Not “are we aware of AI as a threat” — that question gets a comfortable yes. The harder question is whether the rated likelihood and velocity of specific risks have been updated to reflect that vulnerability exploitation now happens faster than most patching cycles can respond.
If the answer is no, the framework needs to be revised before the next risk committee sign-off. Not scheduled for review. Revised.
What Defensible Looks Like From Here
Defensible governance in this environment has three characteristics.
First, the threat model is current. That means risk ratings for technology-dependent exposures are reviewed against the actual exploitation environment — not annually, not at the next scheduled update, but as a standing agenda item whenever the threat landscape shifts materially. The Five Eyes statement is one such shift.
Second, the control environment is honest about its limits. Compensating controls that rely on response time need to be reassessed. Where detection and containment is the primary control, the board should understand how far detection lag has been shrunk — or not — and what residual risk that leaves.
Third, the risk appetite reflects reality. If your organisation genuinely cannot close critical vulnerabilities within hours rather than weeks, that is a risk acceptance decision. It should be explicit, documented, and owned at board level — not buried in an IT team’s backlog.
The Takeaway
The Five Eyes statement is not background noise. It is a formal acknowledgement by the world’s leading signals intelligence community that the threat model has changed in a specific, material way. Boards that continue approving risk frameworks built on pre-AI exploitation timelines are not being prudent — they are approving something they know to be inaccurate.
Under Australian regulatory obligations, that exposure is not abstract. Review your risk appetite statement now, with this specific question on the table: does it reflect an exploitation environment where AI has effectively eliminated the window your controls were designed around? If it doesn’t, fix it before a regulator or a breach makes the question irrelevant.