Australia — DPO, ROPA & DPIAs

Australia's Privacy Act 1988 does not impose a general data protection officer (DPO) or records of processing activities (ROPA) requirement on APP entities. The Act diverges sharply from the EU GDPR model. Neither the Privacy Act itself nor the thirteen Australian Privacy Principles (APPs) in Schedule 1 mandate that organisations or agencies appoint a designated privacy officer or maintain a central register of processing operations.

APP 1.2 requires every APP entity to take "reasonable steps" to implement practices, procedures, and systems that ensure compliance with the APPs and enable the entity to handle privacy inquiries and complaints. The text is principles-based and flexible: an entity may satisfy APP 1.2 through staff training, documented procedures, technical controls, and regular audits, but the Act does not prescribe a specific governance structure or recordkeeping format. APP 1.2 does not mention a DPO, privacy officer, processing register, or record of processing activities.

The Office of the Australian Information Commissioner (OAIC) APP Guidelines (Chapter 1, paragraphs 1.6–1.7) list "governance mechanisms to ensure compliance with the APPs (such as designated privacy officers and regular reporting to the entity's governance body)" as examples of reasonable steps, but emphasise that the reasonableness test turns on the entity's size, resources, business model, and the practicability of each measure. Appointing a privacy officer is voluntary best practice for most entities, not a statutory mandate.

Coverage under the Privacy Act. The Act applies to Australian Government agencies and to private-sector organisations with an annual turnover exceeding AUD 3 million (s 6D), plus certain health service providers, credit reporting bodies, and other prescribed entities regardless of turnover. These entities are collectively called "APP entities." Small businesses (turnover below AUD 3 million) are generally exempt unless they trade in personal information, are related bodies corporate of larger entities, or provide health services or credit reporting.

The critical exception: Australian Government agencies must comply with the Privacy (Australian Government Agencies – Governance) APP Code 2017. This binding legislative instrument, made under s 26G of the Privacy Act and in force since 1 July 2018, imposes mandatory governance requirements on all Australian Government agencies subject to the Act (excluding Ministers). The Code is a separate layer above APP 1.2.

Under the Code, every Australian Government agency must:

• Designate at least one Privacy Officer (s 10.1). The agency may appoint multiple officers and may designate by reference to a position or role. The officer is the primary point of contact on privacy matters (s 10.4). The agency must notify the OAIC in writing of the Privacy Officer's contact details (s 10.3).
• Designate a Privacy Champion, who must be a senior official (s 11.3). The Champion promotes a privacy culture, provides leadership on strategic privacy issues, reviews or approves the agency's privacy management plan, and reports regularly to the agency's executive (s 11.4). The same person may hold both the Privacy Officer and Privacy Champion roles (s 11.5).
• Conduct a Privacy Impact Assessment (PIA) for all high privacy risk projects (s 12.1). A project may be high privacy risk if the agency reasonably considers it involves new or changed handling of personal information likely to have a significant impact on individuals' privacy (s 12.2).
• Maintain and publish a PIA register on the agency's website (s 15.1, in force since 1 July 2018). The OAIC has conducted government-wide assessments of PIA register compliance.

Private-sector organisations are not bound by the APP Code 2017. The Code applies only to Australian Government agencies. Private companies, state government agencies (which are generally exempt under s 7(1)(c) of the Privacy Act), and ACT entities (covered by the separate ACT Information Privacy Act 2014) remain subject to APP 1.2's flexible "reasonable steps" standard, with no statutory DPO or ROPA equivalent.

The Australian regime therefore has a two-tier structure. Federal agencies must appoint Privacy Officers and Champions and must conduct and register PIAs for high-risk projects. All other APP entities—including major private-sector organisations—have broad discretion to design their own privacy governance, with no prescribed DPO, processing inventory, or DPIA threshold. This reflects the Act's principles-based philosophy: entities tailor privacy management to their size and risk profile, subject to OAIC guidance and enforcement if practices fall short of the "reasonable steps" standard.

Source: Privacy Act 1988, Schedule 1 (Australian Privacy Principles)

Source: Australian Privacy Principles Guidelines, Chapter 1 (APP 1)

Source: Privacy (Australian Government Agencies – Governance) APP Code 2017

The Office of the Australian Information Commissioner (OAIC) has published detailed guidance on the methodology for conducting Privacy Impact Assessments (PIAs), including a recommended 10-step process and content requirements. This guidance applies to all Australian Privacy Principle (APP) entities, whether or not they are mandated to conduct PIAs. Australian Government agencies subject to the Privacy (Australian Government Agencies – Governance) APP Code 2017 must conduct PIAs for high privacy risk projects (section 12.1 of the Code), but the OAIC encourages all APP entities to adopt PIAs as part of their risk management and planning processes.

Definition and statutory foundation. A PIA is "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." This definition appears in the OAIC's Guide to undertaking privacy impact assessments (PIA Guide) and mirrors the statutory definition in section 33D(3) of the Privacy Act 1988. Section 33D empowers the Privacy Commissioner to direct an agency to provide a PIA if the Commissioner considers that a proposed activity or function "might have a significant impact on the privacy of individuals." Agencies directed under section 33D must prepare a written assessment that identifies privacy impacts and sets out recommendations for managing, minimising, or eliminating those impacts. The OAIC expects agencies to recognise the value of PIAs proactively and anticipates that formal directions will rarely be required.

PIAs are more than compliance checks. The OAIC emphasises that while PIAs assess a project's risk of non-compliance with privacy legislation and identify controls to mitigate risk, "a PIA is much more than a simple compliance check." A well-conducted PIA facilitates a privacy-by-design approach, embeds privacy considerations into project planning from the outset rather than retrofitting them, and can identify opportunities for better practice that exceed minimum statutory requirements. Even if a project appears compliant with the Privacy Act on its face, a PIA should address broader privacy considerations such as community expectations, reputational risk, and potential loss of trust.

The OAIC's 10-step PIA process. The PIA Guide sets out a recommended 10-step methodology:

1. Prepare. Consider the scope of the assessment, who will conduct it, the timeframe and budget, and who will be consulted.

1. Document the project. Prepare a project description that provides context for the PIA. The description should be brief but sufficiently detailed to allow external stakeholders to understand the project.

1. Identify stakeholders and consult. Identify project stakeholders and consult them. Consultation can help identify new privacy risks and concerns, better understand known risks, and develop strategies to mitigate all risks.

1. Map information flows. Describe and map the project's personal information flows in detail. Document what information will be collected, used, and disclosed; how it will be held and protected; and who will have access.

1. Analyse privacy impacts. Critically analyse how the project impacts on privacy. Consider compliance with the Privacy Act and any other information-handling obligations that may apply to the entity. Even if the project appears compliant, address other privacy considerations such as community expectations.

1. Identify options and solutions. For each identified privacy risk, identify options and solutions to manage, minimise, or eliminate the impact. The aim is to achieve the project's goals while minimising negative and enhancing positive privacy impacts.

1. Document findings. Prepare a written PIA report that documents the assessment, findings, and recommendations.

1. Integrate into the project. Ensure the PIA's recommendations are integrated into project design and implementation.

1. Consult on the draft PIA. Consider consulting stakeholders on the draft PIA report before finalising it.

1. Publish and review. Consider publishing the final PIA report (Australian Government agencies subject to the Code must publish a PIA register). Review and update the PIA as the project evolves or if circumstances change.

Content of a PIA report. The PIA Guide and the OAIC's Privacy impact assessment tool recommend that a PIA report include:

