Australia — Lawful Bases for Processing

Australia does not adopt the GDPR's six-lawful-basis architecture (consent, contract, legal obligation, vital interests, public task, legitimate interests). Instead, the Privacy Act 1988 (Cth) regulates personal-information handling through thirteen Australian Privacy Principles (APPs) set out in Schedule 1 to the Act and enforceable under section 15. The APPs are principles-based, purpose-oriented rules that apply across the information lifecycle: collection (APPs 3–5), use and disclosure (APPs 6–9), quality and security (APPs 10–11), and access and correction (APPs 12–13).

Who is covered. The APPs bind "APP entities"—Australian Government agencies and organisations with an annual turnover exceeding AUD 3 million (section 6C). Smaller organisations (under the AUD 3 million threshold) are exempt unless they are health service providers, trade in personal information for benefit, provide a service under a Commonwealth contract, are related to a larger body corporate that is covered, or are registered or recognised under the Fair Work (Registered Organisations) Act 2009. State and Territory government agencies are generally governed by separate state privacy regimes, though the Commonwealth Privacy Act covers certain acts under contract or involving Commonwealth records.

The collection gateway — APP 3. APP 3 controls when an APP entity may collect personal information. Collection is lawful only if the information is reasonably necessary for one or more of the entity's functions or activities (APP 3.2). For sensitive information (defined in section 6(1) to include racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, health information, genetic and biometric data, sexual orientation, and criminal-record information), collection is prohibited unless the individual consents and the information is reasonably necessary for the entity's functions, or a "permitted general situation" exists under section 16A (e.g., required by law, necessary to prevent a serious threat to life or health, necessary for certain law-enforcement activities), or a "permitted health situation" exists under section 16B for organisations handling health information (APP 3.3–3.4).

The use-and-disclosure restriction — APP 6. Once collected for a particular purpose (the "primary purpose"), an APP entity must not use or disclose the information for a different purpose (a "secondary purpose") unless one of the following applies (APP 6.1–6.2):

• The individual consents to the secondary use or disclosure;
• The individual would reasonably expect the secondary use or disclosure and it is related to the primary purpose (for sensitive information, directly related);
• The secondary use or disclosure is required or authorised by or under an Australian law or a court/tribunal order;
• A permitted general situation exists (section 16A — e.g., necessary to lessen or prevent a serious threat to life, health, or public safety; reasonably necessary for enforcement-related activities by an enforcement body; reasonably necessary to locate a missing person);
• For organisations, a permitted health situation exists (section 16B); or
• The entity reasonably believes the use or disclosure is reasonably necessary for one or more enforcement-related activities conducted by, or on behalf of, an enforcement body, and the use or disclosure is consistent with APP 6.2(e).

Comparison to GDPR. Unlike GDPR Article 6(1), which requires the controller to identify one of six discrete lawful bases before processing, the APPs embed lawfulness into a consent-or-compatibility test at the use/disclosure stage. Collection is permissible if reasonably necessary for the entity's functions; further use is permissible if the individual consents, if the individual would reasonably expect it and it is purpose-related, or if an Australian law requires or authorises it. The "reasonably necessary" standard under APP 3 and the "related/directly related" and "reasonable expectation" tests under APP 6 resemble GDPR's legitimate-interests balancing (Article 6(1)(f)) but are applied contextually rather than as a standalone basis, and there is no formal three-part test (legitimate aim, necessity, balancing) or formal legitimate-interests assessment documentation requirement equivalent to a GDPR Recital 47 balancing test.

Enforcement. The Office of the Australian Information Commissioner (OAIC) investigates complaints and can issue determinations requiring an entity to take specified steps (section 52). Civil penalty provisions introduced by the Privacy Legislation Amendment (Enforcement and Other Measures) Act 2022 impose tiered maximum penalties: for an individual, the greater of AUD 2.5 million, three times the value of any benefit obtained, or (if the benefit cannot be determined) 30% of adjusted turnover during the breach period; for a body corporate, the greater of AUD 50 million, three times the value of any benefit obtained, or 30% of adjusted turnover during the breach period (sections 13G and 13H, as amended December 2022). These penalties apply for serious or repeated interferences with privacy.

Cross-border scope. The Privacy Act has extraterritorial effect: it applies to acts done or practices engaged in outside Australia by organisations or small business operators with an "Australian link" (section 5B(1)–(2)). An entity has an Australian link if it is an Australian citizen, a person whose continued presence in Australia is not subject to a time limitation imposed by law, a partnership formed in Australia, or a trust created in Australia (among other criteria). APP 8 imposes additional obligations on cross-border disclosures of personal information to overseas recipients, including a requirement that the disclosing entity take reasonable steps to ensure the overseas recipient does not breach the APPs, or that the individual consents after being expressly informed that APP 8 will not apply, or that the disclosure is required or authorised by law.

Source: Privacy Act 1988 (Cth), sections 5B, 6, 6C, 13G, 13H, 14, 15, 16A, 16B; Schedule 1 (Australian Privacy Principles)

Source: Australian Privacy Principles Guidelines (OAIC)

Statutory definition. The Privacy Act 1988 (Cth) defines "consent" in section 6(1) as "express consent or implied consent." The Act itself provides no further detail on what constitutes valid consent; the detailed requirements are set out in the Australian Privacy Principles Guidelines (APP Guidelines) published by the Office of the Australian Information Commissioner (OAIC), most comprehensively in Chapter B (Key concepts).

When consent is required. Consent is not a general prerequisite for all personal-information handling under the Privacy Act—unlike GDPR, which requires identification of a lawful basis before any processing. Instead, the APPs require consent in specific higher-risk scenarios:

• Collection of sensitive information (APP 3.3): an APP entity may collect sensitive information only if the individual consents and the information is reasonably necessary for the entity's functions or activities, unless a permitted general situation (section 16A) or permitted health situation (section 16B) applies.
• Use or disclosure for a secondary purpose (APP 6.1): once collected for a primary purpose, personal information may be used or disclosed for a different (secondary) purpose only if the individual consents, or if the individual would reasonably expect the secondary use and it is related (or, for sensitive information, directly related) to the primary purpose, or if another statutory exception applies.
• Cross-border disclosure (APP 8.2(b)): an APP entity may disclose personal information to an overseas recipient without complying with APP 8.1's accountability obligation if the entity expressly informs the individual of the consequences and the individual then consents.

The four elements of valid consent. The OAIC's APP Guidelines articulate a four-part test for valid consent (Chapter B (Key concepts); Chapter 6; Chapter 8):

