Australia’s December 2026 Automated Decision-Making Rules: What Privacy Policies Must Disclose

From 10 December 2026, Australia’s automated decision-making (ADM) transparency requirements will add new obligations to Australian Privacy Principle 1 (APP 1) under the Privacy Act 1988 (Cth).

The requirements affect covered APP entities where computer programs use Personal Information in qualifying decisions that could reasonably be expected to significantly affect someone’s rights or interests. Some human-assisted decisions will qualify too.

APP privacy policies must describe the kinds of Personal Information used, the decisions programs make solely, and those they substantially and directly assist in making.

These changes are enacted, but have not yet commenced. They appear in Schedule 1, Part 15 of the Privacy and Other Legislation Amendment Act 2024. The Office of the Australian Information Commissioner (OAIC) published its final supporting resources and updated APP Guidelines, Chapter 1, version 2.0, on 30 September 2026.

Preparation begins with finding the processes that might qualify: which programs use personal information, what they contribute to a decision and what that decision could change for the person.

Who Is Covered, and Which Systems Count?

If your organisation already falls under the Privacy Act 1988, these additions to APP 1 may affect its decision processes. APP entities generally include Australian Government agencies and many private-sector organisations.

For private businesses, the usual threshold is annual turnover of more than AUD $3 million. Smaller businesses can also be covered through statutory exceptions, including certain health service providers and businesses trading in personal information. The OAIC’s scope guidance explains those boundaries.

Overseas organisations may also be covered where they have an Australian link, including where they carry on business in Australia. Having Australian customers or a website accessible in Australia does not, by itself, determine whether the Act applies.

Employment processes deserve a separate check because the private-sector employee-records exemption can apply to some handling connected with current or former employment. It does not generally cover prospective employment relationships or contractors handling another employer’s employee records.

NOTE: “Computer program” is broader than AI. Rules-based systems, scoring tools, spreadsheets, applications and machine-learning tools can all qualify. Using AI, however, is not enough on its own to trigger APP 1.7.

Does software bought from a vendor count? It can. Under the final OAIC guidance, “arranged for” can encompass development, procurement, configuration and authorisation of software used in a relevant decision-making process. Internally built systems, software-as-a-service (SaaS) products and outsourced processes all belong in the picture.

The guidance’s examples range from purchased applicant-ranking tools to contracted refund software and automatic complaint escalation. An employer permitting staff to use AI in performance assessments that influence promotions is another example, although the private-sector employee-records exemption may apply to the relevant handling of employee records. Ownership of the technology is not the dividing line.

Using a vendor does not automatically shift an APP entity’s privacy-policy obligations to that vendor.

When Software Contributes to the Decision

APP 1.7 has three cumulative conditions:

1. Your organisation has arranged for a computer program to make a decision, or do something substantially and directly related to making a decision.
2. The decision could reasonably be expected to significantly affect the rights or interests of an individual.
3. Personal information about that individual is used in operating the program to make the decision or perform the relevant activity.

Under APP 1.9, making a decision includes refusing or failing to make one; doing something includes refusing or failing to do it. Effects may be beneficial or adverse. A scholarship allocation therefore needs the same analysis as a refused application.

A person still makes the final call in many workplaces. That alone does not settle whether the process falls within scope. The words “substantially and directly related” are what matter here.

In the OAIC’s interpretation, “substantially” means the program is a real or significant factor in facilitating the decision, rather than a nominal one. “Directly” requires a direct connection between what the software does and making the decision.

A process can qualify even when the program’s output is advisory, reviewed by someone, capable of being overridden or only one stage in a larger workflow.

Suppose hiring managers receive a ranked list of applicants. They technically have access to every application, but usually interview only the highest-ranked candidates. The ranking’s influence is more revealing than its “advisory” label. Whether managers genuinely consider other applications—and how often they depart from the recommendation—helps explain the program’s role.

WARNING: A “human review required” procedure may describe the intended workflow rather than everyday practice. Actual cases can reveal whether reviewers independently weigh the evidence or routinely accept the score.

At the other end of the scale, a word processor used only to record a decision already reached does not facilitate that decision in the relevant sense.

What Could Change for the Person?

A minor recommendation change and the loss of an important service are different problems. The OAIC’s fact sheet describes a significant effect as one beyond the trivial, with the potential to considerably influence someone’s circumstances or outcomes.

Statutory benefits, contractual rights and access to significant services or support are relevant interests. Circumstances matter too: vulnerability can make an otherwise similar decision more consequential.

These are audit prompts, not automatic legal classifications.

In the account-access example, the initial fraud flag tells only part of the story. A brief check and a prolonged restriction can have very different consequences. How long someone remains locked out, and which service they lose, help explain the effect.

Advertising has a place in this analysis, but not every personalised advertisement qualifies. The OAIC identifies potentially significant effects where targeting produces differential or personalised pricing for significant goods or services, or limits employment opportunities.

Ordinary recommendations and fraud-detection cookies are not automatically covered merely because they involve personalisation or automated processing. However, if personal information collected through such technologies is used to make or substantially assist a decision that could significantly affect an individual’s rights or interests, the process needs to be assessed against all three APP 1.7 conditions.

What the Privacy Policy Must Explain

Once a process meets all three APP 1.7 conditions, APP 1.8 requires information about three distinct matters:

1. The kinds of personal information used in operating the relevant computer programs.
2. The kinds of decisions made solely by those programs.
3. The kinds of decisions for which the programs do something substantially and directly related to making the decision.

The distinction most easily lost in drafting is between the second and third categories.

Consider a recruitment paragraph. “We use technology to improve recruitment” leaves an applicant guessing whether software ranks candidates for human review or rejects applications automatically. The policy should explain both roles where they occur.

Illustrative privacy-policy wording (where APP 1.7 applies): “We use computer programs to assess job applications. The programs use applicants’ qualifications, employment history and assessment results. Some applications are automatically rejected when specified eligibility requirements are not met. We also use software to rank eligible applicants, which hiring managers consider when selecting candidates for interviews.” The wording must match the organisation’s actual practices.

An internal record connecting information inputs → decision category → software role gives the writer something concrete to work from. Without that connection, a policy can become two disconnected lists: every type of data collected and every activity the business performs.

Whether you are updating an existing document or deciding how to create a privacy policy, the starting material should be an accurate account of the processing—not a template’s assumptions about it.

Enough Detail, Without a Technical Inventory

The OAIC allows categories of decisions and information to be combined where the result remains meaningful to a reasonable person. Broad labels should not conceal more sensitive material such as health information or biometric templates.

Readers are more likely to recognise “claims”, “recruitment” or “account access” than internal product names. The OAIC’s privacy-policy guidance favours accessible explanations tailored to the organisation rather than copied legal wording.

Checking that privacy disclosures match actual processing also helps catch omissions: a clear recruitment explanation still leaves a separate automated account-blocking process undescribed.

Commercial Confidentiality

APP 1.8 asks for categories of information and decisions, not publication of source code, algorithms, model weights or every vendor setting. The OAIC also recognises that commercial-in-confidence information may be excluded from disclosure.

Commercial value alone is insufficient. Disclosure must be capable of harming commercial interests; avoiding embarrassment or public criticism is not the same thing. Where confidentiality is relied on, a record of the particular harm helps distinguish genuinely sensitive technical material from information that could be explained publicly.

A higher-level description may preserve meaningful transparency without exposing those details. Confidentiality should not become a blanket reason for saying nothing about the process.

A Policy Is Not a Collection Notice

Your APP Privacy Policy describes how personal information is managed across the organisation. An APP 5 collection notice addresses matters relevant to a particular collection.

The December amendment adds information to the policy; it does not itself require identical ADM wording in every collection notice. Existing APP 5 duties remain relevant, and a contextual explanation or link may help someone understand a particular application or transaction. That additional explanation is distinct from the new policy requirement.

Existing Systems and the Limits of the Change

The transitional rule applies to qualifying decisions made after commencement, regardless of whether the following occurred before or afterwards:

• the arrangement for the computer program;
• its use of personal information;
• the acquisition or creation of that information.

NOTE: There is no general legacy-system exemption. An earlier score or recommendation used in a post-commencement decision belongs in the review too.

These amendments impose transparency requirements. APP 1.7–1.9 do not themselves prohibit automated decisions or create a universal right to human review, reversal of an outcome or an explanation of an algorithm.

Other duties remain separate. For government agencies, that includes relevant administrative-law and freedom-of-information responsibilities, addressed in the OAIC’s supplementary government guidance.

Broader privacy reform should not be folded into this obligation either. The 2026 exposure draft of the Privacy Amendment (personal data Protection) Bill remains a separate proposal, with consultation having closed on 18 September 2026. It is not the source of the December requirements.

Getting Ready for 10 December 2026

By the time the policy is being drafted, the difficult questions should have answers: what each system does, where its information comes from and how staff use its output. The OAIC’s transparency-obligation flowchart offers a route through the legal assessment.

Automating parts of privacy compliance can support documentation and publication. Consent management platforms (CMPs) usually offer Privacy policy generators that can provide a structured starting point for drafting, with customisable tools allowing organisations to adapt the wording to their actual practices. Privacy-policy and consent-management tools cannot, however, determine whether a particular decision meets the APP 1.7 threshold.

1. Inventory decision systems. Ask operations, finance, HR, customer service, security and product teams about the tools they use. Assign a business owner to each process.
2. Map personal information. Record each program’s inputs, including information supplied by vendors or generated earlier in the workflow.
3. Assess significance. Describe possible effects on rights, services and opportunities. Consider affected individuals’ circumstances rather than only an average customer.
4. Examine the program’s role. Record whether it decides the outcome or contributes substantially and directly. Use evidence of working practices, not procedure documents alone.
5. Review vendors and contracts. Obtain usable explanations and clarify responsibilities. Include SaaS features and employee-permitted third-party tools.
6. Map the disclosures. Separate solely automated decisions from computer-assisted decisions and identify the associated information categories.
7. Update and test the policy. Have operational owners check accuracy and someone unfamiliar with the systems check comprehension. Confirm website and app links reach the approved version.
8. Maintain the assessment. Revisit it when inputs, vendors, settings or human workflows change. Keep reasons for inclusion or exclusion with the system record.

Key Takeaways: Australia’s ADM Privacy Policy Requirements

Before 10 December 2026, organisations should assess their decision-making processes against APP 1.7 and update their APP privacy policies where the disclosure requirements apply.

A useful policy update reflects the processes people actually run—and explains them in terms the people affected can understand without knowing how the software works.