You have until 10 December to know where your software makes decisions about people

TL;DR: APP 1.7 to 1.9 commence 10 December 2026. Every APP entity must disclose automated decision-making (ADM) in its privacy policy. The disclosure takes an afternoon to write. Finding what to disclose is a four-month programme. Almost no organisation has started.

• "Computer program" covers Excel scorecards, rules engines, and legacy decision trees, not just AI models.
• Human sign-off does not exempt you. The trigger covers software that substantially assists a human, not just software that decides alone.
• The disclosure obligation attaches to decisions made from 10 December onward, regardless of when the system was built.
• OAIC final guidance is expected in September. Firms that wait for it before starting will not finish in time.
• Build an inventory that carries explanation data now. Tranche 2 will require it, and retrofitting it under pressure costs more.

Legal will read APP 1.7 to 1.9 as a policy update. Three paragraphs get added, the policy goes live in November, the box gets ticked. That reading is wrong, and it will cost you.

The obligation sounds narrow: add language to your privacy policy before 10 December 2026 describing where software makes decisions about people. The statute says that clearly. What the statute does not say is how hard it is to answer that question honestly.

Here is what most organisations actually have: an AI register built for a board presentation. Vendor contracts that say nothing about what the product decides. An operations team that has been using a scoring spreadsheet for years without anyone asking whether it should be disclosed. The disclosure is the easy part. Finding what to disclose is the actual work.

Three things go in the policy: the kinds of personal information used, the kinds of decisions made solely by software, and the kinds of decisions where software does something substantially and directly related to making them. A lawyer drafts that in an afternoon.

The hard part is knowing what to write. To disclose where software makes decisions about people, you first have to find everywhere software makes decisions about people. The systems that will surprise you are not the ones in the AI register. They are the routing logic embedded in your case management platform, the scorecard an underwriter opens every morning, the shortlisting filter a recruiter considers too basic to count as a system, and the fraud flag that holds an account without a human ever reviewing the case.

This is a discovery project. The second half of this piece is the programme to run. Sequenced, with named artefacts at each step, calibrated to the actual timeline a firm starting in late August 2026 has available. Take it and use it.

What the rule actually does

From 10 December 2026, every APP entity must disclose automated decision-making in its privacy policy. The trigger has three limbs, and all three must be met.

Limb one: you arranged for a computer program to make a decision, or to do something substantially and directly related to making one. Limb two: the decision could reasonably be expected to significantly affect an individual's rights or interests. Limb three: personal information about that individual is used in the program's operation.

Meet all three and you disclose. Miss one and you do not. The limbs are conjunctive, not disjunctive. The burden of establishing that a limb is not met sits with the entity making the assessment. That matters when the answer is genuinely unclear, because the default posture under a new obligation with limited guidance is to resolve doubt outward.

The obligation attaches to decisions made on or after 10 December. The system can be a decade old, the arrangement can predate the Act, the data can have been collected years ago. None of that helps. The decisions start in December.

One thing this rule is not: a right. There is no right to human review, no right to contest, no right to an explanation. Australia took the disclosure half of GDPR Article 22 and left the substantive half for a later tranche. The UK built both sides into the UK GDPR simultaneously. Australia's approach is sequenced. The first obligation lands in December. The harder ones are coming.

Build for what the law requires today and you are building a list. Build for where this is going and keep reading.

"Computer program" does not mean AI

This is where scoping exercises fail on day one. Firms scope to their AI register because that is what the board asked about in 2025. The AI register captures the new tools and misses the twenty-year-old logic that decides more cases per day than any model deployed in the last two years.

The Explanatory Memorandum (EM) is explicit. "Computer program" takes its ordinary meaning and covers pre-programmed rule-based processes, AI, and machine learning. The OAIC's Issues Paper adds generative AI, chatbots, and text, image, video, and code generators.

The rule reaches your scoring spreadsheet. The decision tree in your case management system that nobody has opened since 2019. The rules engine your underwriters inherited and cannot fully explain.

