← BlogOctober 27, 2026Privacy Act · APP 1.7 · Automated Decision-Making · AI Governance · OAIC · Security Leadership

Automated Decisions Under the Privacy Act: The Part Security Has to Find

APP 1.7 starts on 10 December 2026. What the test actually says, why a person in the loop rarely takes a system out of scope, why the OAIC names fraud and security tools, and what security needs to hand legal before the deadline.

Sometime in the next six weeks, someone from legal or privacy is going to ask you for a list. They'll want every system that uses personal information to make decisions about people, or to help someone make them. And they'll want it quickly, because from 10 December 2026 the privacy policy has to describe those decisions, and the OAIC only finalised its guidance at the end of September. Legal will write the policy. They can't build the list on their own, and neither can you. HR knows its recruitment tools. Model risk keeps the credit and pricing models. Fraud might sit with you or with financial crime. Security sees something different again: the SaaS apps behind single sign-on, the AI features a vendor switched on in the last release, the API calls out to scoring and identity services, and the controls you run yourself.

What changes on 10 December

The Privacy and Other Legislation Amendment Act 2024 added three clauses to Australian Privacy Principle 1, numbered 1.7 to 1.9. They start on 10 December 2026, two years after the Act got Royal Assent. From that day, if an organisation covered by the Privacy Act uses computer programs in decisions that significantly affect people, its privacy policy has to say so. That's Australian Government agencies and most businesses turning over more than $3 million a year, plus some smaller ones such as health service providers. It's a disclosure rule. It doesn't ban anything, and it doesn't give anyone a right to an explanation. But it applies to every decision made from 10 December, including decisions made by systems you bought years ago (item 89). The OAIC published its guidance on 30 September: an updated APP 1 chapter, a fact sheet and a flowchart. Read the fact sheet. It's eleven pages, and the seven worked examples at the back are the useful bit.

The three-part test

All three conditions have to be met. 1. The organisation has arranged for a computer program to make a decision, or to do something "substantially and directly related to making" one. "Computer program" has its ordinary meaning. The Explanatory Memorandum says it covers simple rules as well as AI and machine learning. The OAIC adds everyday software, apps, word processors and generative AI, chatbots included. One of its examples is a spreadsheet formula that ranks health and aged care clients by need. "Substantially" means the output is a key factor in the person's decision. "Directly" means there's a direct connection to the decision. It has to be both. The EM explains it with Excel: adding up a column is direct but not substantial, while a score about a person that the decision-maker relies on is both. "Arranged for" is wider than "built". Software you bought counts. So does a product you configured, a program you let decide on its own, or a recommendation your staff rely on. Buying it doesn't make it the vendor's problem either. The OAIC expects the obligation to stay with the organisation making the decision. 2. The decision could reasonably be expected to significantly affect someone's rights or interests. "Significantly" means more than trivial. The OAIC lists areas it would generally treat as significant, including essential banking and credit, telecommunications, utilities, housing, healthcare, education and employment. Saying no counts as a decision, and so does doing nothing. The effect can be good or bad. Vulnerability changes the answer. In the OAIC's rideshare example, suspending an account is minor for most customers, but not for someone who relies on the service to get to medical appointments. If a system's output is materially different for a vulnerable group, the guidance says to treat it as significant. 3. Personal information about the person is used to make the decision. For anything that decides about a named customer, employee or applicant, it is. For the systems security knows best, it usually comes out like this:

Fraud scoring that declines a transaction or blocks access to an account: generally in scope where the service is significant. The OAIC's own sample wording for a lender covers these decisions.
AML transaction monitoring, customer risk rating and sanctions screening that hold payments or exit customers: my reading is these are in scope for the same reason, wherever they sit in your organisation.
Identity checks that refuse to open an account, and lockouts that shut someone out of one: in scope where the service is significant, like banking or telco. I'd treat a step-up challenge the person can pass differently from a refusal, unless some people realistically can't pass it, such as someone without a mobile phone. Ask legal where your line sits.
Recruitment screening and ranking: in scope. The OAIC's recruitment example puts both the job ad targeting and the video interview scorer in scope. I'd expect automated identity, police and financial background checks on applicants to be in scope too, but confirm that with legal.
Insider risk flags about current staff: the employee records exemption may cover a private sector employer here, but probably not where the tool collects new monitoring data. More on that below.
Credit, insurance and personalised pricing models: generally in scope. The OAIC says even small price differences on essential goods can be significant once they add up.
A vendor's AI feature that summarises a case and suggests an outcome: in scope if the person deciding relies on it.
A word processor used to write up a decision someone already made: out. An AI feature in the same tool that drafts the decision is a different story.

