Data Availability and Transparency Code 2022

The Code organises obligations around five core conceptual pillars drawn from the Act: project, people, setting, data and output. Each pillar is given operational content in the Code.

• Project principle (sections 6-7): The Code requires an entity to be satisfied that the project is reasonably expected to serve the public interest (section 6). For delivery of government services alone, the Code treats the public interest test as satisfied (section 6(2)). For projects involving medical research or public health, the Code accepts certain Privacy Act mechanisms and permitted health situations as satisfying the public interest test (section 6(3)). For other research and policy projects, the entity must weigh benefits and harms and document consideration of specified factors (section 6(4)-(5)). It limits projects whose only benefits are to a foreign nation or to non‑Australian commercial entities (section 6(6)). The Code also mandates consideration of applicable ethics processes and requires observance where mandatory (section 7).

• People principle (sections 8-12): The Code makes conflicts of interest a disqualifying factor unless appropriately managed (section 8). It permits certain representational assumptions in service delivery projects (section 9) and sets out what constitutes adequate inquiry and contractual commitments for research/policy projects (section 10). The Code requires entities to take account of attributes (security and other clearances), qualifications, affiliations and expertise (section 11) and prior experience (section 12) of designated individuals and data accessors.

• Setting principle (section 13): Security standards must be reasonable and proportionate to sensitivity and risk; proportionate assessment is required and, in some cases, non‑Commonwealth accredited entities may be required to comply with Commonwealth security standards or parts of them.

• Data principle (section 14): Entities must consider pre‑sharing data treatment such as deletion, modification or aggregation to manage risk proportionately; the data custodian must consider appropriate treatment where sharing occurs through an Accredited Data Service Provider (ADSP) (section 14(2)-(3)). The Code cross‑references statutory privacy protections in sections 16A-16C of the Act (note in section 14).

• Output principle (section 15): Entities must consider the nature and intended use of outputs and, where the accredited user may provide access to or release output, consider whether the data sharing agreement should include procedures to manage such provision or release (section 15(2)-(3)).

Consent and personal information: Part 3 develops how consent interacts with the Act’s privacy provisions (sections 16-23). It prescribes what adequate information must be provided before consent is given, that consent must be voluntary, specific and current, and how withdrawal operates (sections 17-20). For certain actions (for example consent required for output to exit the scheme or for an accredited user to become a data custodian), the Code requires express consent and specific pre‑consent information (sections 19-20). It sets tests for when it is unreasonable or impracticable to seek consent (section 21) and prescribes minimum personal information necessary for various types of government services (section 22) , e.g. contact details and information relevant to timing or eligibility. It also prescribes the balancing test for sharing personal information without consent, requiring identification of likely adverse impacts and weighing them against the public interest benefits, with a non‑exhaustive list of factors (section 23).

Other administrative concepts: The Code prescribes content required when submitting a data sharing agreement for registration (section 90(1)-(2)), and sets an annual report notification timing (section 91). For agreements involving state/territory data obtained under a separate provisioning agreement, the Code requires the data sharing agreement to specify the state or territory data, the provider, and consistency with any provisioning conditions (section 25).

Transitional application: The Code records that specified amendments made by a 2025 amending instrument will apply to agreements entered into on or after 1 July 2025 (Part 10, Division 1; sections 100-101). The instrument text contains repeated copies of that Division (the Code shows two identical blocks), which is present in the source text.

Terminology and cross‑references: The Code relies heavily on terms that the Act defines (see section 4 in the Code listing expressions defined in the Act). It also refers to external legal instruments and frameworks, including the Privacy Act 1988 and guidelines under section 95 of that Act, the AusCheck Act 2007 for the meaning of permanent resident, and other Codes made under the Data Availability and Transparency Act such as the National Security Measures Code (noted in section 5). These cross‑references determine when particular statutory mechanisms or sectoral ethical safeguards apply.

Operational effect: The Code translates the Act’s principles into checklist items and documentary requirements. This produces an evidentiary pathway for registration and oversight: entities must record the considerations they have taken into account (for example, the list in section 6(5) for public interest weighing) and supply specified information to the Commissioner at registration (section 90). The Code therefore binds entities to procedural steps that support regulatory oversight under the Act.

The Code affects a range of actors who participate in the data sharing scheme created by the Act. The instrument repeatedly references roles defined in the Act; reading the Code together with the Act is necessary to determine scope. Based on the Code’s text, the primary affected groups are:

• Data custodians: entities that control or hold the source data being shared. The Code assigns data custodians responsibilities to assess project public interest, ethics processes, necessity of personal information for service delivery, and to consider treatment and ADSP use before sharing (see sections 6, 7, 14, 21-23). Where source data includes state or territory data obtained from a State or Territory body under a provisioning agreement, the data sharing agreement must specify particulars and explain consistency with the provisioning agreement (section 25).

• Accredited entities and accredited users: the Code imposes duties on accredited entities (including accredited users) to ensure that their designated individuals and data accessors are appropriate persons to access data (sections 10, 11, 12), to identify and manage conflicts of interest (sections 8-10), and to operate systems for identifying and managing conflicts in service delivery projects (section 9). Accredited entities are taken to appropriately manage conflicts if they have an effective system in place (section 9(4)).

