Four Pillars → APP 1.7 Homework Checklist

Quick answer: This checklist turns APP 1.7 preparation into engineering tasks: inventory the decisions and personal information involved, map them to resources and tenants, keep policy changes current, and export evidence. Use it before 10 December 2026 if your systems automate or assist decisions about people. Don't use it as legal advice, or if APP 1.7 clearly does not apply to your organization.

APP 1.7 homework is not "write a better privacy policy" first. It is build an evidence-backed inventory of where personal information can influence automated or computer-assisted decisions, then connect that inventory to enforcement, data granularity, realtime change handling, and audit evidence.

APP 1.7-1.9 commence on 10 December 2026 under the Privacy and Other Legislation Amendment Act 2024. The transparency obligation applies where an APP entity arranges for a computer program to use personal information to make, or substantially and directly assist with making, a decision that could reasonably be expected to significantly affect an individual's rights or interests. Under APP 1.8, the APP Privacy Policy must disclose the kinds of personal information used, the kinds of decisions made solely by automated decision-making, and the kinds of decisions substantially and directly assisted by automated processing.

This post is not legal advice and is not a compliance guarantee; it is an implementation checklist for product, security, privacy, and platform teams.

When APP 1.7 applies, the privacy policy must cover the information in APP 1.8. The text, as reproduced by the OAIC, reads:

1.8 The information covered by this subclause is: (a) the kinds of personal information used in the operation of such computer programs; and (b) the kinds of such decisions made solely by the operation of such computer programs; and (c) the kinds of such decisions for which a thing, that is substantially and directly related to making the decision, is done by the operation of such computer programs.

Source: OAIC, Automated Decision-Making Transparency Obligation (APP 1), Attachment A: text of Australian Privacy Principle 1.8

Each checklist item below is meant to produce evidence for one of those three categories.

Use the four-pillar model from Enforcement, Granularity, Realtime, Audit as the operating frame. For the regulatory background, pair this checklist with 10 December 2026: APP 1.7 and the authorization evidence behind automated decisions.

1. Enforcement: inventory decision and data-access surfaces

Identify where software makes or substantially assists decisions: application, API, workflow engine, data layer, model gateway, job, or rules service. These are your PEPs (PEP/PDP architecture). Do not limit the inventory to "AI models": eligibility, fraud scoring, account restrictions, pricing, benefits, triage, document review, and human-facing recommendations can all matter. For each surface, capture owner, decision type, PI available, and downstream outcome.

2. Granularity: map PI to resources, actions, and tenants

APP 1.8 asks for "kinds of personal information," but engineering needs a concrete map underneath. Connect PI categories (identity, financial, health, behavioural, device, transaction, and so on) to resources, actions, tenants, and sole-ADM vs assisted decision categories. A policy sentence like "financial information may be used in eligibility decisions" only holds if you know which attributes which service uses, for which action, in which product or tenant.

3. Realtime: prevent policy drift

The main operational risk is drift: a correct privacy-policy statement can go stale after a new model, feature flag, data source, role change, or a shift from human review to auto-approval. Define change triggers (new PI attributes, new automated actions, assisted→sole ADM shifts, broader permissions, model/rules deployments, tenant overrides, break-glass paths) and make revocation reach the real enforcement path, not only a spreadsheet.

4. Audit/export: create evidence for disclosure

Produce evidence privacy and legal can use: for each decision category, logs should show what happened, sole vs assisted, kinds of PI used or available, resource/action/tenant context, and policy/model/rules version. Explainable deny logs (SOC 2 explainable deny) validate the negative boundary: what was blocked and why.

Working checklist

• Inventory services, workflows, APIs, models, rules, prompts, and jobs that make or substantially assist significant decisions.
• Identify the enforcement point for each decision or assistance path.
• Classify each path as sole ADM, substantially/directly assisted, or likely out of scope.
• Map kinds of PI to concrete resources, actions, tenants, products, and decision categories.
• Identify which PI attributes are required, optional, inferred, or merely accessible.
• Document who can change access, routing rules, model deployments, prompts, and thresholds.
• Define revocation and sync behaviour when access or decision logic changes.
• Log decision context, data category, policy version, resource, action, tenant, and outcome.
• Export evidence in a format privacy/legal teams can use to draft and maintain APP Privacy Policy statements.
• Re-review disclosure language when enforcement, data access, routing, model, or rules behaviour materially changes.

Permit.io fits where teams want authorization explicit and inspectable: PEPs close to the app, a hybrid PDP, and OPAL for near-realtime policy/data sync, a practical base for granular decisions, revocation, and audit evidence. This does not guarantee Privacy Act compliance.

APP 1.7 is a transparency obligation, but transparency depends on architecture. If you cannot show where decisions are enforced, what PI they can use, how changes propagate, and what the logs prove, privacy-policy drafting becomes guesswork.