Data Availability and Transparency (National Security Measures) Code 2022

The Code hinges on a small number of defined and cross‑referenced concepts in the Act and in the instrument itself.

• Accredited entity and designated individual. The Act defines “accredited entity” and “designated individual”, and the Code requires action by accredited entities concerning their designated individuals in relation to specific projects (see s 4 Note and s 5(1)). The Code uses the term responsible entity to mean the accredited entity for which the subject designated individual is listed (s 6(1)).

• ADSP‑enhanced data and output. Both are Act concepts referenced in the Code’s restrictions on who may be involved in an entity’s collection or use (s 5(1)). The Code therefore applies to the handling of both shared outputs and any enhanced dataset produced under the accredited data service provider framework.

• People principle. The Code operates to give effect to subsection 16(3) of the Act, the “people principle”. The Code does not restate that principle, but conditions the responsible entity’s ability to be satisfied that a project is consistent with it on procedural steps such as notifying ASIO and waiting 14 days (s 6(2)). Entities other than the responsible entity are in turn required to be informed in writing that the responsible entity has provided the material to ASIO and to observe the same 14‑day interval before they may be satisfied about compliance with the people principle (s 6(3)).

• Foreign individual / foreign entity. The instrument defines “foreign entity” in s 4 and uses immigration status for permanent resident as defined in the AusCheck Act 2007. The critical practical distinction for the Code is between designated individuals who are Australian citizens or permanent residents, and those who are not, with the latter subject to enhanced procedural requirements in ss 5-7.

• ASIO notification and 14‑day waiting period. Section 6 constructs a two‑step control: provision of a copy of the signed agreement together with specified personal and employment details to ASIO, and a mandatory minimum interval of 14 days after that provision before a responsible entity (and, by notice, other entities in the agreement) may be satisfied that the project meets the people principle (s 6(2)-(3), s 6(4) listing required fields).

• University special measures. Section 7 prescribes additional contractual obligations for Australian universities serving as accredited entities where non‑citizen, non‑permanent resident designated individuals will access data. The obligations are procedural and informational: carrying out due diligence, requiring the individual to undertake training in national security issues including foreign interference, and having regard to government guidance and reports on foreign interference in the higher education and research sectors (s 7(1)-(2)).

The Code therefore marries identity, immigration status and role delineation to procedural checks, time buffers, and sector‑targeted obligations. The instrument is procedural rather than creating new criminal offences or civil liability; it prescribes what a data sharing agreement must require accredited entities to do for particular classes of designated individuals (see s 5 and the opening note to s 4).

The Code affects participants in the data sharing framework established by the Act, with focus on accredited entities, their designated individuals, Australian universities that are accredited entities, data custodians, and ASIO as a notified recipient.

• Accredited entities. The instrument repeatedly places obligations on accredited entities, both as responsible entities and as parties to data sharing agreements. Section 5 requires accredited entities to ensure involvement in collection or use of outputs and ADSP‑enhanced data is restricted to designated individuals who meet citizenship/PR criteria or whose identifying and role details are specified in the agreement (s 5(1)-(2)). Section 6 obliges the responsible entity to provide material to ASIO and to await 14 days before being satisfied the project is consistent with the people principle (s 6(2)). Section 7 places further obligations on accredited entities that are Australian universities (s 7(1)).

• Designated individuals. The instrument directly affects designated individuals by mandating what information must be specified in the data sharing agreement for non‑citizens / non‑permanent residents, and what information must be provided to ASIO when such a person is permitted to access data (s 5(1)(b), s 6(4)). It also constrains their permitted role in a project to that described in the agreement (s 5(2)).

• Australian universities. Where an accredited entity is an Australian university and a designated individual permitted to access data is not an Australian citizen or permanent resident, the data sharing agreement must require due diligence and national security training for the individual, and require the university to have regard to government guidance on foreign interference in the sector (s 7(1)-(2)). This places sector‑specific compliance obligations on universities that are accredited entities.