The EM provides a worked example. An Excel formula used to score and triage callers to a domestic violence hotline is both substantial and direct, because it is a key factor in how a human orders the queue. An Excel formula that calculates age from a date of birth is direct but not substantial.

The distinction is the weight of the output, not the sophistication of the technology. A spreadsheet formula that controls who gets help is in scope. A formula that converts a date is not.

A practical test: take any system that touches personal information. Ask whether a human uses its output to make a decision about a person. If yes, the next question is how much weight that output carries. If the output disappears and the decision process is unchanged, you are probably not in scope. If the output disappears and the team does not know how to decide without it, you are squarely in scope.

Three categories get missed in every scoping exercise.

Key point: scope to "computer program" as the statute defines it, not to the AI register your board approved. The highest-volume decision system in the organisation is probably not in that register.

Legacy rules engines. Built before anyone used the word AI. Encode credit policy, eligibility rules, or compliance flags. Often undocumented, often determinative, often the highest-volume decision system in the organisation.

Embedded vendor logic. Your CRM flags high-churn risk customers. Your HR platform ranks candidates by fit score. Your case management system assigns priority ratings. You did not build any of it. You are still arranging for it.

Spreadsheet-based scorecards. The Explanatory Memorandum example is an Excel formula. Treat every scoring tool in the business as presumptively in scope until you can show the output is not a key factor in the outcome.

A human signs it off. That does not exempt you.

Between now and December, the most common argument will be: a person makes the final call, so the organisation is out of scope. Read limb one again before you accept that conclusion.

The trigger covers a program that makes a decision, or does something substantially and directly related to making one. The second half of that sentence exists precisely to catch software that feeds a human decision-maker.

The test is whether the output is a key factor. A score the assessor acts on is a key factor. A ranking that determines what the reviewer sees first is a key factor. A recommendation the approver accepts nine times out of ten is a key factor, and the acceptance rate is the evidence.

Human sign-off is still relevant. It determines which of the two disclosure buckets in APP 1.8 the decision falls into: made solely by the program, or assisted by it. It does not determine whether you disclose at all.

The UK regulator has already worked through this. The ICO's "Recruitment rewired" report, published March 2026 on evidence from more than 30 employers, found firms running solely automated hiring decisions with no meaningful human involvement, and unable to demonstrate how they prevented hiring managers from relying disproportionately on AI fit scores at volume. The oversight existed on the org chart. It did not exist in the process.

If you are relying on human-in-the-loop as your exemption, one question needs an answer before December: what percentage of the time does that human depart from the software recommendation, and can you produce that number?

If a human approves the system's output 95% of the time, the system is determinative in practice regardless of what the org chart says. If the acceptance rate has never been measured, that absence is itself a finding. It is the finding the OAIC will focus on if it investigates.

Three questions to answer now, before guidance arrives:

One. For each decision assisted by software, what is the override rate? Collect this data. If you cannot collect it from existing logs, build the logging capability before December.

Two. When a human overrides the software recommendation, is the override recorded and reviewable? An override that leaves no trace is not meaningful oversight.

Three. What does the decision process look like when the software is unavailable? If the answer is "we wait for the system to come back", the software is not advisory.

Key point: human-in-the-loop is a disclosure category, not an exemption. The question is not whether a human is involved. It is what the human does when the software says something they disagree with.

The programme

What follows is a sequenced plan: the artefacts to produce at each step and the questions to ask. It assumes a start in late August 2026 with no ADM inventory, and that OAIC guidance lands sometime in September.

The companion workbook has the inventory schema, the threshold assessment worksheet, the vendor question set, and the plan as live templates. Use them or rebuild them. Do not start from a blank page.

Sequence it backwards from 10 December

The trap is waiting. The OAIC has said it intends to publish final guidance before commencement. If the inventory begins when the guidance lands, there are roughly ten weeks to find every decision system, assess it, renegotiate vendor contracts, draft disclosures, and publish. Ten weeks is not enough.