• A description of the project, including its objectives, scope, and how personal information will be handled
• Identification of stakeholders and a summary of consultation undertaken
• A detailed map of personal information flows (collection, use, disclosure, storage, and access controls)
• Analysis of compliance with the APPs and any other applicable privacy obligations
• Identification of privacy risks and their potential impacts on individuals
• Recommendations for managing, minimising, or eliminating each identified risk
• An implementation plan or response to each recommendation

The OAIC has developed a free PIA tool (a template) and a free eLearning course to guide entities through the process.

When to conduct a PIA. The OAIC expects entities to consider conducting a PIA and publishing the final report whenever an entity proposes to engage in an activity or function involving the handling of personal information. A PIA should typically be conducted when a particular activity or program is at the proposal stage, so that the findings can be taken into account when designing the proposal before implementation. For Australian Government agencies, the Code defines a "high privacy risk project" as one that the agency reasonably considers involves "new or changed ways of handling personal information that are likely to have a significant impact on the privacy of individuals" (section 12.2 of the Code). The OAIC provides threshold assessment guidance to help agencies screen for high privacy risk projects.

No formal OAIC approval required. While the OAIC has a formal power under section 33D to direct agencies to provide a PIA, and while agencies directed to provide a PIA must submit it to the OAIC, the OAIC has no formal role in the development, endorsement, or approval of PIAs that have not been directed. The OAIC may, subject to available resources, assist agencies with advice during the PIA process, but entities retain responsibility for conducting and finalising their own PIAs.

Private-sector entities. Private-sector organisations (including those with annual turnover exceeding AUD 3 million) are not required by statute to conduct PIAs, but the OAIC recommends PIAs as a reasonable step to satisfy APP 1.2's requirement to implement practices, procedures, and systems that ensure compliance with the APPs. The APP Guidelines (Chapter 1, paragraphs 1.6–1.7) cite PIAs as an example of a governance mechanism that may constitute a reasonable step, with the reasonableness test turning on the entity's size, resources, business model, and the practicability of the measure. Many large private-sector entities conduct PIAs voluntarily for high-risk projects as part of privacy-by-design practice.

Source: OAIC, Guide to undertaking privacy impact assessments

Source: OAIC, 10 steps to undertaking a privacy impact assessment

Source: Privacy Act 1988, section 33D

Source: OAIC, When do agencies need to conduct a privacy impact assessment?

Source: OAIC, Guide to Privacy Regulatory Action — Chapter 10: Directing a privacy impact assessment

Private-sector APP entities should conduct a threshold assessment for every project that involves the handling of personal information to determine whether a Privacy Impact Assessment (PIA) is necessary. Although the Privacy Act 1988 does not mandate PIAs for private-sector organisations (unlike Australian Government agencies under the Privacy (Australian Government Agencies – Governance) APP Code 2017), the OAIC's APP Guidelines state that "a commitment to conducting a Privacy Impact Assessment (PIA) for new projects in which personal information will be handled" is an example of a practice that an APP entity should consider implementing to satisfy APP 1.2's requirement to take "reasonable steps" to ensure compliance with the Australian Privacy Principles.

What is a threshold assessment? A threshold assessment is a preliminary screening conducted at the start of a project to determine whether a full PIA is warranted. The OAIC's Guide to undertaking privacy impact assessments recommends that a threshold assessment "should be routinely conducted for every project" involving personal information. The OAIC emphasises that "not every project will need a PIA" and that a threshold assessment allows projects with no or minimal information privacy implications to be quickly identified and cleared without the effort of a comprehensive PIA. Regardless of whether an entity proceeds to a full PIA, the OAIC recommends that the entity keep a record of the threshold assessment.

The basic threshold question. The first question in any threshold assessment is: "Will any personal information be collected, stored, used, or disclosed in the project?" If the answer is yes, a PIA is usually necessary. If no personal information is being handled, a PIA may still be useful in some circumstances—for example, to demonstrate how a project uses de-identified information and how the entity will prevent future re-identification, or to address other forms of privacy (bodily, behavioural, or communications privacy) not covered by the Privacy Act.

When a PIA may not be necessary. According to the OAIC's PIA Guide, a PIA may not be necessary if:

• The project does not propose any changes to existing information-handling practices,
• The privacy implications of those existing practices have been assessed previously (whether through a prior threshold assessment, a PIA, or another risk-assessment process), and
• Controls are current and working well.

If the project uses only de-identified information and there are no new or changed ways of handling personal information, a full PIA may be unnecessary, although the entity may still choose to document how it prevents re-identification.

Risk factors pointing to the need for a PIA. The OAIC's resource When do agencies need to conduct a privacy impact assessment?, developed for Australian Government agencies but applicable by analogy to private-sector entities, sets out a non-exhaustive list of general and activity-based risk factors that point to the potential for high privacy risk. An entity should consider conducting a PIA if the project involves any of the following:

• New or changed information-handling practices. Projects involving new ways of collecting, using, disclosing, storing, or securing personal information, or significant changes to existing practices, are strong candidates for a PIA. The greater the change, the greater the likelihood that a PIA is warranted.

• Large volumes of personal information or sensitive information. Projects that involve substantial amounts of personal information—or any handling of sensitive information such as health information, genetic or biometric data, information about an individual's race or ethnicity, political opinions or associations, religious or philosophical beliefs, sexual orientation, or criminal record—raise the privacy risk profile and typically warrant a PIA.

• New technology or surveillance capabilities. The introduction of new technologies (for example, facial recognition, biometric authentication, automated decision-making systems, artificial intelligence, Internet of Things devices, or new software platforms) or enhanced surveillance capabilities increases the likelihood that a PIA is appropriate. Technologies that collect, link, or analyse personal information in novel ways often have unanticipated privacy impacts.

• Disclosure to third parties or overseas recipients. Projects that involve disclosing personal information to external organisations, service providers, contractors, or overseas recipients (including cloud storage or processing) introduce additional privacy risks and should be assessed through a PIA. APP 8 (cross-border disclosure of personal information) imposes strict accountability obligations on entities that disclose personal information overseas, and a PIA can help the entity identify and mitigate those risks.

• Combining or linking data sets. Projects that involve matching, linking, or merging personal information from multiple sources—or that involve data analytics, profiling, or automated decision-making—raise privacy concerns and generally warrant a PIA. The ability to re-identify individuals from combined or linked data sets is a key risk.

• Vulnerable or at-risk populations. Projects that handle personal information about children, vulnerable adults, or other at-risk populations (for example, refugees, victims of family violence, or individuals with mental health conditions) typically have a higher privacy impact and should be assessed through a PIA.

• Community concern or reputational risk. If the project is likely to attract public attention or community concern, or if there is a risk of negative media coverage or loss of trust, a PIA can help identify privacy risks, demonstrate accountability, and support public consultation and stakeholder engagement.

Proportionality — the scale and scope of the PIA. The OAIC emphasises that a PIA is "a flexible and scalable tool" and that "the approach taken in a PIA should be proportionate to the level of risk." Not all PIAs need to be long or complex. For a low-risk project that involves only minor adjustments to existing information-handling practices, a PIA may be only a couple of pages long. For a high-risk project involving new technology, large volumes of sensitive information, or significant changes to handling practices, a robust and independent PIA conducted by external assessors may be preferable and may help build community trust in the PIA findings.