• Designated individuals and data accessors: the Code sets criteria for assessing the appropriateness of individuals who will access data, including attributes (security and other clearances), qualifications, affiliations, expertise and experience (sections 11-12). These factors determine whether a person may be permitted to access data under a data sharing agreement.

• ADSPs (Accredited Data Service Providers): the Code requires data custodians to consider whether data should be treated before sharing with an ADSP, and for ADSP‑mediated accesses to be treated as a factor in public interest and privacy assessments (sections 14(3), 15(3), 23(3)(c)). ADSPs also appear in the people principle context where their conflicts of interest must be managed (sections 9-10).

• State and Territory bodies that provide data to data custodians: where source data is state or territory data obtained under separate provisioning agreements, the Code requires data sharing agreements to spell out the state/territory content, provider and any conditions in the provisioning agreement (section 25). This affects intergovernmental data flows and contractual compliance with provisioning agreements.

• Commissioners and other oversight officers: the Code prescribes the information an entity must provide to the Commissioner when applying for registration of a data sharing agreement (section 90). It also prescribes the period by which certain information must be notified to the Commissioner for inclusion in the annual report (section 91). The Code therefore shapes the operational workload and evidentiary expectations for the Commissioner’s office.

• Individual data subjects: the Code sets out the informational content and form of consent required from individuals whose personal information is shared or may exit the scheme (sections 17-20). It constrains when personal information may be shared without consent and prescribes the minimum personal information necessary to deliver specified types of government services (section 22). Individuals are affected through the mechanics of consent, withdrawal, and the public interest balancing tests that may permit sharing without consent (sections 21-23).

• Third parties who may receive output or access output: the Code requires entities to consider whether data sharing agreements should permit provision of access or release of output, and to include procedures or processes to manage such access or release if permitted (section 15(3) and section 18 dealing with consent to provision of access/release).

• Legal and compliance advisors, auditors, and institutional ethics committees: while not named, these professional roles will be affected because the Code requires entities to identify applicable ethics processes and to observe mandatory ethics processes (section 7), to document conflict management systems (sections 8-10), and to provide information for registration (section 90). The Code therefore creates substantive duties that those advisors will be asked to interpret and operationalise.

Procedural impact: Entities proposing data sharing projects are required to document a range of matters before sharing occurs. For example, when sharing personal information, the data custodian must consider whether it is unreasonable or impracticable to seek consent and must base conclusions on enumerated considerations (section 21). For projects relating to government service delivery, data custodians must apply the narrow necessity tests set out in section 22. For data sharing agreements involving state or territory data, additional specification is required (section 25). Failure to meet these documentary and procedural requirements will affect an entity’s ability to register a data sharing agreement under the Act (see section 90).

Geographic and entity scope: The Code explicitly contemplates benefits and impacts for Australian citizens, permanent residents and other people in Australia as factors in public interest weighing (see section 6(5)(iii)). The Code disqualifies projects in which the only benefits are to another nation or to non‑Australian commercial entities (section 6(6)). It also refers to the AusCheck Act 2007 for the definition of permanent resident (section 4), linking the Code’s coverage to Australian nationality and residency concepts.

Timing and transitional effect: The Code’s transitional provisions (Part 10, Division 1; sections 100-101) state that amendments made by a later amending instrument apply to data sharing agreements entered into on or after 1 July 2025. Entities entering agreements near that date will be affected by the timing rule; however those transitional clauses appear duplicated in the text provided.

The Code imposes specific duties on entities involved in the data sharing scheme and clarifies particular rights of individuals (principally consent and withdrawal mechanics). The main duties and rights set out by the Code, with relevant section pointers, are:

Duties on entities (data custodians, accredited entities, ADSPs where relevant)

• Project assessment duties: Entities must, as part of satisfying the project principle, take into account the matters and comply with the requirements in section 6. This includes treating delivery of government services as satisfying public interest where it is the sole purpose (section 6(2)), applying the Privacy Act framework for certain medical research (section 6(3)), and conducting a balancing exercise for other research and policy projects (section 6(4)-(5)) where specified factors must be considered (section 6(5)(i)-(vi)).

• Ethics processes: Entities must consider what ethics processes are applicable to a project and must observe any mandatory processes (section 7(1)-(1)(b)). Where more than one process is mandatory, the entity satisfies the duty by observing at least one chosen by agreement between the data custodian, accredited user and any ADSP (section 7(2)).

• Conflicts of interest: Entities must not make data available to a person if that person has an actual, potential or perceived conflict of interest that is not appropriately managed (section 8). Accredited entities must identify, notify and manage conflicts: notify the data custodian and other accredited entities of identified conflicts and steps taken to manage them, and manage conflicts in accordance with the data sharing agreement and any directions of the data custodian (section 10(4)(a)-(b)).

• Assessment of designated individuals and data accessors: For projects involving informing government policy and research, entities must take into account attributes, qualifications, affiliations, expertise and experience of individuals who will access data (sections 11-12). Entities may assess classes of individuals rather than each individual (sections 11(3), 12(3)).

• Security standards: Entities must apply reasonable security standards that are proportionate to data sensitivity and the risks posed; the standard must be assessed by the entity (section 13(2)). Non‑Commonwealth accredited entities may, in some cases, be required to comply with Commonwealth security standards or parts of them (section 13(3)).