Almost nothing needed to start is waiting on the guidance. The statute is settled. The commencement date is settled. The Explanatory Memorandum, which is where the interpretive weight currently sits, is settled. Only the threshold edges are moving.

Run discovery and assessment now on what is fixed. Treat the guidance as a reconciliation step, not a starting gun.

Weeks 1 to 2, from now. Stand up ownership. Assemble the working group. Agree scope boundaries and the definition of a decision for your organisation. Produce the first draft inventory from what people already know.

Weeks 3 to 6. Systematic discovery. Work the system list, the process list and the vendor list in parallel. This is the longest phase and the one that always overruns. Expect the inventory to roughly double between the first draft and the end of this phase.

Weeks 5 to 8, overlapping. Threshold assessments on everything discovered. Start as soon as entries land rather than waiting for discovery to close, because assessment surfaces gaps that send you back into discovery.

Weeks 5 to 10, in parallel. Vendor due diligence and contract variations. Start early. This is the only workstream with a dependency on someone outside your organisation, and vendors move at their own pace.

On guidance release, September. Reconcile. Re-test every borderline assessment against the final interpretation. Expect movement on assisted decisions and on advertising.

Weeks 11 to 13. Draft disclosures. Test them on someone outside the project. Legal review.

Weeks 14 to 15. Publish the updated policy. Brief the board. Train the front line and the complaints team. Stand up the escalation path.

Week 16, by 10 December. Live. Evidence pack closed and stored.

Step 1: Ownership, before anything else

Name one accountable owner. A committee does not own it. A workstream does not own it. One person, whose name is on it. In practice this sits with the privacy officer or general counsel, but the person who can actually get answers out of technology and operations is often neither.

The working group needs privacy, legal, risk, technology, operations, HR, and marketing. HR and marketing are the two that get left out and the two that hold the most undiscovered ADM.

Give the group one decision right that matters: the authority to declare something in scope over the objection of the business unit that owns it. Without that authority, every borderline case resolves as out of scope, because the business unit that agrees it is in scope has just created work for itself.

The board needs three things and no more: where ADM is used, the outcome of the threshold assessments, and residual risk. Do not take them the inventory.

The dynamic to watch is the one where every borderline call drifts to out of scope because agreement means work. That is structural, not political. Solve it structurally: give the working group authority to override a business unit's preferred outcome on scope, and log every scope decision with the reasoning so it can be reviewed.

The function that gets underweighted in every programme is operations. Legal and privacy lead. Technology supports. Operations gets consulted after the fact, when the inventory is nearly complete. That sequence misses everything. Operations is where the decisions actually happen. Put operations in the room from week one.

Key point: ownership without authority is decoration. The accountable owner needs the working group to have genuine override power on scope calls, or the inventory will reflect what business units chose to surface.

Step 2: Discovery, which is the actual work

You cannot find automated decision-making by asking people whether they use automated decision-making. They will say no, and they will be wrong. They do not think of the tenancy scoring spreadsheet as automated decision-making. Ask about the decision instead.

The questions that surface what the direct question does not:

What decisions does your team make about individual customers, applicants, employees or claimants?

For each one, what does a person look at on screen immediately before they decide?

Is anything ordered, ranked, scored, flagged, colour-coded or pre-filled when they open it? Who decided that order?

If the system stopped producing that score tomorrow, what would change about how you decide?

How often does the decision differ from what the system suggested? Can you show me?

That last pair surfaces determinative systems dressed as advisory ones. When the answer is "we always go with it" or "I could not tell you, we do not track that", you have found something worth examining closely.

Run three sweeps in parallel. Each one catches what the others miss.

The system sweep works from the application register or the CMDB. For every system that touches personal information, ask what it decides or influences. Include everything with a workflow engine, a scoring field, a rules table or a triage queue.

The process sweep works from the customer and employee lifecycle. Walk each stage from acquisition to exit and ask what decides the outcome at that stage. This catches processes that span multiple systems and processes that run in spreadsheets outside any system.

The vendor sweep works from accounts payable. Every SaaS contract, every embedded module, every plug-in. The question is not "is this an AI vendor", it is "does this product decide, score, rank, route or recommend anything about a person".

