On 30 April 2026, the Australian Prudential Regulation Authority issued a letter to all regulated entities setting out its observations and expectations on artificial intelligence. The letter follows targeted engagements APRA conducted with selected large banks, insurers and superannuation trustees in late 2025.
The letter has been widely covered in connection with frontier models such as Anthropic's Mythos and the AI-enabled threat environment those models foreshadow. That dimension is present, but it is not the centre of gravity. The bulk of APRA's observations and expectations concern how regulated entities are themselves adopting AI: governance of internal AI use, lifecycle management of AI systems, oversight of AI suppliers, and the operational risks that arise when AI is embedded into business processes. AI-enabled threats from external actors are a secondary theme.
CPS 234 Information Security and CPS 230 Operational Risk Management already cover the obligations APRA is invoking. The letter does not introduce new standards. What it does is signal heightened expectations for how those existing standards apply when AI is part of the operating environment, both as something the entity is using and as something attackers are using against the entity.
What APRA expects
The letter sets out specific expectations across five themes - the first in the main letter, and the other four under Observations in the attachment, covering the engagement debrief.
1. Boards must have technical literacy and live oversight
In the main letter, APRA observed that many boards are still developing the technical literacy required to provide effective challenge on AI risks. The letter expects boards to set strategic direction, oversee an AI strategy aligned to risk appetite, and respond to "clearly defined triggers aligned to resilience objectives." Vendor presentations and summaries are explicitly insufficient.
2. AI must be governed across its lifecycle
APRA expects frameworks and reporting lines for safe AI adoption, with ownership across design, development, deployment, monitoring and decommissioning. Entities are expected to maintain an inventory of AI tooling and use cases, embed human involvement in high-risk decisions, and train staff on AI use, misuse and limitations.
3. Information security must address AI-specific threats and tempo
This is the part most directly anchored in CPS 234. APRA states plainly that current implementation timelines for remediation are "not consistently aligned to the accelerated threat environment." The letter expects controls over agentic and autonomous workflows, timely patching, hardened configurations, automated vulnerability discovery, and security testing across AI-generated code.
4. Supplier risk must be visible end-to-end
Entities are expected to map the full AI supply chain including fourth parties, ensure contractual audit rights and incident reporting, and actively manage concentration risk on critical AI providers with credible substitution arrangements. These sit within CPS 230 and the supporting CPG 230.
5. Change management and continuous, integrated assurance
Expected across all four of the previous themes is that assurance is integrated and continuous, not point-in-time and sample-based. APRA is explicit that periodic methods are "ill suited to probabilistic models that learn, adapt and degrade over time." Few entities, the letter notes, have continuous validation in place.
The letter closes with a clear escalation pathway: "Where entities fail to adequately identify, manage or control AI risks in a manner proportionate to their size, scale and complexity, we will take stronger supervisory action and, where appropriate, pursue enforcement."
What this means for incident response teams
The letter's centre of gravity is governance of AI adoption, but several of its expectations have direct consequences for security operations. AI changes the population of incidents an IR team will handle. AI systems can be the subject of an incident (a model failing, drifting, or being misused). AI agents can be actors in an incident. AI suppliers can be the trigger for an incident. AI-enabled adversaries can be a source of incidents. All of these need to be handled with the same rigour as any other incident, and the evidence of how they were handled needs to be available for board reporting and supervisory review.
The first practical consequence is that the incident audit trail takes on greater weight. APRA's emphasis on continuous assurance places more weight on the contemporaneous record of what happened, what was decided, and how the response unfolded. Records assembled after the fact from email threads, chat messages and ITSM are harder to collate and harder to defend in that environment.
The second is that cross-domain coordination needs to be coherent. AI incidents are particularly prone to APRA's "fragmented assurance" problem because they often touch cyber, privacy, model risk, conduct and supplier risk simultaneously. A consolidated case view, with classification against established frameworks (MITRE ATT&CK for traditional TTPs, MITRE ATLAS for AI-specific techniques such as prompt injection or model manipulation), supports both the operational coordination and the reporting that follows it.
A third consequence is that agentic activity has to be investigatable. APRA's concern about identity and access management not having adjusted to nonhuman actors lands across the business, not just the SOC. But IR teams inherit the consequences at investigation time. When an AI agent's actions are part of an incident, the response team needs to determine what the agent did, under whose authority, and how to distinguish its activity from compromise. That requires upstream logging and attribution to be in place before the incident, and preserved end to end through the response.
Finally, the policy-practice gap is harder to defend. Continuous validation raises the bar for what counts as a tested capability. A playbook tested annually is not the same as one whose execution is observable in current incident data.
Building defensible AI risk management with CIRM
These implications align closely with what Cybersecurity Incident Response Management platforms are designed to support. Cydarm's CIRM platform is built around the principle that the value of incident response is captured in the record of how it was done.
In practical terms, that starts with centralised case management. Every action, decision, escalation and communication during an incident is captured in Cydarm's case timeline with attribution and timestamps. Whether the incident involves an AI system, an AI agent, an AI supplier, or an AI-enabled adversary, the response is drawn from a record generated by the response itself rather than assembled after the fact.
Cydarm uses the open CACAO standard for playbooks that embed directly into the response workflow, so the documented procedure and the executed procedure are the same artefact. This narrows the policy-practice gap APRA flags in its observations. To be clear though: consistent execution of a response playbook is a different problem from continuous validation of an AI model in production. Model behaviour monitoring sits with the AI platform, not the IR platform. CIRM supports the response side of the assurance picture, not the model behaviour side.
Attribution is preserved across the case lifecycle, with every action recorded against its originating identity, whether an analyst, an integration, or an automated playbook step. CIRM does not replace upstream IAM controls for nonhuman actors, but it ensures the visibility your detection and logging produce is preserved through the response record.
On metrics and reporting, Cydarm tracks response times, can be used classify activity against MITRE ATT&CK and MITRE ATLAS, and generates situational and operational reports directly from incident data. The metrics boards need for oversight, and the data that supports supervisory review, are drawn from the same source as the response itself.
The practical effect is that the evidence supporting AI risk management is generated through the response, rather than reconstructed when the regulator asks for it. CIRM is one part of a broader AI risk capability, and it earns its place by ensuring that when an AI-related incident occurs, the response and the record of it meet the bar APRA has now made explicit.
The practical takeaway
APRA's letter signals that CPS 234 and CPS 230 apply to AI with no carve-outs, and that the expectation for how those obligations are evidenced is rising. The dominant focus is on how entities govern the AI they themselves are adopting, with AI-enabled threats a secondary but reinforcing concern. Entities are not being asked to do something fundamentally new. They are being asked to do the existing work in a way that is more continuous, more integrated, and more readily demonstrable.
For boards and CISOs, the practical question is whether the operational data, the case records, and the reporting that flows from incident response can support that demonstration across the full range of AI-related incidents an entity will increasingly face.
The letter is posted online here: https://www.apra.gov.au/apra-letter-to-industry-on-artificial-intelligence-ai