• Data custodians. Although the Code is made under the Act and its measures are directed at accredited entities and their agreements, the instrument’s notes caution that a data custodian is not authorised to share data under s 13 unless it is satisfied that the project is consistent with the data sharing principles. The instrument therefore indirectly affects data custodians by altering what accredited entities must do in order to demonstrate that consistency (notes at s 6(2) and s 6(3)).

• Australian Security Intelligence Organisation. ASIO is the recipient of the specified material from the responsible entity (s 6(2)(a)(i)-(ii)), and the Code prescribes the nature of that material and the 14‑day interval that follows. The Code explicitly envisions an information flow to ASIO but does not prescribe ASIO’s actions after receipt.

• Parties to data sharing agreements beyond the responsible entity. Section 6(3) requires non‑responsible entities within an agreement to be informed in writing that the responsible entity has provided the material to ASIO and to observe the same 14‑day interval before being satisfied about the people principle. This creates an intra‑agreement coordination obligation.

In practical terms, the most immediate burdens fall on accredited entities and universities that are accredited entities when they want to allow non‑citizen, non‑permanent resident designated individuals to access shared data or outputs. The Code does not change the authorisations in s 13, 13A, 13B of the Act, but conditions the satisfaction of the people principle required to exercise those authorisations on compliance with the Code’s procedures (notes to s 6(2)-(3)).

The Code establishes duties for accredited entities and Australian universities in respect of designated individuals, and creates a process right in the form of a mandatory notice and waiting period involving ASIO. The instrument does not create new rights for designated individuals; rather, it prescribes information to be collected about them and procedures to be followed before access may proceed.

Principal duties

• Restrict involvement to specified designated individuals. Data sharing agreements must require accredited entities to ensure involvement in collection or use of outputs or ADSP‑enhanced data of a project is restricted to designated individuals who are Australian citizens or permanent residents, or to designated individuals for whom specified identity, nationality, role and designation details are recorded in the agreement (s 5(1)(a)-(b)). The duty is one of contractual obligation to include and enforce these restrictions.

• Limit roles to those described in the agreement. Where an agreement relies on paragraph 5(1)(b), the agreement must require that the individual’s involvement be restricted to the role described in the agreement (s 5(2)). This is a duty to confine access and use to pre‑specified roles.

• Notify ASIO and wait. If a responsible entity permits a designated individual who is neither a citizen nor a permanent resident to access data, the responsible entity cannot be satisfied that the project meets the people principle unless it has provided ASIO with a signed data sharing agreement and the detailed list of individual particulars in s 6(4), and 14 days have passed since providing that material (s 6(2)). Entities other than the responsible entity must be informed in writing that the responsible entity provided that material and must also observe the 14‑day interval before being satisfied about the people principle (s 6(3)).

• University‑specific duties. For Australian university accredited entities with non‑citizen, non‑permanent resident designated individuals, the data sharing agreement must require the university to carry out due diligence on the individual and ensure the individual undertakes training in national security issues including foreign interference, and to have regard to relevant government guidance and reports about foreign interference threats in the sector (s 7(1)-(2)).

Specified content duties

• Information required in agreements and to ASIO. The Code specifies the fields that must appear in the data sharing agreement for non‑citizen designated individuals (s 5(1)(b)(i)-(iv)), and lists the fuller set of details to be provided to ASIO (s 6(4)(i)-(x)). These are precise documentary duties that an accredited entity must collect, record and transmit as required.

Rights and limits

• No new statutory authorisations to share or collect data. The Code’s notes make clear that the Act’s existing authorisations under s 13 (data custodians sharing), s 13A and 13B (accredited entities collecting and using data) remain the legal basis for sharing and collecting; the Code does not grant new substantive rights to access data (notes to s 6(2)-(3)). Instead, it conditions the ability of responsible entities and other entities to be satisfied about consistency with the people principle on the procedural steps in the Code.

• Role confinement as contractual limitation. The limitation that a designated individual’s involvement must be restricted to the role described in the agreement (s 5(2)) is a contractual restriction that can be enforced between parties. The Code does not set criminal penalties for deviation; enforcement would be by the mechanisms available under the Act and the data sharing agreement.