Six places get missed, in rough order of frequency:

Third-party and embedded tools, where your CRM, HR platform, practice management software or case management system ships with scoring and routing logic you did not build and may never have configured.

Marketing and ad tech, where differential pricing and targeted delivery of job advertisements are both live questions in the OAIC's consultation and unresolved.

Fraud and risk systems where an alert carries an account consequence, because a hold on funds affects contractual rights.

HR, covering screening, shortlisting and any performance assessment input that feeds promotion. The employee records exemption does not cover job applicants.

Eligibility and access determinations across benefits, services, support, tenancy, credit and underwriting.

Legacy logic that has drifted. A rule built in 2018 to flag a small population for review very often ends up ordering the entire queue. Ask when the logic was last reviewed, not when it was built.

Key point: ask about decisions, not systems. The people who know where ADM lives are in operations, not IT architecture. The questions above are the ones that get them talking.

Step 3: The inventory

One row per decision, not per system. A single system commonly makes several decisions with different risk profiles. A single decision commonly spans several systems. That distinction matters for what ends up in the disclosure.

Each row carries: the decision itself in plain language; the business process and owning unit; the systems involved and whether each is internal or vendor; the categories of personal information used; whether the program decides alone or assists; who the human decision-maker is if there is one; the override rate if known, flagged if not; whether the individual is aware the decision is being made; when the logic was last reviewed; the three-limb assessment outcome; and the disclosure grouping if in scope.

Two fields carry more weight than the rest. The override rate is your evidence on the substantial question. Its absence is itself a finding worth reporting to the board. Whether the individual is aware is the field that tells you how exposed you are if the OAIC resolves the unseen-decision question broadly.

Expect the inventory to double between the first draft and the end of discovery. If it does not, discovery was not thorough enough.

Key point: the inventory is evidence, not administration. Every field matters only to the extent it answers a specific assessment question or supports a specific disclosure. Build it for defensibility, not completeness.

Step 4: Threshold assessment

Three limbs, assessed in order, with the reasoning recorded. Stop at the first no. The sequence matters: rushing to limb three before resolving limb one is where assessments go wrong.

Limb one: did you arrange for it. You arranged for it if you procured it, configured it, directed staff to use it, or contracted someone to do it for you. You merely operate it if you built or host it for another entity that made those choices. Procuring a system to screen job applications is arranging. Hosting software another firm uses to approve applications is operating. Where a vendor operates and you arranged, you comply.

Limb two: is it substantial and direct. Direct means a direct connection to the decision. Substantial means the output is a key factor. Use the OAIC's consultation factors as your rubric, scoring each from advisory to determinative: how much the decision-maker relies on the output; whether override is possible and how often it actually happens; whether the output is advisory or determinative in form; how transparent and explainable the output is; and how deeply the tool is embedded in the workflow.

Where the score is genuinely borderline, record it as borderline and revisit it on guidance. Do not round borderline down to out of scope. That is the failure mode this rule was written to catch.

Limb three: is the effect significant. APP 1.9 lists the categories: decisions under an Act granting or refusing a benefit; decisions affecting rights under a contract, agreement, or arrangement; and decisions affecting access to a significant service or support. Beneficial effects count as well as adverse ones. Failing to decide is itself a decision.

Record every assessment, including every out-of-scope conclusion and the reasoning behind it. Out-of-scope calls are the ones you will be asked to defend. A contemporaneous record made before the guidance landed is far more defensible than a reconstruction made afterwards.

Key point: the threshold assessment is the legal spine of the programme. Every borderline call needs reasoning on record. Reconstructed reasoning does not hold.

Step 5: Vendors

Your vendor's roadmap is now your compliance exposure. A model update that changes how much weight a score carries can move a system from advisory to determinative without anyone notifying you.

Six questions to put to every vendor whose product touches a decision about a person:

Does your product make, score, rank, route or recommend anything about an individual, and at which points in our configuration?