• Data protection before sharing: Entities must consider whether data should be treated (for example by deletion, modification or aggregation) before sharing to manage risks proportionately; where sharing through an ADSP the data custodian must consider the appropriateness of treatment before sharing (section 14(2)-(3)).

• Output controls: Entities must consider the nature and intended use of outputs and whether permissions in the data sharing agreement to provide access to or release output are appropriate; include procedures or processes if necessary (section 15(2)-(3)).

• Documentation and registration: Entities submitting a data sharing agreement for registration must provide specified information to the Commissioner in an approved form, including entities party to the agreement, project description, data description, whether personal information is to be shared, the public interest statement, description of final output, circumstances for exit, expiry date, and attachments (see section 90(1)-(2)(a)-(m)).

• State/territory data requirements: If source data includes state or territory data obtained under a provisioning agreement, the data sharing agreement must specify the state or territory data included, the provider, whether there are conditions in the provisioning agreement relating to sharing, and if so how sharing under the data sharing agreement is consistent with those conditions (section 25).

Duties relating to consent and personal information

• Information before consent: Where consent is required under the Act, entities must ensure individuals are adequately informed about specified matters before consent is given, including the nature of personal information, whether information will be shared more than once, and identities of recipient entities (see sections 17(2), 18(2), 19(2)-(3), 20(2)-(4)).

• Form and currency of consent: Consent must be voluntary, specific to the project or purpose, and current at time of sharing or provision of access/release (sections 17(3)-(6), 18(3)-(6), 19(6)-(9), 20(6)-(9)). For certain actions (for example subsection 16A(1) of the Act and exits under section 20E(4)(c) of the Act), the Code requires express consent (section 17(9) and section 19(1)-(3)).

• Withdrawal: Withdrawal of consent must be done expressly (orally or in writing) and only applies to sharing/access after the withdrawal, not retrospectively (sections 17(6)-(7), 18(6)-(7), 19(8)-(10), 20(8)-(10)).

• Capacity: Consent must be given by the individual if they have capacity, otherwise by a responsible person as defined in the Privacy Act 1988 (sections 17(8), 18(8), 19(11), 20(11)).

• Impracticability test: Data custodians must base any conclusion that it is unreasonable or impracticable to seek consent on enumerated considerations (section 21(1)), and may find impracticability where seeking consent would be excessively burdensome (section 21(2)). Mere inconvenience, time or cost, or a large number of people, are not by themselves sufficient (sections 21(3)-(4)).

Rights of individuals

• Rights to be informed and to give or withhold consent: Individuals have the right to be adequately informed before consent and the right to give voluntary, specific and current consent, with limited circumstances for implied consent for certain subparagraphs specified in the Code (sections 17-20).

• Right to withdraw and limits on retrospective effect: Individuals can withdraw consent expressly and this affects only future sharing or access/release (sections 17(6)-(7), 18(6)-(7), 19(9)-(10), 20(9)-(10)).

• Right to information about exit: For personal information exit from the scheme, the individual must be adequately informed that the Act will no longer limit the accredited user’s use of the personal information, and that other laws may still apply (section 19(2)-(4)).

Balancing duties: For sharing personal information without consent, data custodians must identify likely adverse impacts and determine whether the public interest benefits outweigh those impacts, taking into account specified factors such as serious threats to life, safeguards, whether data will be de‑identified or remain with an ADSP, and benefits to individuals (section 23).

Procedural obligations and record keeping: The Code’s duties require entities to undertake and record risk assessments, ethics process findings, conflict registers and consent records. The registration requirements in section 90 create an obligation to maintain documentary evidence in order to secure registration by the Commissioner.

Limits on duties: The Code also expressly notes that some requirements, for example the people principle conflict management rule, do not limit other circumstances in which an entity may be inappropriate to make data available (section 8(2)). The Code clarifies when entities may assume the adequacy of conflict management systems in service delivery projects (section 9) and when an entity is taken to manage conflicts appropriately under specified conditions (section 9(4)).

The Code itself does not create criminal offences or civil penalties, nor does it describe enforcement actions or sanctions. It is a standards and procedural instrument made under section 126 of the Act (section 3). Enforcement and penalties for contraventions of the Act, and the mechanism for regulatory response, are contained in the Act rather than in this Code. The role of the Code in enforcement is therefore indirect and administrative: it defines the operational expectations and documentary requirements that underpin registration, the Commissioner’s oversight functions and compliance assessments.

Practical enforcement interfaces created by the Code

• Registration and Commissioner oversight: The Code prescribes the information that an entity must provide to the Commissioner at the time of giving documents under subsection 33(1) of the Act (section 90). That creates an evidential basis for the Commissioner to assess whether a data sharing agreement meets the Act’s requirements. The Commissioner’s decisions on registration, refusal or conditions will in practice be an enforcement mechanism facilitated by the Code’s documentation requirements (section 90(1)-(2)).

• Reporting timelines: Section 91 prescribes the applicable period for notifying the Commissioner of certain information for inclusion in the annual report prepared under section 138 of the Act, by specifying the notification period ends on 31 July. Timely notification is necessary for the Commissioner to prepare the statutory annual report and for public accountability.

