How to run a privacy impact assessment in Australia

You have a launch coming up. A new app, a customer relationship system, an AI tool, a new cloud supplier, or a first foray into collecting health information or biometrics. Any of these means your business will start handling personal information in a way it has not before, and under the Privacy Act 1988 (Cth) that is exactly the moment to stop and work out the privacy risk.

The tool for that is a privacy impact assessment (a PIA): a systematic assessment of how a project handles personal information, measured against the Act and the Australian Privacy Principles (the APPs), that sets out recommendations for managing, minimising or eliminating the privacy impacts the project creates. When you finish you will have a PIA report: the evidence record of what the project does with personal information, the risks it raises, and the actions your business has committed to take.

Two assumptions are worth correcting up front. A PIA is not a lodgement. Nothing is filed with the Office of the Australian Information Commissioner (the OAIC), there is no form and no fee, and for private sector organisations a PIA is not generally compulsory. And a PIA is not a big-corporate exercise. The OAIC encourages PIAs for any project that involves personal information, and the consequences of getting privacy wrong can reach businesses that sit outside the Act altogether.

Before you start: the prerequisites

A PIA is a process you scale to the project, not a fixed-length document, so most of the groundwork is about deciding what the project actually involves and who needs to be in the room. Work through these before you begin:

• APP entity status: Confirm whether your business is bound by the Act at all. Businesses with an annual turnover of $3 million or less for the previous financial year are generally exempt under s 6D of the Privacy Act 1988 (Cth), subject to exceptions that can pull a business back in, such as handling health information or credit reporting. This is the prerequisite that trips people up most: businesses near the threshold, or that touch sensitive information, assume they are exempt when they are not.
• A defined project: Write a short scope statement covering what is changing, who is involved, which systems and vendors are in scope, and what success looks like. A PIA without a defined scope drifts, and the OAIC's process depends on a describable project.
• The right people: The OAIC warns that a PIA done by one staff member in isolation is unlikely to be effective. Line up the project owner, the privacy officer or equivalent, IT security, legal, and the operational people who actually handle the information.
• Your current privacy documents: Privacy policy, collection notices, contracts with any processors, and a data breach response plan. The PIA tests what you do against what your documents say, so the documents need to be on the table before the analysis starts.
• A decision on who runs the PIA: An internal team may be right for small projects. For high-impact or sensitive projects, an external assessor brings independence and can build community trust in the findings.
• The OAIC's Guide and PIA tool: The Guide to undertaking privacy impact assessments sets out the ten-step process below, and the OAIC publishes an accompanying PIA tool to work through it.

The OAIC's ten-step process

The OAIC's Guide describes ten steps for a PIA. You can adapt them, combine them, or fold them into your own project methodology, but the Guide suggests each element should be addressed in some form. The steps have to happen in roughly this order because each depends on the one before: you cannot analyse privacy impacts until you know what the project does with information, and you cannot map information flows until the project is described.

Run a threshold assessment

The first step is deciding whether a PIA is needed at all. Ask whether the project will collect, store, use or disclose any personal information. If the answer is no, the project is unlikely to affect information privacy and you can stop there. If the answer is yes, some form of PIA is usually necessary, even if it is a short one.

The OAIC's guidance is explicit that you should keep a record of the threshold assessment either way. Record:

• a brief description of the project
• the personal information involved, if any, and its key privacy elements, such as purpose and sensitivity
• any changes the project makes to existing information handling practices
• the decision and who made it.

Plan the PIA

Plan how detailed the PIA needs to be, who will conduct it, the timeframe, the budget, and who will be consulted and when. Think about what happens after the report as well: implementation of recommendations and ongoing monitoring.

Scale the effort to the project's privacy scope, not its budget. The OAIC notes that the size or budget of a project is not a useful indicator of its likely privacy impact. Privacy scope grows with:

• the quantity of personal information handled and whether sensitive information is involved
• cross-organisation or cross-sector information sharing
• aggregation of information in databases, or data matching
• entirely new collections, or new ways of using information already held
• the impact on individuals if things go wrong, such as effects on their livelihood, reputation or health.