What personal information does it use to do that, including anything derived or inferred?

Can you provide, on request, a description of the logic in terms we can put in a public privacy policy?

What is your notice period and process for material changes to model or rule behaviour?

Will you cooperate with individual queries and complaints routed from us, and on what timeframe?

Will you accept audit rights over the decision logic and the data used?

Four provisions belong in the contract: visibility into decision behaviour and data used; audit rights; advance notice of material change to model behaviour; and an obligation to cooperate with your disclosure and individual queries.

For APRA-regulated entities, do not run this as a parallel process. CPS 230 material service provider obligations and CPS 234 asset inventory already cover most of this ground. The ADM questions should be added to those assessments, not duplicated alongside them.

The practical difficulty is that vendors do not have ready answers. Larger enterprise platforms route the request through a formal legal review and take weeks. Smaller SaaS vendors may not have documented their decision logic in terms that can go into a public policy. Both problems require starting early. The vendor response cycle is the longest external dependency in the programme.

Three things to do before sending the six vendor questions:

First. Review the existing contract for any existing representations about the product's functionality. A contract that describes the platform as providing scoring or recommendation features is your evidence that the vendor already knows what the system does. Use that in the conversation.

Second. Identify which vendor relationships are material under CPS 230 or constitute critical service dependencies under your own risk framework. Those get escalated treatment: a direct conversation rather than an email, and a deadline rather than an open-ended request.

Third. Assess which vendor-operated systems you cannot characterise for disclosure purposes. Where you cannot describe the logic in plain language because the vendor has not provided it, that is itself a compliance risk. The conversation with the vendor is about getting the information you need to meet your obligations.

Key point: vendors move at their own pace. Start the six-question process the week you stand up the working group. Do not attach it to the end of discovery.

Step 6: Drafting the disclosure

The instinct under a new obligation is to write everything down and hedge it. Resist that. Dense defensive drafting makes a policy harder to read, not safer to publish.

The OAIC's stated position is that disclosures should be specific enough to be meaningful, in plain language, structured so a reader can ask for more. Over-disclosure is its own compliance failure: it fails APP 1.3, which requires a clearly expressed policy.

Two versions of the same fact:

Version A: "The entity may utilise automated processing technologies, including artificial intelligence and machine learning systems, in connection with certain operational determinations relating to individuals."

Version B: "We use AI scribe software that processes consultation audio and clinical notes to generate structured documentation and suggested billing codes. A clinician makes the final billing decision."

Version B is shorter, more specific, and more defensible. Write that one.

A structure that works: a short plain-language section explaining that some decisions are made or assisted by software; decisions made solely by software, grouped by kind; decisions where software substantially assists a human, grouped by kind; the categories of personal information used; then how to ask for more.

Group by kind of decision, which is what APP 1.8 asks for. Readers do not care which platform you bought.

Three drafting tests before it goes to legal. Can a reader tell whether a decision that affects them is covered? Would someone in the business recognise their own process from the description? Is there anything in it you would be uncomfortable defending as accurate in twelve months?

Then test readability on someone who has not worked on the project. If they cannot tell you what it means, it fails APP 1.3 regardless of how legally sound it is.

Two additional failure modes in disclosure drafting:

Describing the system instead of the decision. Firms write about the technology they use rather than what it does. The obligation is to describe the kinds of decisions made. A reader asking "does this affect me?" cannot answer that from a description of the vendor platform.

Grouping at the wrong level. Too broad and the disclosure says nothing. "We use automated tools in our operations" is meaningless and non-compliant. Too granular and it runs to fifteen pages. Group at the level of kind of decision: credit assessment, claims triage, account hold, applicant shortlisting.

Key point: the disclosure is a communication to a person who received a decision they did not expect. Write for that person.

Step 7: The questions you will get

Nothing in APP 1.7 to 1.9 requires answering an individual who asks how a decision about them was made. They will ask anyway. The disclosure is what prompts them.