Section 33D power to direct a PIA. Under section 33D of the Privacy Act 1988, the Privacy Commissioner has the statutory power to direct an agency to provide a PIA to the OAIC if the Commissioner considers that a proposed activity or function of the agency "might have a significant impact on the privacy of individuals." Section 33D(3) defines a PIA for this purpose as "a written assessment that identifies the impact that the activity or function might have on the privacy of individuals, and sets out recommendations for managing, minimising or eliminating that impact." The OAIC has not been given the power to direct a private-sector organisation to conduct a PIA in the same way; however, the section 33D definition and the "significant impact" threshold provide useful benchmarks for any entity assessing whether a project warrants a voluntary PIA.

Timing — conduct the threshold assessment early. The OAIC's PIA Guide states that to be effective, a PIA (and its threshold assessment) should be an integral part of the project planning process, "not an afterthought." The assessment should be undertaken early enough in the development of a project that it is still possible to influence the project design or, if there are significant negative privacy impacts, to reconsider proceeding with the project. Conducting a threshold assessment at the proposal stage, before design and implementation decisions are locked in, maximises the value of the PIA process and embeds privacy by design.

Documentation and accountability. Regardless of whether an entity proceeds to a full PIA, the OAIC recommends that the entity keep a record of the threshold assessment. This record serves as evidence that the entity has taken reasonable steps to assess privacy risks as part of its APP 1.2 compliance obligations. In the event of a future complaint, privacy assessment, or investigation, a documented threshold assessment can demonstrate that the entity had a proactive approach to managing privacy risk.

Source: OAIC, Guide to undertaking privacy impact assessments

Source: OAIC, When do agencies need to conduct a privacy impact assessment?

Source: OAIC, Australian Privacy Principles Guidelines, Chapter 1 (APP 1)

Source: Privacy Act 1988, section 33D

Australian Government agencies subject to the Privacy (Australian Government Agencies – Governance) APP Code 2017 must maintain a register of the Privacy Impact Assessments (PIAs) they conduct and must publish that register, or a version of it, on the agency's website. This obligation is contained in section 15.1 of the Code and has been in force since 1 July 2018. The requirement applies to all Australian Government agencies covered by the Privacy Act 1988, excluding Ministers. Private-sector organisations and state or territory government agencies (which are generally exempt from the Privacy Act under section 7(1)(c)) are not bound by the Code and have no statutory register publication obligation.

Statutory text. Section 15 of the Code provides:

> (1) An agency must maintain a register of the PIAs it conducts. > > An agency must publish the register, or a version of the register, on its website. > > (2) An agency may provide a copy of the register, and any PIAs that are listed on the register, to the Commissioner on request from the Commissioner.

The provision does not prescribe the format, content, or location of the register. The Code is silent on these implementation details.

Scope of the register — what PIAs must be included. Section 15.1 requires an agency to maintain a register of "the PIAs it conducts." The Code does not limit this to PIAs conducted under section 12.1 (high privacy risk projects). The natural reading is that the register must include all PIAs the agency conducts, whether mandatory under section 12.1, prepared in response to a section 33D direction from the Privacy Commissioner, or conducted voluntarily as a matter of best practice.

Publication discretion — full register or a version. Section 15.1 requires that the agency "publish the register, or a version of the register, on its website." The phrase "or a version of the register" permits an agency to redact or omit certain information from the published version—for example, where publication would compromise security, breach confidentiality, or disclose commercially sensitive information. The Code does not specify what information must appear in the published version. The OAIC's PIA register assessment program page states that the assessment will check "whether agencies are complying with the requirement in s 15.1 of the Code" through a desktop review of agency websites but does not articulate content or format standards.

The OAIC's own published PIA register (published at oaic.gov.au/about-us/access-our-information/our-privacy-impact-assessment-register) provides one example: each entry lists the project name, a brief description or summary of topics covered, and (for some entries) a link to the full PIA report or a note that the project was assessed at threshold and did not proceed to a full PIA. This is illustrative of one agency's practice, not a regulatory standard.

Publication of the underlying PIA reports. Section 15 requires publication of the register; it does not mandate publication of the underlying PIA reports. Section 13 of the Code provides that "an agency may publish a PIA conducted under section 12, or a summary version or an edited copy of the PIA, on the agency's website" (emphasis added). Publication of PIA reports is voluntary under the Code. The OAIC's Guide to Privacy Regulatory Action — Chapter 10: Directing a privacy impact assessment states: "The OAIC will generally publish all PIA directions issued, and will require the agency to publish all final PIAs prepared in response to a PIA direction" (paragraph 10.15). This indicates that when a PIA has been directed under section 33D of the Privacy Act, publication of the PIA itself (or a summary) is expected as a matter of OAIC policy, but for PIAs conducted under section 12.1 (the mandatory high-risk threshold in the Code), publication remains permissive under section 13.

OAIC government-wide compliance assessment. The OAIC announced in May 2021 that it was undertaking a government-wide privacy assessment under section 33C(1)(a) of the Privacy Act 1988 to assess Australian Government agencies' compliance with the requirement in section 15.1 of the Code to publish a PIA register on their website. The OAIC states on its PIA register assessment program page: "The scope of this assessment will be limited to whether agencies are complying with the requirement contained in s 15.1 of the Code. The OAIC will be assessing compliance through a desktop review of agency websites." The OAIC page does not publish assessment findings or identify non-compliant agencies, and the page does not specify enforcement actions for non-compliance. The assessment program demonstrates that the OAIC treats section 15.1 as a binding and enforceable obligation.

Providing the register to the Commissioner on request. Section 15.2 provides that an agency "may provide a copy of the register, and any PIAs that are listed on the register, to the Commissioner on request from the Commissioner." The use of "may" rather than "must" is permissive, though the context suggests that the provision contemplates cooperation with the OAIC's regulatory oversight. If the Commissioner requests the register or a listed PIA under section 15.2, an agency would ordinarily provide it, particularly given the Commissioner's broader powers to obtain information under section 33C (privacy assessments) and Part V (investigations).

Timing and updating. The Code does not specify how frequently an agency must update its published PIA register. Section 9 of the Code requires agencies to measure and document their performance against the privacy management plan at least annually, and section 4.2 requires the plan to address "maintaining the agency's register of PIAs as required by section 15." These provisions imply that the register should be current, but the Code does not prescribe an update interval.

Private-sector entities — no statutory register obligation. Section 15 of the Code applies only to Australian Government agencies. Private-sector organisations covered by the Privacy Act 1988 are not bound by the Code and have no statutory requirement to maintain or publish a PIA register. The OAIC's Australian Privacy Principles Guidelines, Chapter 1 (APP 1) notes that "a commitment to conducting a Privacy Impact Assessment (PIA) for new projects in which personal information will be handled" is an example of a practice that an APP entity may consider implementing as a reasonable step under APP 1.2, and the OAIC's Guide to undertaking privacy impact assessments recommends that entities "keep a record of this threshold assessment" regardless of whether a full PIA is conducted. Maintaining an internal record of PIAs or threshold assessments may be a reasonable step for a private-sector entity to demonstrate APP 1.2 compliance, but there is no regulatory requirement to publish that record.

Source: Privacy (Australian Government Agencies – Governance) APP Code 2017, sections 13–15

Source: OAIC, PIA register assessment program

Source: OAIC, Our privacy impact assessment register

Source: OAIC, Guide to Privacy Regulatory Action — Chapter 10: Directing a privacy impact assessment

