On 30 April 2026 APRA published a letter to industry on artificial intelligence, addressed to every entity it regulates: banks, insurers and superannuation trustees. Search for it and the results are law firm summaries, each one restating what the letter says. None of them answers the question a CISO or CRO actually has after reading it, which is what evidence the organisation can put in front of APRA when the supervision team asks how those expectations are met. For the many regulated entities whose AI adoption is happening inside Microsoft 365, through Copilot, Copilot Studio agents and Azure AI services, that evidence lives in the tenant. This guide maps each expectation area in the letter to the specific Microsoft 365 controls that produce it.
What the letter is, and what it is not
The letter is not a new prudential standard, and it names no existing one. APRA describes its prudential framework as principle-based, technology and vendor agnostic. That framing matters more than it first appears. It means AI gets no regulatory holiday: the expectations in the letter land inside obligations regulated entities already carry. CPS 234 has required an information security capability commensurate with threats to information assets since 1 July 2019, along with tested controls and prompt incident notification. CPS 230 has required operational risk management for critical operations, including material service provider management, since 1 July 2025. Read as a pair, they are the enforcement surface for everything the AI letter describes. An entity that treats the letter as optional guidance is really betting that its next CPS 234 tripartite review or CPS 230 conversation will not raise AI. That bet is now poor.
The letter groups its expectations into recognisable themes: board-level governance and AI literacy, cyber resilience, supplier and third-party risk, change management and controls across the AI lifecycle, and assurance and monitoring. Each maps cleanly onto capability that most regulated entities on Microsoft 365 already licence but have not configured with APRA in mind.
Governance: the board needs an AI picture, not a policy PDF
APRA expects boards to maintain sufficient understanding and literacy with respect to AI, and to oversee AI strategy against risk appetite with clearly defined triggers aligned to resilience objectives. In practice a board cannot oversee what nobody can enumerate, so the first artefact is an inventory (covered below) and the second is recurring reporting built on it.
- Microsoft Purview's Data Security Posture Management (DSPM) for AI gives a tenant-level view of AI interactions: which AI tools are in use, whether sensitive information is appearing in prompts and responses, and where oversharing risk sits. Its reports are the natural raw material for a quarterly board pack, because they are generated from the tenant rather than self-reported by project teams.
- Purview Audit records Microsoft 365 Copilot interactions in the unified audit log. That is the difference between telling the board 'Copilot is governed' and showing an auditable trail when a specific interaction is questioned.
- Risk-appetite triggers need numbers behind them. Sensible tenant-derived metrics include the count of deployed agents, the share of AI interactions touching information labelled at the highest sensitivity tiers, and DLP policy matches involving Copilot.
Cyber resilience: the letter's most concrete paragraph
The cyber section of the letter is unusually specific for a principle-based regulator. It expects strong privileged access management, timely patching and hardened configurations, security testing that accounts for AI-generated code and automated vulnerability discovery, credible fallback processes where AI supports operations, and attention to concentration risk in common platforms. Each of those has a direct Microsoft 365 implementation.
- Privileged access management: Microsoft Entra Privileged Identity Management (PIM) removes standing administrative privilege and makes elevation time-bound and approved. For AI specifically, that includes the roles that can create and publish agents, change Purview policy or alter DLP scope, which are now privileged roles in every practical sense.
- Timely patching and hardened configurations: Microsoft Intune and Autopatch for the endpoint fleet, security baselines and attack surface reduction rules for hardening. AI does not change the mechanics here; it raises the cost of failure, because a compromised endpoint now carries Copilot access to everything its user can read.
- Security testing of AI-generated code: if development teams use Copilot-style code assistance, the compensating control is the review and scanning pipeline, not a prohibition. Branch protection, mandatory review and static analysis need to be evidenced as applying to AI-assisted commits on the same terms as human ones.
- Credible fallback processes: for each process where AI output feeds an operational decision, document what the manual path is and confirm it still works. This is CPS 230 language arriving through an AI door, and it is the expectation most entities have no artefact for today.
Supplier risk: what to put in the CPS 230 register for Copilot
APRA expects entities to map their AI supply chains including fourth-party dependencies, to secure contractual arrangements providing sufficient transparency, auditability and assurance, and to manage concentration risk with feasible exit and substitution strategies. For Microsoft 365 Copilot the mapping is more tractable than it sounds, because Microsoft documents the data flow publicly.
- The service boundary: Microsoft's published privacy documentation for Microsoft 365 Copilot states that prompts, responses and data accessed through Microsoft Graph are processed within the Microsoft 365 service boundary and are not used to train the underlying foundation models. That document, together with the Microsoft Products and Services Data Protection Addendum and Microsoft's published subprocessor list, is the transparency artefact set to attach to the material service provider register.
- The fourth-party question: for Copilot the model layer runs on Microsoft-operated Azure infrastructure, which keeps the chain shorter than a multi-vendor AI stack. The chain lengthens the moment agents gain connectors, plugins or Copilot Studio integrations to non-Microsoft services. Each connector in a published agent is a supply chain entry and belongs in the map.
- Concentration and exit: an honest register entry acknowledges that substituting Microsoft 365 is not a feasible short-term exit for most regulated entities. What APRA's language actually requires is knowing which critical operations depend on AI outputs and evidencing the fallback for each, which is the achievable form of substitution.
Frontrow's guide to Microsoft 365 Copilot for Australian financial services, at /insights/copilot-for-financial-services-australia, covers the deployment posture side of this in more depth, including data sovereignty and licensing.
Change management: the inventory and the identity problem
The letter expects a consistent governance framework with clear ownership across the AI lifecycle, an inventory of AI tooling and use cases, and human involvement in decisions where risk is high. The inventory is where most entities discover the real state of things: agents built in Copilot Studio trials, Power Automate flows quietly making eligibility calls, AI features switched on inside SaaS products nobody logged.
- Agent inventory: the Microsoft 365 admin center lists Copilot agents deployed to the organisation, and the Power Platform admin center enumerates every Copilot Studio environment and the agents inside each. Between the two, a complete first-pass inventory of Microsoft-side agents is an afternoon's work, not a program.
- Agent identity: Microsoft Entra Agent ID gives AI agents first-class identities in the tenant directory, so agents get the same treatment as users and workload identities: Conditional Access, lifecycle management, an accountable human owner, and access that expires rather than persists. For APRA's 'clear ownership across the AI lifecycle' expectation, an agent registry where every agent has a named owner and a governed identity is close to a literal implementation.
- Human involvement in high-risk decisions: design agents so that consequential outputs are recommendations routed to a person, and record the approval. Where a Power Automate flow currently auto-actions something with member or customer impact, that is the first candidate for inserting an approval step.
Assurance: frameworks, second line and continuous monitoring
The final expectation set covers the use of globally recognised control frameworks and control libraries, integrated assurance across cyber security, data governance and model performance, monitoring proportionate to use-case criticality, and second-line functions capable of technically assessing AI. Two practical notes from engagements with regulated entities.
First, the framework question has a defensible answer today: ISO 42001 for the AI management system, mapped against the controls already run for CPS 234. Frontrow's comparison of ISO 42001, the Voluntary AI Safety Standard and the Essential Eight, at /insights/iso-42001-voluntary-ai-safety-standard-essential-eight-australia, covers which to start with and why they are complements rather than rivals. Second, the second-line capability gap is real: risk functions that can challenge a credit model often cannot yet challenge a retrieval-grounded Copilot agent. Giving second line read access to DSPM for AI reporting and Purview Audit is a fast, concrete uplift, because it lets them test claims rather than accept attestations.
Verified August 2026 against APRA's letter to industry on artificial intelligence of 30 April 2026, the current CPS 234 and CPS 230 pages on apra.gov.au, and Microsoft's published documentation for Entra Agent ID, Purview DSPM for AI and Microsoft 365 Copilot privacy. The letter names no specific prudential standard; the CPS 234 and CPS 230 connections above are Frontrow's analysis of where its expectations become supervisable obligations.