Operational responsibilities

• Who decides? The accredited entity, acting as responsible entity where relevant, decides to provide the material to ASIO and the parties to the agreement decide to include the required provisions in the data sharing agreement. However, the entity cannot lawfully consider the project consistent with the people principle until the 14‑day window has passed after ASIO is notified (s 6(2)-(3)). ASIO’s role is passive in the instrument: receiver of the material, not an explicit approver within the Code.

• Record and evidence duties. The Code imposes documentary requirements on data sharing agreements and on the information to be supplied to ASIO. Entities must therefore create and retain records sufficient to demonstrate compliance with those requirements, so they can show they have been “satisfied” of the people principle consistent with the Act and the Code.

In aggregate, duties are procedural and documentary: identify and restrict who can access shared data, collect and provide specified personal and role information where necessary, observe a 14‑day interval after notifying ASIO, and for universities, perform due diligence and training obligations. These duties are framed as prerequisites to being satisfied the project complies with the Act’s people principle rather than as independent statutory licences.

The instrument itself does not create criminal offences or specify new civil penalties. It prescribes contractual and procedural requirements to be included in data sharing agreements and conditions on when accredited entities and data custodians may be satisfied that projects are consistent with the Act’s data sharing principles, in particular the people principle (see s 6 notes). Enforcement and penalties must therefore be read against the enforcement framework in the Act and the contractual arrangements in the data sharing agreement.

What the Code does not do

• No standalone sanctioning provisions. The Code contains no express penalty regime, infringement notices, or criminal sanctions. It does not create powers for ASIO to block access, nor does it specify remedial steps if an entity fails to provide required material or to wait the 14 days.

• Does not alter statutory authorisations. The Code does not change the Act’s substantive authorisations under s 13, s 13A or s 13B; rather, it makes compliance with procedural steps a condition to an entity being satisfied about the people principle and therefore to the exercise of sharing or collection powers under the Act (notes to s 6(2)-(3)).

Likely enforcement pathways

• Contractual remedies. Because the Code requires that data sharing agreements include particular obligations (s 5, s 7), compliance can be enforced contractually among parties to the agreement. Parties may contract for contractual remedies, including injunctive relief or damages, if a party breaches the agreement’s obligations to restrict access or to limit roles.

• Administrative action under the Act. The Act sets out the accreditation, audit and compliance regime for accredited entities. Although the Code does not create new sanctions, non‑compliance with the Code-based requirements could be relevant to regulatory action under the Act’s enforcement framework, including any conditions on accreditation and any powers the National Data Commissioner or other enforcement officials have under the Act to require compliance or to take administrative measures. The instrument itself points readers back to relevant Act provisions governing authority and authorisations in notes to s 6(2)-(3).

• Reputational and contractual consequences for universities. For Australian universities, failure to implement due diligence and training obligations required under s 7 could expose them to loss of trust from government and other data sharing counterparties, contract termination, or regulatory scrutiny under the Act’s accreditation system.

Evidence‑and‑satisfaction standard

• “Cannot be satisfied” standard. The Code repeatedly uses the language that an entity cannot be satisfied that the project is consistent with the people principle unless the notification and waiting requirements are met (s 6(2)-(3)). This is an evidentiary threshold rather than an express statutory prohibition. It imposes on entities an obligation to make a contemporaneous assessment and to ensure the procedural steps have been completed before proceeding. Failure to do so could mean the project is inconsistent with the Act’s requirements, which in turn has legal consequences under the Act for the lawfulness of data sharing and the authority to collect or use data.

Practical enforcement risks

• Compliance will depend on internal governance and audit controls within accredited entities to ensure data sharing agreements contain the required provisions and that ASIO notifications are made and documented. The absence of express sanctions in the Code makes enforcement depend on the interplay between contractual remedies, the Act’s regulatory regime, and ordinary law remedies for breach.