• Contractual and administrative consequences: By prescribing minimum content in data sharing agreements (for example, section 25 for state/territory data and the detailed items in section 90(2)), the Code increases the likelihood that a data sharing agreement that fails to include required content will be refused registration or will be subject to conditions by the Commissioner under the Act. Those registration outcomes produce practical consequences: inability to lawfully share data under the Act, contractual renegotiation, or public reporting.

• Procedural and documentary obligations as compliance anchors: The Code requires entities to consider and document specific matters,public interest balancing, conflict identification and management, ethics processes, security standards and consent mechanics. Failure to document these steps risks a finding of non‑compliance with the Act’s principles when assessed by the Commissioner or other oversight bodies.

Limitations and interpretive risk

• Absence of penalties in instrument: Because the Code does not itself specify penalties, a reader must consult the Act for specific sanctions and enforcement procedures. The Code therefore functions as a compliance standard rather than a direct punitive instrument.

• Administrative discretion: Many obligations in the Code are expressed as matters to be taken into account or steps that must be complied with when an entity is satisfying itself that a project meets the Act’s principles (e.g. “an entity must take into account the matters” in section 6). That language gives scope to administrative judgement in how matters are weighed and documented, which in turn means that enforcement will likely turn on whether the entity’s exercise of judgment is reasonable and adequately documented.

• Commissioner’s role: The Code creates specific documentary expectations for registration; the Commissioner’s assessment against those expectations will be the immediate point of enforcement. The Code does not describe the Commissioner's decision‑making framework in full; those details are in the Act.

In sum, the Code generates enforceable compliance obligations by defining what entities must document and consider in order to satisfy the Act’s principles. Actual enforcement powers and penalties reside in the Act and in the Commissioner's statutory powers; the Code shapes how those powers are operationalised through standards, required information for registration, and procedural expectations.

The Code explicitly cross‑references and operates in the context of several external laws, regulations and frameworks. The instrument is designed to be read together with the Act and to integrate with existing sectoral rules and statutory frameworks. Its interactions are primarily in the form of cross‑references and incorporation of external standards and processes by reference.

Key statutory and regulatory interactions identified in the Code

• The Data Availability and Transparency Act 2022 (the Act): The Code is made under section 126 of the Act and repeatedly instructs how to meet the Act’s principles (see section 3 and the numerous notes referencing the Act). Many defined terms used in the Code are taken from the Act (section 4). The Code prescribes matters entities must take into account when applying statutory provisions such as subsections 16(1), 16(3), 16(5), 16(7), 16(9) and the privacy protections in sections 16A-16C of the Act (see notes in sections 5 and 14).

• Privacy Act 1988: The Code relies on the Privacy Act and its instruments for medical research and health information contexts. Section 6(3)(a) refers to “medical research within the meaning of the Privacy Act 1988 and in accordance with guidelines made under section 95 of that Act.” Section 6(3)(b) incorporates the concepts of “organisation” and “health information” from the Privacy Act and permits a permitted health situation under that Act to justify sharing. Sections 19 and 20 also refer to the Privacy Act’s constructs for responsible person and the nature of consent.

• Sectoral ethics frameworks and bodies: The Code requires entities to consider applicable ethics processes and to comply where observance is mandatory (section 7). It explicitly mentions independent bodies such as the National Health and Medical Research Council and the Australian Institute of Aboriginal and Torres Strait Islander Studies as potential sources of mandatory ethics processes (section 7, Note 1). This creates an interaction where sectoral ethics approval or frameworks may be required in addition to compliance with the Code and the Act.

• Data Availability and Transparency (National Security Measures) Code 2022: The Code directs readers to see also the National Security Measures Code (section 5), signalling coordinated operation between codes. Data sharing that raises national security issues will be subject to additional or different rules under that separate Code.

• AusCheck Act 2007: The Code adopts the AusCheck Act’s definition of “permanent resident” for its own purposes (section 4). That links residency concepts relevant to public interest weighing and eligibility tests to existing statutory definitions.

• Commonwealth security standards and other government security frameworks: Section 13(3) permits application of Commonwealth security standards, or parts of them, to accredited entities that are not Commonwealth bodies. That creates an interaction where Commonwealth security policy or standards (for example the Protective Security Policy Framework, though not named) can be applied to non‑Commonwealth entities through the Code’s standards.

• State and Territory provisioning agreements and applicable state/territory law: Section 25 addresses cases where a data custodian obtained state or territory data from a State or Territory body under a separate provisioning agreement. The Code requires the data sharing agreement to specify the state/territory data, the provider and whether any conditions in the provisioning agreement limit sharing, and if so how the sharing is consistent. This creates a contractual and legal interaction between federal data sharing agreements and existing state/territory contracts and possibly state law restrictions.

• Other laws otherwise contravened by a data sharing agreement: Section 90(2)(i) requires that, if but for section 23 of the Act sharing would contravene another law, the entity must provide the title of that other law to the Commissioner. This signals that the Act and the Code operate with awareness of potential conflicts with other legal obligations (for example secrecy provisions) and requires disclosure so the Commissioner can consider the interaction.

Practical consequences of these interactions

• Multi‑framework compliance: Entities must navigate multiple regimes when a project touches on privacy, health, human research ethics, national security and state/territory contractual conditions. The Code requires that entities explicitly identify and comply with the applicable processes (section 7) and to document consistency with provisioning agreements (section 25).