Before December, have three things ready: a named owner for ADM queries and complaints; a defined path from the front line to that owner, briefed to whoever answers the phone; and for your highest-risk decisions, the ability to describe what data was used, what logic was applied, and how that produced the outcome.

That last capability is not required today. It will be required later. Building it now costs less than retrofitting it under pressure.

The queries that are hardest to handle are not the ones asking whether a decision was made. Those are answerable from the disclosure. The hard ones are the specific ones: I was declined. What did the software do and why did it reach that conclusion.

Today there is no legal obligation to answer that. The individual will ask it anyway. The complaints team will escalate it. A privacy complaint will follow if the answer is unsatisfactory. Under Tranche 2, the obligation to provide a meaningful explanation will be law. Firms that have built the trace from data input to decision outcome will answer those queries cleanly. Firms that have not built it will reconstruct it under regulatory pressure, which is the most expensive way to do it.

The minimum to build now for each high-risk decision: what data was used as input, a plain-language description of the logic applied, and the output produced. That is the explanation capability. It does not require publishing a technical specification. It requires having the information organised so it can be retrieved when the question arrives.

Key point: the disclosure triggers the question. The explanation capability is what lets you answer it. Build both.

Step 8: Reconcile when the guidance lands

Do not re-run the programme. Re-test the borderline calls. That is the only part of the inventory that moves.

Four things in the final guidance will change scope. Know in advance which of your assessments each one moves.

• How broadly the OAIC reads "substantially and directly related" moves your assisted decisions.
• Whether human sign-off of a generative AI recommendation stays in scope (the NACIA question) moves anything with a review step.
• Whether targeted advertising the individual never sees counts as a decision moves your entire marketing stack.
• How firmly the arranged-for line is drawn moves your vendor-operated systems.

Tag every borderline assessment against whichever of those four questions decides it. When the guidance publishes, re-open the tagged subset, not the whole inventory.

Reconciliation is also when you update the threshold assessment records. A clean record showing initial assessment, reasoning, borderline tag, reconciliation date, and revised outcome is the evidence pack you want if the OAIC investigates. It shows the process was rigorous and responsive, not that conclusions were fixed in advance and paperwork followed.

One more thing at reconciliation: re-check the disclosure drafts. If the guidance moves any borderline assessments from out of scope to in scope, those decisions need to be added before the policy publishes. If guidance narrows scope, trim the over-disclosures. The disclosure reflects the final assessment, not the preliminary one.

Key point: tag borderline calls to the four open questions before guidance arrives. Reconciliation then takes days, not weeks.

What goes wrong

Five failure modes, all of them common, and each one more expensive than the one before it.

Scoping to AI. Covered above, and it is the one that invalidates everything downstream.

Treating it as a legal deliverable. Legal drafts the disclosure. Legal cannot find the systems. If this sits entirely in legal, the inventory will be built from what business units volunteer, which is a fraction of what exists.

Rounding borderline to out of scope. Every borderline call resolved conservatively looks like diligence and reads, in aggregate, like avoidance.

Waiting for the guidance. Ten weeks is not enough, and the guidance changes edges, not foundations.

Building a list instead of a capability. Which brings us to the last point.

What this is a rehearsal for

Proposal 19.3 of the Privacy Act Review was a right for individuals to request meaningful information about how substantially automated decisions are made. The Government agreed to it and deferred it to Tranche 2. As of February 2026 the Attorney-General confirmed Tranche 2 is being progressed with no timetable.

Western Australia has already gone further. IPP 10 under the Privacy and Responsible Information Sharing Act commenced 1 July 2026 and requires impact assessments, periodic evaluation, notification, information on request, and a process to request human intervention. It is the first regime of its kind in Australia and it is materially more demanding than the federal one.

The direction is clear even though the date is not. Disclosure now, explanation and contestability later.

The firms that treat this as a disclosure problem will solve it once and face it again when Tranche 2 arrives. The firms that treat it as an inventory and governance problem will solve it once and have the infrastructure to answer the next question without starting from scratch.