1. The individual is adequately informed before giving consent. The entity must explain the scope of the proposed collection, use, or disclosure, including who will receive the information and for what purpose. For cross-border disclosures under APP 8.2(b), the entity must expressly inform the individual that if they consent, APP 8.1 will not apply, the entity will not be accountable under the Privacy Act for an overseas recipient's breach of the APPs, and the individual will not be able to seek redress under the Act.
2. The individual gives consent voluntarily. Consent must be a free choice, not coerced or bundled in a way that makes refusal impracticable. Bundled consent—a single request combining several purposes without allowing the individual to choose which to approve—is disfavoured by the OAIC (see Chapter B and the OAIC's public guidance on consent). A bundled request that conditions access to a service on consent to unrelated secondary uses (e.g., requiring agreement to direct marketing as a condition of receiving medical treatment) will not meet the voluntary standard.
3. The individual has the capacity to understand and communicate consent. The Privacy Act does not specify a minimum age for consent. The OAIC guidance provides that an individual under the age of 18 has capacity to consent when they have "sufficient understanding and maturity to understand what is being proposed" (Chapter B, paragraphs B.60–B.61). Where it is not practicable to assess capacity on a case-by-case basis, an APP entity may presume that an individual aged 15 or over has capacity to consent unless there is something to suggest otherwise. For younger individuals or those lacking capacity, a parent or guardian may consent on their behalf.
4. Consent is current and specific. The OAIC recommends that consent relate to a specific purpose and remain current; consent given years earlier for one purpose will not automatically authorise a new, materially different use. The OAIC has recommended (in its 2020 submission on the Privacy Act Review) that the Act be amended to include an express right to withdraw consent and a requirement that entities notify individuals of this right.

Express versus implied consent. Express consent is consent that is "clearly and unmistakably stated" (Chapter B and OAIC guidance). It may be communicated orally, in writing, electronically, or in any other form, provided it is clearly communicated. Written and electronic records of express consent are strongly preferred for evidentiary purposes.

Implied consent requires communication and understanding between the entity and the individual; it may be inferred from the individual's conduct and the entity's conduct in the circumstances. The OAIC states: "If the discussion has provided the individual with an understanding about how their health information may be used, then it would be reasonable for the health service provider to rely on implied consent" (former OPC Guidelines on Privacy in the Private Health Sector, cited in ALRC Report 108 at paragraph 62.80). Implied consent is context-specific and carries a higher evidential burden; entities relying on implied consent must be able to demonstrate that the individual, in the circumstances, would reasonably have understood the proposed handling and agreed to it.

Opt-out as a route to implied consent. The OAIC recognises that in some circumstances an entity may assume implied consent where it offers an opt-out mechanism: the entity writes to the individual stating that it will use or disclose personal information for a specified secondary purpose unless the individual opts out within a stated period (e.g., 30 days). For this to constitute valid implied consent, the OAIC requires (from its public guidance on consent):

• The opt-out option was presented clearly and prominently and the entity can be reasonably sure the individual saw it.
• The individual was given sufficient information about what will happen if they do not opt out.
• The opt-out option was freely available and not bundled with other purposes.
• It was easy for the individual to opt out (little effort, free or low cost).
• The results of failing to opt out are not serious for the individual.

If these conditions are not met, silence or inaction will not constitute consent.

Comparison to GDPR. The Australian consent standard shares certain features with GDPR Article 7 (freely given, specific, informed, unambiguous indication of the data subject's wishes) but is applied selectively rather than as a universal lawful basis. The GDPR requires affirmative action (pre-ticked boxes do not constitute consent); the Privacy Act does not expressly prohibit pre-ticked boxes but the OAIC's four-element test—particularly the requirement that consent be voluntary and clearly communicated—would call into question any mechanism that does not involve active, informed choice. The GDPR mandates an explicit right to withdraw consent (Article 7(3)); the Privacy Act does not, though the OAIC has recommended legislative amendment to this effect and in practice encourages entities to provide clear withdrawal mechanisms.

Source: Privacy Act 1988 (Cth), section 6(1) (definition of consent)

Source: Australian Privacy Principles Guidelines, Chapter B (Key concepts) — consent, capacity of individuals under 18

Source: OAIC public guidance: Consent to the handling of personal information

Function and scope. Section 16A of the Privacy Act 1988 (Cth) defines seven permitted general situations that operate as statutory exceptions to the consent requirements and purpose-compatibility restrictions of the Australian Privacy Principles. When a permitted general situation exists, an APP entity may:

• Collect sensitive information without consent under APP 3.4(b)–(c), even where the information is reasonably necessary for the entity's functions (the dual consent + reasonable-necessity requirement of APP 3.3 does not apply);
• Use or disclose personal information for a secondary purpose without consent under APP 6.2(c), even where the secondary use is not related to the primary purpose and the individual would not reasonably expect it; and
• Disclose personal information to an overseas recipient under APP 8.2(d) without complying with APP 8.1's accountability obligation, and use or disclose a government related identifier under APP 9.2(d) in circumstances that would otherwise be prohibited.

The permitted general situations are intended to accommodate essential public-interest activities and rights of the entity or third parties that would be frustrated if consent or purpose-compatibility were strictly required. The existence of a permitted general situation does not compel an entity to collect, use, or disclose; the entity remains free to comply with the APPs even when an exception applies.

The seven permitted general situations. Section 16A(1) sets out the situations in a table format. The table specifies, for each situation, which entities may rely on it (all APP entities, agencies only, or the Defence Force only), what information the exception covers, and the conditions that must be satisfied. The Office of the Australian Information Commissioner (OAIC) publishes detailed guidance on each situation in Chapter C (Permitted general situations) of the Australian Privacy Principles Guidelines. The seven situations are:

1. Serious threat to life, health, safety, or public health or safety (section 16A(1), Item 1). Any APP entity (agency or organisation) may collect, use, or disclose personal information where:

• It is unreasonable or impracticable to obtain the individual's consent; and
• The entity reasonably believes that the collection, use, or disclosure is necessary to lessen or prevent a serious threat to the life, health, or safety of any individual, or to public health or safety.

The OAIC guidance explains that "reasonably believes" is a subjective test constrained by what a reasonable person in the entity's position would believe, given what the entity knows or ought to know. "Necessary" is an objective test: a reasonable person, properly informed, would agree that the handling is necessary (not merely helpful, desirable, or convenient). "Serious threat" must be serious in nature and does not need to be imminent (the former Information Privacy Principle 10 requirement of imminence was removed in the 2014 APP reform). This exception is commonly invoked for emergency medical treatment without consent, disclosure to law enforcement or emergency services during a crisis, and public-health measures (e.g., contact-tracing during a pandemic).

2. Suspected unlawful activity or serious misconduct (section 16A(1), Item 2). Any APP entity may collect, use, or disclose personal information where:

• The entity has reason to suspect that unlawful activity or misconduct of a serious nature that relates to the entity's functions or activities has been, is being, or may be engaged in; and
• The entity reasonably believes that collection, use, or disclosure is necessary in order for the entity to take appropriate action in relation to the matter.

"Unlawful activity" is not defined but the OAIC guidance (Chapter C, paragraph C.16) states that it includes activity that is criminal, illegal, or prohibited by law, and can include unlawful discrimination or harassment, but does not include breach of contract. Examples include criminal offences, unlawful discrimination, and trespass. "Serious misconduct" captures non-criminal behaviour that is nevertheless serious in nature. The OAIC notes (Chapter C, paragraph C.15) that this exception is intended to apply to an APP entity's internal investigations about activities within or related to the entity. "Appropriate action" includes conducting an investigation, making a report to a law-enforcement body, or taking disciplinary or remedial action. This exception is commonly used by employers investigating employee misconduct, financial institutions conducting fraud investigations, and professional bodies investigating ethical breaches.

3. Missing persons (section 16A(1), Item 3). Any APP entity may collect, use, or disclose personal information where:

• The entity reasonably believes that the collection, use, or disclosure is reasonably necessary to assist any APP entity, body, or person to locate a person who has been reported as missing; and
• The collection, use, or disclosure complies with rules made by the Commissioner under section 16A(2).

The OAIC has not yet issued rules under section 16A(2) as of June 2026. The OAIC guidance (Chapter C, paragraph C.23) states that in the absence of rules, APP entities must exercise their own judgement about whether the handling is reasonably necessary to assist in locating a missing person, and should be mindful of the potential harm to the missing person or others if the information is misused. This exception is intended for use by police, search-and-rescue organisations, and entities assisting family members in locating a missing person.

4. Legal or equitable claims (section 16A(1), Item 4). Any APP entity may collect, use, or disclose personal information where the collection, use, or disclosure is reasonably necessary for the establishment, exercise, or defence of a legal or equitable claim.

"Reasonably necessary" is an objective test. "Legal or equitable claim" includes claims in litigation, arbitration, tribunal proceedings, administrative review, and negotiated settlement. The OAIC guidance (Chapter C, paragraph C.26) provides that this exception applies at all stages of a claim: pre-litigation investigation, pleadings, discovery, trial, appeal, and enforcement of a judgment. Examples include an insurer using personal information to defend a disputed claim, an employer disclosing employee records in a Fair Work Commission unfair-dismissal proceeding, and a plaintiff's solicitor collecting witness information to establish a negligence claim.

5. Confidential alternative dispute resolution (section 16A(1), Item 5). Any APP entity may collect, use, or disclose personal information where the collection, use, or disclosure is reasonably necessary for the purposes of a confidential alternative dispute resolution (ADR) process.

"Alternative dispute resolution process" is not defined in the Privacy Act. The OAIC guidance (Chapter C, paragraph C.30) explains that ADR includes mediation, conciliation, arbitration, and expert determination, whether conducted under statute, contract, or a professional scheme. The requirement that the ADR be confidential means that the parties have agreed or are bound by statute or rules to keep the process and communications confidential. Examples include disclosure of personal information by a party to a mediator in a Family Court parenting dispute, or disclosure by an employer to a Fair Work ombudsman during a confidential conciliation of a workplace complaint.

6. Diplomatic or consular functions or activities (section 16A(1), Item 6, agencies only). An agency (not an organisation) may collect, use, or disclose personal information where the agency reasonably believes that the collection, use, or disclosure is necessary for the agency's diplomatic or consular functions or activities.

This exception applies only to agencies with diplomatic or consular functions conferred by legislation or an executive instrument (such as the Administrative Arrangements Order). "Diplomatic" and "consular" are not defined in the Privacy Act. The OAIC guidance (Chapter C, paragraphs C.33–C.34) gives examples including: granting a diplomatic visa to a foreign national accredited as a member of the diplomatic staff of a mission to Australia, providing consular assistance to an Australian citizen detained overseas, or negotiating a treaty on behalf of the Australian Government. The Department of Foreign Affairs and Trade is the primary agency relying on this exception.

7. Overseas operations by the Defence Force (section 16A(1), Item 7, Defence Force only). The Defence Force (as defined in section 6(1) of the Privacy Act, which includes the Australian Defence Force and the Australian Defence Force Cadets) may collect, use, or disclose personal information where the Defence Force reasonably believes that the collection, use, or disclosure is necessary for a warlike operation, peacekeeping, civil aid, humanitarian assistance, a medical emergency, a civil emergency, or disaster relief occurring outside Australia and the external Territories.

This exception does not apply to domestic operations. The OAIC guidance (Chapter C, paragraph C.38) explains that "warlike operation" is not defined in the Privacy Act but has its ordinary meaning: an operation involving the use of armed force for a military purpose. Examples include a peacekeeping deployment to a United Nations mission, disaster relief after a tsunami in the region, or medical assistance provided by ADF personnel during a humanitarian crisis overseas.

Relationship to enforcement-related activities exception in APP 6.2(e). APP 6.2(e) creates an additional, narrower exception for enforcement-related activities conducted by or on behalf of an enforcement body (a law-enforcement agency or a body with functions of investigating or prosecuting offences). This exception applies only to use and disclosure (not collection), only for secondary purposes, and only where the entity reasonably believes the use or disclosure is reasonably necessary for one or more enforcement-related activities. Unlike the permitted general situations, the enforcement-related-activities exception is embedded in APP 6 itself and is not defined in section 16A. The two exceptions operate in parallel: an enforcement body may rely on permitted general situation 2 (unlawful activity or serious misconduct) for internal investigations, and also on APP 6.2(e) for law-enforcement activities.

Source: Privacy Act 1988 (Cth), section 16A (Permitted general situations in relation to the collection, use or disclosure of personal information)

Source: Australian Privacy Principles Guidelines, Chapter C (Permitted general situations)

Source: Australian Privacy Principles Guidelines, Chapter 6 (APP 6 — Use or disclosure of personal information), paragraphs 6.33–6.45

Function and scope. Section 16B of the Privacy Act 1988 (Cth) defines four permitted health situations that operate as statutory exceptions allowing organisations (not agencies) to collect, use, or disclose health information or genetic information without consent and without satisfying the purpose-compatibility restrictions of the Australian Privacy Principles. When a permitted health situation exists, an organisation may:

• Collect sensitive health information without consent under APP 3.4(c), even where the dual consent + reasonable-necessity requirement of APP 3.3 does not apply;
• Use or disclose health information for a secondary purpose without consent under APP 6.2(d), even where the secondary use is not related to the primary purpose and the individual would not reasonably expect it;
• Disclose health information to an overseas recipient under APP 8.2(d) without complying with APP 8.1's accountability obligation; and
• Use or disclose a government related identifier under APP 9.2(e) in circumstances that would otherwise be prohibited.

The permitted health situations apply only to organisations—they do not apply to agencies (government entities). Where an agency needs to handle health information in a health-related context, it must rely on the permitted general situations under section 16A or another APP exception. The Office of the Australian Information Commissioner (OAIC) publishes detailed guidance on each permitted health situation in Chapter D (Permitted health situations) of the Australian Privacy Principles Guidelines.

The existence of a permitted health situation does not compel an organisation to collect, use, or disclose; the organisation remains free to comply with the APPs even when an exception applies.

Situation 1: Collection of health information necessary to provide a health service (section 16B(1)). An organisation may collect health information about an individual if the information is necessary to provide a health service to the individual, and either:

• The collection is required or authorised by or under an Australian law (other than the Privacy Act); or
• The information is collected in accordance with rules established by competent health or medical bodies that deal with obligations of professional confidentiality which bind the organisation.

"Health service" is defined in section 6FB to include an activity performed in relation to an individual that is intended or claimed (expressly or otherwise) to assess, record, maintain, or improve the individual's health; to diagnose, treat, or prevent illness or disability in the individual; or to dispense a prescription drug or medicine to the individual. Examples include general medical practice, specialist medical treatment, hospital care, allied health services (physiotherapy, psychology, dietetics), dental services, pharmacy services, and nursing care (OAIC APP Guidelines, Chapter B (Key concepts)).

"Necessary" is an objective test: a reasonable person, properly informed, would agree that the handling is necessary—not merely helpful, desirable, or convenient (Chapter D, paragraph D.6). In deciding whether the collection is necessary, an organisation should consider if there are reasonable alternatives available, and should collect only the minimum amount of health information needed to provide the service (paragraphs D.8 and D.16).

The Privacy Act does not specify which bodies qualify as "competent health or medical bodies." Common examples include medical boards and other rule-making bodies recognised in an applicable Australian law, such as the Medical Board of Australia (under the Health Practitioner Regulation National Law), the Australian Health Practitioner Regulation Agency (Ahpra), and professional bodies like the Royal Australasian College of Physicians or the Australian Medical Association that publish codes of ethics and professional standards (paragraph D.9).

This exception overlaps with APP 3.4(a), which permits collection of sensitive information (including health information) as required or authorised by law or a court/tribunal order (paragraph D.7).

Situation 2: Collection of health information for research or statistics relevant to public health or public safety (section 16B(2)). An organisation may collect health information about an individual if the collection is necessary for research, or the compilation or analysis of statistics, relevant to public health or public safety, and:

• It is unreasonable or impracticable to obtain the individual's consent; and
• The collection is required by or under an Australian law, or the collection is in accordance with rules established by competent health or medical bodies that deal with obligations of professional confidentiality which bind the organisation, or the collection is in accordance with guidelines approved under section 95A.

The phrase "relevant to public health or public safety" is not defined in the Privacy Act. The OAIC guidance (Chapter D, paragraph D.13) provides illustrative examples: research or the compilation or analysis of statistics relating to communicable diseases, cancer, heart disease, mental health, injury control and prevention, diabetes, and the prevention of childhood diseases.

"Guidelines approved under section 95A" are issued by the National Health and Medical Research Council (NHMRC) or a "prescribed authority" and approved by the Information Commissioner (paragraph D.16). As of June 2026, the NHMRC has issued Guidelines under Section 95 of the Privacy Act 1988 covering certain activities involving personal information for research and public health purposes; organisations relying on section 16B(2) should verify that their activity falls within the scope of the approved guidelines.

This exception overlaps with APP 3.4(a), which permits collection of sensitive information as required or authorised by law (paragraph D.12).

Situation 3: Use or disclosure of health information for research or statistics relevant to public health or public safety (section 16B(3)). An organisation may use or disclose health information about an individual for a secondary purpose if the use or disclosure is necessary for research, or the compilation or analysis of statistics, relevant to public health or public safety, and:

• It is impracticable to obtain the individual's consent to the use or disclosure; and
• The use or disclosure is conducted in accordance with guidelines approved under section 95A; and
• In the case of disclosure, the organisation takes reasonable steps to ensure that the information is de-identified before disclosure.

The requirement to de-identify before disclosure is codified in APP 6.4, which states: "If an organisation collects personal information [under section 16B(2)] … the organisation must take such steps as are reasonable in the circumstances to ensure that the information is de-identified before the organisation discloses it in accordance with [APP 6.1 or 6.2]" (Chapter D, paragraph D.17). "De-identified" is defined in section 6(1): personal information is de-identified if the information is no longer about an identifiable individual or an individual who is reasonably identifiable.

The OAIC guidance emphasises that the "impracticable" standard under section 16B(3) is stricter than "unreasonable or impracticable" under section 16B(2), and that organisations must make a genuine effort to assess whether consent is practicable before relying on this exception (paragraph D.18).

Situation 4: Use or disclosure of genetic information to prevent a serious threat to a genetic relative (section 16B(4)). An organisation may use or disclose genetic information about an individual if:

• The organisation has obtained the information in connection with the provision of a health service to the individual; and
• The organisation reasonably believes that the use or disclosure is necessary to lessen or prevent a serious threat to the life, health, or safety of a genetic relative of the individual; and
• The use or disclosure is conducted in accordance with guidelines approved under section 95AA; and
• In the case of disclosure, the recipient of the information is a genetic relative of the individual.

"Genetic relative" of an individual (the first individual) is defined in section 6(1) to mean another individual who is related to the first individual by blood, including but not limited to a sibling, a parent, or a descendant of the first individual.

"Genetic information" is not defined in the Privacy Act. However, genetic information about an individual is included in the definition of "sensitive information" (section 6(1)), and genetic information that is "about an individual in a form that is, or could be, predictive of the health of the individual or a genetic relative of the individual" is also covered by the definition of "health information." This permitted health situation applies to genetic information whether it is sensitive information or health information (Chapter D, paragraphs D.26 and D.30).

The terms "health service," "necessary," and "reasonably believes" are discussed in Chapter B (Key concepts) of the OAIC Guidelines. The phrase "serious threat to life, health or safety" is discussed in Chapter C (Permitted general situations); the OAIC guidance explains that "serious threat" must be serious in nature but does not need to be imminent (the former requirement of imminence was removed in the 2014 APP reform).

"Guidelines approved under section 95AA" are issued by the NHMRC or a prescribed authority and approved by the Information Commissioner, analogous to the section 95A guidelines but specifically addressing genetic information. As of June 2026, the NHMRC has issued Guidelines for the disclosure of health information to a genetic relative approved under section 95AA of the Privacy Act 1988, which set out the conditions and procedures an organisation must follow to rely on this exception. Organisations proposing to disclose genetic information to a genetic relative under section 16B(4) must comply with the approved guidelines.

Comparison to permitted general situations (section 16A). The permitted health situations in section 16B are narrower and more specialised than the permitted general situations in section 16A. Both sets of exceptions operate in parallel; an organisation may rely on either, depending on which fits the circumstances. Key differences:

• Coverage. Permitted health situations apply only to organisations and only to health information or genetic information. Permitted general situations apply to any APP entity (agency or organisation) and to any personal information.
• Serious-threat exception. Section 16A(1), Item 1 (serious threat to life, health, or safety) applies to any personal information and requires "unreasonable or impracticable" to obtain consent. Section 16B(4) (genetic information to a genetic relative) applies only to genetic information, requires that the organisation "reasonably believes" the threat is serious, and mandates compliance with section 95AA guidelines. An organisation with genetic information may choose the exception that best fits the facts; in practice, section 16B(4) is used when the disclosure is to a blood relative and the threat is predictive or hereditary, while section 16A(1), Item 1 is used for immediate life-threatening situations not limited to genetic relatives.
• Research and public-health activities. Section 16B(2) and (3) create specific pathways for health research and public-health statistics, conditioned on NHMRC-approved guidelines and (for disclosure) de-identification. No equivalent pathway exists under section 16A; agencies conducting health research typically rely on APP 3.4(a) (collection required by law) or APP 6.2(b) (use or disclosure required by law), and organisations rely on section 16B.

Cross-reference to enforcement. The OAIC investigates complaints alleging that an organisation improperly relied on a permitted health situation—for example, by collecting health information for "research" that was in fact direct marketing, or by disclosing genetic information to a person who is not a genetic relative. Civil penalty provisions introduced by the Privacy Legislation Amendment (Enforcement and Other Measures) Act 2022 impose tiered maximum penalties for serious or repeated interferences with privacy: for a body corporate, the greater of AUD 50 million, three times the value of any benefit obtained, or 30% of adjusted turnover during the breach period (sections 13G and 13H). Misuse of a permitted health situation—particularly where an organisation fabricates a research purpose to avoid consent—may result in a determination under section 52 requiring corrective action and, for egregious cases, civil penalty proceedings.

Source: Privacy Act 1988 (Cth), section 16B (Permitted health situations in relation to the collection, use or disclosure of health information)

Source: Australian Privacy Principles Guidelines, Chapter D (Permitted health situations)

Function and scope. Australian Privacy Principle 6 (APP 6) establishes a purpose-limitation principle: once an APP entity collects personal information for a particular purpose (the "primary purpose"), the entity must not use or disclose the information for another purpose (a "secondary purpose") unless one of the exceptions in APP 6.2 applies (APP 6.1). The most widely relied-upon exception is APP 6.2(a), which permits secondary use or disclosure where (i) the individual would reasonably expect the secondary use or disclosure, and (ii) the secondary purpose is related to the primary purpose of collection (or, for sensitive information, directly related to the primary purpose). This two-limb test is the Australian functional equivalent of GDPR legitimate interests (Article 6(1)(f)), embedded within a purpose-compatibility framework rather than as a standalone lawful basis.

APP 6.2(a) is the workhorse exception for everyday secondary processing. It is how organisations justify using personal information for internal analytics, sharing with service providers, disclosing to credit-reporting bodies, or conducting surveys and audits, without obtaining fresh consent for each secondary purpose. Unlike consent (which is always an available alternative under APP 6.2(a)), reasonable expectation and purpose-compatibility are objective tests that an entity must be able to justify if challenged by the Office of the Australian Information Commissioner (OAIC) or in a complaint investigation.

The two-limb test. Both conditions must be satisfied for APP 6.2(a) to apply. The OAIC's Australian Privacy Principles Guidelines, Chapter 6 (APP 6 — Use or disclosure of personal information), set out the detailed interpretation of each limb.

Limb 1: The individual would reasonably expect the secondary use or disclosure. "Reasonably expect" is an objective test that has regard to what a reasonable person, who is properly informed, would expect in the circumstances (Chapter B (Key concepts), paragraphs B.108–B.115). It is not a subjective test of what the particular individual actually anticipated; it is what a reasonable person in the individual's position would expect, given the context and the information provided to them at or before collection.

The OAIC guidance (Chapter 6, paragraphs 6.19–6.22) identifies factors that support a finding of reasonable expectation:

• The entity notified the individual of the secondary purpose under APP 5.1. APP 5 requires an APP entity that collects personal information to take reasonable steps to notify the individual of the purposes for which the information is collected. If the entity's APP 5 collection notice expressly stated that the information may be used or disclosed for a particular secondary purpose, and the entity's APP Privacy Policy (under APP 1) also describes this practice, the individual would likely reasonably expect that secondary purpose. The OAIC states: "This may create a reasonable expectation that the personal information will be used or disclosed for a secondary purpose, of relevance to the exception in APP 6.2(a)" (Chapter 5 (APP 5), paragraph 5.16).

• The secondary purpose is a normal internal business practice. The OAIC provides illustrative examples of secondary purposes that would generally be within reasonable expectations: auditing, business planning, billing, de-identifying personal information, quality assurance, incident monitoring, and clinical audit (where the individual is a patient in a healthcare setting) (Chapter 6, paragraph 6.21; Guide to Health Privacy, Chapter 3).

• The entity disclosed the secondary purpose in subsequent communications or updated privacy policies. Whether APP 5 notices or privacy policies were updated at a point in time after the collection may also be relevant to the assessment, though the OAIC's recent guidance on AI systems (January 2025) notes that it is more difficult to establish reasonable expectations for materially new and high-risk secondary uses (such as using historic customer data to train generative AI models) where the individual was not informed at the time of collection and the use was not a standard industry practice.

• The context of collection makes the secondary purpose obvious. For example, the OAIC guidance states: "Where an individual provides their personal information to an entity in order to make a complaint, it may be reasonable to expect that the entity may respond publicly to these comments in a way that reveals personal information specifically relevant to the issues that the individual has raised" (Chapter 6, paragraph 6.21, Example [7]). Similarly, where an agency collects personal information for the primary purpose of operating a program, it may be within reasonable expectations to use that information for the secondary purpose of monitoring, evaluating, or managing that program, or conducting follow-up surveys and reporting to Parliamentary Committees (OAIC, Conducting surveys guidance; Chapter 6, Example [8]).

Factors that undermine reasonable expectation include:

• The individual was not informed of the secondary purpose at collection or in a privacy policy. The OAIC's guidance on AI and chatbots (January 2025) states: "It may be difficult to establish reasonable expectations if customers were not specifically notified of these disclosures, given the significant public concern about the privacy risks of chatbots" (Guidance on privacy and the use of commercially available AI products).

• The secondary purpose is materially different from the primary purpose and not a standard industry practice. The OAIC's guidance on developing and training generative AI models (November 2024) emphasises: "Given the unique characteristics of AI technology, the significant harms that may arise from its use and the level of community concern around the use of AI, in many cases it will be difficult to establish that such a secondary use was within reasonable expectations" (Guidance on privacy and developing and training generative AI models, paragraph 10).

• The secondary use involves sensitive information and was not disclosed at collection. Sensitive information (defined in section 6(1) of the Privacy Act to include health information, racial or ethnic origin, political opinions, religious or philosophical beliefs, sexual orientation, biometric information, genetic information, criminal-record information, and trade-union membership) attracts higher protection under the APPs and would generally require more rigorous transparency to establish reasonable expectation.

Limb 2: The secondary purpose is related (or, for sensitive information, directly related) to the primary purpose. The second limb is a purpose-compatibility test. The OAIC defines these terms as follows (Chapter 6, paragraphs 6.23–6.28):

• "Related" (for non-sensitive personal information): A related secondary purpose is one that is connected to or associated with the primary purpose. The OAIC provides illustrative examples:
• An agency collects personal information for the primary purpose of administering an individual's employment and then uses it for the secondary purpose of investigating a complaint by the individual about working conditions. The investigation is related to the primary purpose of employment administration and would be within the individual's reasonable expectations (Example [13]).
• An entity uses personal information for the purpose of de-identifying the information. This is related to the primary purpose of collection (paragraph 6.21, Example [10]; also paragraph 6.28).

• "Directly related" (for sensitive information): A directly related secondary purpose is one that is closely associated with the primary purpose, even if it is not strictly necessary to achieve that primary purpose (paragraph 6.26). The threshold is higher than "related." The OAIC provides a healthcare example:
• A health service provider collects health information (sensitive information) for the primary purpose of providing treatment. The provider then decides, for ethical and therapeutic reasons, that they cannot treat the individual, and advises another provider at the medical clinic of the individual's need for treatment and of the provider's inability to provide that treatment. This disclosure to the other provider is directly related to the purpose for which the information was collected and would be within the individual's reasonable expectations (Example [14], paragraph 6.27).

The OAIC's Guide to Health Privacy (Chapter 3) provides further healthcare-specific examples of directly related secondary purposes that would typically be within a patient's reasonable expectations in a health context (provided the patient was informed or would reasonably anticipate the practice):

• Disclosure of health information within a multi-disciplinary treating team (provided the patient understands who is part of the team and what information will be shared).
• Billing or debt recovery (consistent with confidentiality obligations).
• Management, funding, complaint-handling, planning, evaluation, accreditation, quality assurance, incident monitoring, or clinical audit activities (though de-identified information should be used where practicable).
• Disclosure to a medical expert, insurer, medical defence organisation, or lawyer for the purpose of addressing liability, indemnity arrangements, legal proceedings, or provision of legal advice.
• Disclosure for quality-assurance audits (e.g., as part of vocational registration under Medicare), where it is directly related to providing healthcare and the patient would reasonably expect the disclosure.

Interaction with consent (APP 6.2(a)(i)). APP 6.2(a)(i) permits secondary use or disclosure where the individual has consented to the secondary use or disclosure. Consent and reasonable expectation are alternative exceptions; an entity may rely on either. Where an entity cannot clearly establish reasonable expectation and purpose-compatibility (for example, when the secondary purpose is novel, high-risk, or materially different from the primary purpose), the OAIC recommends seeking express consent or offering a meaningful and informed opt-out (OAIC guidance on AI, November 2024 and January 2025).

Comparison to GDPR. The reasonable-expectation and purpose-compatibility test under APP 6.2(a) shares certain structural features with GDPR Article 6(4) (assessment of compatible further processing) and the legitimate-interests balancing test under Article 6(1)(f), but differs in important respects:

• No formal balancing-test documentation. Unlike GDPR legitimate interests, which requires the controller to conduct and document a three-part test (legitimate aim, necessity, balancing of interests and fundamental rights), the APPs embed the compatibility and expectation inquiry into the APP 6.2(a) exception itself. There is no statutory requirement to prepare a formal "legitimate-interests assessment" or equivalent documented balancing test under the Privacy Act, though the OAIC recommends that entities be able to justify their reliance on APP 6.2(a) if challenged, and document their reasoning for evidentiary purposes.

• Purpose-first architecture. APP 6 requires the entity to identify the primary purpose at collection (the purpose the individual provided the information for, or the function for which it was reasonably necessary to collect it), and then assess secondary purposes against that primary purpose. GDPR Article 5(1)(b) imposes a similar purpose-limitation principle, but the lawful-basis analysis under Article 6(1) is conducted upfront rather than at the use/disclosure stage.

• Sensitive information receives a higher bar ("directly related"). The GDPR equivalent is the special-category data regime under Article 9, which imposes a separate enumerated-lawful-basis requirement (explicit consent, employment law, vital interests, etc.) and does not allow Article 6(1)(f) legitimate interests for special-category data at all (Article 9(2) does not list legitimate interests). The APP framework is less restrictive: sensitive information may be used or disclosed for a directly related secondary purpose if the individual would reasonably expect it, without requiring a separate statutory basis.

Enforcement and evidentiary burden. The OAIC investigates complaints alleging that an entity improperly relied on APP 6.2(a) — for example, by using personal information for a secondary purpose that was not related to the primary purpose, or by asserting reasonable expectation where the entity had not disclosed the secondary purpose in its APP 5 notice or privacy policy and the purpose was not a standard internal practice. In a complaint investigation, the entity bears the evidentiary burden to demonstrate that both limbs of APP 6.2(a) were satisfied. The OAIC states: "It is the responsibility of the entity to be able to justify that its conduct was reasonable" (Chapter B (Key concepts), paragraph B.107). An entity that cannot produce evidence of notification (e.g., an archived copy of the APP 5 collection notice in effect at the time of collection, showing that the secondary purpose was disclosed) or evidence that the secondary purpose was related to the primary purpose will be found to have breached APP 6.

Civil penalty provisions introduced by the Privacy Legislation Amendment (Enforcement and Other Measures) Act 2022 impose tiered maximum penalties for serious or repeated interferences with privacy: for a body corporate, the greater of AUD 50 million, three times the value of any benefit obtained, or 30% of adjusted turnover during the breach period (sections 13G and 13H). Misuse of APP 6.2(a) — particularly where an entity repurposes personal information for commercial gain (e.g., selling customer data to third-party marketers or using it to train AI models) without having disclosed the practice at collection and without a reasonable-expectation or purpose-compatibility justification — may result in a determination under section 52 requiring corrective action and, for egregious cases, civil penalty proceedings.

Cross-reference to enforcement-related activities exception (APP 6.2(e)). APP 6 includes a parallel exception for enforcement-related activities conducted by or on behalf of an enforcement body (a law-enforcement agency or a body with functions of investigating or prosecuting offences): where the entity reasonably believes that the secondary use or disclosure is reasonably necessary for one or more enforcement-related activities, the entity may use or disclose personal information without satisfying the reasonable-expectation or purpose-compatibility tests (APP 6.2(e)). This exception is narrower than APP 6.2(a) (it applies only to enforcement bodies and only for enforcement-related activities), and is discussed separately in the OAIC Guidelines Chapter 6, paragraphs 6.54–6.66.

Source: Privacy Act 1988 (Cth), Schedule 1 — Australian Privacy Principles, APP 6.1 and APP 6.2(a)

Source: Australian Privacy Principles Guidelines, Chapter 6 (APP 6 — Use or disclosure of personal information), paragraphs 6.13–6.28

Source: Australian Privacy Principles Guidelines, Chapter B (Key concepts) — Reasonable and reasonably, paragraphs B.108–B.115

Statutory requirement and updated 2026 OAIC guidance. Australian Privacy Principle 3 (APP 3), Schedule 1 to the Privacy Act 1988 (Cth), continues to prohibit collection of personal information by organisations unless the information is reasonably necessary for, or (for agencies) directly related to, one or more of the entity's functions or activities. APP 3.2 applies to organisations; APP 3.1 applies to agencies. No statutory amendments to APP 3 have been enacted since the last update. However, the Office of the Australian Information Commissioner (OAIC) revised its official APP Guidelines in May 2026, releasing Version 1.2 of Chapter 3, which introduces substantive clarifications practitioners should note.

2026 OAIC guidance enhancements:

• The OAIC has added detailed examples of how APP 3 applies to emerging digital practices, including facial recognition, scraping of public data, use of tracking pixels, and AI-generated inferences. These examples clarify that collection by any automated or AI process is fully subject to the "reasonably necessary" test.
• Paragraphs 3.26–3.28 now explicitly require entities to take a proportional, data minimisation approach: collection must be justifiable as necessary, not merely desirable or convenient, and must be the minimum amount of data required for a defined function.
• The Guidelines include a decision flow-chart for determining whether collection satisfies both the necessity and minimisation requirements—useful for compliance documentation.
• Enforcement experience from recent OAIC determinations (referenced in the 2026 update) stresses the risk of over-collection (e.g., biometric scans for retail security, bulk data acquisitions for analytics, and retention of incidentally captured audio/video). Collections not clearly linked to an explicit business function or not reduced to the minimum required are likely to breach APP 3.
• The burden of proof remains with the APP entity to be able to demonstrate, with contemporaneous evidence, why the collection was "reasonably necessary."

Proportionality and limitation reaffirmed. The OAIC makes clear that vague business purposes (e.g., "future analytics opportunities") are not sufficient to justify open-ended collection. Instead, entities must justify why each element of data is required for a current and specific function or activity, referencing their own public documentation (constitution, annual reports, privacy policy, etc.). The collection gateway is now operationalised as a practical compliance triage point: over-collection increases risk, and the guidance provides new detailed scenarios to help entities distinguish lawful necessity from convenience.

No change to the role of APP 5 or the intersection with secondary-use rules (APP 6). Entities must continue to align their collection notices (APP 5) with the specific functional justification relied on under APP 3, and cannot use broad collection notices to paper over weak necessity justifications. If a proposed use or disclosure falls outside the primary purpose or was not notified, a new lawful basis must be found under APP 6 or an exception.

Comparison to GDPR still accurate: The structure and logic of the "reasonably necessary" and minimisation requirements continue to parallel GDPR Article 5(1)(c), but Australian law applies these at the collection gateway rather than as a universal principle.

Enforcement and penalties. The 2026 OAIC update reinforces that breach of APP 3 can trigger OAIC investigation, determinations, and substantial penalties for serious or repeated violations—including, for corporates, the greater of AUD 50 million, three times the benefit, or 30% of turnover during the breach period (ss. 13G, 13H).

Summary of 2026 material update: While the legislative text is unchanged, as of May 2026 the OAIC's official guidance materially deepens its expectations around proportionality, justification, and technology-driven collection. Practitioners should review the new examples and compliance flow-chart for current best practice.

Source: Privacy Act 1988 (Cth), Schedule 1, Australian Privacy Principle 3 (Collection of solicited personal information) Source: Australian Privacy Principles Guidelines, Chapter 3 (APP 3 — Collection of solicited personal information), Version 1.2 (updated 13 May 2026) Source: OAIC, Guide to privacy regulatory action

Statutory gateway. APP 3.2 of the Privacy Act 1988 (Cth), set out in Schedule 1 to the Act, provides that an organisation must not collect personal information (other than sensitive information) unless the information is reasonably necessary for one or more of the entity's functions or activities. (Agencies are governed by APP 3.1, which requires information to be reasonably necessary or directly related to a function or activity.) This "reasonably necessary" threshold is the foundational gateway for lawful collection under the Australian Privacy Principles. Unless an organisation can demonstrate that personal information is reasonably necessary for a function or activity it performs, the collection breaches APP 3 and constitutes an interference with privacy (section 13 of the Privacy Act).

Objective test. The Office of the Australian Information Commissioner (OAIC) states in Chapter B (Key concepts) of the Australian Privacy Principles Guidelines that "reasonably necessary" is an objective test based upon reason and capable of sound explanation. What is reasonable is a question of fact in each individual case. It is an objective test that has regard to how a reasonable person, who is properly informed, would be expected to act in the circumstances. What is reasonable can be influenced by current standards and practices. It is the responsibility of an APP entity to be able to justify that its conduct was reasonable (Chapter B, paragraphs B.107, B.108, B.115, B.119, and B.121). Chapter 3 (APP 3) elaborates: the test requires the APP entity to be able to justify that the particular collection is reasonably necessary (Chapter 3, paragraph 3.17).

"Necessary" versus "helpful, desirable, or convenient." The OAIC guidance on the permitted general situations (Chapter C) explains that "necessary" is an objective test: a reasonable person, properly informed, would agree that the handling is necessary. It is not enough that the handling is helpful, desirable, or convenient (Chapter C, paragraph C.8). While this commentary appears in the context of section 16A permitted general situations, the OAIC cross-references the same objective standard in Chapter 3 when interpreting the "reasonably necessary" requirement under APP 3.2. The entity must be able to demonstrate that the information is required to achieve the function or activity, not merely that it would make the function easier or more efficient.

Proportionality and data minimisation. The OAIC states in Chapter 3 (APP 3 — Collection of solicited personal information) that proportionality is implicit in the requirement that personal information collection be reasonably necessary for an entity's functions and activities: entities must ensure proportionality in their collection of personal information. Entities should adopt a data minimisation approach and limit collection of personal information to the minimum amount necessary in the circumstances. Over-collection may contravene the requirements of APP 3, as well as increase risks to the security of personal information and lead to greater potential harm in the event of a data breach (Chapter 3, paragraphs 3.4, 3.5, and 3.6; updated 13 May 2026). The OAIC's Guide to Securing Personal Information reinforces this point: under APP 3, entities should only collect personal information that is reasonably necessary (and for agencies, directly related) to carry out their functions or activities. Over-collection can increase risks for the security of personal information. Therefore, the first step in managing the security of personal information is to ask whether the collection is reasonably necessary to carry out the entity's functions or activities. If it is, entities should then consider, even if they can collect it, should it be collected? (OAIC Guide to Securing Personal Information, paragraphs 9.15, 9.16, 9.17, and 9.18).

Application to organisations' "functions or activities." An organisation's functions or activities include the purposes for which the organisation exists and the things it does to achieve those purposes. This encompasses business, operational, regulatory, and administrative functions. The OAIC notes that an organisation's functions or activities are not defined in the Privacy Act but are ordinarily evident from the organisation's constituting documents (such as a company constitution or partnership deed), business plans, annual reports, websites, and public statements (Chapter 3, paragraphs 3.12 and 3.13). When assessing whether a collection is reasonably necessary, the entity should first identify the relevant function or activity, then ask whether the particular personal information is necessary to carry out that function.

Examples from OAIC guidance. The OAIC provides examples of collection scenarios in Chapter 3:

• Necessary: A health service provider collecting health information about an individual in order to provide a health service to that individual (this would also fall within the permitted health situation under section 16B(1); Chapter 3, paragraph 3.48 and cross-references).
• May be unnecessary (context-dependent): Collecting sensitive information using a facial recognition system. The OAIC states that this might be lawful under a permitted general situation (serious threat to life, health, or safety) if the collection is for the limited purpose of combatting very significant retail crime, violence, abuse, and intimidation, in a security environment that poses unique challenges—for example, where products on sale can be readily accessed by individuals and used as a weapon. However, outside such exceptional circumstances, facial-recognition collection would need to satisfy APP 3.3 (consent and reasonable necessity for sensitive information) or another statutory exception (Chapter 3, paragraph 3.48).

The OAIC's March 2026 guidance on age assurance technologies applies the proportionality requirement: APP entities should consider whether the collection of personal information is reasonably necessary for age assurance purposes, which means considering proportionality, taking a data minimisation approach, and choosing the least intrusive way to achieve a clearly defined age result or outcome. The fact that a particular age assurance method or combination of methods is available, convenient, or desirable should not be relied on to establish necessity. It is the responsibility of the entity providing the service to justify that the age assurance method adopted is reasonably necessary (OAIC Privacy Guidance on Age Assurance Technologies, 17 March 2026, pages 4 and 5).

Relationship to "directly related to" for agencies. APP 3.1 imposes a dual standard for agencies: an agency must not collect personal information unless the information is reasonably necessary or directly related to one or more of the entity's functions or activities. "Directly related to" is a broader and more permissive standard than "reasonably necessary." Information is directly related if it has a clear and direct connection to the agency's function or activity, even if it is not strictly necessary. The OAIC notes that the "directly related to" limb was retained for agencies in recognition that many agency functions are conferred by statute or the executive, and agencies may need to collect contextual information to discharge those statutory functions effectively (Chapter 3, paragraphs 3.8, 3.9, 3.10, and 3.11). Organisations, by contrast, must satisfy the stricter "reasonably necessary" standard and cannot rely on the "directly related to" alternative.

Burden of justification and accountability. The OAIC emphasises that it is the responsibility of an APP entity to be able to justify that its conduct—including any collection of personal information—was reasonable (Chapter B, paragraph B.23). This means the entity should maintain contemporaneous documentation of the entity's assessment: why the information is needed, what function or activity it supports, what alternatives were considered, and why those alternatives are insufficient or impracticable. While the Privacy Act does not mandate a formal written necessity assessment for every collection, entities that cannot produce evidence supporting the reasonableness of a collection will be at a significant disadvantage if the OAIC investigates a complaint alleging over-collection in breach of APP 3.2. The OAIC will expect the entity to demonstrate, with evidence, that the collection was objectively reasonable in the circumstances.

Comparison to GDPR necessity. The "reasonably necessary" standard under APP 3.2 serves a similar gatekeeper function to the GDPR's necessity requirement, which appears in the data minimisation principle (Article 5(1)(c) GDPR: personal data shall be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed") and as a condition in several of the Article 6(1) lawful bases (for example, Article 6(1)(f) requires processing to be "necessary for the purposes of the legitimate interests pursued by the controller"). However, the Australian standard is applied as a threshold collection test under APP 3 rather than as a condition layered onto a chosen lawful basis. Practitioners advising organisations with operations in both Australia and the European Union should note that evidence prepared for one regime—such as a documented necessity justification, a list of alternative less-intrusive means considered, and a proportionality assessment—will often be directly useful for the other, even though the formal legal tests differ.

Enforcement. Breach of APP 3.2—collecting personal information that is not reasonably necessary—is an interference with privacy under section 13 of the Privacy Act. The OAIC may investigate a complaint or initiate an own-motion investigation under Part V. If the OAIC determines that an interference has occurred, it may issue a determination under section 52 requiring the entity to take specified steps, such as ceasing the collection, destroying or de-identifying the over-collected information, publishing an apology, or paying compensation to affected individuals. Civil penalty provisions introduced by the Privacy Legislation Amendment (Enforcement and Other Measures) Act 2022 apply to serious or repeated interferences with privacy: for a body corporate, the maximum penalty is the greater of AUD 50 million, three times the value of any benefit obtained through the breach, or 30% of the entity's adjusted turnover during the breach period (sections 13G and 13H, as amended December 2022). Systematic over-collection—collecting unnecessary personal information from many individuals over an extended period—may constitute a repeated interference attracting civil penalty proceedings in the Federal Court.

Source: Privacy Act 1988 (Cth), Schedule 1, Australian Privacy Principle 3 (Collection of solicited personal information); sections 13, 13G, 13H, 52

Source: Australian Privacy Principles Guidelines, Chapter B (Key concepts) — "Reasonable" and "reasonably" (paragraphs B.107–B.108, B.115–B.121, B.119, B.121, B.23)

Source: Australian Privacy Principles Guidelines, Chapter 3 (APP 3 — Collection of solicited personal information) — proportionality and data minimisation (paragraphs 3.4–3.6, 3.17); organisations' functions or activities (paragraphs 3.12–3.13); agencies' "directly related to" standard (paragraphs 3.8–3.11); examples (paragraph 3.48)

Source: Australian Privacy Principles Guidelines, Chapter C (Permitted general situations) — "necessary" test (paragraph C.8)

Source: OAIC, Guide to Securing Personal Information (paragraphs 9.15–9.18)

Source: OAIC, Privacy guidance on age assurance technologies, 17 March 2026, pages 4–5

Statutory basis. Australian Privacy Principle 6.2(e) (Schedule 1 to the Privacy Act 1988 (Cth)) allows an APP entity to use or disclose personal information for a purpose other than the primary purpose of collection (a “secondary purpose”) without consent where the entity “reasonably believes that the use or disclosure is reasonably necessary for one or more enforcement-related activities conducted by, or on behalf of, an enforcement body.” This exception applies only to use or disclosure, not to initial collection (which is governed by the APP 3 “reasonably necessary” standard).

Who is an “enforcement body”? Section 6(1) of the Privacy Act defines “enforcement body” to include federal and state police, the Australian Crime Commission, customs, anticorruption bodies, the Australian Prudential Regulation Authority (APRA), the Australian Securities and Investments Commission (ASIC), the Immigration Department, and certain other bodies with investigation or prosecution powers. Organisations and even some government agencies are not enforcement bodies unless specifically listed.

What are “enforcement-related activities”? Section 6(1) defines these broadly, including: prevention, detection, investigation, prosecution, or punishment of criminal offenses, breaches of law imposing a penalty or sanction, or serious misconduct; preparation or conduct of court or tribunal proceedings; execution or implementation of orders of a court or tribunal; or the protection of public revenue.

Key requirements:

• Reasonable belief: The entity must have a reasonable belief that the use or disclosure is necessary for the enforcement activity. This is an objective threshold—the entity must be able to justify the belief as reasonable under the circumstances (see OAIC Guidelines, Ch. 6 para. 6.63). Mere assertion or internal policy is not enough; evidence and documentation are critical, especially if challenged.
• No consent required: The exception is available even where the individual does not consent and would not reasonably expect the secondary use or disclosure. However, the entity cannot use this exception if another APP provision applies; it is specifically for secondary uses/disclosures by or on behalf of enforcement bodies in the listed areas.
• Documentation and notification: While the Privacy Act does not impose an explicit recordkeeping requirement for each disclosure under APP 6.2(e), agencies and organisations are strongly advised—by the OAIC and sectoral codes—to document the circumstances, the enforcement body involved, and why the entity considered the use/disclosure necessary.

OAIC guidance and complaints: The OAIC states (Chapter 6.62–6.66) that over-use or general reliance on this exception—especially “pre-emptive” or “routine” large-scale disclosure to enforcement bodies without clear necessity—will be closely scrutinized. Example scenarios include disclosures to police for criminal investigations, to ASIC in financial regulatory matters, and to government bodies in Centrelink, welfare, or immigration enforcement contexts.

Relationship to permitted general situations (s. 16A): While APP 6.2(e) is only for enforcement bodies, s. 16A permitted general situations cover broader scenarios (e.g. threats to life/health, suspected unlawful activity). Agencies must assess which fits. Entities must not “default” to 6.2(e) for convenience or for disclosures not strictly relating to enforcement.

Enforcement and penalties: Inadequate justification or systemic misuse of 6.2(e) may lead to findings of privacy interference (s. 13), OAIC determinations (s. 52), and (for serious or repeated contraventions) civil penalties: for bodies corporate, the greater of AUD 50 million, three times any benefit, or 30% of adjusted turnover (s. 13G, as amended 2022).

Source: Privacy Act 1988 (Cth), Schedule 1, APP 6.2(e) and sections 6(1), 13, 13G

Source: Australian Privacy Principles Guidelines, Chapter 6 (APP 6 — Use or disclosure of personal information), paras 6.54–6.66

Statutory groundwork. Australian Privacy Principle 9 (APP 9), set out in Schedule 1 to the Privacy Act 1988 (Cth), imposes a special restriction on "government related identifiers"—numbers or codes assigned to an individual by government agencies, such as Medicare numbers, driver licence numbers, passport numbers, Centrelink identifiers, and Tax File Numbers. APP 9 is triggered when an organisation (not agency) that is subject to the APPs (an APP entity) uses or discloses a government related identifier of an individual as part of its operations.

The general prohibition. APP 9.1 provides that an organisation must not adopt a government related identifier of an individual as its own identifier, nor use or disclose such an identifier, unless one of the exceptions in APP 9.2 applies. The rule aims to limit the risk of widespread identity tracking and linkage across different contexts. An “identifier” is defined broadly in section 6(1) of the Act and expressly covers numbers or other codes assigned by Commonwealth, State or Territory government agencies (APP 9.3 enumerates examples).

The six statutory exceptions (APP 9.2). Organisations may use or disclose a government related identifier only if one of the following applies:

• the use/disclosure is necessary so the organisation can fulfill its obligations to a government agency or contractor (APP 9.2(a));
• the individual has consented (APP 9.2(b));
• the use/disclosure is required or authorised by or under Australian law or a court/tribunal order (APP 9.2(c));
• use/disclosure is reasonably necessary for enforcement-related activities by or on behalf of an enforcement body (APP 9.2(d));
• a permitted general situation exists (see s. 16A; APP 9.2(e));
• a permitted health situation applies (for health information; APP 9.2(f)).

Enforcement and practical pitfalls. The Office of the Australian Information Commissioner (OAIC) has emphasised that organisations frequently breach APP 9 where they unnecessarily record, replicate, or share identifiers such as Medicare or driver’s licence numbers, especially in digital onboarding or KYC (Know Your Customer) processes. Over-collection and subsequent use/disclosure of a government related identifier—beyond what is strictly necessary for statutory or contractual compliance—creates risk of regulatory enforcement (OAIC Guide: "APP 9 – Adoption, use or disclosure of government related identifiers").

Comparison to GDPR. Unlike the GDPR, which does not single out government-assigned identifiers for standalone protection but applies heightened rules for national IDs by member-state law under Article 87, the Australian regime requires all organisations to treat these identifiers as particularly sensitive. The OAIC has issued determinations requiring destruction of identifiers and payment of compensation where organisations used or disclosed government related identifiers outside the permitted exceptions (see also OAIC determination summaries).

OAIC guidance highlights:

• Organisations should only collect, use, or disclose government related identifiers when there is a clear, demonstrable need—usually due to statutory, regulatory, or contractual obligations.
• Consent (APP 9.2(b)) must be informed and voluntary, and not bundled with unrelated consents.
• Documentation is critical—organisations must be able to justify any use or disclosure of government related identifiers.

Breach of APP 9 is an “interference with privacy” under the Act and may result in OAIC investigation, enforceable undertakings, mandatory corrective action, or civil penalties for serious or repeated breaches (Privacy Act s. 13, s. 13G).

Source: Privacy Act 1988 (Cth), Schedule 1, APP 9; sections 6(1), 13, 13G Source: Australian Privacy Principles Guidelines, Chapter 9 (APP 9 – Adoption, use or disclosure of government related identifiers)

Statutory framework. The “required or authorised by or under Australian law or a court/tribunal order” exception appears repeatedly in the Australian Privacy Principles (APPs), forming a key pathway for lawful handling of personal information even without consent or reasonable expectation. It is codified in:

• APP 3.4(a): permits collection of sensitive information without consent if required or authorised by law;
• APP 6.2(b): permits use or disclosure for a secondary purpose if required or authorised by law;
• APP 9.2(c): permits use or disclosure of government-related identifiers if required or authorised by law.

What counts as "required or authorised." According to the OAIC’s Guidelines (Ch. B, para. B.140; Ch. 6, para. 6.38), "required" means there is a legal obligation to handle the information (e.g., mandatory reporting, statutory registers). "Authorised" means the law gives an entity the power (but not the obligation) to handle the information. The law must be valid and clear; vague regulatory expectations or commercial contracts do NOT qualify unless they are enacted under, or give effect to, a law or court/tribunal order (see Ch. 6, para. 6.41). This requires precise statutory or regulatory citation and, if relying on a court or tribunal order, a copy of that order.

Examples and limitations. The OAIC and case law highlight when this exception applies:

• Reporting to authorities under public health laws (COVID-19 case reporting), anti-money laundering, or child protection statutes is lawful where the statute explicitly requires disclosure.
• Laws authorising but not requiring disclosure support the exception (e.g., certain law enforcement or consumer protection powers). But the power must be clear—mere policy or memorandum is not enough.
• Industry codes registered under the Privacy Act may, depending on their terms, establish an authorisation basis.

This exception cannot be used where only the entity’s contractual obligations or internal policies require the action. Blanket references to “required by law” in privacy notices do not suffice; the relevant law, order, or authority must be able to be cited and justified to the OAIC if challenged.

Comparison to GDPR. The GDPR contains “legal obligation” and “exercise of official authority” as distinct lawful bases (Art. 6(1)(c)–(e)). The Australian “required or authorised” test has no direct GDPR analogue but frequently overlaps with those bases in practice. Australian practice, however, puts the burden squarely on the entity to justify the legal requirement or authorisation.

Enforcement and documentation. The OAIC expects robust recordkeeping whenever this exception is used, including:

• The statutory provision or order relied on;
• A copy of the request, order, or relevant correspondence;
• Assessment of necessity and proportionality where authorisation is broad or discretionary.

Misapplied reliance is an APP breach and can lead to enforcement, particularly if used as a default bypass for consent or transparency duties.

Source: Privacy Act 1988 (Cth), Schedule 1, APP 3.4(a), 6.2(b), 9.2(c) Source: Australian Privacy Principles Guidelines, Ch. B (Key concepts), para. B.140; Ch. 6, paras 6.38–6.45

Australian Privacy Principle 7 (APP 7) in Schedule 1 to the Privacy Act 1988 (Cth) imposes a distinct lawful-basis framework for direct marketing, separate from the general consent-or-reasonable-expectation tests under APPs 3 and 6. APP 7 applies only to "organisations" (not agencies) that use or disclose personal information for the purpose of direct marketing—that is, to promote goods or services directly to individuals, regardless of the communication channel.

Under APP 7.1–7.3, an organisation must not use or disclose personal information for direct marketing unless:

1. The individual has consented, or it is reasonable to expect the organisation would use the information for direct marketing, and the individual has not opted out (APP 7.2);
2. The individual is given a clear and simple means to opt out of future communications (APP 7.2(b),(d));
3. For sensitive information (such as health, racial/ethnic origin, etc.), direct marketing is prohibited unless the individual has expressly consented (APP 7.4);
4. Any use or disclosure for direct marketing must comply with other provisions, including those under the Spam Act 2003 (for email/SMS, not phone) and the Do Not Call Register Act 2006 (for phone marketing).

The "reasonable expectation" route under APP 7.2(a)(ii) depends on what the individual would reasonably expect at the time of collection, generally shaped by privacy notices. If this expectation does not exist, consent is required. For third-party direct marketing (using or disclosing to another entity for them to market), stricter rules apply—explicit consent or notification and opt-out are required (APP 7.3).

Every direct marketing communication must include a conspicuous opt-out mechanism, and requests to opt out must be acted on promptly (within a reasonable period, typically no more than 30 days: APP Guidelines, Ch. 7, para 7.22). Failure to do so is a breach of the APP and may result in an “interference with privacy” under section 13.

APP 7 does not apply to agencies, nor to registered political parties, direct mail fundraising by charitable organisations, or where exceptions under the Do Not Call Register Act or Spam Act provide an alternative rule. Notably, APP 7 is also subject to restrictions on using government-related identifiers for marketing (see APP 9) and on health information (see APP 3 and 16B).

OAIC guidance and enforcement actions stress that bundled consents and unclear opt-out options are common sources of complaint. The OAIC recommends a practical, prominent, and free opt-out route—such as unsubscribe links, do-not-mail lists, or dedicated phone or online channels.

Source: Privacy Act 1988 (Cth), Schedule 1, APP 7; Part IIIA; section 13 Source: Australian Privacy Principles Guidelines, Chapter 7 (APP 7 – Direct marketing)

No fixed statutory age: capacity, not strict age, determines consent for children. The Australian Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs) do not set a specific age under which a minor cannot validly consent to the collection, use, or disclosure of personal information. Instead, lawful consent for children and young people is determined by capacity: whether the individual has sufficient understanding and maturity to grasp the nature and consequences of what is proposed. This is detailed not in the Act itself, but in the Office of the Australian Information Commissioner (OAIC) Australian Privacy Principles Guidelines (Chapter B, Key concepts).

Presumption at age 15, otherwise case-by-case assessment. The OAIC says an entity may presume that a person aged 15 years or older has capacity to give consent independently, unless there is evidence to the contrary. For those under 15, the entity should either assess capacity individually or seek parent/guardian consent. The key is whether the child can understand the nature, purpose, and consequences of the information handling in question (Guidelines Chapter B, paras B.57–B.62). Where practicable, entities are expected to ensure that privacy practices reflect the best interests of the child and to involve parents or guardians for younger children.

Current position — Children’s Online Privacy Code (COPC) not yet in force. In 2023, the Attorney-General’s Department published an Exposure Draft for a Children’s Online Privacy Code, proposing higher standards for digital services accessed by minors, including stronger consent and privacy-by-design duties for those under 18. As of June 2026, the code remains a draft and has not commenced; no age-based statutory obligations for digital services apply as law. Practitioners should monitor for updates, as passage of the code or additional legislative reform may affect compliance duties in future.

OAIC best-practice recommendations and focus. The OAIC recommends that, when handling children’s information, entities provide clear, age-appropriate privacy notifications and allow for parental contact or involvement where prudent—even if not strictly required by law. For children under 15, securing parental (or guardian) consent is best practice when assessing capacity is impracticable. The OAIC’s guidance encourages opt-in practices, easy-to-understand explanations, and particular care around direct marketing and profiling of minors. Enforcement reflects these expectations, with the OAIC highlighting children’s privacy as a key area in public advice and informal resolutions.

Contrast with GDPR. Australia does not adopt a GDPR-style "child’s consent" derogation or default age for online services (GDPR Article 8). Consent is based on actual capacity, not formal age, and there is no requirement to override a child’s consent with that of a parent at a set threshold.

Source: OAIC, Australian Privacy Principles Guidelines, Chapter B (Key concepts), paragraphs B.57–B.62 Source: Privacy Act 1988 (Cth), sections 6(1), Schedule 1 (APPs) Source: Attorney-General’s Department, Draft Children’s Online Privacy Code released, 31 March 2026 Source: OAIC, Children and young people

Employee records exemption — statutory scope and key exclusions. The Australian Privacy Act 1988 (Cth) contains a significant carveout for "employee records" held by private sector employers, set out in section 7B(3). This exemption means that personal information about an individual who is or was employed by an organisation is generally not subject to the Australian Privacy Principles (APPs) when held in connection with the employment relationship. Specifically, section 7B(3) provides that an act or practice of a private sector organisation is exempt from the APPs if it is directly related to "a current or former employment relationship" between the organisation and the individual, and relates to an "employee record" held by the organisation (Privacy Act, s. 7B(3)).

Definition of employee record and coverage. "Employee record" is defined in section 6(1) to include "a record of personal information relating to the employment of the employee," such as health information, performance information, leave records, terms and conditions, and training records. Importantly, the exemption applies only to private sector "organisations"—it does not cover public sector agencies, which remain bound by the APPs. The OAIC guidance states that the exemption is limited to data collected or used in the context of employment—information held outside this context (e.g., unrelated use, disclosures to third parties) may not be exempt (OAIC APP Guidelines, Chapter B, para B.138–B.141).

Limits and exclusions. The exemption does not apply:

• Before an employment relationship exists—job applicants' information is covered by the APPs;
• To contractors, subcontractors, volunteers, or employees of labour hire firms (they are not "employees" of the principal for s. 7B(3));
• To employee records not "directly related" to employment (e.g., using employee data for unrelated marketing);
• To records held by public sector employers or private educational institutions;
• To workplace surveillance, health and safety law obligations, or anti-discrimination law—these may impose transparency, fairness, or privacy-like standards outside the Privacy Act.

Lawful basis for processing—practical implications. For covered employee records, the main lawful basis is the statutory exemption itself. However, if an employer processes personal information for secondary purposes not "directly related to" employment (such as large-scale analytics, AI profiling, or third-party data sharing), those uses may fall outside the exemption. In these cases, the employer must identify a lawful basis under the APPs much as with any other personal information.

Reform and legislative review. The Privacy Act Review Report (Attorney-General's Department, February 2023) recommended narrowing or removing the employee records exemption to provide baseline privacy protections for employees (Rec. 7.1–7.3). As of June 2026, legislation to reform or repeal the exemption is pending but not in force; no changes have been enacted. Practitioners should monitor for legislative changes and consider implementing privacy-compliant practices for employee records in anticipation of reform.

OAIC approach and comparative context. The OAIC supports reform to bring employee data more fully under privacy law. Notably, the exemption is broader than arrangements in the UK, EU, or Canada, where employee data is regulated almost equivalently to other personal data. The OAIC has issued guidance urging good practice regardless of the legal carveout.

Source: Privacy Act 1988 (Cth), section 7B(3), section 6(1) (definitions) Source: Australian Privacy Principles Guidelines, Chapter B (Key concepts) — employee records exemption Source: Attorney-General’s Department, Privacy Act Review Report, February 2023 — Recommendations 7.1 to 7.3

Statutory boundaries: de-identified data versus personal information. The Australian Privacy Act 1988 (Cth) applies only to "personal information," defined in section 6(1) as information or an opinion about an identified individual, or an individual who is reasonably identifiable, whether true or not and whether recorded in a material form or not. Data that has been "de-identified" so that the individual is no longer identifiable, or not reasonably identifiable, falls outside the regulated scope of the Act. The test is risk-based: the standard is "not about an identifiable individual or an individual who is reasonably identifiable" (s. 6(1), definition of de-identified; Australian Privacy Principles Guidelines, Chapter B).

What does de-identified require? According to the OAIC (APP Guidelines, Ch. B, B.86–B.96), de-identification is a process; the Act defines de-identified data as "personal information that is no longer about an identifiable individual or an individual who is reasonably identifiable." This requires not only the removal or alteration of direct identifiers (such as name, Medicare number, address), but also an assessment of whether any other information, alone or in combination with other reasonably accessible data, would enable re-identification. This test is contextual: it may change as technology or the amount of available third-party data changes. It is not enough to apply technical de-identification methods; the entity must consider the risk of re-identification in the particular environment.

OAIC guidance — re-identification risk and reasonable steps. The OAIC's guidance requires that de-identification measures be robust in practice. Entities must:

• Remove direct and indirect identifiers and consider possible "linkage attacks" where external datasets could restore identifiability.
• Regularly review de-identification as context, technology, or available data change, as what is de-identified now may not remain so in the future.
• Not rely on de-identified status if any entity (not just the discloser) could reasonably re-identify individuals from the data set (OAIC Guidelines B.89–B.91).

The Act distinguishes between "de-identified" and "anonymised": the former is a statutory term with a risk-based threshold; if re-identification is reasonably possible by any party, the data remains personal information. The OAIC states de-identification is effective only if "no reasonable steps could be taken to re-identify an individual"—a high bar. Neither the Act nor the Guidelines use the GDPR term "anonymisation," but the functional test is broadly similar to GDPR Recital 26 (data outside scope if individuals are not, or are no longer, identifiable by any means reasonably likely to be used).

Practical consequences: If data is de-identified and not reasonably re-identifiable, it is not regulated personal information. However, if re-identification is possible in practice, the entity is accountable for the information as personal information. There are statutory penalties for re-identification of government de-identified datasets (see s. 16D), but for private sector APP entities, the regulatory focus is on ensuring ongoing reviews and sound de-identification methods rather than blanket immunity.

OAIC compliance expectation: The OAIC expects entities to document their de-identification process and risk assessment, especially before sharing de-identified data with third parties or publishing it. Failure to take "reasonable steps" opens the entity to regulatory scrutiny and possible determinations that the data was, in fact, personal information at disclosure. This is particularly relevant for secondary uses (APP 6) and research exceptions (section 16B).

Enforcement and reform. The OAIC investigates data breaches and complaints involving re-identification, especially in cross-border processing or health/statistical research. Section 16D of the Act makes it an offence to intentionally re-identify information from a government de-identified dataset, punishable by penalties. The Privacy Act Review Report (2023) recommended further clarity and codification of de-identification standards, but as of June 2026, legislative reform is pending.

Source: Privacy Act 1988 (Cth), section 6(1) (definitions), section 16D (re-identification offence) Source: Australian Privacy Principles Guidelines, Ch. B (Key concepts), de-identification B.86–B.96

Statutory framework and compliance risk. The Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs) do not expressly name “incidental collection”—the situation where personal information is collected unintentionally or as a secondary byproduct (such as images on CCTV, ambient audio, or data logged by digital systems primarily for technical reasons). However, the Office of the Australian Information Commissioner (OAIC) interprets APP 3 to regulate all collections by an APP entity, regardless of intent: if personal information is “collected,” the entity must justify that it is "reasonably necessary" for a function or activity of the entity (APP 3.2 for organisations; APP 3.1 for agencies).

Collection is defined broadly. Section 6(1) defines “collects” to include obtaining personal information from any source or by any means—active or passive. OAIC guidance (Chapter B, Key concepts, para B.31) underlines that collection occurs as soon as an entity obtains personal information—whether or not it sought, requested, or anticipated receiving it. This includes unintentional, opportunistic, or technology-driven collection: e.g., CCTV that captures guests, audio recorders that pick up private conversations, or webserver logs that incidentally record IP addresses or location data.

Application of "reasonably necessary" to incidental collection. The OAIC requires that if incidental collection is anticipated or likely, an APP entity must (a) limit the scope of systems and notice so as to avoid collecting personal information “not reasonably necessary” (APP 3.2, para 3.19); (b) design systems and workflows—where practicable—to avoid or promptly delete unnecessary incidentally-collected data; and (c) ensure that collection notices (APP 5) inform individuals about the nature and purposes of incidental collection if reasonably foreseeable (e.g., “this area monitored by CCTV which may capture audio or images of guests…”). Where personal information is passively captured but not reasonably necessary for any function, best practice is to avoid collection, deactivate collection features, or promptly destroy/de-identify the data (para 3.20–3.23).

Systems often cannot avoid every byproduct, but recurring or predictable patterns (such as background conversations or bystander images) demand specific technical, notice, and minimisation safeguards. OAIC enforcement actions emphasise that private sector and government entities must justify why each type of personal information—deliberately or unintentionally collected—is necessary, and cannot default to retaining all incidentally captured data "just in case" (para B.103; see also OAIC Guide to Data Analytics, 27.18–27.21).

Enforcement and risk. Failing to assess, restrict, or disclose incidental collection exposes an entity to OAIC complaint investigation, enforceable undertakings, or civil penalties for breach of the APPs (Privacy Act s. 13G, s. 52). Notably, incidents involving unnecessary recording of audio or video in change rooms or private spaces have resulted in OAIC regulatory action. The OAIC expects robust documentation of risk assessments and technical choices relating to camera placement, logging retention, and incident minimisation.

Comparison: GDPR and international baseline. GDPR Article 5(1)(c) and Recital 39 (data minimisation) similarly require that personal data must be "adequate, relevant and limited to what is necessary." However, only Australia’s regime—through the broad assignment of the “reasonably necessary” standard at collection—pervasively applies this to all byproduct, not just primary data flows.

Source: Australian Privacy Principles Guidelines, Chapter 3 (APP 3 — Collection of solicited personal information), paras 3.19–3.23 Source: Australian Privacy Principles Guidelines, Chapter B (Key concepts), paras B.31, B.103 Source: OAIC, Guide to Data Analytics and the Australian Privacy Principles, paras 27.18–27.21