• Standards cross‑adoption: The Code’s ability to require non‑Commonwealth entities to comply with Commonwealth security standards (section 13(3)) means that entities accustomed to state or private sector standards may be required to upgrade or map their practices to Commonwealth ones for particular projects or classes of data.

• Consent and overlapping statutory duties: The Code’s consent provisions often rely on concepts from the Privacy Act and define where consent must be express versus where it may be implied (sections 17, 18, 19, 20). Entities must therefore align their consent forms and processes to satisfy both the Code’s specific requirements and any overlapping duties under the Privacy Act or other statutes.

• Intergovernmental contract compliance: Where data custodians receive state or territory data under separate provisioning agreements, the Code requires explicit mapping of contractual conditions (section 25). This creates a need to review downstream sharing against upstream contractual obligations, and to document consistency or seek variations where necessary.

• Reporting and regulatory interface: The Code’s registration and reporting requirements (section 90 and 91) feed information to the Commissioner, who is the statutory regulator under the Act. The Commissioner will thus assess compliance against the Code but may also consider how other laws and standards apply.

Limits and uncertainties

• The Code signals interaction with other laws but does not elaborate how conflicts between the Act and other statutes will be resolved; entities are required to disclose the titles of other laws they consider relevant (section 90(2)(i)), but resolution of legal conflicts remains a matter of statutory interpretation and administrative exercise under the Act.

• The Code requires observance of mandatory ethics processes (section 7(1)(b)), but where multiple mandatory processes apply it permits observance of any one selected by agreement (section 7(2)). That creates an interaction where sectoral mandates can be harmonised for the purposes of the data sharing scheme, but does not remove those obligations in other contexts.

Overall, the Code functions as a compliance bridge between the Act and other statutes, sectoral ethics processes, security frameworks and intergovernmental contractual arrangements. Entities must therefore map their obligations across these instruments and ensure the data sharing agreement and registration materials reflect that mapping.

The instrument as provided states that it is the Data Availability and Transparency Code 2022 (section 1) and that it is made under section 126 of the Act (section 3). The source text contains explicit transitional and application provisions that anticipate an amending instrument titled the Data Availability and Transparency Amendment (No. 1) Code 2025. The Code records:

• In Part 10 , Application, saving and transitional provisions , Division 1 (Application provisions relating to the Data Availability and Transparency Amendment (No. 1) Code 2025), sections 100 and 101 define “amending instrument” as that 2025 Code and state that amendments made by Schedule 1 to that amending instrument apply in relation to data sharing agreements entered into on or after 1 July 2025 (sections 100 and 101).

• The text provided contains duplicated copies of those Division 1 provisions and duplicated sections 100 and 101. The duplication is present in the instrument’s text itself as provided.

No other amendments or amendment dates are recorded in the text provided. The Code therefore presently incorporates a built‑in transitional rule for a single amending instrument anticipated in 2025. The Code does not disclose the substantive content of Schedule 1 to the amending instrument; it only sets the application date for any amendments contained in that Schedule.

What the Code itself changes and does not change

• The Code is the 2022 Code and sets the standards and procedural matters described elsewhere in this deep dive. It does not record earlier versions or prior amendments in the text provided. The only amendment history reflected in the instrument is the forward‑looking application clause for the 2025 amending instrument, indicating that some future changes have been contemplated and that they will be applied to agreements entered into on or after 1 July 2025 (sections 100-101).

• The duplicated Division 1 suggests there may be clerical or drafting duplication in the published text. The instrument as given contains two identical blocks labelled “Division 1 Application provisions relating to the Data Availability and Transparency Amendment (No. 1) Code 2025” with identical sections 100 and 101. The duplication in the source text is not resolved by the Code itself.

Implications for practitioners reviewing amendment history

• Absent other records, practitioners should treat the Code as the 2022 instrument with only the stated transitional provision for the 2025 amending instrument. To understand the content or impact of Schedule 1 to the amending instrument, one must inspect the 2025 instrument itself when published.

• The presence of duplicated clauses in the source text suggests checking the official legislative register or published legislative instruments to confirm whether the duplication exists in the authoritative copy and whether corrigenda or further amendments have been made.

• Because the Code anticipates application from 1 July 2025 for certain amendments, entities negotiating or entering data sharing agreements close to that date should be alert to the possibility that different standards may apply to agreements entered before versus on or after that date (see sections 100-101).

The Code does not provide a chronological log of previous amendments or version history beyond the 2025 transitional note. It thus places the onus on practitioners to consult the official register for any subsequent amending instruments or corrigenda.

The Code as provided contains no case law citations, no references to judicial decisions, and no record of litigation regarding its validity, interpretation or enforcement. The instrument itself refers to the Act and to other statutory instruments and frameworks (for example the Privacy Act 1988, the AusCheck Act 2007 and certain ethics bodies) but does not name any court decisions.

What the document establishes for litigation risk assessment

• Absence of recorded litigation in the instrument: Since the Code contains no litigation history, there are no authoritative judicial interpretations of the Code’s provisions contained within the instrument. Any legal disputes about the Code’s meaning, the Commissioner’s exercise of registration powers in light of the Code, or the adequacy of an entity’s procedural compliance would therefore be matters for future litigation and judicial interpretation.