Describe the project

Write a short, plain-English description of the project: its overall aims, how they fit your broader objectives, its scope, any links to existing programs or systems, who is responsible, the timeframes for design decisions, and the key privacy elements such as the type of information to be collected. Keep the analysis out of this step; the description provides the context for everything that follows. If the project is still early, describe what is known and update the description as the project develops.

Identify and consult with stakeholders

Stakeholders are anyone interested in or affected by the project: internal teams, regulators, clients, advocacy groups, service providers, industry experts. The OAIC treats consultation as basic to the PIA process. It surfaces privacy risks the assessment team has not seen, gives stakeholders a chance to comment on proposed fixes, and signals to the public that privacy was considered.

For projects handling substantial amounts of personal information or sensitive information, consider public consultation. Where a business does not want to publicise commercially sensitive plans, targeted consultation with representative or advocacy groups can still do most of the work.

Map the information flows

This is usually the most labour-intensive step and the one that decides the quality of the whole PIA. Describe and map what information the project collects, uses and discloses, how it is held and protected, and who can access it. The OAIC's checklist for this step includes:

• whether identity verification is necessary and how it will be done
• what personal information is collected, how, and from whom, and whether collection could be anonymous or de-identified
• the notice given to individuals at or before collection, which APP 5 requires
• every planned use and disclosure, including secondary uses and whether consent is needed for them
• any data matching or linkage, which carries additional privacy risk
• security safeguards, information quality processes, and how individuals can access and correct their information.

Communicate with staff and stakeholders while you map. A flow map drawn in isolation misses how information actually moves through a business, and problems found late in a project are expensive to fix.

Run the privacy impact analysis and compliance check

Now analyse how the project affects individuals' privacy and check it against the Act. The compliance check runs the project against each APP that applies:

• APP 3 (collection): organisations must not collect personal information unless it is reasonably necessary for their functions or activities, and sensitive information requires consent
• APP 5 (notification): individuals must be notified at or before collection of matters such as the entity's identity and the circumstances of collection
• APP 6 (use and disclosure): information collected for one purpose cannot be used or disclosed for another unless consent or a permitted situation applies
• APP 8 (cross-border disclosure): before disclosing information to an overseas recipient, the entity must take reasonable steps to ensure the recipient does not breach the APPs
• APP 11 (security): the entity must take reasonable steps to protect information from misuse, interference and loss, and from unauthorised access, modification or disclosure
• APPs 12 and 13 (access and correction): individuals must be able to access and correct their information.

Compliance is not the whole analysis. The OAIC says a PIA should go beyond a compliance check to consider the broader privacy implications, including whether the planned handling of personal information will be acceptable to the community and whether it could harm individuals.

The analysis should also test the project against what happens when things go wrong. Under Part IIIC of the Act, the Notifiable Data Breaches scheme, an entity that has reasonable grounds to suspect an eligible data breach must carry out a reasonable and expeditious assessment within 30 days, and if it has reasonable grounds to believe a breach has occurred, it must give a statement to the OAIC and notify affected individuals as soon as practicable. A PIA should confirm the project has the processes in place to do that.

Two developments in the reform pipeline belong in the analysis as well. From 10 December 2026, new APPs 1.7 to 1.9 will require APP entities to describe automated decision-making in their privacy policies, so a project that uses AI to make decisions should be tested against that obligation now. And the OAIC is developing a Children's Online Privacy Code under the 2024 amendments to the Act, which will matter for any project that collects information from children. There is also the statutory tort for serious invasions of privacy, which commenced on 10 June 2025 and applies more broadly than the Act: individuals can sue for intrusion upon their seclusion or misuse of their information where they had a reasonable expectation of privacy, so even a business that is not an APP entity can face a claim.

Decide the privacy management responses