In summary, the Code prescribes compliance steps but leaves enforcement to the Act’s existing frameworks and to contract law; it does not itself create penalty clauses or enforcement powers against non‑compliant individuals or entities.

The Code is an instrument made under s 126 of the Act and therefore functions as a subordinate instrument that operationalises aspects of the Act, particularly the people principle in subsection 16(3) and the requirements in subsection 19(16) (see s 3 and notes in ss 5-6). Its interaction with other laws is expressed mainly by cross‑reference; the instrument itself does not amend other statutes.

Interactions explicitly referenced in the instrument

• Data Availability and Transparency Act 2022. The Code repeatedly references the Act. Section 3 states authority under s 126. Several provisions condition entities’ satisfaction about the people principle in subsection 16(3) of the Act on compliance with the Code’s procedural steps (s 6(2)-(3)). Section 5 supplies a prescription for what a data sharing agreement must require for the purposes of subsection 19(16) of the Act.

• AusCheck Act 2007. The instrument adopts the Act’s definition of “permanent resident” by reference to the AusCheck Act 2007, using that existing statutory meaning in determining who is treated as a domestic person for the Code’s purposes (s 4).

• Data Availability and Transparency Code 2022. The instrument explicitly cross‑references the Data Availability and Transparency Code 2022 as containing other requirements in relation to the people principle (notes to s 6(2)-(3)). Thus compliance with the national security measures Code must be read together with obligations in the broader Code addressing the people principle.

• Guidance and reports by other government agencies. Section 7(2) requires Australian universities to have regard to guidance and reports published by Australian government security or regulatory agencies responsible for regulating the higher education or research sectors, and gives as an example the Department of Education’s Guidelines to counter foreign interference in the Australian university sector. This makes the university obligations an intersection point between the data sharing framework and specialist advice/guidance produced under other statutes or administrative powers.

What the Code does not do

• It does not modify immigration law or create immigration consequences. Citizenship and permanent residency status are used as thresholds, with “permanent resident” defined by reference to the AusCheck Act, but the Code does not affect visa or immigration rights.

• It does not create new security intelligence powers. The Code requires notification to ASIO and a 14‑day waiting period, but does not confer new powers on ASIO, nor does it prescribe any action by ASIO during or after the 14‑day period.

• It does not override or replace the authorisations in s 13, s 13A or s 13B of the Act. The notes emphasize that a data custodian or accredited entity is not authorised to share or to collect/use data under these sections unless satisfied that the project is consistent with the data sharing principles, and the Code sets out procedural material necessary for that satisfaction in cases involving foreign individuals (notes to s 6(2)-(3)).

Potential compliance dependencies and friction points

• Contract law and administrative law. The Code’s substantive effect is to require particular contractual terms in data sharing agreements and particular administrative steps in an accreditation context. Consequently, compliance will require harmonising contractual drafting, internal governance, and administrative certification under the Act. Entities must ensure that inclusion of the Code’s requirements in agreements aligns with the Act’s overall compliance regime.

• Interagency guidance. The university obligations require regard to external guidance, which can evolve. The Code does not define the legal status of that guidance, so interaction will depend on whether such guidance is advisory or has statutory force under other laws. Section 7(2) leaves it to universities to have regard to the guidance.

In sum, the Code integrates into the Act’s existing architecture, imports definitions from other statutes for thresholds, and references external sectoral guidance for universities. It creates procedural dependencies between accredited entities and ASIO, and between accredited entities and other parties to data sharing agreements, but does not create new standalone statutory powers or offences.

The instrument includes a commencement table and an explicit note that the table relates only to provisions as originally made and will not be amended to deal with later amendments of the instrument (s 2 and accompanying note). The Code was made on 16 December 2022 by the National Data Commissioner and commenced the day after registration, listed as 22 December 2022 in the instrument’s commencement schedule (ss 1-2 and opening matter). Section 3 records the statutory authority as s 126 of the Data Availability and Transparency Act 2022.

