Privacy impact assessments: when an Australian business should run one and what it must cover

What a privacy impact assessment is

The OAIC defines a privacy impact assessment as "a systematic assessment of a project that identifies the impact that the project might have on the privacy of individuals, and sets out recommendations for managing, minimising or eliminating that impact." It is a project artefact, not a compliance certificate: it is produced while a design can still change, and its value is the recommendations it forces into the build.

For private-sector entities the legal hook is APP 1.2, which requires an APP entity to take reasonable steps to implement practices, procedures and systems that will ensure it complies with the Australian Privacy Principles. A PIA is the standard way of evidencing that those reasonable steps were taken before a new collection, a new disclosure or a new technology went live. The APP 1 privacy policy obligations sit alongside it — the policy is the external statement, the PIA is the internal working.

Where a PIA is legally mandatory in Australia

For most Australian private-sector organisations, a PIA is not mandatory. The OAIC's guide to undertaking privacy impact assessments states that its power to direct an entity to undertake a PIA "does not apply to private sector organisations". Two contexts change that answer.

Australian Government agencies. The Privacy (Australian Government Agencies — Governance) APP Code 2017 makes PIAs compulsory. Section 12(1) requires an agency to conduct a PIA for all high privacy risk projects. Section 13 permits publication of the PIA or a summary. Section 15 requires the agency to maintain a register of the PIAs it conducts and to publish that register, or a version of it, on its website. Those are three separate sections — the PIA duty and the register duty are not the same provision.

Accredited digital ID providers. The Digital ID (Accreditation) Rules 2024 require a privacy impact assessment as part of accreditation. Rule 2.4 sets the PIA's scope and content, the independence and competency of the assessor, and the applicant's response to the risks and recommendations it identifies; rule 2.3(3)(c) makes it part of pre-accreditation assessment. The explanatory statement describes it as a point-in-time compliance assessment. Note the common misstatement: accredited entities must furnish their PIA at annual review, not conduct a new one each year. See Digital ID Act accreditation for the wider obligation set.

A mandatory private-sector PIA obligation for high privacy risk activities has been canvassed in the Privacy Act reform program but has not been legislated. The Privacy and Other Legislation Amendment Act 2024 contains no PIA part. As at August 2026 there is no statutory PIA duty on private-sector APP entities.

Contractual mandates are a different matter and bind more businesses than the statute does. Government procurement, health sector agreements and large enterprise supplier terms increasingly require a PIA before a system handling personal information is onboarded. Those obligations belong in the contract register alongside the security schedules they usually accompany.

The threshold test for a high privacy risk project

The APP Code 2017 defines the trigger in section 12(2): a project may be a high privacy risk project if the agency reasonably considers that the project involves "any new or changed ways of handling personal information that are likely to have a significant impact on the privacy of individuals."

Two words carry weight. "Reasonably considers" makes this a documented self-assessment rather than an objective test — the record of why you concluded a project was or was not high risk is itself the compliance artefact. "New or changed" means an existing collection that is being used for a different purpose triggers the test just as a new collection does.

Private-sector entities have no legal obligation to apply this test, but it is the most defensible threshold available and it maps onto the risks regulators have actually pursued. The characteristics that most often push a project over the line are the collection of sensitive information, including biometric information; a new surveillance or monitoring capability; automated decision-making that affects individuals; a new disclosure to a third party or offshore recipient; a large-scale data linkage or enrichment; and any handling of children's data. The biometric information guide covers the first of those in detail, and the automated decision-making transparency obligation the third.

What the assessment has to cover

A PIA that will withstand scrutiny covers six things, whatever template it uses.

It describes the project accurately enough that a reader outside the project can understand what is being built and why. It maps the personal information flows end to end — what is collected, from whom, by what means, where it is held, who can access it, to whom it is disclosed, how long it is retained, and how it is destroyed or de-identified. It tests the design against each Australian Privacy Principle, not just the ones that seem relevant, and records the reasoning where a principle does not apply. It analyses privacy impact in terms the affected individuals would recognise, not only in terms of compliance risk to the business. It sets out options for removing, minimising or mitigating each identified risk. And it makes recommendations that are specific enough to be assigned to an owner with a due date.

The information-flow map is the part most often thin, and the part that most often makes the difference. A PIA that cannot say where the data goes cannot assess cross-border disclosure under APP 8 or retention under APP 11.2.

The ten-step process

The OAIC's published process runs ten steps (checked August 2026):

1. Threshold assessment — decide whether a PIA is needed at all.
2. Plan the PIA — scope, who conducts it, timeframe, budget, who will be consulted.
3. Describe the project.
4. Identify and consult with stakeholders.
5. Map information flows.
6. Privacy impact analysis and compliance check.
7. Privacy management — consider options for removing, minimising or mitigating the risks.
8. Recommendations.
9. Report.
10. Respond and review.

Step one is a document in its own right. A short, dated threshold assessment concluding that a project is low risk is a better compliance position than no record at all, and it takes an hour. Step four is the step most frequently skipped, and skipping it is why PIAs so often miss the impact that the affected population would have raised immediately. Step ten is what makes the OAIC's framing — "a PIA should be regarded as an ongoing process" — operative: the assessment is revisited when the project changes, not filed when it ships.

A PIA is not a security risk assessment

The OAIC's guide to securing personal information distinguishes the two directly. An information security risk assessment, also called a threat risk assessment, "is generally more specific than a PIA because it involves the identification and evaluation of security risks, including threats and vulnerabilities, and the potential impacts of these risks to information." The guide contemplates running one "in conjunction with" a PIA, and says the findings of both should inform the entity's risk management and information security policies, plans and procedures.

The practical division is this: the PIA asks whether you should be handling this information at all, in this way, for this purpose. The security assessment asks whether the information you have decided to handle is adequately protected. A project that passes an ISO 27001 gap assessment can still fail a PIA, because a well-secured collection that should never have been made is still a privacy problem. Entities running a formal privacy management system will recognise the same split in ISO 27701.

Turning findings into commitments that survive an audit

A PIA generates value only where its recommendations become tracked commitments. Three practices separate the assessments that hold up from the ones that sit in a shared drive.

Assign each recommendation an owner, a due date and an acceptance criterion, and track it in the same register the business uses for every other compliance action. Record the decision where a recommendation is not accepted, with the reasoning and the approver — an accepted residual risk that has been documented and approved is a defensible position; an ignored recommendation is not.

Keep a register of the PIAs conducted, even though only agencies are required to. It answers the first question an auditor, an acquirer or a regulator asks, which is not "was this project assessed" but "how do you know which projects were assessed". Run the Privacy Act 2026 readiness check against the register to see which of the reform obligations the assessed projects already address, and use the obligation finder to confirm which privacy duties apply to the entity in the first place.