Human review doesn't take it out of scope

This is the first thing people reach for, and the guidance shuts it down. The APP 1 chapter says a decision can be in scope "even where a computer program output does not replace the entire decision-making process or is subject to human review." That's why the "substantially and directly related" limb is there. The EM says programs recommend decisions to people and guide them, and the limb is meant to catch that. A person signing at the end doesn't change it. What the OAIC looks at is how much the person actually adds. It lists five factors:

how much the decision-maker relies on the output
whether they can override it, and how often they do
whether the output is advice or the answer
whether they can see what the program did and why
how deeply the program is built into the workflow

Two of its examples are worth showing your team. In one, staff can overturn an algorithm that suspends seller accounts, but they rarely do because they trust it. In the other, a scholarship panel is free to ignore a ranking, but it still looks at it, so the program still counts. For machine learning and generative AI the fact sheet goes further. Outputs used for significant decisions "would generally fall within scope of the transparency obligation unless subject to extensive human oversight and control." It doesn't say what extensive means. Its pay review example gives a hint: people questioning the output, checking the numbers behind it, setting the tool's parameters more narrowly, using other evidence, and writing down why they went against the recommendation. Every one of those leaves a record. A reviewer who leaves none will struggle to show the output wasn't a key factor.

The OAIC names security's own tools

The APP 1 chapter's example of how to group disclosures is about our tools. Paragraph 1.73 describes an organisation using "a range of different computer programs for fraud detection, scam identification, and cybersecurity which may prevent access to significant goods or services". Its policy can then say which personal information those tools use, such as identity information, geolocation data, biometric information and IP addresses, to decide whether to permit, flag or deny access to an account. So think about account takeover rules, device and behavioural risk scores, lockouts, transaction holds and the bot defences on a sign-up page. If any of them can stop someone getting into their bank account, energy account or phone service, there's probably a disclosure to make. Security or fraud is usually the team that knows what those systems actually use. You don't have to publish your detection logic. Commercial-in-confidence information, such as how a unique in-house model weights its inputs, can stay out. The carve-out is narrow, though. In the fact sheet's lender example, using personal information for fraud detection at all is standard practice and not confidential, so that part goes in. Agree the level of detail with your fraud and threat teams. Wording like "device and network information" describes the inputs without handing fraudsters a list of signals to fake. If AML monitoring is involved, bring your AML compliance officer into the wording too.

What the policy has to say

APP 1.8 asks for three things:

the kinds of personal information the programs use
the kinds of decisions made solely by the programs
the kinds of decisions where the programs do something substantially and directly related to the decision

The Act lists those last two separately, so I'd say which is which. The OAIC's own samples don't always split them, and how to present it is legal's call. But which bucket a system sits in is a fact about the system, and legal won't know it unless you tell them. Grouping is allowed, so nobody expects a paragraph per model. The grouping still has to be "meaningful to a reasonable person", and "we use technology to improve our services" won't pass. The OAIC also wants it clear where sensitive information like health information or biometric templates is used, and wants the wording framed so a decision can be "challenged or contested". That's drafting guidance. APP 1.7 doesn't give anyone a new right to have a decision reviewed. A privacy policy is a public statement. If yours lists three kinds of decision and the organisation makes seven, or leaves out the face matching on the login page, it's wrong in public. And the OAIC has already started checking privacy policies.

What security brings

Legal decides what's in scope and writes the words. Privacy owns the policy. What they need from you is the evidence underneath it, and none of that is legal work. Before you start, ask legal whether the work should run at their direction. If it does, you record the facts and they record the conclusions, so their advice on scope can stay privileged. I'd split the work into five parts.

1. Find the decisions

Email each business unit asking "do you use AI to make decisions?" and you'll get a short list with gaps in it. People don't think of a rules engine as a decision-maker, and they rarely know what their SaaS vendor shipped last quarter. Start with what already exists:

the information asset register or CMDB, and for APRA-regulated entities, the material service provider register
the model risk inventory and the end-user computing register, where the spreadsheets live
the identity provider's app catalogue, for SaaS behind single sign-on. Use the catalogue, because sign-in logs tell you who uses a tool but not what it decides
the contract register and accounts payable, for SaaS bought outside IT, including on corporate cards
API gateway and integration logs, which show calls out to credit bureaus, identity verification and fraud scoring services
the admin consoles of your big platforms like HR, CRM, ticketing, contact centre, collections and marketing, where AI features show up as settings and are sometimes on by default
vendor release notes for those platforms, because new automated features usually turn up in an update
your own controls: fraud, identity proofing, account protection, insider risk
old privacy impact assessments, and complaints that say "the system declined me"
outsourced operations, like collections agencies and contact centres that score or prioritise customers

CASB and proxy logs will mostly show staff using chat tools. Worth a look, but as a separate job after the deadline. The OAIC expects organisations to "actively identify, assess and keep oversight over" the third-party programs they use, "both during and after procurement". That's an inventory. If you already work to the NIST AI RMF, GOVERN 1.6 asks for one too, and the Control Mesh maps it to controls you already test.

2. Record what each one uses

For each system, write down the kinds of personal information it takes in. Use the categories your privacy policy already uses, so legal can map them across. Flag anything sensitive, especially biometrics. Then check it. A vendor's data sheet and the fields actually flowing in production aren't always the same.

3. Name the owners

Name the business owner of each decision and the technical owner of the system. They're often different people, and the business owner answers for what the policy says. If nobody will own a decision, fix that first. It's a bigger problem than the policy.

4. Keep it current

APP 1.3 already says a privacy policy has to be up to date. The policy goes stale the day someone switches on a new feature, adds a data source to a model, or changes a threshold so low scores skip human review. An annual review won't catch that on its own. Keep it, and add one question to changes on the systems you've tagged: does this change what the system decides about a person, or what personal information it uses? Model changes can go through model risk validation. SaaS feature toggles mostly never touch the change board, so check those admin consoles each quarter or watch them with an SSPM tool. A yes goes into your normal privacy impact process. This part can wait until after 10 December. Give it ninety days. Until then, ask the owners of tagged systems to tell privacy before they switch on a new feature or data source.

5. Keep the evidence

If the OAIC issues a compliance notice, it can ask for "reasonable evidence of compliance with the notice" (s 80UC(3)). Its APP 1 guidance also suggests keeping a record of the steps you take to comply. So for each system, keep the facts: what it does, the personal information it uses, whether it decides alone or feeds a person, the owners, the vendor's description and the date you checked. Legal keeps its scope reasoning alongside. If legal wants to argue that a person really makes the decision, they'll need proof. Override rates are the best proof, but most systems don't log "recommended" and "decided" side by side, and pulling the numbers takes time. Don't try before 10 December. Where you're not sure, recommend that legal assumes people rely on the output and discloses it. Collect override data later, only for the few systems legal wants to revisit, and report it in total, never by named reviewer.

Who signs

Nobody should sign for what they can't see. A privacy officer can't see the systems. A CISO can't see every spreadsheet or business-configured SaaS rule, and shouldn't sign that a list of business decisions is complete. I'd want three sign-offs:

each business owner, that their entries are right
whoever ran the inventory, usually security or GRC, on the method: which sources, when, and the known gaps
legal and privacy, that the policy matches the list

All three go to one named executive, who reports to the risk committee before 10 December. Agree who that is this week, not in a panicked meeting in December.

If it's wrong

From 10 December, APP 1.7 joins APP 1.3 and 1.4 on the list in section 13K of the Privacy Act. A breach is a civil penalty contravention, and the OAIC can issue an infringement notice or a compliance notice without going to court. Ignoring a compliance notice is a further contravention. The numbers, from the Act and the EM:

An infringement notice is 60 penalty units for a company, or 200 per contravention for a listed company.
In court, the maximum is 200 penalty units for an individual and 1,000 for a company.
The penalty unit went from $330 to $364 on 1 July 2026. That makes an infringement notice $21,840 for a company and $72,800 for a listed one, and the court maximum for a company $364,000.

When the OAIC announced its first privacy policy compliance sweep in December 2025, it quoted "penalties of up to $66,000". That's 200 units at the old $330 rate. The unit value that applies is the one at the time of the contravention, so check the figures with legal. The sweep matters more than the money. The OAIC started 2026 by reviewing the privacy policies of about 60 organisations that collect information in person, against APP 1.4. Section 13K also notes that the same conduct may breach sections 13G or 13H, where the penalties are far bigger. Then there's everyone else who reads it. Your privacy policy will tell customers, journalists, researchers and future complainants where your organisation lets a program decide about them.