There are no amendment provisions contained within the instrument itself. The instrument contains no schedules or transitional provisions varying its effect over time. It contains a standalone definition section (s 4) and the operative provisions in ss 5-7. The instrument’s text contains no subsequent amendment history, savings clauses, or references to earlier versions of the Code, and no dates other than the making date and commencement date are recorded.

The instrument’s commencement table carries a Note stating that it relates only to the provisions of the instrument as originally made and will not be amended to deal with any later amendments of the instrument. This indicates the published instrument is the original made version, and the instrument itself does not record subsequent amendments. Any future amendments would, in the ordinary course, be made by later instruments and would be recorded in consolidated legislative databases, but no such instruments or amendment records are included in the material provided.

Because the instrument is made under the Act, any amendment of the Code would be via a subsequent legislative instrument made under the Act’s delegating provision, s 126, and subject to the usual disallowance and registration processes in the Legislative Instruments Act 2003. The instrument does not itself set out an amendment or repeal process beyond the normal statutory instrument framework.

Given the absence of recorded amendments in the supplied text, the operative historical facts in this instrument are: made by the National Data Commissioner on 16 December 2022, registered and taken to commence 22 December 2022, and no amendments or repeals are recorded in the instrument as provided.

The instrument contains no references to judicial or administrative decisions. It names no cases, cites no precedent, and the text includes no account of disputes or litigation regarding its operation. The instrument’s notes also do not cite any judicial or tribunal determinations.

Because the Code is a statutory instrument under the Act, litigation that might arise would be expected to proceed under the Act’s statutory framework and general administrative law, but the instrument provides no history or examples of such litigation. The Code itself does not create new offences, and so any litigation would most likely concern:

• disputes about whether an accredited entity or data custodian complied with the procedural and documentary obligations in data sharing agreements required by the Code (contractual or administrative review challenges);

• judicial review applications challenging administrative decisions made under the Act that rely on an entity’s satisfaction about the people principle, in circumstances where the decision‑maker did or did not apply the Code’s requirements correctly; or

• disputes between parties to a data sharing agreement about whether a designated individual’s access exceeded the role described in the agreement (s 5(2)).

None of these hypothetical litigation pathways are reflected in the instrument text. Absent any cases or litigation references in the supplied document, the Code’s litigation history in the material provided is nil.

The Code contains precise documentary and procedural prescriptions that create several practical pitfalls for accredited entities, universities and data custodians. Below are points that require attention because they are explicit in the instrument and may be missed in practice.

1. “Cannot be satisfied” is the operative constraint, not a prohibition. Sections 6(2)-(3) do not state a criminal prohibition on allowing non‑citizen designated individuals access. They say the responsible entity or other entity cannot be satisfied that the project is consistent with the people principle unless the entity provides ASIO with specified material and waits 14 days. The legal consequence is that sharing or collection powers that rely on satisfaction of the people principle will be unavailable if the procedural steps are not completed. Entities must therefore document satisfaction only after meeting the Code’s steps, or they risk acting without the necessary evidentiary foundation required by the Act (see notes to s 6(2)-(3)).

2. Detail required in agreements is not limited to name and role. Section 5(1)(b) requires data sharing agreements to specify full name, previous names, preferred name, nationality(ies), applicable designation under s 123 of the Act, and a description of the individual’s proposed role in the project. Section 6(4) requires an expanded set of fields to be provided to ASIO, including date and place of birth, current employment and contractual arrangements (with geographical locations), any authorisations to act as agent of foreign governments or entities, work and personal contact details, and the designation under s 123 of the Act. Failing to collect and transmit this fuller set of details will leave the responsible entity unable to satisfy the people principle.

3. Role restriction is contractual and may require operational controls. Section 5(2) requires the agreement to restrict the individual’s involvement to the role described in the agreement. In practice, entities need internal access controls, role‑based permissions, logging, and audits to ensure individuals cannot exceed the role. A data sharing agreement alone is not operational; entities must translate role descriptions into technical and managerial controls.