Australian Privacy Principle 1.2 requires every APP entity to take reasonable steps to implement practices, procedures, and systems that ensure compliance with the APPs and enable the entity to handle privacy inquiries and complaints, but the Privacy Act 1988 does not prescribe what documentation those systems must generate or retain. Unlike the EU GDPR Article 30 obligation to maintain detailed records of processing activities, APP 1.2 is principles-based and leaves the form and content of internal privacy documentation to the entity's discretion, subject to the overarching "reasonable steps" standard. The Office of the Australian Information Commissioner (OAIC) has, however, issued extensive guidance on documentation best practices that the OAIC considers evidence of reasonable steps, and the OAIC expressly states that it will assess documentation when investigating complaints or conducting privacy assessments.

Statutory text. APP 1.2 provides:

> An APP entity must take reasonable steps to implement practices, procedures and systems relating to the entity's functions or activities that will: > > (a) ensure that the entity complies with the Australian Privacy Principles and a registered APP code (if any) that binds the entity, and > > (b) enable the entity to deal with inquiries or complaints from individuals about the entity's compliance with the Australian Privacy Principles or such a code.

APP 1.2 imposes a distinct and separate obligation beyond merely complying with other APPs. The OAIC APP Guidelines state that "the purpose of APP 1.2 is to require an entity to take proactive steps to establish and maintain internal practices, procedures and systems that ensure compliance with the APPs" and that "the obligation is a constant one."

The OAIC's recommendation: keep records of steps taken to comply with APP 1.2. The OAIC APP Guidelines (Chapter 1, paragraph 1.6) state: "An entity could consider keeping a record of the steps taken to comply with APP 1.2, to demonstrate that personal information is managed in an open and transparent way." While the verb "could" signals that such recordkeeping is not mandatory under the statute, the OAIC's guidance makes clear that documented systems serve as evidence of compliance. The OAIC emphasises that documented practices, procedures, and systems should be "regularly reviewed and updated to ensure they reflect your current acts and practices."

What to document — security measures and information flows (APP 11 and PIA context). The OAIC's Guide to Securing Personal Information (June 2025) provides the clearest statement of documentation expectations under APP 1.2. For the purposes of APP 11 (security of personal information), the OAIC states: "you should document the internal practices, procedures and systems that you use to protect personal information. Your documentation should outline the personal information security measures that are established and maintained against the risks and threats to personal information. These documents should be regularly reviewed and updated to ensure they reflect your current acts and practices. You could also consider documenting the security choices you have made about your security profile, including the reasons why you have or have not adopted specific personal information security measures."

The OAIC further notes that documentation of security measures can be "addressed in a single policy or in a number of separate policies." The OAIC does not mandate a particular format or location for these records, but the guidance anticipates that entities will maintain written documentation of their security posture and will be able to produce it during an investigation or assessment.

Information-flow mapping and data inventories. Multiple OAIC guidance documents recommend that entities map personal information flows and maintain inventories of the personal information they collect and hold. The OAIC's Guide to undertaking privacy impact assessments includes a detailed module (Step 4: Map information flows) that instructs entities to "describe and map the project's personal information flows in detail" and to "document what information will be collected, used, and disclosed; how it will be held and protected; and who will have access." The OAIC's Guide to data analytics and the Australian Privacy Principles recommends that entities "map what they expect to learn by processing that data" and states that a PIA should be used to map information flows and assess whether the personal information is "relevant and not excessive" in relation to the entity's legitimate functions and activities.

Although PIA guidance is formally directed at projects, the mapping methodology the OAIC describes — documenting what personal information is collected, from whom, for what purpose, how it is used and disclosed, where it is stored, who has access, and when it is destroyed — is effectively an inventory of processing activities. The OAIC has stated that "a PIA would assist loyalty schemes to map customer data flows and privacy risks which may emerge at various stages of collection, use and disclosure of personal information," signalling that such mapping is a reasonable step for any entity handling personal information at scale, not merely for discrete high-risk projects.

What a documented APP 1.2 compliance system might include. The OAIC APP Guidelines (Chapter 1, paragraph 1.7) list a range of "practices, procedures and systems that an APP entity should consider implementing" to satisfy APP 1.2. The list is illustrative and non-exhaustive; the reasonableness of each measure turns on the entity's size, resources, business model, and the sensitivity of the personal information it holds. The examples include:

• Governance structures: "Governance mechanisms to ensure compliance with the APPs (such as designated privacy officers and regular reporting to the entity's governance body)." For private-sector entities this is voluntary; for Australian Government agencies subject to the Privacy (Australian Government Agencies – Governance) APP Code 2017, appointment of a Privacy Officer and Privacy Champion is mandatory.
• Staff training and awareness programs: Regular training for staff who handle personal information, to ensure they understand the entity's obligations under the APPs and the entity's internal policies.
• Internal policies and procedures: Written policies addressing the handling of personal information, including collection, use, disclosure, storage, security, access and correction requests, and complaints handling. The policies should be reviewed and updated regularly.
• A commitment to conducting Privacy Impact Assessments (PIAs) for new projects in which personal information will be handled. The OAIC states this is an example of a reasonable step for APP 1.2 compliance.
• Assurance mechanisms: Regular audits, monitoring, and compliance reviews to ensure that the entity's practices conform to its documented procedures and to the APPs. The OAIC APP Guidelines (Chapter 13, paragraph 13.17) note that "a practice, procedure or system the entity has implemented in compliance with APP 1.2 (such as an auditing or monitoring program)" may detect incorrect personal information and trigger correction obligations under APP 13.

Evidence from OAIC enforcement: documented PIAs, System Security Plans, and information-flow mapping. The OAIC's published privacy assessments demonstrate that the OAIC routinely examines whether entities have documented their compliance measures. In the OAIC's assessment of the Australian Digital Health Agency's handling of personal information in the My Health Record app (September 2024), the assessment team found that "documentation that demonstrated that reasonable steps had been taken to implement practices, procedures and systems relating to the security of the app, including a Privacy Impact Assessment and a System Security Plan" constituted evidence of reasonable steps under APP 1.2. The assessment also focused on "the way that information flows through the app" and assessed whether the entity had documented those flows in a manner sufficient to support compliance with APP 1.2 and APP 5.

No prescribed format or statutory template — flexibility remains. The Privacy Act does not specify the format, structure, or location of APP 1.2 documentation. The OAIC has not issued a mandatory template or register requirement for private-sector entities. The APP 1.2 "reasonable steps" standard is fact-specific and scales with the entity's size, resources, business model, and the volume and sensitivity of personal information it handles. A small entity with straightforward information flows may satisfy APP 1.2 with a brief written privacy policy and a documented training schedule; a large entity engaged in complex data analytics, cross-border disclosures, or handling of sensitive information (health records, children's information, biometric data) would be expected to maintain more detailed documentation, including comprehensive information-flow maps, documented PIAs for high-risk projects, and evidence of regular privacy audits.

Contrast with Australian Government agencies. Australian Government agencies subject to the Privacy (Australian Government Agencies – Governance) APP Code 2017 face more prescriptive documentation requirements. Section 4 of the Code requires every agency to develop, implement, and maintain a written Privacy Management Plan that addresses, among other matters, "the agency's processes and procedures for handling personal information" and "how the agency will measure and document its performance against the plan." The Code also requires agencies to conduct PIAs for high privacy risk projects (section 12), to maintain and publish a PIA register (section 15), and to designate a Privacy Officer (section 10) and Privacy Champion (section 11). Private-sector entities and state government agencies are not subject to the Code and remain governed by APP 1.2's flexible "reasonable steps" standard.

