Your control library is not evidence that you are resilient.
That is not a provocation. It is close to what two regulators have put in writing. On 1 September 2026, APRA and ASIC released public notes from the joint superannuation chief executive roundtables they hosted on 24 and 30 June 2026. Buried in the crisis preparedness section is the most operationally useful sentence a resilience team will read: participants noted that crisis exercises often reveal governance, delegation and communication issues that may not be apparent through documentation alone.
Regulators do not often say out loud that a document cannot tell you what you need to know. This one does, in a joint publication, about the exact class of failure that resilience programs are built to prevent.
What did APRA and ASIC actually publish?
Two things, on the same day. A short media release, and an information paper carrying the notes themselves.
The roundtables were held on 24 and 30 June 2026 with superannuation chief executives representing what the notes call a broad cross-section of the industry. The paper's attendee list for 24 June records APRA's then Deputy Chair Margaret Cole, Head of Cyber Risk and Response Joe Dalessandro and ASIC Commissioner Simone Constant. The agenda was frontier artificial intelligence, cyber and operational resilience, and crisis preparedness, alongside broader emerging issues.
Be precise about what this is. It is not a prudential standard, not guidance, not a consultation, and not an enforcement signal. It is a public record of a private conversation, released by both regulators together. That combination is rare enough to be worth reading closely, because what regulators choose to publish from a closed-door discussion is itself a choice about what they want the rest of the sector to hear.
Four observations in the notes carry weight beyond superannuation.
The first is on AI and threat. The notes record broad recognition that AI is accelerating the speed, scale and sophistication of existing cyber threats, and that this reinforces the importance of strong cyber fundamentals, effective governance and resilient operating models. Note the framing. Not new threats. Existing threats, faster.
The second is on maturity. Participants acknowledged that organisational maturity, including board engagement and director capability, varies across organisations, and that high-quality education and practical capability uplift are challenges as well as enablers of effective board oversight.
The third is on concentration. The notes highlight shared dependencies on material service providers and technology platforms as a key source of systemic vulnerability, and record general agreement that CPS 230 has sharpened focus on critical operations and supplier dependencies while transparency and assurance across complex supply chains remain ongoing challenges.
The fourth is the one this article is about. On crisis preparedness, the regulators led a discussion focused on polycrisis scenarios involving multiple concurrent disruptions. There was broad agreement that preparedness should focus on building organisational resilience, decision-making capability and crisis response capacity rather than attempting to predict specific events. And then the sentence about exercises finding what documents do not.
Why does the exercise find things the document cannot?
Because a document records an intention and an exercise records a behaviour, and the gap between those two is where resilience programs fail.
A documented plan can be internally consistent, board-approved, mapped to every clause of the standard, and still wrong in three ways that only appear under time pressure.
It can be wrong about authority. The plan names a role that can invoke a fallback. Nobody has told the person currently in that role, or they have the authority but not the information, or the decision needs two approvals that in practice are the same person on leave.
It can be wrong about sequence. Every step is present and every step is correct, but the plan assumes the incident is declared before the customer impact starts, and in the exercise the impact arrives first and the declaration takes forty minutes.
It can be wrong about communication. The escalation path is documented to the executive, and the exercise shows that the person who first sees the problem is a vendor's night shift who has no path at all.
None of those show up in a control test. They are not control failures. They are governance, delegation and communication failures, which is exactly the list the roundtable notes name.
What does agentic AI change about the scenario?
This is where the roundtable's two themes meet, and where much existing exercise material is now out of date.
Conventional crisis exercise design assumes a system that stops. The service degrades, the humans notice, the humans convene, the humans decide. Agentic AI breaks that assumption in a specific way: the automated part of the operation does not convene. It keeps running on whatever it can still reach.
That produces failure modes an older scenario will never surface.
An agent that keeps calling a degraded downstream service can turn a partial outage into a queue that is hours deep by the time anyone declares an incident. An agent working from a cached or stale dataset keeps producing outputs that look normal and are wrong, and those outputs keep landing in ledgers, files and customer communications while the war room is still confirming the facts. An agent that has been granted a standing credential keeps holding that credential through the containment step, because the containment runbook was written for user accounts.
There is a further wrinkle the roundtable notes point at without naming. If shared dependence on a small number of material service providers is a systemic vulnerability, then shared dependence on a small number of foundation models is the same shape of problem one layer up. Two vendors in your critical operation can be a single point of failure if both sit on the same model provider. The site has covered that concentration question in common foundation model dependency, and it belongs in the scenario rather than the vendor register.
The design consequence is simple to state and uncomfortable to build. Your scenario has to say what the automated components are doing at each injection point, not just what the people are doing. If the scenario does not answer the question of what the agent did during the first forty minutes, the exercise is testing a system you do not operate.
How do you design an exercise that produces evidence?
The purpose is not to pass. An exercise that everyone passes has told you nothing, and it costs the same to run as one that teaches you something. Design for discovery, then treat what you discover as the output.
Pick the operation, not the incident. Start from a critical operation and work outward to what could disrupt it, rather than starting from a threat and asking who it hits. The roundtable's own framing supports this: preparedness should build capacity rather than predict events.
Make it a polycrisis. One clean failure is a tabletop. Two concurrent disruptions competing for the same responders is a test of delegation. A realistic pairing is a material service provider degradation plus an internal change freeze, or a model provider incident plus a scheduled release.
Write the agent behaviour into the injects. For each inject, state what the automated components continue to do. Include at least one inject where an agent produces a confident, plausible and wrong output that a human accepts.
Do not pre-brief the decision-makers. If the people who will make the calls have seen the scenario, you are testing recall, not judgement.
Instrument the three failure classes. Assign an observer to authority, an observer to sequence and an observer to communication. Ask them to record the time of each decision, who made it, and what information they had. That timeline is the artefact.
Run to remediation, not to the debrief. The roundtable notes tie preparedness to following through on remediation and recovery. An exercise finding that closes without an owner and a date is not a finding.
Where AI helps in the exercise itself, it helps before and after, not during. It is good at generating scenario variants from your own dependency register, at drafting injects that are consistent with a documented architecture, and at turning three hours of observer notes into a structured timeline. TheAICommand works to the Verified Draft Method: de-identify the inputs, ground the model in your own source material, keep a person at the decision point, verify against the primary source, and log what happened.
What AI must not do is write the findings. A finding that a named person could not get an approval is a statement about your organisation, and it needs a human who was in the room to stand behind it.
What should the board see?
Not the plan. Boards have seen the plan.
Give them four things. The scenario, in a paragraph, including what was automated. The decision timeline, showing when the incident was recognised, when it was declared, and how long each approval took. The three failure classes, with what was found in each. And the remediation register, with owners and dates, including the items still open from the last exercise.
That last column is the one that matters. The roundtable notes record participants emphasising individual organisational accountability even where there is cross-industry cooperation, and a shift from discussing cyber resilience to embedding it in business operations. A remediation register that carries forward is the difference between those two states, and it is the only part of this that a supervisor can test independently.
For related coverage, see the site's CPS 230 and AI operational resilience playbook, the dependency-to-action test for proving a single recovery action survives without its AI tooling, and the incident response evidence pack for what to capture when the event is real rather than simulated.
Do this Monday
- Pull your most recent crisis exercise report. Check whether the scenario says anything about what automated components were doing. If it does not, that is your first gap.
- List the critical operations that now contain an agent, a model call or an automated decision step. That list is your scenario shortlist.
- Find the open items from your last exercise. Count how many have an owner and a date. That number is your honest maturity score.
- Book the next exercise as a polycrisis with two concurrent disruptions, and appoint three observers to authority, sequence and communication before you write a single inject.
Bottom line
Two regulators have jointly published a participant observation that exercises often reveal governance, delegation and communication issues that documentation alone may not surface. That is an invitation to move assurance effort from drafting to testing. For any entity with agents inside a critical operation, the exercise also has to change shape, because the automated part of the operation does not stop to attend the meeting. Design the scenario so it keeps running, and let the exercise tell you what your control library cannot.
References
- APRA and ASIC, APRA and ASIC host Superannuation CEO Roundtables - June 2026, information paper, published 1 September 2026.
- APRA, APRA and ASIC host super CEOs to discuss frontier AI, cyber and operational resilience, media release, published 1 September 2026.
Content disclaimer: This article is for general educational and informational purposes only. It does not constitute legal advice, regulatory guidance, or a substitute for professional compliance judgement. Regulatory obligations vary by entity type, licence, and circumstance. Always refer to primary source guidance from APRA, ASIC, or the relevant regulatory authority.
TheAICommand. Intelligence, At Your Command.