That changes what you should build. Build only the list the statute asks for and you will do this work twice. Build the inventory so that each entry carries the data used, the logic applied, and the trace of how it reached the outcome, and you have the disclosure today and the explanation when it is required.

The architecture of a future-ready inventory is not complicated. Each decision entry in the inventory carries: the data inputs used for that specific decision type; the logic applied, described in plain language; the output produced and the range of possible outputs; the human involvement in translating that output into a final decision; and a link to the system or documentation that would allow the trace to be reconstructed for a specific case. That is the minimum. It is buildable now. The systems that produce the decisions already contain most of this information. The work is in organising it, not generating it.

Western Australia's IPP 10 is the benchmark to build toward. It requires impact assessments before deployment, periodic evaluation of the system's ongoing behaviour, notification to individuals that a decision about them has been made using automated means, provision of meaningful information about the process on request, and a mechanism for requesting human review. Each of those requirements maps to something that should be in the inventory now: the impact assessment as a risk assessment field, the periodic evaluation as a review date field, the notification as an individual awareness field, the meaningful information as the explanation capability, and the human review path as the escalation process.

The enforcement context is not theoretical. The OAIC ran its first proactive compliance sweep in January 2026 across about 60 entities, looking at privacy policy content, and the Commissioner has said publicly that a significant proportion were non-compliant. A non-compliant policy attracts an infringement notice up to $66,000. The tiers above run to $3.3m and, for serious or repeated interference, the greater of $50m, three times the benefit, or 30% of adjusted turnover.

Those numbers are not the point. The point is that the OAIC has demonstrated a willingness to conduct proactive sweeps without waiting for a complaint. The ADM disclosure obligations are new, prominent, and the subject of active regulator attention. The firms that will attract scrutiny in the first sweep after December are the ones whose policies are clearly incomplete, whose disclosures are vague enough to be obviously uninformative, or whose policy has not been updated at all.

Preparation visible from outside the organisation: an updated privacy policy with specific, plain-language ADM disclosures, structured by kind of decision, with a mechanism for individuals to seek further information. That is what compliance looks like from the street. Everything else is internal infrastructure the OAIC sees only if it investigates. Build the infrastructure first, because it is what produces the disclosure. The disclosure is the output of the programme, not the starting point.

The firms that will struggle in December are not the ones with the most automation. They are the ones who cannot say where it is.

There is a version of this that ends well. You run the programme, find the systems, assess the threshold, get what you need from vendors, draft a disclosure that is specific and plain and accurate, publish it, and have an inventory that is good enough to answer an individual query, good enough to reconcile against Tranche 2 guidance, and good enough to demonstrate to the OAIC that the work was done properly.

That version requires starting in August. It requires the working group to have the right people in it from day one. It requires someone who can get answers out of technology, operations, and vendors simultaneously, and turn those answers into a disclosure that satisfies a regulator and communicates clearly to a person who received a decision they did not expect.

That is the outcome. Work backward from it.

Grab your free ADM Readiness Pack nomark.au/adm-readiness-pack
The companion workbook contains the inventory schema, the threshold assessment worksheet with the scoring rubric, the vendor question set and contract checklist, the disclosure drafting guide and the 16-week plan. It is free. Take it.

Sources. Privacy Act 1988 (Cth) Schedule 1, as amended by the Privacy and Other Legislation Amendment Act 2024 (Act No. 128 of 2024) Schedule 1 Part 15; Explanatory Memorandum to the POLA Bill 2024 (paragraphs 335, 336, 337, 343); OAIC, Automated Decision-Making Issues Paper, 18 May 2026; OAIC, APP Guidelines Chapter 1; OAIC media release, Privacy compliance sweep to put privacy policies under the spotlight, 9 December 2025; Privacy Act Review Report 2022, Proposals 19.1 to 19.3, and the Government Response, September 2023; ICO, Recruitment rewired, 31 March 2026; Privacy and Responsible Information Sharing Act 2024 (WA), IPP 10.

This is general information, not legal advice. Thresholds under APP 1.7 remain subject to the OAIC's final guidance, unpublished as at 20 August 2026.