How to Conduct a Privacy Impact Assessment in Australia: A Practical Guide

13 February 2026 • Shaun Crouch

A step-by-step guide for privacy officers and project managers navigating PIAs under the Australian Privacy Act.

Most organisations know they should be doing Privacy Impact Assessments. Government agencies are required to under the APP Code. Private sector organisations handling personal information are strongly expected to. Health service providers dealing with sensitive patient data have no real choice.

But knowing you need a PIA and knowing how to actually conduct one well are two very different things. The OAIC publishes a 10-step framework and a PIA tool, and they're solid starting points — but they don't tell you what the process actually looks like inside an organisation when real people are trying to get it done alongside their day jobs.

This guide bridges that gap. It's written for the privacy officer who's been asked to "set up a PIA process," the project manager who's been handed the template and told to fill it in, and the consultant who needs to deliver PIAs efficiently across multiple clients.

Who Needs to Conduct PIAs?

Before diving into the how, let's clarify the who.

Australian Government agencies are required to conduct PIAs for all high-privacy-risk projects under the Privacy (Australian Government Agencies — Governance) APP Code 2017. This isn't optional — non-compliance can result in regulatory action.

Private sector organisations covered by the Privacy Act (generally those with annual turnover above $3 million) are strongly expected to conduct PIAs as good practice. The OAIC recommends it, and the Privacy Act reforms are expected to strengthen this expectation further.

Health service providers handle sensitive information regardless of their size. If you're deploying a new patient portal, integrating clinical systems, or changing how you share patient data between providers, a PIA should be part of the project.

Aged care and community services organisations increasingly operate under both Commonwealth and state privacy obligations. With the regulatory environment tightening, systematic PIAs are becoming a practical necessity.

The honest answer? If your project involves collecting, using, storing, or disclosing personal information in a new or changed way, you should be conducting a PIA.

The OAIC's 10-Step Framework

The OAIC outlines 10 steps for conducting a PIA. Here's what they are — and what they actually mean in practice.

Step 1: Threshold Assessment — Do You Even Need a Full PIA?

Not every project needs a comprehensive PIA. The threshold assessment is a quick screening exercise to determine whether the project involves personal information handling that warrants a full assessment.

Ask two questions:

Does this project involve the collection, storage, use, or disclosure of personal information?
Does it involve new or changed ways of handling that information?

If the answer to both is yes, you need a PIA. If no personal information is involved at all, document that decision and move on. If personal information is involved but nothing is changing from current practice (and current practice has already been assessed), you may not need a full PIA — but document the rationale.

The practical challenge: People often underestimate what counts as personal information. It's not just names and addresses. IP addresses, device identifiers, employee IDs, health data, biometric data, and even behavioural data can all be personal information under the Privacy Act. When in doubt, do the PIA.

Step 2: Plan the PIA

Before filling in any template, plan the assessment itself:

Scope: What exactly is being assessed? A new system? A process change? A data-sharing arrangement? Be specific — a vague scope leads to a vague assessment.
Who will conduct it? The project team usually fills in the operational detail, but a privacy officer or specialist should guide the process and review the output.
Timeline: Build the PIA into the project plan, not as an afterthought. A PIA started after the system is built is an audit, not an assessment.
Budget: Complex projects with multiple data flows and stakeholders may need external privacy expertise. Factor that in early.

The practical challenge: PIAs get treated as a gate to pass rather than a tool to use. If the PIA is just a compliance checkbox, the project team will fill it in to get approval and file it away. The real value comes when the PIA process genuinely informs design decisions.

Step 3: Describe the Project

Write a clear, concise description of what the project does and why. This isn't a technical specification — it's context that allows someone outside the project team to understand the privacy implications.

Cover:

What the project is and what business problem it solves
What personal information will be involved
How the information will be collected (directly from individuals, from other systems, from third parties)
What systems and technologies are involved
Who will have access to the information
Whether any third parties or external service providers are involved

The practical challenge: Project teams describe what the system does, not how information flows through it. A project description that says "we're implementing a new HR system" isn't useful for a PIA. One that says "the system will collect health and wellbeing survey responses from employees, store them in a US-hosted cloud platform, and share aggregate reports with managers" gives you something to work with.

Step 4: Identify and Consult Stakeholders

The OAIC expects you to consult with people who can help identify privacy risks. This typically includes:

The project team — they understand the technical and operational detail
The privacy officer — they understand the regulatory requirements
IT/security — they understand the technical safeguards
Affected individuals or their representatives — they understand the real-world impact
Business process owners — they understand current information handling practices

The practical challenge: Stakeholder consultation often becomes a rubber-stamp exercise. The project team fills in the PIA, emails it to the privacy officer for review, and considers consultation done. Genuine consultation means having conversations early — before design decisions are locked in — where stakeholders can actually influence the outcome.

Step 5: Map Personal Information Flows

This is where most PIAs either deliver real value or fall flat. The OAIC asks you to describe and map how personal information flows through the project.

For each piece of personal information, document:

Collection: Where does it come from? How is it collected? What's the lawful basis?
Use: What is it used for? Who accesses it? What decisions are made using it?
Storage: Where is it stored? For how long? What security controls are in place?
Disclosure: Who is it shared with? Under what circumstances? Are there overseas transfers?
Destruction: When and how is it disposed of?