• Administrative discretion and documentary standards: Many of the Code’s obligations are framed as matters to be taken into account, or procedural requirements that entities must comply with when satisfying statutory principles (for example, “an entity must take into account the matters” in section 6). This formulation tends to leave substantial margin for administrative judgment. In litigation, courts typically review whether an administrative decision was lawful, rational and procedurally fair; the Code’s detailed list of factors and prescribed documentary requirements may therefore be used as benchmarks to evaluate whether an entity or the Commissioner acted reasonably or complied with statutory process.

• Consent, public interest balancing and ethics processes as likely dispute areas: The Code sets out balancing tests (section 6 for public interest; section 23 for sharing personal information without consent), ethics process requirements (section 7) and detailed consent mechanics (sections 17-20). These topics commonly generate contestation in legal disputes about administrative decisions and privacy outcomes. The Code’s detailed lists of required considerations will likely be central in any judicial review of registration decisions or in disputes where an individual alleges improper sharing of personal information.

• Interplay with other laws may be litigated: The Code contemplates interactions with other statutes and contracts (for example, state/territory provisioning agreements in section 25 and other laws that might otherwise be contravened in section 90(2)(i)). Disputes could therefore raise questions about statutory conflict, contractual obligations and how the Act and Code interact with state law or sectoral secrecy provisions.

Practitioner implication

• Because the Code creates procedural steps that will shape administrative decision‑making, practitioners should anticipate that the first wave of litigation will concern the sufficiency of entities’ documented assessments under the Code, the Commissioner’s registration decisions based on submissions made under section 90, and the reasonableness of public interest and privacy balancing exercises. In those contests, the Code’s lists of required matters and documentary items will operate as evidentiary focal points in both administrative review and, if necessary, judicial review proceedings.

This section highlights operational pitfalls and non‑obvious legal consequences that follow directly from the Code’s text. Each item cites the relevant provision that creates the risk or nuance.

1. Consent currency and withdrawal mechanics are forward‑looking only (sections 17(5)-(7), 18(5)-(7), 19(8)-(10), 20(8)-(10)). Gotcha: withdrawal is effective only for future shares or releases, not retroactively. Entities must therefore track timelines carefully: a consent that is valid at the moment of sharing authorises that sharing even if the subject later withdraws consent.

2. Different consent standards depending on the statutory subprovision (section 17(9), section 19(1)). Gotcha: consent sometimes must be express and sometimes may be implied. For example, subsection 16A(1) of the Act requires express consent (note in section 17). Practitioners must map which statutory route they rely on and apply the stricter consent form where required.

3. “Reasonable person, properly informed” test for data necessity (section 14(4)). Gotcha: the Code requires an entity to consider whether a reasonable, properly informed person would agree that the data is necessary to achieve the project purpose. This introduces an objective standard; entities should document why the data is necessary against that hypothetical standard, not just record subjective internal beliefs.

4. Delivery of government services treated as prima facie public interest (section 6(2)) but strict minimum necessity rules apply (section 22). Gotcha: although service delivery projects are treated as serving the public interest, the Code simultaneously constrains what personal information is “necessary” to share for such services. For example contact information and information relevant to timing or eligibility are generally limited to what is necessary (section 22(3)-(6)). Entities cannot rely on section 6(2) to justify wholesale personal information sharing; they must still apply section 22’s necessity rules.

5. Large numbers of individuals is not by itself grounds for impracticability (section 21(4)) while excessive burden is (section 21(2)). Gotcha: an inability or reluctance to seek consent because of scale will not be sufficient; the entity must show seeking consent would be “excessively burdensome” in all the circumstances. Prepare contemporaneous cost and feasibility evidence if relying on section 21.

6. Multiple mandatory ethics processes can be satisfied by complying with only one chosen by agreement (section 7(2)). Gotcha: compliance with one mandatory process for the purposes of the data sharing scheme does not relieve the entity from observing other mandatory processes outside the scheme. Entities should document explicitly which process they chose and ensure compliance where required for other legal or policy purposes.

7. Conflicts of interest rules differ by project purpose (sections 9 and 10). Gotcha: for delivery of government services, a representation by the accredited user or ADSP that it has an effective conflict management system can be sufficient (section 9). For research and policy projects, the custodian must make reasonable inquiries and place contractual obligations on the accredited user or ADSP to identify and manage conflicts (section 10). Entities switching project purpose or mixing purposes must apply the correct standard.

8. ADSP routing affects treatment and public interest analysis (sections 14(3), 23(3)(c)). Gotcha: if personal information is only shared with an ADSP that will de‑identify it or will provide ADSP‑controlled access, that fact is a factor in the public interest test (section 23(3)(c)). Entities should consider whether ADSP mediation reduces privacy risk and document it.

9. Security standards may require Commonwealth security standards for non‑Commonwealth entities (section 13(3)). Gotcha: an accredited user who is a private or state entity may be required to meet Commonwealth standards; compliance may be costly and may require contractual or operational changes.

10. State/Territory provisioning agreements impose extra specification duties (section 25). Gotcha: where data was obtained under a separate provisioning agreement, the data sharing agreement must identify the state/territory data and explain consistency with those conditions. Practitioners must obtain and review upstream provisioning agreements before drafting downstream data sharing agreements.