4. ASIO notification is passive but mandatory. The Code requires the responsible entity to provide an electronic copy of the signed agreement and the details in s 6(4) to ASIO, and to wait 14 days. The instrument does not describe how to provide material to ASIO, what receipt or acknowledgement is required, or what happens within the 14‑day window. Entities must therefore establish procedures to transmit the material, obtain proof of transmission, and retain evidence of the 14‑day compliance period.

5. Unclear consequences if ASIO requests further information. The Code prescribes what must be provided, but is silent on whether ASIO may request more information, whether the 14‑day period restarts if further information is provided, or whether any negative or positive response from ASIO is required. Entities must plan for uncertainty about ASIO’s follow‑up and how to record that they have complied with the instrument.

6. Inter‑party notification duties. Section 6(3) requires entities other than the responsible entity to be informed in writing by the responsible entity that the responsible entity has provided material to ASIO, and to wait 14 days from being so informed. Parties cannot rely on tacit knowledge; the Code requires explicit written notice. Agreements and governance must therefore include a clear written notification path.

7. Universities have extra obligations and a dynamic guidance environment. Section 7 requires universities to perform due diligence, require national security training for the individual, and have regard to government guidance and reports, including Department of Education guidance. Universities must therefore monitor relevant guidance and records of due diligence and training, which can create ongoing compliance and record‑keeping burdens.

8. “Permanent resident” definition is external. The Code uses the AusCheck Act 2007 meaning of permanent resident (s 4). Entities must rely on that statute to determine which threshold applies, including how the AusCheck Act defines or evidences permanent residency.

9. The Code cross‑references other Codes and provisions. The instrument repeatedly points to obligations and requirements in the Data Availability and Transparency Code 2022 and to the people principle in the Act. Entities must consider those other instruments and provisions when implementing the Code’s steps; compliance is not satisfied by addressing the Code in isolation.

10. No express timelines other than the 14 days. Apart from the 14‑day waiting period, the Code contains no timing deadlines for when the material must be provided to ASIO relative to the commencement of a project, nor does it set retention periods for records. This could create ambiguity about when an entity has actually completed the procedural step and is entitled to be “satisfied” about the people principle.

These are not abstract risks; they derive from the precise words of ss 5-7 and the explanatory notes within the instrument. Entities should map these gotchas into contractual drafting, operational controls, and record‑keeping to ensure they can demonstrate compliance.

Compliance with the Code requires integrating contractual drafting, identity and role verification, ASIO notification processes, internal governance and sector‑specific steps for universities. Below is a practical checklist, structured against the Code’s operative provisions, which accredited entities and universities should follow to meet the instrument’s requirements.

1. Contract drafting and inclusion of required clauses (s 5(1)-(2))

   • Ensure every data sharing agreement expressly restricts involvement in the entity’s collection or use of outputs, and ADSP‑enhanced data, to designated individuals who are either Australian citizens or permanent residents, or to designated individuals for whom the agreement specifies:
     • full name, any previous names, and preferred name (s 5(1)(b)(i));
     • nationality or each nationality if more than one (s 5(1)(b)(ii));
     • the applicable designation under s 123 of the Act (s 5(1)(b)(iii));
     • a description of the individual’s proposed role in the project (s 5(1)(b)(iv)).
   • Include a clause that explicitly restricts any non‑citizen, non‑PR designated individual to the role described in the agreement and sets out remedies for breaches of role restrictions (s 5(2)).

2. Collect and verify required personal and role information for foreign designated individuals (s 6(4))

   • For any designated individual who is neither an Australian citizen nor a permanent resident and who is permitted to access data, collect and retain:
     • name history and preferred name; nationality(ies); date and place of birth (s 6(4)(i)-(iii));
     • current employment details including employer and geographic location, and any current contractual arrangements for service provision with geographic locations (s 6(4)(iv)-(v));
     • any current or previous authorisations to act as agent of foreign governments, authorities or other foreign entities (s 6(4)(vi));
     • current work and personal email addresses, work telephone number and personal mobile telephone number (s 6(4)(vii)-(viii));
     • the applicable designation under s 123 of the Act and a description of the proposed role in the project (s 6(4)(ix)-(x)).

