Until recently, assessing an AI tool against the ISM meant mapping general controls onto a product they weren’t written for. That has changed. Over the past year or so the ISM has picked up a set of AI-specific controls, and the September 2026 release adds more. If your vendor assessment template predates them, it’s out of date.
This article covers what those controls ask for, where IRAP fits, and the questions worth putting to an AI vendor. Control IDs are from the September 2026 ISM; check the current release before you quote them in an assessment.
Accountability starts at the top
The ISM’s governance principles now include GOV-08: the board of directors or executive committee is accountable for ensuring AI is secure, controllable, human-supervised and used in an ethical and accountable manner. It’s a principle rather than a control, but it changes who owns the risk. AI adoption can’t sit solely with an innovation team.
For Commonwealth entities this lines up with the DTA’s Policy for the responsible use of AI in government (version 2.0, effective 15 December 2025), which requires accountable officials, use case owners and internal use case registers.
The controls that matter for an AI chat or assistant
These are the ones we’d put in front of any vendor of a chat-style AI tool:
- ISM-2074: a general-purpose AI usage policy is developed, implemented and maintained.
- ISM-2093: role-based access controls restrict AI applications’ access to sensitive data.
- ISM-1924: generative AI applications evaluate prompts to detect and mitigate adversarial inputs (prompt injection and jailbreaks).
- ISM-2094: content filtering detects and blocks sensitive data exposure and improper output.
- ISM-2103: organisational data isn’t used for training, fine-tuning or improving models without informed and explicit consent from the data owners.
- ISM-2123: prompts and outputs are securely deleted when a chat session is removed.
- ISM-2112: AI applications that process classified data have direct access to external public data sources disabled. In practice, that means web search off for classified work.
If the tool can take actions rather than just answer questions, the agent controls apply too: human approval before sensitive or high-impact actions (ISM-2113), a unique identity for each AI agent (ISM-2133), an AI agent register (ISM-2134), and central logging of every tool invocation and output (ISM-2159).
The general logging controls haven’t gone away. ISM-0585 sets the minimum detail for each logged event (date and time, user or process, event description and equipment involved), ISM-1405 asks for a centralised logging facility, and ISM-1988 asks for event logs to be kept searchable for at least 12 months. An AI tool whose logs you can’t export can’t help you meet any of these.
What IRAP does and doesn’t tell you
The Infosec Registered Assessors Program lets ASD-endorsed assessors evaluate how a system implements ISM controls. The output is a report that helps your authorising officer decide whether to accept the residual risk. It isn’t a certificate, and it doesn’t make the decision for you.
ISM-1570 expects outsourced cloud service providers and their cloud services handling non-classified, OFFICIAL: Sensitive, PROTECTED or SECRET data to undergo an IRAP assessment at least every 24 months, against a recent ISM release. Three things follow for AI procurement.
First, an assessment of the underlying cloud isn’t an assessment of the AI service. A vendor that runs on an IRAP-assessed AWS or Azure region has inherited assurance for the infrastructure, but its own application, staff, logging and data handling sit outside that scope.
Second, read the scope and the date. Which services, which classification, which ISM release, and which controls were found ineffective or not implemented? A two-year-old report predates every AI control listed above.
Third, register it. ISM-1637 and ISM-1638 expect an outsourced cloud service register that records, for each service, the data sensitivity involved and the due date for its next assessment. Add your AI tools to it, including the ones staff adopted without asking.
Unsanctioned AI use
The procured tool is rarely the biggest risk. Staff using personal accounts on consumer AI services for work tasks are harder to see and harder to govern, because your logging and retention controls don’t reach them.
Banning these tools on its own tends not to work. Staff who find AI useful keep using it, just less visibly. What works better is a sanctioned tool that is good enough to use, plus a clear policy on what can go where. For government, the DTA’s staff guidance on public generative AI already draws the line: OFFICIAL information subject to agency policy, nothing OFFICIAL: Sensitive or above.
A vendor checklist built on the current controls
Data location
- Where inference runs, and where prompts, outputs, files, indexes, logs and backups are stored
- Every sub-processor that touches content, and its location
Data handling
- No training on your data without explicit consent (ISM-2103), stated in the contract
- Retention periods for prompts and outputs, including any provider-side logs
- Deleting a chat deletes its prompts and outputs (ISM-2123)
Access and identity
- SSO through your identity provider, MFA enforced, role-based access to models and features (ISM-2093)
- Whether vendor staff can read your content, and how you’d know
Monitoring
- Prompt-level audit events with the ISM-0585 fields, exportable to your SIEM
- Logs retained and searchable for at least 12 months (ISM-1988)
Assurance
- The vendor’s own IRAP report: scope, classification, ISM release and date (ISM-1570)
- Prompt-injection screening (ISM-1924) and output filtering (ISM-2094)
- Incident notification timeframes in the contract
Our own position
Since we’re asking you to check vendors this carefully, here’s where K9 AI stands. K9 AI is undergoing an independent IRAP assessment up to PROTECTED, expected to complete by December 2026. It runs on AWS infrastructure in Sydney, and AWS’s in-scope services have been IRAP-assessed up to PROTECTED, but that is an AWS assessment, not one of K9. K9 AI is currently operated for information up to OFFICIAL: Sensitive; PROTECTED handling is not available in production.
Frequently asked questions
Does the ISM have controls specific to AI?
Yes. The current ISM has an AI usage policy control (ISM-2074), a set of controls for AI applications covering access, prompt injection, content filtering, training on organisational data and chat deletion, and newer controls for AI agent identity and registers. The governance principle GOV-08 makes the board or executive accountable for AI being secure and human-supervised.
If an AI tool runs on an IRAP-assessed cloud, is the tool IRAP-assessed?
No. The cloud platform's assessment covers the platform. ISM-1570 expects the outsourced cloud service itself to have an IRAP assessment, so ask the AI vendor for theirs and read its scope.
How often should an AI vendor's IRAP assessment be renewed?
ISM-1570 says outsourced cloud services should be assessed against a recent ISM release at least every 24 months, so check the date of the report as well as its scope.
Put this into practice with K9 AI.
Australian-hosted AI with redaction, classification and audit built in. Try it free for 14 days with no credit card, or talk to us about a pilot.