Map the connections between systems. If employee data flows from an HRIS to a wellbeing app via an API, that's a data flow that needs to be documented and assessed.

The practical challenge: Most organisations do this as a one-off exercise — draw a diagram in Visio, paste it into the Word document, and move on. The diagram is outdated before the PIA is signed off. Systematic data mapping that stays connected to your asset register and is maintained over time is significantly more valuable than a static diagram.

We've seen data mapping exercises uncover actual security issues — publicly accessible URLs exposing personal information, data flows to systems nobody knew about, third-party integrations sharing more data than anyone realised. This step is where PIAs move from compliance exercise to genuine risk discovery.

Step 6: Analyse Privacy Compliance

Work through each of the 13 Australian Privacy Principles and assess whether the project complies. The OAIC PIA tool provides questions for each APP, but the key ones that catch organisations out are:

APP 3 (Collection): Are you only collecting information that's reasonably necessary? Are you collecting it by lawful and fair means?
APP 5 (Notification): Are individuals being told what information is being collected, why, and who it will be shared with?
APP 6 (Use and Disclosure): Is the information only being used for the purpose it was collected for? If not, does an exception apply?
APP 8 (Cross-border Disclosure): If data is stored or processed overseas (cloud services, anyone?), have you taken reasonable steps to ensure the overseas recipient handles it in accordance with the APPs?
APP 11 (Security): Are there reasonable security measures in place? This includes both technical controls and governance arrangements.

The practical challenge: Manually cross-referencing your project against 13 APPs in a Word document is tedious and error-prone. It's also where privacy officers spend disproportionate time — not because the analysis is difficult, but because the tool makes it difficult. Structured compliance checking that flags non-compliance items automatically and tracks how each finding is addressed is far more effective than a free-text table.

Step 7: Identify Privacy Risks

Turn your compliance analysis into a risk register. For each issue identified:

Describe the risk
Assess the likelihood (how likely is it to occur?)
Assess the consequence (how bad would it be if it did?)
Rate the overall risk level

Not all privacy risks are compliance issues. Community expectations, reputational risk, and the potential for function creep (using data for purposes beyond what was originally intended) are all legitimate privacy risks that may not show up in a pure compliance check.

The practical challenge: Risks identified in a PIA frequently have no home. They're documented in the PIA report, which gets filed, and nobody tracks whether the risks were actually treated. A risk register that's linked to the PIA and tracked over time ensures identified risks don't just disappear into a filing cabinet.

Step 8: Identify Options to Address Risks

For each risk, determine a treatment:

Avoid: Redesign the project to eliminate the risk entirely
Mitigate: Implement controls to reduce the likelihood or consequence
Accept: Acknowledge the risk with documented justification
Transfer: Shift the risk to another party (e.g., through contractual obligations)

Each treatment should have a specific action, an owner, and a due date.

Step 9: Write Recommendations and Report

Document your findings in a structured report. The OAIC PIA tool provides a template, but the key is that the report should be actionable — not just a description of risks, but clear recommendations with owners and timelines.

The report goes to the project sponsor or decision-maker, who needs to respond to each recommendation: accept, accept with modification, or reject with documented rationale.

Step 10: Respond, Implement, and Review

This is where most PIA processes fail. The PIA is completed, the report is signed off, and everyone moves on. But:

Recommendations need to be implemented, not just agreed to
Actions need to be tracked to completion
The PIA should be revisited when the project changes
The PIA register should be maintained as an organisational record

A PIA that sits in a Word document on SharePoint is a point-in-time artefact. A PIA that drives actions, tracks risks, and records sign-offs is a management tool.

Common Mistakes to Avoid

Starting too late. A PIA started after design decisions are made is damage control, not privacy by design. Build it into the project plan from the beginning.

Treating it as a document. The PIA is a process, not a report. The report is one output of that process — the ongoing risk management, compliance tracking, and action follow-up are where the real value lies.

Underestimating data flows. "We collect names and email addresses" is rarely the full picture. Trace every system, every integration, every third-party service. What you discover may surprise you.

Ignoring the threshold assessment. Either everything gets a PIA (wasting resources on low-risk projects) or nothing does (because nobody knows which projects need one). A consistent threshold process saves time and ensures the right projects get assessed.

No sign-off process. If there's no formal sign-off, there's no accountability. The responsible person should sign to confirm the PIA is complete and accurate. The privacy officer or auditor should sign to confirm they've reviewed it and the process was followed properly.

Moving Beyond Word Documents

If your organisation is conducting more than a handful of PIAs, the Word-document-and-email approach becomes unsustainable. Version control issues, no audit trail, no visibility across the organisation, and no way to track whether risks are being treated.

Purpose-built PIA management platforms provide structured workflows, compliance automation, risk registers, and audit-ready reporting. They turn PIAs from documentation exercises into ongoing compliance management tools.

PIMS is one such platform — purpose-built for Australian organisations, with the OAIC template out of the box, customisable templates for organisational needs, integrated risk registers, and interactive personal information maps that keep data flow mapping connected to your assessments.

Resources

Pragmatix is a Brisbane-based consultancy specialising in digital transformation and privacy compliance. PIMS is our purpose-built Privacy Information Management System for Australian organisations. Request a demo to see how it can streamline your PIA process.