Six weeks, in order

If I were starting today, this is the order I'd work in. This week. Meet whoever owns the privacy policy. Agree who drafts, who decides scope, who signs, and the dates. Send vendor questions now, through vendor management, and keep them short: what does the product decide or recommend about people, what personal information does it use, and which AI features are on by default in our tenant? The OAIC expects vendors to give "clear, high-level information". Don't wait on their answers. Your own configuration review comes first. Weeks one and two. Build the candidate list from the sources above. Start with your own controls and the systems that touch customers' money, access, jobs and housing. Split it into what you can describe precisely by 10 December, and what you'll cover now in broader grouped wording and tighten by the end of March. Nothing known or suspected to be in scope gets left out of the December policy. Weeks two and three. For each candidate, record what the program does, the personal information it uses and the owners. Legal makes the calls and starts drafting. Where you're unsure, flag it to legal as one to include, which is the cautious approach the fact sheet recommends. Put it in the right bucket, though. Calling a human-reviewed decision "solely" automated is wrong too. Weeks four and five. Approvals: your executive or disclosure committee, a risk committee update, brand and comms, and every collection notice or app screen that links to the policy. Read every line of the draft against your list. Check the "solely" and "substantially and directly related" split matches what the systems actually do, and that biometric and health information is named where it's used. Give the contact centre and complaints team a short answer for "was my decision automated?". Get the website change in before any December change freeze. By 10 December. The policy is live a few days early, the three sign-offs are filed, and legal has a note, prepared at their direction, of where the wording is broad and when it'll be tightened. The change triggers follow within ninety days.

If you sit on a board

You don't need a board paper for this. Ask management four questions before 10 December:

Who is accountable for our automated decision disclosure being complete and accurate, and when will we see it?
How did we build the list? Does it include our own fraud, identity and security tools, and the AI features our vendors have switched on?
Where we say a person makes the final call, how do we know they actually do?
Once it's published, what tells us it's out of date?

And look for one thing: a system on the list with no named owner.

What's still open

Quite a lot. These are the ones I'd take to legal rather than guess.

How much oversight counts as "extensive". Nobody knows yet how much human review takes an AI-assisted decision out of scope.
The employee records exemption. For a private sector employer, an act is exempt from the APPs only if it's directly related to both a current or former employment relationship and an employee record the employer already holds about that person. The OAIC's examples include performance reviews and pay decisions but don't say how the exemption fits with APP 1.7. It doesn't cover job applicants or contractors, so recruitment tools are judged on the normal test.
Features a vendor turns on by default. If a SaaS release adds a ranking your staff then rely on, the guidance suggests you've arranged for it. That hasn't been tested.
Targeted advertising. The OAIC treats programmatic advertising tied to selling significant goods or services as generally in scope. Past that, it's grey.
How broad the grouping can be. "Meaningful to a reasonable person" will get argued over.
Enforcement. There's none yet, because the rule hasn't started. I couldn't find published results from the 2026 sweep either.
What comes next. The government's exposure draft of the Privacy Amendment (Personal Data Protection) Bill 2026, open for comment from 31 August to 18 September, doesn't change APP 1.7 itself. It would widen the definition of personal information that APP 1.7 relies on, and make precise geolocation tracking data sensitive information, which matters for fraud and identity tools. It's a draft and may change. Separately, Kate Chaney's private member's bill on automated decisions taken under Commonwealth law is before the House.

Check one system

I built a small check for this. Pick one system and one kind of decision, answer a few questions, and it walks you through the test the way the Act and the OAIC's guidance set it out. It shows its reasoning at each step and what to take to legal. It runs in your browser, nothing you type leaves the page, and there's nothing to sign up for. It's built only from the Act, the EM and the OAIC's published guidance. It isn't legal advice. Use it to get your facts ready before legal asks.

Who decides

In the introduction to Decide Who Decides, I wrote about decisions that "used to sit inside somebody's judgement" and now "sit inside a system that somebody configured". A few lines later: "Somebody has to decide who decides. In most organisations, nobody has been asked to." APP 1.7 asks a narrower question. Where does a program decide about a person, or help someone decide? The list you build for legal answers it, and in a lot of organisations it'll be the first time anyone has written that down.

This is general commentary, not legal advice. Work out your organisation's position with your legal and privacy teams.