3366 Members
Join Permit's SlackQuick answer: From 10 December 2026, APP 1.7 requires certain Australian APP entities to disclose in their privacy policy the kinds of personal information and decisions involved when computer programs make, or substantially assist, decisions that significantly affect individuals. Use this post to prepare engineering evidence. Don't treat it as legal advice or a policy template: privacy counsel decides your wording and scope.
From 10 December 2026, APP 1.7 creates a hard privacy-policy obligation for APP entities that arrange for computer programs to make, or substantially and directly assist, decisions that could significantly affect an individual's rights or interests, where personal information about that individual is used in the program's operation. The policy wording belongs with privacy counsel. But truthful disclosure depends on engineering evidence: an inventory of decisioning systems and agents, provenance for the personal information they use, and authorization logs that show who or what could access which data, under which policy, for which decision path. AuthZ is not legal drafting. It is the control layer that makes the drafting defensible.
The Privacy and Other Legislation Amendment Act 2024 introduced APPs 1.7, 1.8, and 1.9. They commence on 10 December 2026.
From that date, an APP entity must include additional information in its APP Privacy Policy if all of the following are true:
The text of APP 1.7, as reproduced by the Office of the Australian Information Commissioner (OAIC), reads:
1.7 Without limiting subclause 1.3, the APP privacy policy of an APP entity must contain the information covered by subclause 1.8 if: (a) the entity has arranged for a computer program to make, or do a thing that is substantially and directly related to making, a decision; and (b) the decision could reasonably be expected to significantly affect the rights or interests of an individual; and (c) personal information about the individual is used in the operation of the computer program to make the decision or do the thing that is substantially and directly related to making the decision.
APP 1.8 sets the disclosure categories: the policy must describe the kinds of personal information used in the operation of such computer programs; the kinds of such decisions made solely by the operation of such computer programs; and the kinds of such decisions for which a thing substantially and directly related to making the decision is done by the operation of such computer programs.
APP 1.9 clarifies two important points. "Making a decision" includes refusing or failing to make a decision. And the obligation applies whether the decision is beneficial or adverse to the individual.
The OAIC has given examples of decisions that may affect rights or interests, including decisions under legislation to grant or refuse a benefit, decisions affecting rights under a contract or agreement, and decisions affecting access to a significant service or support, such as healthcare.
This is a transparency and privacy-policy obligation. It is not, by itself, a general right to human review. It is not a ban on AI. It is also not limited to AI; the language is broader than that. Rules engines, scoring systems, workflow automation, and agentic systems can all become relevant depending on the decision and the personal information used.
The amendments apply to decisions made from 10 December 2026, regardless of when the arrangement was made, the program was created, or the personal information was collected. Existing systems can therefore matter from commencement.
The OAIC has said it will publish detailed guidance about these APP 1 obligations in 2026, and that guidance may evolve. That is another reason to build an evidence base now rather than treat this as a last-minute policy rewrite.
The practical question for security and engineering leaders is simple: can you prove what personal information your automated decisioning systems and agents are allowed to use, and under what conditions?
Here is the tighter homework list.
Build a living inventory of computer programs that may make, refuse, fail to make, recommend, route, escalate, or substantially assist a decision that could significantly affect an individual.
Do not stop at "AI models." Include rules engines, eligibility services, fraud workflows, scoring systems, triage tools, orchestration layers, and agents that call tools or retrieve information for a decision path.
For each item, capture owner, decision function, sole vs assisted path, kinds of personal information used, systems/tools involved, and current enforcement/logging posture. That inventory bridges privacy language and production reality.
APP 1.8 asks for "kinds" of personal information and "kinds" of decisions. Engineering teams should map those kinds to concrete authorization objects.
Map kinds of PI to concrete resources and actions (for example profile.read, transactions.read, eligibility.calculate, service_access.approve / service_access.refuse), then attach tenant, product, purpose, workflow step, and human or agent identity. Broad internal grants like "the risk service can read customer data" are too vague for consequential decisioning disclosure.
Authorization evidence only matters if enforcement happens at the right boundary.
For automated decisioning, there are two critical enforcement points:
As covered in PEP/PDP architecture and decision logs, the policy enforcement point asks the authorization question at runtime, and the policy decision point evaluates it against policy and context.
For APP 1.7 readiness, the decision record should show more than allow or deny. It should preserve the identity, resource, action, policy, context, tenant, time, and result. If personal information is used in a significant decision path, access to that information should not be an invisible internal implementation detail.
A useful policy model answers: can this agent read this PI for this tenant? Can this workflow use data for triage but not refusal? Can this model recommend review but not decide? Can a support user override? Can a batch job use historical data for monitoring but not live eligibility? The pattern is granularity across human and non-human identity, resource, action, tenant, purpose, and workflow step. As discussed in Agents as privileged identities, agents that retrieve PI, call tools, or prepare decision outputs should be governed like privileged identities, often more strictly than humans, because they act continuously and at machine speed.
APP 1.7 does not require "realtime authorization" as a phrase. But stale authorization is how disclosure drifts away from production.
Drift happens when an agent gets a new tool, a workflow adds a data source, a model is routed through a different provider, tenant settings change, role mappings move, or emergency restrictions are applied during an incident.
If authorization changes propagate slowly while automated workflows change quickly, your evidence describes yesterday's system. Realtime sync and revoke help keep the enforcement layer aligned with the actual decisioning path.
The goal is not to paste raw logs into a privacy policy. The goal is to support the policy statement with operational facts.
Useful evidence covers systems and agents in the decision path, PI categories accessed, human and non-human identities, policy versions, allow/deny decisions by resource/action/tenant/time, and permission-change history. That lets privacy and legal describe kinds of PI and kinds of decisions from production facts, not only interviews.
For APRA-regulated entities, APP 1.7 sits alongside a broader prudential conversation about AI and operational resilience.
APRA's April 2026 Letter to Industry on Artificial Intelligence did not announce a separate dedicated AI prudential standard in that letter. It did state that the existing prudential framework applies, and it signalled expectations for a step-change in governance, risk management, assurance, and operational resilience.
Authorization themes in that letter are familiar: IAM that may not yet account for AI agents and other non-human actors; stronger controls for agentic workflows; privileged access beyond admins to tools, models, and service identities; human involvement for high-risk decisions; inventories of AI tooling and use cases; and assurance that lags deployment. That is parallel pressure, not a claim that APP 1.7 is an APRA requirement. Permit.io does not satisfy APRA obligations or replace CPS 230, CPS 234, or any other prudential standard, but the same muscles show up: inventory, NHI IAM, enforcement, privileged access, realtime change control, and evidence.
APP 1.7 readiness should not feel like a new control universe. It is another reason to build access control you can prove.
| Earlier post | Relevance to APP 1.7 readiness |
|---|---|
| Explainable deny and decision evidence | Shows why access to data or a decision action was allowed or denied. |
| Access control you can prove | Turns policy into evidence for security and regulatory review. |
| PEP/PDP architecture and decision logs | Places enforcement at runtime and records decisions. |
| Four pillars: enforcement, granularity, realtime, audit | Provides the operating model for changing decisioning systems. |
| The AI era: same bar, higher workload | Explains why agents increase authorization volume and complexity. |
| Agents as privileged identities | Extends IAM and PAM thinking to non-human actors. |
The Week 8 support companion, the four-pillars APP 1.7 checklist, turns this into a more tactical review path.
Permit.io is an authorization platform. The right way to think about Permit here is product second, homework first: define the systems, data, actions, and evidence you need; then use an authorization architecture that can enforce and observe them.
Permit uses a hybrid PDP model. Policy management and configuration live in the control plane, while authorization decisions can be evaluated close to your application in the data plane. For regulated and privacy-sensitive systems, that matters because you can enforce policy near the protected resource without making every access check dependent on a remote SaaS call. See how Permit works and the PDP documentation.
OPAL is the realtime policy and data distribution layer behind this model. It helps synchronize policy and authorization data to PDPs, so changes in permissions, relationships, tenant configuration, or policy can take effect quickly. See Permit's control plane / data plane split and how Permit works.
For APP 1.7-style readiness, the pattern is:
Permit's audit log types and filtering cover the product concept. Those logs do not write the APP Privacy Policy. They help answer the operational question behind it: what did our users, services, and agents have permission to access, and what did the authorization layer decide?
Count back from 10 December 2026. If your environment is complex, start earlier. But these windows are useful forcing functions.
Authentication is not enough. IAM may identify the caller; authorization decides whether that caller, in this context, can access this PI or perform this decision action.
The point is not to turn engineers into lawyers. It is to prevent legal from drafting in the dark.
Can you accurately describe the personal information your automated systems use, the kinds of significant decisions they make or support, and the controls governing access to that information? SaaS vendors selling into Australia will hear the same question in customer reviews. For APP entities and APRA-regulated organizations, privacy transparency, AI governance, privileged access, and operational resilience converge on one control surface: who or what can access sensitive data, under what conditions, to make or assist which decision.
This is not legal advice, and Permit does not guarantee compliance with the Privacy Act, APRA expectations, SOC 2, DORA, or any other framework; counsel should confirm applicability and wording.
Start with the inventory. Map PI to resources and actions. Put PEPs at the right boundaries. Treat agents as privileged identities. Keep policy synchronized. Preserve audit evidence. Then let counsel translate production facts into the APP Privacy Policy.
For the tactical version, use the companion four-pillars APP 1.7 checklist. To see how Permit's hybrid PDP, OPAL-based realtime sync, and audit logs can support the authorization evidence layer, talk to us.
Co-Founder / CEO at Permit.io