Practical effect: an internal processing inventory is voluntary but advisable. While there is no statutory ROPA obligation in Australia analogous to GDPR Article 30, the OAIC's cumulative guidance on APP 1.2 — particularly the recommendation to document practices, procedures, and systems, the emphasis on mapping information flows in PIA guidance, and the OAIC's reliance on documented evidence when conducting assessments — creates a strong compliance incentive for entities to maintain an internal inventory of personal information processing activities. Such an inventory would document the categories of personal information collected, the purposes of collection, the lawful basis for collection and use (whether consent, necessity for performance of a contract, legal obligation, or another permitted general situation under section 16A), typical disclosures (including cross-border disclosures under APP 8), storage and security measures, and retention schedules. Entities that cannot produce such documentation when the OAIC investigates a complaint or conducts a section 33C assessment risk a finding that they have not taken reasonable steps to implement systems that ensure APP compliance.

Currency note. On 10 December 2026, new APP 1 obligations for automated decision-making will commence under the Privacy and Other Legislation Amendment Act 2024. Entities that arrange for a computer program to use personal information to make decisions that could reasonably be expected to significantly affect the rights or interests of an individual will be required to include additional information in their APP Privacy Policy (APP 1.7–1.9). Documentation of these automated decision systems — including the logic involved and the consequences for individuals — will become an additional element of reasonable steps under APP 1.2 for entities engaged in such processing.

Source: OAIC, Australian Privacy Principles Guidelines, Chapter 1 (APP 1)

Source: OAIC, Guide to securing personal information

Source: Privacy Act 1988, Schedule 1 (Australian Privacy Principles)

Source: OAIC, Guide to undertaking privacy impact assessments

Source: OAIC, Handling of personal information: my health app (privacy assessment)

Australian Government agencies subject to the Privacy (Australian Government Agencies – Governance) APP Code 2017 must develop, implement, and maintain a written Privacy Management Plan (PMP), setting out how the agency will meet its compliance obligations under the Australian Privacy Principles (APPs) and the Code. This is a binding requirement under section 4 of the APP Code 2017, in force since 1 July 2018, and applies to all Australian Government agencies subject to the Privacy Act 1988 (excluding Ministers).

Section 4 of the Code: statutory content and review requirements. Section 4(1) requires an agency to have a PMP that "complies with this section." The PMP must:

• address the agency's processes and procedures for identifying and managing privacy risks;
• address the agency's processes and procedures for handling personal information;
• set out how the agency will measure and document its performance against the plan (s 4.2);
• be reviewed and updated regularly to ensure it remains effective (s 4.3).

Section 4.2 specifically requires the PMP to address:

• the agency's program for ongoing monitoring, reviewing, and assessing the agency's privacy processes;
• how the agency will maintain and publish its register of PIAs as required by section 15.

Ownership and responsibility. While the Code does not mandate a particular official or team responsible for developing or maintaining the PMP, in practice, the designated Privacy Officer (section 10) and Privacy Champion (section 11) roles have key responsibility for the PMP's implementation.

Integration into agency governance. The PMP is intended to be a dynamic tool: it documents privacy practices, assigns accountability, drives ongoing risk assessment, and enables regular reporting to senior leadership. Section 9 of the Code requires agencies to "measure and document their performance against the plan at least annually." This includes reviewing the effectiveness of privacy practices in light of new risks, legislative changes, and agency initiatives.

OAIC guidance and expectations. The Office of the Australian Information Commissioner (OAIC) has published PMP guidance and urges agencies to align their plans with OAIC priorities (such as privacy by design, proactive PIAs, and transparent communication with the public). When assessing agency compliance, the OAIC expects the PMP to be detailed, tailored to the agency's functions, and linked to risk assessment and senior oversight. The OAIC's guidance also recommends:

• describing how privacy is embedded in agency culture and decision-making;
• outlining mechanisms for privacy training and awareness;
• specifying how the agency will ensure ongoing compliance (e.g., audits);
• mapping key accountability roles (Privacy Officer, Champion, exec sign-off).

Currency and update obligations. The Code requires at least annual review. Agencies must keep the PMP current—to reflect legislative amendments and any major changes in information handling. Regular review and executive reporting are both mandated and audited by the OAIC in its regulatory oversight role.

Private sector not covered. The PMP obligation is unique to Australian Government agencies—private-sector organisations are not required to implement a PMP under the Privacy Act or the APPs.

Source: Privacy (Australian Government Agencies – Governance) APP Code 2017, section 4

Source: OAIC, Privacy management framework: enabling compliance and encouraging good practice

The Privacy (Australian Government Agencies – Governance) APP Code 2017 (the APP Code) mandates that all Australian Government agencies subject to the Privacy Act 1988 designate at least one Privacy Officer and one Privacy Champion, with distinct statutory functions and responsibilities. These requirements are separate and additional to the general obligations under Australian Privacy Principle 1.2 and are binding only on federal agencies (not private-sector APP entities or state/territory authorities).

Privacy Officer role and responsibilities (section 10). Section 10.1 of the APP Code requires every agency to "designate at least one employee as the agency's Privacy Officer." This officer must be the agency's principal point of contact on privacy matters (s 10.4) and their contact details must be notified to the OAIC (s 10.3). The agency may appoint more than one Privacy Officer and designate officers either by name or position/rank (s 10.2). The Privacy Officer's functions—set out at s 10.5—include providing privacy advice, investigating possible breaches, supporting privacy education and compliance initiatives, and acting as the liaison with the OAIC. There are no prescribed qualifications, but the officer must have sufficient seniority and expertise to effectively discharge these functions.

Privacy Champion requirements (section 11). The APP Code requires every agency to "designate a senior official as the agency's Privacy Champion" (s 11.3). The Champion is intended to drive cultural change and executive accountability for privacy compliance. Their functions (s 11.4) include promoting privacy across the agency, advocating for privacy at the executive level, overseeing the privacy management plan, and reporting regularly to the executive team. The Champion must be sufficiently senior—typically a member of the SES or an equivalent leadership role. Section 11.5 allows one person to serve as both Privacy Officer and Champion if appropriate, but only if they can fulfill both roles effectively.

Organisational considerations. The Code is silent on detailed selection criteria or reporting lines, leaving agencies flexibility to adapt the roles to their structure. Agencies are expected to give the Privacy Officer and Champion adequate support, resources, and authority to carry out their duties. The OAIC interprets these obligations as requiring agencies to ensure that privacy leadership is entrenched at both operational and strategic levels.

No private-sector equivalent. The mandatory appointment of a Privacy Officer and Privacy Champion under the Code applies solely to Australian Government agencies. Private-sector APP entities may voluntarily appoint similar roles, and the OAIC considers this a "reasonable step" towards APP 1.2 compliance, but there is no statutory obligation or minimum requirement for the private sector.

Source: Privacy (Australian Government Agencies – Governance) APP Code 2017

Section 33D of the Privacy Act 1988 gives the Office of the Australian Information Commissioner (OAIC) the statutory power to direct an agency to provide a Privacy Impact Assessment (PIA) for any proposed activity or function that "might have a significant impact on the privacy of individuals." This power applies to Australian Government agencies subject to the Act and, in principle, can also be extended to certain private-sector organisations designated as "APP entities," though in practice, directions are almost exclusively issued to federal agencies.

Trigger and scope of section 33D. The Commissioner may issue a formal written direction requiring the agency to deliver a PIA, setting a deadline for completion and specifying the project or activity to be assessed. The statutory threshold is whether the Commissioner considers there is a "significant impact on the privacy of individuals." This test is distinct from, and broader than, the high privacy risk threshold under the APP Code 2017 (applicable to federal agencies), allowing the OAIC to intervene before implementation where perceived risks justify regulatory review. Where the Commissioner exercises this power, compliance is mandatory: the directed entity must provide a PIA that (at minimum) identifies the privacy impact of the proposed activity and contains recommendations for managing, minimising or eliminating those impacts.