11. Registration checklist is detailed and omissions matter (section 90(1)-(2)). Gotcha: when applying for registration the entity must provide particulars including whether subsection 16B(7) or 16B(8) of the Act applies and relevant statements, the title of any other law that would be contravened but for section 23, and, if output may exit, the circumstances for exit (see section 90(2)(g)-(l)). Failure to disclose these items risks rejection or conditions at registration.

12. Repetition in the instrument text (Part 10 repeated sections 100-101). Gotcha: the instrument as supplied contains duplicated transitional clauses. Practitioners should verify the official repository for any corrigenda or repeals to avoid relying on a duplicated provision that may reflect a drafting error.

13. Public interest balancing excludes projects whose only benefits are to foreign nations or non‑Australian commercial entities (section 6(6)). Gotcha: projects with clear or dominant commercial benefit to non‑Australian entities will not satisfy the public interest test; consider structuring benefits or partners to demonstrate Australian benefit where possible.

14. “Appropriate person” standard is factual and includes perceived conflicts (section 8(1)(a)). Gotcha: perceptions of conflict alone, if not appropriately managed, can make a person inappropriate to access data. Entities should adopt transparent conflict registers and management measures.

15. Exit and new custodian rules require express, fully informed consent (sections 19-20). Gotcha: transferring personal information out of the scheme or appointing an accredited user as a new data custodian triggers a higher consent bar: express consent with specific pre‑consent information about the effect of the Act not applying afterwards and the identity of the accredited user. Ensure consent forms include these particular elements.

These “gotchas” derive directly from the Code’s language and prescribe where documentation, contractual design, consent processes and project scoping require particular care.

This section provides a practical compliance checklist and recommended operational steps tied to the Code’s provisions. The list is structured by phase: project design, agreement drafting, registration and ongoing management.

Project design and assessment (before sharing)

1. Define project purpose and map to data sharing purpose categories in the Act and Code:

   • Determine whether the sole purpose is delivery of government services (section 6(2)). If so, you may rely on the Code’s presumption that the project serves the public interest, but you still must apply necessity constraints for personal information (section 22).

2. Public interest assessment (section 6):

   • For policy and R&D projects where section 6(3) does not apply, prepare a written public interest balancing statement that addresses all matters in section 6(5)(i)-(vi): availability benefits, benefits to individuals/groups, benefits to Australian citizens/permanent residents, desirability of evidence‑informed government policy (if applicable), adverse privacy impacts, and R&D output release plans.
   • Explicitly record consideration of additional matters if relevant (section 6(5)(b)(i)-(iii)), including national interest considerations and social/economic/environmental benefits and costs.

3. Ethics processes (section 7):

   • Identify all applicable ethics review requirements (institutional, sectoral, statutory).
   • If any process is mandatory, document how the entity will observe it and ensure the data sharing agreement specifies the actions to observe the process (note in section 7 and cross‑reference to subsection 19(7) of the Act).
   • If multiple mandatory processes apply, obtain agreement between the data custodian, accredited user and ADSP (if any) on which process will be observed; record the agreement.

4. Conflicts of interest (sections 8-10):

   • Run conflict checks for the entity and each data accessor/designated individual.
   • Maintain a conflict register and identify actual, potential and perceived conflicts.
   • For delivery of government services, obtain representations in the data sharing agreement that the accredited user (and ADSP where relevant) has a system to identify/manage conflicts and that it operates effectively (section 9).
   • For policy or research projects, perform reasonable enquiries, and include contractual obligations requiring identification and management of conflicts and compliance with data custodian directions (section 10).

5. Designated individuals and accessors (sections 11-12):

   • Identify classes of individuals who will access data and map attributes, qualifications, affiliations, expertise and experience to those classes.
   • Document security clearances and any training or on‑the‑job experience relevant to handling sensitive data.
   • Ensure the data sharing agreement permits access only to appropriately qualified and experienced designated individuals.

6. Security and setting standards (section 13):

   • Conduct a risk assessment to determine data sensitivity and sharing risks.
   • Select and document reasonable, proportionate security standards. Map these standards to Commonwealth security standards where required; if Commonwealth standards are to be applied to a non‑Commonwealth entity, document which parts are required and why (section 13(3)).
   • Ensure contractual obligations on the accredited user and ADSP require compliance with security standards and regular audit or attestation.

7. Data treatment and ADSP considerations (section 14):

   • Assess whether data should be treated (de‑identified, aggregated, reduced) before sharing.
   • If using an ADSP, document the custodian’s consideration of treatment prior to sharing and whether ADSP‑controlled access suffices.
   • Record the “reasonable person, properly informed” rationale that data is reasonably necessary for the project purpose (section 14(4)).

8. Output management (section 15):

   • Define final and intermediate outputs and intended uses. For each output, determine whether accredited users may provide access or release and, if so, draft procedures to manage that access and release in the data sharing agreement.

Consent processes and personal information (Part 3: sections 17-23)