3. ASIO notification and documentation (s 6(2))

   • Prepare an electronic package containing:
     • an electronic copy of the signed data sharing agreement (s 6(2)(a)(i));
     • the full set of individual details required by s 6(4) (s 6(2)(a)(ii)).
   • Establish an auditable transmission method to send the package to ASIO, and obtain and retain proof of transmission. Although the Code does not specify the method of delivery or required acknowledgement, entities should keep contemporaneous records showing that the material was provided.
   • Only after 14 days have passed from the date the material was provided to ASIO should the responsible entity consider itself able to be satisfied that the project is consistent with the people principle (s 6(2)(b)). Record the date of provision and the date after which satisfaction is documented.

4. Notify other entities to the agreement in writing (s 6(3))

   • The responsible entity must provide written confirmation to other entities party to the data sharing agreement that the ASIO notification has been made. Those entities must then observe a 14‑day interval from the date of being informed before they may be satisfied about the people principle (s 6(3)(a)-(b)).
   • Maintain a record of the written notification and its date to demonstrate the start of the 14‑day period for all parties.

5. University‑specific measures (s 7(1)-(2))

   • If an accredited party to the agreement is an Australian university and a designated individual who is not a citizen or permanent resident will access data:
     • carry out due diligence on the individual prior to granting access, and document the due diligence completed (s 7(2)(a));
     • ensure the individual undertakes training in national security issues including foreign interference, and retain evidence of completion of that training (s 7(2)(a));
     • have regard to relevant government guidance and reports about foreign interference threats in the higher education and research sectors, and document the guidance considered and how it informed due diligence and training (s 7(2)(b)).
   • Integrate those steps into admission, appointment, and project on‑boarding processes for research staff, visiting researchers and contractors who will be designated individuals under a data sharing agreement.

6. Operational and technical controls

   • Implement role‑based access controls, least privilege principles, logging and monitoring to ensure that a designated individual’s actual access aligns with the role described in the agreement, as required by s 5(2).
   • Maintain audit trails demonstrating compliance with role restrictions, ASIO notification, and the 14‑day waiting period.
   • Store and protect the personal information collected under ss 5 and 6 in accordance with applicable privacy and data security requirements, noting the sensitivity of the details required (s 6(4)).

7. Governance, policy and training

   • Update organisational policies and governance procedures to incorporate the Code’s obligations, including templates for data sharing agreements that include the required clauses and a process owner for ASIO notifications.
   • Train compliance, legal, contracting and project teams on the requirement to collect specified information, to notify ASIO, to observe the 14‑day period, and to restrict roles in practice.
   • For universities, develop or source national security training that addresses foreign interference topics and maintain records of training completion.

8. Record retention and evidence

   • Keep records proving that the signed agreement and the s 6(4) details were provided to ASIO on a specific date, and that at least 14 days elapsed before satisfaction was recorded.
   • Preserve evidence that other entities to the agreement were informed in writing of the ASIO notification and the date of that notification.

9. Legal review and alignment with the Act

   • Confirm that inclusion of the Code’s clauses aligns with the Act’s broader requirements and with the Data Availability and Transparency Code 2022, because the instrument points to other people principle requirements in that Code (notes to s 6(2)-(3)).
   • Ensure that data custodians and accredited entities are clear about when sharing and collection authorisations under s 13, s 13A and s 13B of the Act are engaged, and that they do not proceed to exercise those powers unless the people principle has been satisfied in light of the Code.

10. Monitor guidance and update processes

• For universities, monitor government guidance and reports on foreign interference and update due diligence and training programmes accordingly (s 7(2)(b)).
• For all entities, monitor any procedural guidance the National Data Commissioner or ASIO may publish about how notifications should be made, and incorporate that guidance into operational processes.

Following these steps will align an accredited entity’s contractual documents, operational practices and compliance records with the Code’s requirements, and will create the documentary trail necessary to demonstrate that the organisation was entitled to be “satisfied” that a project met the Act’s people principle after the procedural steps were completed.