Required content. Section 33D(3) defines a PIA as, at a minimum, "a written assessment that identifies the impact that the activity or function might have on the privacy of individuals, and sets out recommendations for managing, minimising or eliminating that impact." The OAIC may provide further guidance or templates, but the Act itself does not dictate the structure or publication of the PIA beyond this baseline. Agencies may choose to publish the resulting PIA, but only publication of the PIA register is strictly required under the APP Code.

Publication and transparency. While the Code allows voluntary publication of PIAs, the OAIC Guide to Privacy Regulatory Action states that the OAIC will generally publish all PIA directions it issues (including the fact and scope of the direction), and expects the agency to publish all final PIAs prepared in response to a section 33D direction. This is a transparency and accountability practice, not an express statutory mandate.

Enforcement context. The section 33D power supplements the OAIC’s broader investigative and regulatory toolkit under the Privacy Act, including powers of assessment (section 33C) and investigation (Part V). Failure to comply with a section 33D direction is a breach of the Act and could trigger further regulatory action.

Practical examples. Most PIAs undertaken in response to section 33D directions have related to government projects with significant new data collections, expansions of digital identity regimes, or rollouts of national health, education, or digital platform initiatives. The OAIC seldom exercises this power for routine APP compliance gaps—instead, it is reserved for projects with sector-wide privacy consequences or where the public interest in independent scrutiny is high.

Currency note (June 2026): Section 33D remains in force and has not been substantively amended since its expansion in 2014. OAIC guidance and practices as described are current as of 2026.

Source: Privacy Act 1988, section 33D Source: OAIC, Guide to Privacy Regulatory Action — Chapter 10: Directing a privacy impact assessment

Privacy by design is not an express statutory requirement in the Privacy Act 1988 or its Australian Privacy Principles (APPs), but is a recurring theme in the Office of the Australian Information Commissioner (OAIC) guidance as a best practice to meet the 'reasonable steps' obligation under APP 1.2. APP 1.2 requires every APP entity to take reasonable steps to implement practices, procedures, and systems that ensure compliance with the APPs and enable the handling of privacy inquiries and complaints. The statute does not define or mandate 'privacy by design.'

OAIC guidance and the 'reasonable steps' standard. OAIC guidance documents, including the APP Guidelines (Chapter 1) and the Guide to undertaking privacy impact assessments (PIA Guide), advise entities to integrate privacy considerations early and throughout the information-handling lifecycle—often referring to this as a 'privacy by design' approach. The OAIC recommends that privacy be "integrated into decision-making," not treated as an afterthought, and that new projects or processing activities be assessed for privacy impacts from conception onward. However, this expectation arises from non-binding guidelines and not from statutory text.

Examples drawn from OAIC guidance:

• Anticipating privacy risks in project planning and documentation stages.
• Embedding privacy settings, data minimisation, and access controls as defaults where technically and operationally feasible.
• Performing privacy impact assessments (PIAs) as part of implementing privacy by design on new or significantly changed projects—though PIAs are mandatory only for certain federal agencies and in prescribed risk scenarios.
• Documenting privacy considerations and decisions made throughout system development and vendor procurement processes.

Compliance and enforcement posture. Although adoption of privacy by design is not legally required, the OAIC has, in enforcement outcomes and investigative assessments, used the extent to which an entity follows privacy by design principles as one factor in determining whether "reasonable steps" have been taken (see, for example, the 2024 assessment of the handling of personal information by the My Health app). The OAIC's language is measured: a lack of privacy by design indicates gaps that may contribute to a finding of insufficient compliance, but is not by itself a breach of the APPs.

Contrast with GDPR. Unlike Article 25 GDPR, which imposes a binding privacy by design and by default obligation, the Australian Privacy Act currently relies on principles-based compliance, with privacy by design emerging only through regulator guidance and not as a freestanding right or obligation. For multinationals, bridging to the stricter GDPR model is often a practical necessity, but is not compelled by Australian law.

Currency note (2026): There is no legislative amendment pending that would introduce a statutory privacy by design duty as of June 2026. The OAIC guidance and enforcement approach as outlined here is current and authoritative for Australian practice.

Source: OAIC, Australian Privacy Principles Guidelines, Chapter 1 (APP 1)

Source: OAIC, Guide to undertaking privacy impact assessments

Source: OAIC, Handling of personal information: my health app (privacy assessment)

Australian Privacy Principle (APP) 8 in Schedule 1 to the Privacy Act 1988 governs the disclosure of personal information to overseas recipients (“cross-border disclosure”) by APP entities. While APP 8 does not impose a mandatory Privacy Impact Assessment (PIA) for cross-border transfers, the Office of the Australian Information Commissioner (OAIC) has long recommended that entities conduct a PIA for projects or initiatives involving cross-border transfers, treating such disclosures as inherently high risk.

2026 material update – new statutory exception and OAIC guidance:

• In late 2025 and early 2026, the OAIC released a new version of the APP Guidelines, Chapter 8 to reflect amendments from the Privacy and Other Legislation Amendment Act 2024. The new guidance introduces a new exception to APP 8’s general accountability rule, clarifies application of s 16C, and expands the description of "reasonable steps" to explicitly include appropriate technical and organisational security measures (building on the obligations under APP 11).
• APP entities must now take documented technical and organisational steps to ensure an overseas recipient will not breach the APPs, not just rely on contractual or policy measures. This is both a compliance and risk expectation: failure to do so may increase regulatory exposure if a recipient mishandles Australian personal information.
• The OAIC guidance continues to recommend that a PIA be undertaken for any project involving overseas disclosure, and specifically calls out that the PIA should address the technical/organisational controls and assess their sufficiency in light of both the new exception and the broader risk landscape.

What changed and when:

• The OAIC’s updated APP Guidelines, Chapter 8 (published after October 2025) and public announcements confirm these changes. The new statutory exception affects when an entity will remain accountable for the acts of an overseas recipient under s 16C. The updated guidance broadens the definition of "reasonable steps" under APP 8.1 (and by implication, what should be documented in a PIA) to include technical as well as legal/commercial safeguards. Entities must address these expectations in any cross-border data transfer assessment.

Enforcement risk and best practice:

• OAIC assessments are likely to scrutinise not only whether a PIA was conducted for a cross-border disclosure project, but whether the assessment specifically analyzed the sufficiency of technical and organisational measures, and whether any reliance on the new exception is soundly documented with reference to the legislative criteria.
• These OAIC clarifications and the legislative update apply to both public and private-sector APP entities. The compliance burden for cross-border disclosures has increased and so PIAs—while still non-mandatory—are functionally expected when international transfers are material to a project.

Source: OAIC, Australian Privacy Principles Guidelines — Chapter 8 (APP 8: Cross-border disclosure of personal information), version 1.4 (2026) Source: OAIC, Guide to undertaking privacy impact assessments Source: Privacy Act 1988, as amended by the Privacy and Other Legislation Amendment Act 2024

Section 9 of the Privacy (Australian Government Agencies – Governance) APP Code 2017 imposes a recurring obligation on Australian Government agencies to systematically review and report on the effectiveness of their Privacy Management Plan (PMP) at least annually. This duty applies to all Commonwealth agencies (excluding Ministers) subject to the Privacy Act 1988, and represents a key element of the Code's 'living governance' model.