1. Consent design and documentation:

   • Prepare consent forms or scripts that include the specific information required by the Code: nature of personal information, whether sharing will occur more than once, the accredited entities with which it will be shared (sections 17(2), 18(2), 19(2)-(3), 20(2)-(4)).
   • Ensure consent is voluntary, specific, current and given by the individual with capacity or a responsible person (sections 17(3)-(8) etc.).
   • For actions requiring express consent (e.g. subsection 16A(1) of the Act, or exit under section 20E(4)(c)), make sure the form captures express consent in writing or orally with contemporaneous records (sections 17(9), 19(1)).

2. Withdrawal and record keeping:

   • Implement procedures to record withdrawals of consent expressly (oral or written) and to ensure withdrawals apply to future sharing only (sections 17(6)-(7), 18(6)-(7), 19(10)).
   • Maintain time‑stamped records of consent and withdrawal and track shares against those timestamps.

3. Impracticability and public interest balancing:

   • If relying on impracticability to seek consent, document the considerations in section 21(1) and evidence that seeking consent would be “excessively burdensome” (section 21(2)). Do not rely solely on scale or cost (sections 21(3)-(4)).
   • If proposing to share personal information without consent under a public interest ground, prepare a written analysis identifying all likely adverse impacts and demonstrating the public interest benefits outweigh them, addressing section 23(3)’s factors.

4. Necessity tests for service delivery (section 22):

   • For government service delivery projects, apply the narrow tests in section 22 to determine what personal information is necessary (e.g. contact information and eligibility information where services are under legislation).
   • Document why each data element proposed for sharing is necessary under the relevant paragraph in section 22.

Drafting the data sharing agreement and registration materials

1. Draft the data sharing agreement to incorporate all statements and contractual commitments the Code requires (sections 9-11, 14-15).
2. Where source data includes state/territory data obtained under a provisioning agreement, include the required particulars in the data sharing agreement and explain consistency with provisioning agreement conditions (section 25).
3. Prepare the registration package required by section 90(1)-(2) including: parties and capacities; entry date; project description; data description; whether personal information is to be shared; any statements required by subsections 16B(7) or 16B(8) of the Act; the title of any other law that would be contravened but for section 23; a public interest statement; final output description; circumstances under which output may exit the scheme; and expiry date (section 90(2)(a)-(m)).
4. Attach ethics approvals, security attestation documents, conflict registers, consent forms and relevant provisioning agreements as attachments to the registration submission where applicable (section 90(1)(b)).

Registration and Commissioner interaction (section 90-91)

1. Submit the information specified in section 90 in an approved form where available and include attachments and any other relevant documents.
2. For the Commissioner’s annual report inputs, ensure relevant notifications are provided within the applicable period, which the Code specifies as the period ending 31 July (section 91).

Operational compliance and ongoing management

1. Governance, training and access control:

   • Implement governance arrangements for data sharing projects: assign roles, log designated individuals, verify clearances and provide training in handling sensitive data (sections 11-12).
   • Enforce access controls and logging that map to the classes of individuals authorised in the data sharing agreement.

2. Conflict management systems:

   • Maintain systems to identify and manage conflicts of interest, and document them. For service delivery projects, obtain the representations required under section 9; for research/policy projects ensure contractual obligations and data custodian directions in place (sections 9-10).

3. Security monitoring and audits:

   • Implement security control monitoring and periodic audits or attestations of compliance with the security standards identified in the agreement and in section 13.
   • If Commonwealth security standards are applied to non‑Commonwealth entities, schedule remediation and compliance activities to meet those standards.

4. Consent lifecycle management:

   • Operate consent capture, storage, and withdrawal processes with time‑stamped records. Ensure exit and new custodian consents are obtained and recorded as express consents where required (sections 19-20).

5. ADSP oversight:

   • Where an ADSP is used, document the custodian’s consideration of treatment before sharing (section 14(3)) and include contractual obligations on the ADSP regarding de‑identification, access controls and outputs.

6. Documentation retention:

   • Retain public interest assessments, ethics approvals, conflict registers, consent records, security assessments and registration submissions to support future audits or Commissioner inquiries (section 90).

7. Transitional planning:

   • Review the forthcoming amendments referenced (Schedule 1 to the 2025 amending instrument) and determine whether agreements should be entered before or after 1 July 2025 depending on the operational and legal consequences (sections 100-101). Confirm the official legislative register for updates and possible corrigenda given the duplication in the instrument text.

Checklist summary mapped to Code provisions

• Project purpose and public interest statement: section 6(4)-(5)
• Ethics process identification and compliance: section 7
• Conflict identification, notification and management: sections 8-10
• Designated individuals attributes and experience: sections 11-12
• Security standard selection and mapping: section 13
• Data treatment and ADSP considerations: section 14
• Output controls and release protocols: section 15 and section 18 (consent for provision/release)
• Consent forms, express consent where required, capacity checks, withdrawal procedures: sections 17-20
• Impracticability evidence if not seeking consent: section 21
• Necessity tests for service delivery projects: section 22
• Public interest balancing for sharing without consent: section 23
• State/territory data and provisioning agreement mapping: section 25
• Registration package items and attachments: section 90(1)-(2)
• Notification timing for annual report: section 91
• Transitional application for 2025 amendments: sections 100-101

Following these steps and maintaining contemporaneous documentary evidence mapped to the specific Code provisions will position an entity to satisfy the Commissioner’s registration requirements and to demonstrate procedural compliance with the Act as operationalised by the Code.