For each risk identified in the analysis, work through the options for removing, minimising or mitigating it. The options are often design choices: collect less information, use de-identified data, change the flow, restrict who has access, encrypt, add deletion timeframes. The OAIC's framework treats this as a distinct step because a risk is not managed until someone decides how it will be managed.

Make the recommendations

Turn the chosen responses into specific recommendations, each with an owner and a timeframe for implementation. Recommendations without owners and dates are the part of a PIA that most often fails in practice.

Write the PIA report

The report is the record of the whole process. It should be practical and easy to interpret, thorough without being repetitive, and written for the people who have to act on it. The OAIC encourages entities to publish their PIA reports. A report typically includes:

• an executive summary of the project, scope and key outcomes
• the project description and the information flows
• the APP analysis and how the project aligns with each principle
• the identified risks with their likelihood and impact
• the mitigation actions, owners, due dates and status
• the implementation plan and the next review date.

Respond and review

The PIA does not end with the report. Monitor implementation of the recommendations, and revisit and update the PIA when the project changes. If there are substantial changes to how personal information will be handled, the OAIC says it may be necessary to undertake another PIA.

Where projects get held up

Most PIAs stall at one of a handful of predictable points, and each is avoidable with planning:

• The threshold assessment is never recorded: Without a written record of the decision, there is no evidence a PIA was considered, which matters if a complaint or regulator later asks. Record the assessment even when the answer is no.
• Information flows are mapped in isolation: A data flow map built from memory misses how information actually moves, and the gaps surface later as real privacy problems. Interview the people who handle the data.
• The analysis stops at APP compliance: A project can comply with the letter of the APPs and still be a privacy problem if the handling is not what individuals would expect. The community expectation test is part of the OAIC's process, not an add-on.
• The report is written but never implemented: A PIA whose recommendations have no owners, dates or review cycle is a paper exercise. Assign the actions and schedule the post-launch review before the report is signed off.

When to bring in a privacy lawyer

A small team can run a PIA for a modest project, but the analysis gets harder as the risk profile rises, and that is where a privacy lawyer earns their place:

• Scoping and planning: deciding whether a PIA is needed, how deep it should go, and who should conduct it, particularly for high-risk or sensitive projects.
• The APP analysis: working out how each principle applies to the project's specifics, especially cross-border disclosure under APP 8, sensitive information, and use of information for secondary purposes.
• Contracts and due diligence: drafting data processing agreements so privacy and security obligations flow down to vendors and offshore processors, and reviewing what those vendors actually do.
• Breach readiness: making sure the project can meet the Notifiable Data Breaches scheme's 30-day assessment and notification obligations, and integrating that with a data breach response plan.
• The report and approvals: reviewing the PIA report for accuracy and completeness, and providing the independent assurance that gives sign-off real weight.
• Directions and disputes: Australian Government agencies can be directed under s 33D of the Act to provide a PIA to the OAIC, and the statutory tort gives individuals a way to sue for serious invasions of privacy, so legal advice matters once a project is contentious.

Start the PIA before the design is locked in

The thing that most determines whether a PIA succeeds is timing. A PIA run after the design is settled is a retrospective audit: it documents risk, but the recommendations are expensive to implement because the architecture, contracts and launch dates are already fixed. Run early enough, the PIA changes the design itself. The collection is narrowed, the notice is drafted, the vendor contract is corrected, all at the cost of a document, and the project launches with privacy built in rather than bolted on.

The shape of the process is worth remembering. A PIA is a scaled assessment, not a compulsory lodgement, though Australian Government agencies must conduct one for high privacy risk projects and the OAIC encourages every entity to run one for any project involving personal information. Work through the OAIC's ten steps: threshold assessment, planning, project description, stakeholder consultation, information flow mapping, the APP compliance and impact analysis, risk responses, recommendations, the report, and respond and review. Keep records, test against community expectations as well as the APPs, test breach readiness, and check the project against the coming obligations for automated decision-making and children's data. If the project is high risk, complex or sensitive, bring in a privacy lawyer before the design is fixed, not after.