Statutory requirement and scope: Section 9 of the Code provides:

> An agency must measure and document their performance against the plan at least annually.

This means that every agency must—on a rolling, not one-off—basis:

• Assess how its privacy practices, procedures, and systems, as described in the current PMP, are working in practice.
• Identify and document strengths, gaps, and areas for improvement.
• Update the PMP and supporting documentation as needed to reflect changes in law, technology, or risk profile (see section 4.3: "reviewed and updated regularly to ensure it remains effective").

Executive reporting: While the Code does not prescribe a fixed reporting format, it expects agencies to ensure senior leadership oversight of privacy performance. Section 11.4(c) (Privacy Champion responsibilities) expressly requires regular reporting on privacy management to the agency's executive. OAIC guidance (Privacy Management Framework, 2023 update) elaborates that privacy performance measurement must flow into management-level review and inform agency risk management, resource decisions, and cultural change initiatives.

OAIC guidance and expectations: The OAIC’s Privacy Management Framework further describes regulator expectations: agencies should set measurable privacy objectives, assign clear responsibility, conduct self-assessments or internal audits, and report progress to the executive at least annually. The resulting review should:

• Incorporate lessons from privacy incidents, complaints, and OAIC engagements during the period.
• Evaluate the effectiveness of privacy training programs, PIAs, and register maintenance.
• Lead to an updated PMP, which should be disseminated internally, and sections made public where appropriate.

The OAIC reviews agency compliance through periodic privacy assessments under section 33C of the Privacy Act, and expects documented annual PMP reviews and executive reporting as central evidence of compliance with the Code. Agencies that cannot evidence this cycle risk regulatory action and adverse findings in OAIC assessment reports.

Currency note: Section 9 (annual performance review) and section 11.4(c) (executive reporting) remain in force and unchanged as of June 2026.

Source: Privacy (Australian Government Agencies – Governance) APP Code 2017, sections 4, 9, and 11

Source: OAIC, Privacy management framework: enabling compliance and encouraging good practice

Health service providers in Australia are subject to strict privacy governance and recordkeeping requirements under the Privacy Act 1988, as augmented by the My Health Records Act 2012. Recent regulatory reforms, effective from 2026, have further tightened these obligations, particularly for providers participating in the My Health Record system.

Definition and APP entity status Under s 6FB of the Privacy Act, a "health service provider" includes any entity providing healthcare, diagnosis, or treatment, regardless of size. All such providers are considered "APP entities" under the Act, even if their turnover is below AUD 3 million (Privacy Act ss 6FB, 6D(4)(b)).

Privacy Act obligations

• Privacy policy (APP 1.4): Must clearly set out the types of personal information collected and held, how and why it is collected, handled, used, or disclosed, the procedures for access, correction, and complaint, and whether disclosures are likely to be made overseas. The OAIC requires regular updating of the privacy policy and evidence of staff training (OAIC APP Guidelines Chapter 1).
• Practices, procedures, and systems (APP 1.2): Must be documented and regularly reviewed. This includes risk assessments, mapping information flows, staff training records, and security logs (see also APP 11 and OAIC Guide to Health Privacy, June 2025 update).
• Records of disclosures/access (APP 6/12/13): Health providers must keep records of disclosures (particularly to third parties or as legally required) and maintain responsive systems for individual access and correction requests. These practices are the focus of OAIC audits of health-sector APP compliance.

My Health Records Act and Rules — new and continuing requirements (April/July 2026 updates)

• My Health Records Regulations 2026 and Rules 2026 commenced 1 April 2026, replacing prior instruments (Rules 2016 et al) with a transition period for existing participants until 1 October 2026. These regulations clarify audit log requirements, access control record-keeping, and mandatory staff security training documentation. Health providers engaging with My Health Record must maintain comprehensive access and security documentation in accordance with the new requirements (My Health Records Regulation 2026 rr 23, 27; My Health Records Rule 2026 rr 41–45).

• Recordkeeping for access and audit: Providers must log all access to My Health Records data and maintain those audit logs (My Health Records Act s 74A; My Health Records Rule 2026 r 41). Providers must also develop, implement, and annually review a written internal privacy/security policy for My Health Record participation, and document all staff training on the Act’s privacy provisions (Rule 2026 r 42).

• Breach notification: Providers must notify the OAIC and the System Operator (Australian Digital Health Agency) of any "eligible data breach" (My Health Records Act s 75). The breach notification threshold remains lower than under the general Privacy Act’s NDB scheme. Non-compliance may trigger civil/criminal penalties (My Health Records Act ss 105A, 109).

• New "Sharing by Default" regime for prescribed reports (from 1 July 2026):
• The Modernising My Health Record – Sharing by Default Act 2025 now requires prescribed health providers (notably pathology and diagnostic imaging providers) to upload written reports to the My Health Record system by default as soon as practicable, unless a valid statutory exception applies (s 67C My Health Records Act).
• Providers are required to document any exception to uploading—including the grounds, decision-maker, and timeframe (s 67C(5), My Health Records Regulation 2026 r 27). There are penalties for non-compliance, including civil penalty provisions and possible Medicare benefit recovery for repeated or egregious breaches (s 109, s 129 My Health Records Act as amended).
• The four statutory exceptions are: (a) patient opted out for this episode, (b) serious threat to life/health, (c) legal prohibition on disclosure, (d) technical infeasibility at time of report. Providers must keep a formal record justifying use of any exception.

OAIC enforcement context The OAIC routinely audits health service providers for evidence of up-to-date privacy and security documentation and detailed audit logs. The 2024–2026 compliance focus includes not only general Privacy Act documentation, but also adherence to the updated My Health Records Act/Regulation/Rules and Sharing by Default regime record-keeping.

State/territory overlays remain (e.g. NSW Health Records Act 2002). This section covers Commonwealth requirements only.

Currency note: The above summary incorporates regulatory changes effective April and July 2026. The previous 2016 Rules are repealed as of 1 October 2026 (end of transition period) for all participants.

Source: Privacy Act 1988, Schedule 1 (APP 1.2, 1.4, 6, 11, 12, 13), s 6FB Source: My Health Records Act 2012, ss 62–65, 67C, 74A, 75, 105A, 109, 129 (as amended 2025/2026) Source: My Health Records Regulation 2026 Source: My Health Records Rule 2026 Source: OAIC, Guide to health privacy

Australian Government agencies—and private-sector entities aiming for best practice—must not only conduct Privacy Impact Assessments (PIAs) but should also rigorously document the follow-through and tracking of recommended mitigation measures. OAIC guidance, both in the Privacy (Australian Government Agencies – Governance) APP Code 2017 and in the Guide to undertaking privacy impact assessments (PIA Guide), makes clear that conducting a PIA is only the first compliance step. The ongoing reduction of risk, implementation of recommendations, and proper recordkeeping are essential to demonstrating compliance in OAIC assessments and potential investigations.

Statutory and code requirements. Section 15 of the APP Code 2017 obliges Commonwealth agencies to maintain and publish a register of PIAs, but does not explicitly require tracking mitigation outcomes. However, section 4 (Privacy Management Plan) and section 9 (annual review of PMP) imply a continuous responsibility to review, update, and document the agency's privacy risk posture—including follow-up on PIAs. Section 12(3) of the Code further explicitly requires agencies to "identify lessons learnt from all PIAs undertaken and apply those lessons in the design and conduct of future projects."

