The six frontier AI obligations as controls and evidence a business can hold today
The government will propose that a new targeted regulator, working with the Australian AI Safety Institute, enforce the obligations with significant penalties.

On this page
Six obligations and the record behind each
On 10 November 2026 the Australian Government said it will legislate six safety and security obligations for frontier AI companies that wish to operate in Australia. The release names no technical standard, such as ISO/IEC 42001, that companies must follow. We mapped the six to ISO/IEC 42001:2023 and ISO/IEC 27001:2022.
Obligation: Security controls across development and deployment
- Control
- Secure development life cycle, access control, logging and separate environments for each AI system
- Evidence
- Design review, access review, pipeline and audit logs, test results for each release
- Reference
- ISO/IEC 27001 Annex A 5.15, 8.15 and 8.25 to 8.31; ISO/IEC 42001 Annex A.6
Obligation: Identify and manage serious risks
- Control
- A risk assessment and treatment for each AI system, and an impact assessment where people are affected
- Evidence
- Risk register with owner, rating, treatment and review date
- Reference
- ISO/IEC 42001 clauses 6.1, 8.2, 8.3 and 8.4
Obligation: Independent evaluation
- Control
- Testing and review by people who did not build the system
- Evidence
- Test report with findings, severity and re-test results; internal audit report
- Reference
- ISO/IEC 42001 clause 9.2; ISO/IEC 27001 Annex A 5.35 and 8.29
Obligation: Incident notification
- Control
- Incident response plan with an AI scenario, a decision owner and notification contacts
- Evidence
- Runbook, contact list, exercise record and incident log
- Reference
- ISO/IEC 27001 Annex A 5.24 to 5.28; ISO/IEC 42001 Annex A.8
Obligation: Published safety and security framework
- Control
- AI policy, accountable roles and a statement of the controls in operation
- Evidence
- Approved policy, Statement of Applicability and a summary a customer can read
- Reference
- ISO/IEC 42001 clauses 5.2 and 7.5, Annex A.2
Obligation: Respond to updated standards and rules
- Control
- A register of legal, contract and standards requirements with an owner and a review cycle
- Evidence
- Management review minutes and a dated change log
- Reference
- ISO/IEC 42001 clauses 4.2, 9.3 and 10.1; ISO/IEC 27001 Annex A 5.31
| Obligation | Control | Evidence | Reference |
|---|---|---|---|
| Security controls across development and deployment | Secure development life cycle, access control, logging and separate environments for each AI system | Design review, access review, pipeline and audit logs, test results for each release | ISO/IEC 27001 Annex A 5.15, 8.15 and 8.25 to 8.31; ISO/IEC 42001 Annex A.6 |
| Identify and manage serious risks | A risk assessment and treatment for each AI system, and an impact assessment where people are affected | Risk register with owner, rating, treatment and review date | ISO/IEC 42001 clauses 6.1, 8.2, 8.3 and 8.4 |
| Independent evaluation | Testing and review by people who did not build the system | Test report with findings, severity and re-test results; internal audit report | ISO/IEC 42001 clause 9.2; ISO/IEC 27001 Annex A 5.35 and 8.29 |
| Incident notification | Incident response plan with an AI scenario, a decision owner and notification contacts | Runbook, contact list, exercise record and incident log | ISO/IEC 27001 Annex A 5.24 to 5.28; ISO/IEC 42001 Annex A.8 |
| Published safety and security framework | AI policy, accountable roles and a statement of the controls in operation | Approved policy, Statement of Applicability and a summary a customer can read | ISO/IEC 42001 clauses 5.2 and 7.5, Annex A.2 |
| Respond to updated standards and rules | A register of legal, contract and standards requirements with an owner and a review cycle | Management review minutes and a dated change log | ISO/IEC 42001 clauses 4.2, 9.3 and 10.1; ISO/IEC 27001 Annex A 5.31 |
Who is exposed in Australia
Piper Alderman says the announcement does not specify a commencement date or any specific thresholds for which companies or models fall in scope. It says most Australian organisations will not be frontier AI companies and that the obligations are not directed at them.
For an organisation that uses AI, Piper Alderman advises assessing whether that use gives rise to automated decision-making transparency requirements. Those requirements are in Part 15 of Schedule 1 to the Privacy and Other Legislation Amendment Act 2024. Part 15 commences on 10 December 2026 and adds Australian Privacy Principle 1.7.
What Australian Privacy Principle 1.7 covers
The principle covers an APP entity that has arranged for a computer program to make a decision, or to do a thing substantially and directly related to making one. The decision must be one that could reasonably be expected to significantly affect an individual's rights or interests, and the program must use personal information about that individual.
The entity's privacy policy must then state the kinds of personal information used and the kinds of decisions involved.
Security controls across development and deployment
The obligation covers every stage, so the control set starts at design and ends at retirement. For an AI system that means the data it is trained or run on, the pipeline that builds it, the permissions it holds in production and the logs it writes.
The Guidance for AI Adoption lists applying the Essential Eight Maturity Model to AI systems among its cybersecurity processes. Input and output controls, tool permissions and tenant boundaries sit beside the secure development controls in ISO/IEC 27001 Annex A 8.25 to 8.31 and the life cycle controls in ISO/IEC 42001 Annex A.6.
- Guardrails on input and output for each AI feature, tested as controls that can fail
- Least privilege for every agent and service account, with tool access approved by a named owner
- An audit trail of each automated action: what ran, on whose data, with what result
- Tenant isolation enforced at the data layer for multi-tenant products
- Separate development, test and production environments, with production data kept out of test
A risk register for model risks
Give each AI system its own entry in the risk register: what it does, the data it reaches, what could go wrong, who owns the risk and how it is treated.
ISO/IEC 42001 asks for the risk assessment in clause 8.2, the treatment in clause 8.3 and an impact assessment in clause 8.4 for systems that affect people. Review each entry at a planned interval and after any significant change to the system or its use.
- Prompt injection through user input or retrieved content
- Data leakage across users, tenants or permission levels
- An agent acting outside its approved task or tool scope
- Outputs trusted downstream without review
- A supplier model change that alters behaviour without notice
- Decisions about people made with no way to challenge them
Independent evaluation
The release says only that companies will be required to allow independent evaluation of their models. The committee recommended independent, qualified and, over time, accredited individuals embedded in frontier labs with employee-like access. The government has not said which form evaluation will take.
For a business, independence means the people who test a system did not build it. The Guidance for AI Adoption asks for independent review, internal or external, of testing and evaluation for general-purpose AI systems and use cases that need enhanced practices. Its examples of safety evaluation include testing for jailbreaking or prompt manipulation, and red teaming.
- A test report with each finding, its severity, impact and steps to reproduce
- A re-test record showing which fixes held
- An internal audit of the AI management system under ISO/IEC 42001 clause 9.2
A published safety and security framework
Frontier AI companies will have to maintain and publish safety and security frameworks. The business-scale version is a short public statement backed by internal documents: the AI policy, accountable roles, the risk method, testing, incident handling and how often each is reviewed.
Under ISO/IEC 42001 the policy sits in clause 5.2 and the selected controls in a Statement of Applicability. Publish the summary and share the detail with customers under a confidentiality agreement. Check each sentence of the public summary against the approved AI policy, the Statement of Applicability or a dated test report.
An incident notification runbook
The release sets no deadline beyond the word rapidly and does not define an incident. The Joint Select Committee on Artificial Intelligence recommended clear reporting deadlines. Its letter lists events that may be reported to a proposed parliamentary standing committee, including significant cyber incidents involving AI and unintended actions of AI agents and models.
A business can write the runbook around existing duties. An entity that suspects an eligible data breach must take all reasonable steps to complete its assessment within 30 days. The Guidance for AI Adoption asks developers and deployers to maintain two-way communication for incident reporting.
- What counts as an AI incident for your systems, with examples
- Who decides to notify, and who can stop the system
- Each party to tell: customers, the AI supplier, regulators and insurers, with contacts
- The clock for each notice, taken from the law or contract that sets it
- The evidence to keep: prompts, outputs, logs and the model version
- A tabletop exercise each year against an AI scenario
What to do now
Build the AI inventory first, because every later check draws on it. The Guidance for AI Adoption asks for an organisation-wide inventory of each AI model and system that records accountable people, purpose, identified risks, the risk treatment plan and dates of review.
The committee's final report is due by 30 November 2026, and Australian Privacy Principle 1.7 commences on 10 December 2026. The government says further details of the legislation will become available as it completes its detailed work and consultation.
- AI inventory: list each AI model and system with its accountable people, purpose, datasets and review date
- Risk register: check each system has an entry with a risk owner, a rating and a treatment
- Incident runbook: check it has an AI incident scenario, a named decision owner and a 30-day data breach assessment step
- Privacy policy: check it states each kind of decision a computer program makes or helps make about a person
- Requirements register: assign one owner to the laws, standards and contract terms, and review it at management review
Sources
- PrimaryPrime Minister of Australia, New Australian AI safety and security protections (joint media release, 10 November 2026)Retrieved 15 Nov 2026
- PrimaryJoint Select Committee on Artificial Intelligence, letter to the Prime Minister (12 October 2026)Retrieved 15 Nov 2026
- PrimaryNational AI Centre, Guidance for AI adoption: implementation guidance (5 May 2026)Retrieved 15 Nov 2026
- PrimaryFederal Register of Legislation, Privacy and Other Legislation Amendment Act 2024 (No. 128, 2024), section 2 and Schedule 1 Part 15Retrieved 15 Nov 2026
- PrimaryAttorney-General's Department, Privacy Reform consultation paperRetrieved 29 Oct 2026
- SecondaryPiper Alderman, Mandatory AI safety and security protections for frontier AI: Australia sets its direction (11 November 2026)Retrieved 15 Nov 2026



