Privacy Impact Assessments for In-House Legal Teams

When a PIA is Required

Australian Government agencies subject to the Australian Government Agencies Privacy Code must conduct a PIA for every high privacy risk project. Section 12 of the Code covers new or changed information handling likely to have a significant impact on individuals’ privacy. The Information Commissioner can also direct an agency to provide a PIA.

An outside analysis arrangement can change who receives bank records, where copies reside and how transaction information is combined. A modest contract value does not establish low privacy risk. Record the threshold decision against the actual information handling and potential harm.

For private sector legal teams, the Commonwealth agency Code does not create the same blanket PIA duty. The Office of the Australian Information Commissioner’s PIA guidance encourages assessments for projects involving personal information. A PIA helps teams identify unnecessary disclosure and put workable controls into the engagement before records move.

The Victorian and NSW Position

State public sector teams use their applicable state privacy framework. The Commonwealth agency rule is not a nationwide requirement for every government body.

The Office of the Victorian Information Commissioner’s PIA guide and template support Victorian public sector organisations under the Privacy and Data Protection Act 2014. OVIC says Victorian privacy law does not make PIAs mandatory. It recommends a PIA where a program handles personal information to assess compliance with the Information Privacy Principles.

The NSW Information and Privacy Commission’s PIA guide likewise describes no strict NSW legal requirement to undertake a PIA. Agency policies or project approval processes can still require one. Distinguish those requirements from a statutory mandate when recording why your team is conducting the assessment.

How a PIA Compares With a GDPR DPIA

A data protection impact assessment (DPIA) is the assessment required by the European Union’s General Data Protection Regulation (GDPR) for processing likely to create high risks. Article 35 requires the controller to conduct it before processing. It examines the proposed processing, necessity and proportionality, risks to people and planned protections.

First establish whether the GDPR applies. Article 3 can cover an Australian organisation through an EU establishment, services offered to people in the EU or monitoring their behaviour there. Holding information about an EU citizen alone does not establish that territorial connection.

An Australian team can need both an Australian PIA and a GDPR DPIA when each framework applies and its assessment threshold is met. Use a shared information-flow map and evidence file, then assess each framework’s requirements separately. An Australian PIA label alone does not establish compliance with Article 35.

Running a PIA Step by Step

Use the OAIC’s ten-step process to produce an assessment with assigned actions and a recorded response. Before starting, gather the project proposal, proposed provider terms and a description of the records. Include your privacy officer and the people who manage access and records retention.

The OAIC PIA tool is a downloadable Word document. Its four parts organise the full assessment. The separate threshold assessment template screens whether to proceed.

1. Threshold assessment. Describe the change and screen for privacy risks. Retain the reason for proceeding or stopping.
2. Plan the PIA. Assign responsibility, resources and timing before the provider receives records.
3. Describe the project. Define the analysis purpose, records involved and each party’s role.
4. Identify and consult with stakeholders. Obtain input from the privacy officer, legal team, security staff and provider.
5. Map information flows. Trace collection, transfer, processing, outputs and disposal, including subcontractors and backups.
6. Privacy impact analysis and compliance check. Assess impacts on people and compliance with each relevant privacy principle.
7. Privacy management: addressing risks. Rate risks before and after controls using your organisation’s risk framework.
8. Recommendations. Specify the changes needed and identify any risk requiring a decision.
9. Report. Record the assessment and its supporting evidence for decision-makers.
10. Respond and review. Allocate actions, record responses and monitor whether controls work.

Which Template Part Completes Each Step?

In the threshold template, Part 1 identifies changed information handling. Part 2 screens for potential high privacy risk. Part 3 records the decision and reasons. Together they complete step 1, including a documented decision when a full PIA is unnecessary.

The full PIA tool then groups the remaining steps as follows.

Tool part	OAIC steps it supports	What your team records
Part 1: Plan the PIA	Steps 2 to 5	Project and parties, assessment scope, consultation and information flows
Part 2: Privacy impact analysis and compliance check	Step 6	Privacy impacts and analysis against the applicable principles
Part 3: Privacy management	Steps 7 to 9	Initial and residual ratings, controls, risk owners and recommendations for the report
Part 4: Respond and review	Step 10	Action owners, implementation timing, sign-off and later updates

The tool’s questions support analysis. Write a reasoned answer about your project in each applicable field, with evidence of the proposed handling arrangements.

Fictional Privacy Risk Assessment Example

A government legal team proposes sending five years of bank statements to an outside analyst for a disputed financial matter. The analyst will return a consolidated ledger and findings report. This fictional example assumes the team has lawful authority to provide the records for that purpose.

The team uses an illustrative matrix based on impact and likelihood. The table shows the assumptions behind each rating. These ratings explain the example and are not an OAIC scoring rule.

Risk and consequence	Initial rating	Recommended response	Residual rating if controls work
A reusable download link reaches someone outside the engagement, exposing account and transaction details	Major / possible: high	Use named accounts and expiring access. Verify recipients and log downloads	Major / unlikely: medium
The bundle includes unrelated records about third parties, widening disclosure beyond the matter’s purpose	Moderate / possible: medium	Limit accounts and periods to the instructed scope. Remove unnecessary personal details where analysis permits	Moderate / unlikely: low
An undisclosed offshore subcontractor receives the statements, creating unassessed cross-border disclosure	Major / possible: high	Identify every recipient and location. Assess applicable transfer rules before authorising that flow	Major / unlikely: medium
Working files remain after the agreed retention trigger, exposing records through later access	Major / possible: high	Specify disposal of originals and derived files. Address backup expiry and obtain confirmation	Major / unlikely: medium

