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)