APP compliance is the ongoing baseline of lawful privacy governance under the Privacy Act. Privacy impact assessments are a targeted review method used for high-risk activities to identify privacy harms and mitigation steps before problems occur. In practice, APPs define what organisations must do, while PIAs help them test whether a planned activity will create unacceptable privacy risk.
How APP compliance differs from a PIA in practice
APP compliance is the standing legal duty that sits behind everyday collection, use, disclosure, retention and security decisions. A PIA is not the rule set itself, it is a method for testing a proposed activity against privacy risk before you launch it. In other words, APPs tell you what lawful behaviour looks like, while a PIA helps you check whether a proposed change will stay inside that boundary.
The practical difference is scope and timing. APP compliance is continuous and organisation-wide, so it should shape policies, contracts, notices, access controls and incident handling. A PIA is narrower and project-based, used when a new system, data flow, integration or redesign could create material privacy harms. The same activity may require both: one to govern the baseline, the other to assess the change.
That distinction matters because a PIA does not replace compliance, and compliance does not guarantee the project is safe. An organisation can meet APP obligations and still introduce a new processing model that creates avoidable privacy risk. A good PIA turns that risk into design decisions early, rather than leaving it to legal review after deployment. For broader privacy governance patterns, see Privacy Programme Guide for Security Teams.
When each one is used
APP compliance is the default expectation for all personal information handling, so it applies whether or not a formal review is running. You should think of it as the baseline control environment. If an activity is routine, low-risk and already covered by documented privacy controls, the organisation still needs to comply with the APPs even if no PIA is required.
A PIA is used when the change is new, large, sensitive or likely to affect individuals in a way that is not fully covered by existing controls. That is why PIAs are commonly used for high-risk programs such as new analytics, cross-system data sharing, automation, biometrics or major platform changes. The question is not whether privacy exists, but whether the proposal changes the risk profile enough to justify a targeted assessment. The clearest trigger is usually a material change in purpose, scale, sensitivity, recipients or retention.
In practice, teams often use a screening step first, then decide whether a full PIA is needed. If the screening shows only ordinary processing with well-understood safeguards, a lightweight record may be enough. If the screening shows uncertain harms, broad sharing or hard-to-explain impacts, the PIA should be expanded and completed before go-live. That approach is consistent with a risk-based privacy program and with the way PIAs are commonly used in regulatory practice, including the GDPR’s DPIA model at EU General Data Protection Regulation (GDPR).
What a strong privacy review should produce
APP compliance should produce durable controls: clear collection notices, lawful use limits, access restrictions, retention rules, disclosure checks, complaint handling and security measures that remain in place over time. The evidence is operational, because the organisation has to show that privacy is built into normal business practice rather than treated as a one-off review.
A PIA should produce a different kind of output: a documented assessment of privacy harms, who could be affected, what data is involved, whether the proposal is necessary and proportionate, and what mitigation is required before release. A strong PIA does not just say “approved” or “rejected”. It creates design changes, owner actions, residual-risk decisions and a record of why the final shape of the activity is acceptable. For teams that want a repeatable review method, the DPIA Guide: Running a Data Protection Impact Assessment is a useful companion even where the local terminology differs.
Because PIAs are decision tools, they work best when they are tied to architecture and delivery gates. If the review happens after implementation is already committed, it becomes paper compliance rather than risk management. That is why privacy-by-design disciplines matter: they force the organisation to surface harms early, before they become embedded in production systems. A practical engineering lens is covered in Privacy by Design Guide for Engineering Teams.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST AI RMF set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | APP compliance and PIAs are both privacy risk governance activities. |
| GV.OV-01 — Oversight of Risk Management Strategy | The comparison hinges on baseline governance versus targeted review oversight. | |
| Recommendation — Define when privacy reviews are required and how residual privacy risk is accepted. Assign oversight for APP compliance and PIA triggers to an accountable privacy owner. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | APP compliance is a legal privacy obligation under the Privacy Act context. |
| A.5.34 — Privacy and protection of PII | Both APP compliance and PIAs operationalise privacy protection for personal information. | |
| Recommendation — Maintain an obligations register and map privacy controls to statutory requirements. Embed privacy review and control checks into the lifecycle of personal information processing. | ||
| GDPR | Art.35 — Data Protection Impact Assessment | A PIA is conceptually aligned with formal impact assessment for high-risk processing. |
| Art.25 — Data protection by design and by default | The answer depends on building privacy into design, not only documenting compliance. | |
| Recommendation — Use a pre-launch impact assessment to identify and mitigate high-risk privacy processing. Build privacy controls into design decisions before deployment. | ||
| NIST AI RMF | GOVERN — Govern | The distinction is about governance processes for privacy risk and accountability. |
| Recommendation — Set governance for when assessments are required and who approves residual risk. | ||
Practitioner Guidance
What to verify: Check whether the organisation is treating APP compliance as an operational baseline and PIAs as a project control. If the same team uses one document for both, confirm that it still distinguishes ongoing obligations from pre-implementation risk review.
Decision rule: If the activity changes the purpose, volume, sensitivity, sharing or retention of personal information, run a PIA early. If it is ordinary processing, keep the APP controls current and avoid creating unnecessary review overhead.
Practitioner takeaway: APP compliance is about staying lawful every day, while a PIA is about proving a proposed change will not create unacceptable privacy harm before it ships.
Related resources from NHI Mgmt Group
- Guide: Australian Privacy and Cyber Rules Guide
- Australian Privacy Principles
- How should organisations build an Australian Privacy Principles compliance programme that actually reduces breach and penalty risk?
- How should organisations prepare privacy impact assessments and data mapping for GDPR compliance?
- Why do traditional Privacy Impact Assessments create compliance risk when they are based mainly on questionnaires and interviews?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org