Assign each response to a named person. The legal project owner controls scope and recipients. The security lead owns access checks, while the records manager agrees retention triggers with the provider.

Treat residual ratings as conditional until the controls are implemented and checked. If the provider introduces another recipient, redraw the flow and reassess the risk before that recipient gets access. The completed assessment records which residual risks the authorised decision-maker accepts and which changes must happen before transfer.

Assessing an Outside Data Processor

Assess an outside provider’s actual handling of the records, including copies created during analysis and the outputs returned to your team. Put agreed controls into the engagement terms and retain evidence that they operate.

Area	What to establish before sharing bank records
Storage location	Countries and systems holding PDFs, extracted data and outputs, including backups and remote access
Access controls	Who can access the matter, authentication, access logs and how access ends when staff leave or the engagement closes
Use and onward handling	Permitted analysis purpose, subcontractors and whether records can be reused for another purpose, including model training
Retention	The retention trigger for each copy, applicable legal holds and who can authorise continued retention
Return and deletion	How outputs are returned, how working files are destroyed or de-identified and how completion is confirmed

APP 11 Across the Engagement

Australian Privacy Principle 11 in the Privacy Act 1988 requires reasonable protection against misuse, interference and loss, plus unauthorised access, modification or disclosure. It applies to a forensic accountant who is an APP entity and holds the bank records.

For a covered provider, protection begins when records are received and continues during storage, analysis and return. APP 11.3 expressly includes technical and organisational measures. The 2024 amendment applies to information held from its commencement, including records acquired earlier. The OAIC’s security guidance explains that rule.

Technical measures can include encryption and restricted accounts. Organisational measures include staff training and procedures for releasing files to the authorised recipient. The controls must suit the sensitivity, volume and likely harm from exposure. A return email does not end the security obligation for copies still held by the provider.

APP 11.2 requires reasonable steps to destroy or de-identify information once it is no longer needed for a permitted purpose. Exceptions include Commonwealth records and information that Australian law or a court or tribunal order requires the entity to retain. Record the actual retention basis for each class of records.

The OAIC’s APP 11 guidelines explain that outsourcing storage can leave the client holding information through control of it. For an APP-covered legal team, outsourcing does not remove its own responsibilities. Address provider copies, backups and deletion confirmation alongside disposal of your team’s copies.

Recording and Reviewing the PIA

Australian Government agencies covered by the Code must keep a register of completed PIAs and publish the register or a version of it. Section 15 creates that requirement. Section 13 permits publication of a full PIA, summary or edited copy. Publishing the register does not require publishing confidential matter details or the entire report.

Keep a controlled internal assessment with its version, owner and decision record. Link the register entry to the project and retain the implementation evidence. Private sector teams can use an internal register to keep track of assessments without adopting a Commonwealth publication duty that does not apply to them.

Revisit the PIA when information handling changes. Examples include another subcontractor, offshore access, broader analysis or a different retention period. Reassess whether the changes create new impacts and whether a new PIA is necessary. Set a review point to check agreed actions after implementation.

Before the first transfer, confirm that the information-flow map matches the engagement terms and all required controls are in place. The decision record must identify any accepted residual risks and the person authorised to accept them. If the terms and map disagree, resolve the discrepancy before releasing the statements.

Privacy and Ethics Impact Assessments

A privacy and ethics impact assessment examines whether a proposed use of personal information is justified, alongside its privacy risks and legal authority. In NSW, the Information and Privacy Commission’s PIA guidance already extends beyond a compliance checklist. It calls for consideration of community expectations, stakeholder views and public benefits, as well as positive and adverse privacy impacts.

For NSW public sector projects, keep those broader questions visible even where the agency records them within its PIA. Assess whether the expected public benefit justifies the intrusion and whether a less intrusive approach would achieve the purpose. Record who bears the risk and whether affected people can understand or challenge decisions. Legal permission to handle information does not settle those questions.

Fictional Public-Sector Data-Matching Proposal

Suppose a NSW agency proposes matching grant applications against payment records to identify duplicate claims. Assume it has identified a lawful basis for the proposed handling. The assessment must still examine how matching errors and unnecessary collection could affect applicants.

Keep the privacy findings separate from the ethical judgement so each decision has a reason and an owner.

Assessment issue	What the team documents	Mitigation or decision
Privacy: unnecessary information	Whether full transaction histories are needed to identify duplicate claims	Limit the match to the fields needed for the stated purpose and restrict access
Privacy: incorrect matches	How shared names or outdated account details could connect unrelated applicants	Validate match criteria and require staff to resolve uncertain matches before further use
Ethics: unequal effects	Whether applicants with shared household accounts face more false alerts	Assess error patterns across affected groups and revise the criteria where they create unequal burdens
Ethics: proportionality and public interest	Expected benefit, likely harm and whether a narrower pilot would answer the same question	Compare alternatives and document why the chosen scope is justified
Ethics: consequences and accountability	Whether an alert could delay a grant without an applicant understanding why	Require human assessment before adverse action and provide an explanation and review route

Document the privacy controls in the risk register and the broader ethical reasoning in the decision record. Assign owners to both. If the narrower design cannot deliver the claimed benefit, reassess the proposal before expanding access or making decisions about applicants.