OAIC guidance on PIA follow-through. The OAIC’s PIA Guide (Step 8: "Integrate into the project") instructs APP entities that the recommendations and risk treatment plans outlined in the PIA must be systematically tracked and integrated as the project moves forward. Entities should document:

• which recommendations were adopted or rejected (with reasons),
• implementation timelines and responsible owners,
• review points for post-launch audits, and
• any adjustments to risk mitigation as the project environment evolves.

The Guide also advises keeping a written record of the management response to each PIA finding—both for agency governance and OAIC assessment purposes. Failure to document the follow-through on mitigation actions can be evidence of insufficient compliance with APP 1.2’s "reasonable steps" standard.

OAIC audit and assessment expectations. OAIC privacy assessments, including those published on high-profile digital government platforms, consistently cite not only the quality of initial PIAs but also the presence or absence of documented implementation of recommendations as critical. For example, in its 2024 audit of the "My Health App," the OAIC highlighted documented closure of risks and tracking of mitigation steps as key factors for compliance. Agencies are expected to provide evidence of:

• a project risk register updated with PIA outcomes,
• assignment of implementation responsibility,
• regular executive or Privacy Champion review,
• and records of post-implementation review or lessons learnt.

Best practice advice for private-sector APP entities. While these obligations are codified only for government agencies, the OAIC’s expectations under APP 1.2 mean that large or high-risk private entities should adopt similar PIA follow-through practices, maintain risk registers, and be ready to provide evidence of implemented risk mitigation if investigated.

Currency note (June 2026): This practice is current and aligns with OAIC audit standards and published guidance as of June 2026. No legislative amendment requiring statutory tracking registers for private entities is pending.

Source: OAIC, Guide to undertaking privacy impact assessments

Source: Privacy (Australian Government Agencies – Governance) APP Code 2017, sections 4, 9, 12, 15

Source: OAIC, Handling of personal information: my health app (privacy assessment)

The Office of the Australian Information Commissioner (OAIC) has published a comprehensive Privacy Management Framework (PMF) setting out the foundational governance elements expected of all entities subject to the Privacy Act 1988—whether government agencies or private-sector APP entities—to meet their ongoing obligations under Australian Privacy Principle (APP) 1.2. While not a binding statutory instrument, the PMF is referenced throughout OAIC audits, privacy assessments, and enforcement actions as the operationalisation of APP 1.2’s core requirement: that an entity take and document “reasonable steps” to ensure open and effective privacy management across the organisation.

The OAIC’s Privacy Management Framework is structured around four pillars, derived from both domestic regulatory requirements and global best practice (drawing in part from the OECD Privacy Guidelines):

1. Embed a culture of privacy: Senior leaders must set expectations and drive privacy awareness and accountability throughout the entity by designating roles (such as Privacy Officer and, for government agencies, a Privacy Champion), integrating privacy into key decisions, and ensuring staff training. Embedding privacy includes executive oversight, clear assignment of responsibilities, and creating staff awareness that privacy is an enterprise-wide issue.

1. Establish robust privacy practices, procedures and systems: Entities must develop, document, and maintain internal policies and procedures to ensure ongoing compliance with the APPs. This documentation should be regularly reviewed, kept up to date, and include mapping of personal information flows, risk assessment processes (such as Privacy Impact Assessments), staff induction and refresher training, and guidance on how to handle privacy inquiries and complaints. The OAIC recommends allocating resources commensurate to the scale and complexity of data handling, and tailoring controls to the sensitivity and volume of personal information managed.

1. Evaluate and enhance privacy processes: The framework expects regular internal review—at least annually—of all practices, procedures, and systems associated with the handling of personal information. Entities should use audits, compliance reviews, and lessons from incidents or complaints to inform improvements. OAIC guidance requires updates not only in response to law changes but also following risk events, new business operations, or changes in service delivery.

1. Demonstrate privacy compliance: The OAIC expects entities to be able to provide evidence of their privacy management activities in response to assessment or enforcement action. This includes documented policies, training records, completed privacy impact assessments and threshold assessments, risk registers, logs of reviews and updates, and executive reporting on privacy matters. Demonstration of compliance is an explicit element in OAIC’s enforcement and assessment documentation (see My Health App assessment 2024).

The PMF is explicitly cited by the OAIC as the practical roadmap for satisfying APP 1.2. Entities are expected to adopt and adapt the four pillars to their size, risk profile, and complexity of operations. The framework is referenced in numerous OAIC assessments and is often incorporated as a corrective action when remediation is required. Private-sector entities are not required to mirror the more prescriptive requirements of the APP Code for agencies, but alignment with the PMF is the key evidentiary threshold in regulatory scrutiny.

Currency note: The OAIC’s Privacy Management Framework was most recently updated in May 2023 and is endorsed as current best practice as of June 2026.

Source: OAIC, Privacy management framework: enabling compliance and encouraging good practice

From 10 December 2026, all APP entities that use or propose to use automated decision-making (ADM) involving personal information face new documentation and disclosure requirements under Australian Privacy Principle (APP) 1, as amended by the Privacy and Other Legislation Amendment Act 2024.

Statutory duty—scope and triggers: The new duties apply to any "APP entity" (as defined in s 6(1) of the Privacy Act 1988) that arranges for a computer program to make a decision or to assist in making a decision about an individual, where that decision could reasonably be expected to have a significant effect on that individual's rights or interests. This encompasses fully automated decisions as well as automated support for human-in-the-loop decision-making. There is no exemption for sector, turnover, or specific technological method; any form of artificial intelligence or machine learning system affecting individuals in a substantive way is in scope.

Key requirements:

• APP Privacy Policy disclosure: The Privacy Act, as amended, requires the organisation’s APP Privacy Policy to include clear information about:
• The use (or proposed use) of ADM systems to make or substantially contribute to decisions that significantly affect individuals.
• The types of decisions covered.
• A plain-language description of how the ADM works ("the logic involved") and the potential consequences for individuals whose information is processed. This must be up to date and sufficiently granular that affected persons and the OAIC can understand both the existence of ADM and its foreseeable impacts.
• Internal documentation: To meet the expanded "reasonable steps" standard under APP 1.2, entities must maintain records describing:
• The decision process flow—including which systems or programs are in-scope under the Act’s definition of ADM,
• How individuals can seek further information or contest the use or outcome of automated decisions (links to complaint handling under APP 1.4(d) and access/correction under APPs 12–13),
• Any details relevant to risk assessment or mitigation considered by the entity, especially where the ADM involves sensitive information or profiling.

Standard and enforcement: The OAIC is empowered to assess whether these disclosures and records meet the new expectations for fairness, transparency, and explainability (see Explanatory Memorandum to the Act). Practices must be both published (in the privacy policy) and demonstrable through internal records. While the OAIC has not—yet—published detailed sector-specific guidance or a mandatory ADM documentation template, entities should be prepared for assessment of ADM records as part of ongoing APP 1.2 audits from December 2026.

Distinctions from GDPR Art. 22: Unlike the EU GDPR, Australia’s APP amendments do not grant a direct right to opt-out of ADM or to demand a human-only decision. The 2026 reforms focus on accountability and transparency, not a standalone prohibition or override right. Entities with global operations should note that compliance with the new APP 1 ADM requirements will not, alone, fulfill EU (or UK) obligations for ADM explainability and individual rights.

Currency note: These ADM documentation requirements are binding for all covered data-processing activities from 10 December 2026. As of June 2026, transitional OAIC guidance is still under development.

Source: Privacy and Other Legislation Amendment Act 2024 (Schedule 1, items 13–16)