Published

A lender's privacy policy says applications are reviewed by staff. Its supplier platform also scores applicants and recommends approval or refusal. Before changing the policy, the lender needs to establish what the software actually does, which personal information it uses, and how its output shapes the decision.
Start with an evidence-backed decision inventory. From December 10, 2026, Australian Privacy Principle (APP) entities must provide additional privacy-policy information for certain uses of computer programs in significant decisions. The OAIC's September 30 announcement explains the commencement date and APP 1.7–1.9 requirements. Establish whether your organisation is an APP entity before applying this obligation.
APP 1.7 combines three conditions: the entity arranges for a program to make a decision or do something substantially and directly related to it; the decision could reasonably have a significant effect on an individual's rights or interests; and the program uses personal information about that individual for that work. Record the assessment and supporting facts for each workflow.
Describe the outcome, affected people, information inputs, and program's role.
Assign an owner to review significance, human involvement, and supplier evidence.
Approve the wording and revisit it when the deployed workflow changes.
The OAIC's APP 1 Guidelines include rule-based software as well as AI. A human's final approval does not automatically remove a workflow from scope. Assess how substantially the output influences the decision; software used only to document a decision already made is a different case. Significance depends on circumstances, and beneficial effects can count too.
APP 1.8 calls for the kinds of personal information used, the kinds of relevant decisions made solely by programs, and the kinds substantially and directly supported by programs. The OAIC's transparency fact sheet (PDF) supports meaningful, accessible disclosure without overwhelming readers with technical detail. Keep operational evidence behind the approved wording.
| Inventory record | Evidence and policy connection |
|---|---|
| Outcome and impact | Name the decision, affected people, significance assessment, owner, and inclusion or exclusion rationale. |
| Personal information | Map input categories to source systems and documents. Check derived scores and inferred attributes as well as form fields. |
| Program contribution | Retain the enabled rules or service version, output type, decision path, and evidence of human review or override. |
| Supplier and configuration | Link the contract, enabled features, data-flow description, change notices, and responsible system owner. |
| Approved disclosure | Connect the assessed category to a policy clause, approval record, effective version, and next review trigger. |
These inventory fields are an implementation approach, rather than a prescribed statutory template. Use references to restricted case files where possible instead of duplicating applicant documents in a broadly accessible governance register. Define permissions and retention for the register and its evidence separately.
Consider a fictional lender using a supplier service to extract information from income documents, produce an affordability assessment, and recommend an application outcome. An officer reviews the recommendation and records the final decision. Treat each stage as something to investigate; the product's “human reviewed” label is insufficient evidence on its own.
Record the enabled extraction and assessment features, input categories, configuration version, and outputs visible to the officer. Check whether a threshold also rejects an application or prevents it from reaching review.
Walk through representative, appropriately protected cases. Establish whether officers inspect source evidence, can question the recommendation, and actually exercise their authority. Retain the assessment and its limits without treating a small sample as proof of every decision.
Have the privacy owner assess the workflow and distinguish any solely automated outcome from supported decisions. Link the approved category and information types to the relevant policy wording and effective date.
If a supplier enables automatic refusal, adds a new information source, or changes how recommendations reach staff, compare the new path with the approved record. Review the policy mapping before the change goes live.
The document layer should retain the evidence relationship, while the lending system remains responsible for its decision process. FormKiQ's Financial Application Management Business Solution can organise application and agreement files; connecting an external scoring service and capturing its configuration history require an integration design.
The APP 1 Guidelines explain that using a third-party program can leave the arranging entity responsible for transparency. Ask suppliers about enabled functions, input categories, decision outputs, configuration controls, and change notifications. Retain dated answers and resolve gaps with the accountable owner.
Obtain a description of the proposed decision path and information flows. Compare contracted features with what will actually be enabled, and assign responsibility for maintaining the record.
Route material feature, rule, model, and data-source changes to the system and privacy owners. Use periodic owner attestations to catch configuration drift and retire obsolete policy mappings.
For government agencies, check related disclosure duties separately. The OAIC's supplementary government fact sheet (PDF) explains connections with the Information Publication Scheme and government AI transparency statements. One disclosure should not be assumed to satisfy the others.
An accurate privacy policy depends on knowing how decisions are made. Build the inventory around real outcomes, connect its assessments to approved wording, and maintain that connection as systems change. Transparency work also sits alongside the organisation's other privacy and decision-making obligations; the policy update does not establish that the underlying processing is lawful.
Regulatory guidance reviewed: November 12, 2026, against the OAIC's September 30 resources. Confirm applicability and final policy wording with Australian privacy counsel.
The open-source foundation — API-first, deployable into your own AWS account, and free to use. Right for architecture validation and early implementation.
Production-ready editions for departments and complex workflows. Start with a Proof-of-Value deployment or go straight to production.
For governance-heavy environments with residency, sovereignty, assurance, and multi-jurisdiction requirements. Talk to us about the right deployment model.