澳洲 APP 1.7 工程檢查清單，相關規定將於 2026 年 12 月 10 日生效

I work at Permit, and this is adapted from a checklist our CEO published on our blog, so keep that in mind. It isn't legal advice either. Your privacy counsel decides whether APP 1.7 applies to you and what the policy says.

Some background first. APP 1.7 to 1.9 start on 10 December 2026 under the Privacy and Other Legislation Amendment Act 2024. If an APP entity arranges for a computer program to use personal information to make a decision, or to substantially and directly assist with one, and that decision could reasonably be expected to significantly affect someone's rights or interests, the privacy policy has to say so. APP 1.8 lists what goes in: the kinds of personal information used, the kinds of decisions the program makes on its own, and the kinds of decisions it substantially and directly assists.

Legal writes those sentences, but engineering is the one who can tell whether they're true. The checklist splits that work into four areas.

Enforcement

Find every place where software decides, routes, ranks, approves, denies, recommends or escalates using personal information. That includes APIs, workflow engines, background jobs, rules services and model gateways, so it's a wider list than the AI feature. Eligibility checks, fraud scoring, account restrictions, pricing and triage can all count. For each one, write down the owner, the decision type, what personal information it can see, and what happens downstream.

Granularity

A line like "financial information may be used in eligibility decisions" only holds up if you know which attributes which service reads, for which action, in which product or tenant. Map personal information categories to resources, actions and tenants, and mark each path as a solely automated decision, an assisted one, or probably out of scope.

Realtime

A policy statement that's accurate today can go stale after a new model, a feature flag, a new data source, or a workflow that moves from human review to auto-approval. Decide which changes trigger a re-review, and make sure revoking access reaches the code that actually enforces it, so the change isn't only recorded in a spreadsheet.

Audit and export

For each decision category, the logs should show what happened, whether it was solely automated or assisted, the kinds of personal information used or available, the resource, action and tenant, and the policy, model or rules version. Deny logs help too, because they show what was blocked and why.

The working list

List the services, workflows, APIs, models, rules, prompts and jobs that make or substantially assist significant decisions.
Find the enforcement point for each one.
Classify each path as solely automated, substantially and directly assisted, or likely out of scope.
Map kinds of personal information to resources, actions, tenants, products and decision categories.
Note which attributes are required, optional, inferred, or just accessible.
Document who can change access, routing rules, model deployments, prompts and thresholds.
Define how revocation and sync work when access or decision logic changes.
Log decision context, data category, policy version, resource, action, tenant and outcome.
Export evidence in a format your privacy and legal people can work from.
Re-review the disclosure wording whenever any of the above changes in a material way.

The full version, with a table mapping each area to the question it answers, is here: https://www.permit.io/blog/four-pillars-app17-checklist?utm_source=devto&utm_medium=social&utm_campaign=four-pillars-app17-checklist&utm_content=authbyexample-article

We build authorization tooling (enforcement points in the app, a hybrid decision point, and OPAL for syncing policy and data), which is why we care about this topic. None of that makes anyone Privacy Act compliant by itself.

If you're already doing APP 1.7 prep, I'm curious whether you started from the system inventory or from the draft policy wording, and how that went.