Digital ID (Accreditation) Rules 2024 (Cth)

Digital ID (Accreditation) Rules 2024

I, Katy Gallagher, Minister for Finance, make the following rules.

Dated 7 November 2024

Katy Gallagher

Minister for Finance

Contents

1. •
2. •
3. •
4. •

1. •
2. •

1. •
2. •
3. •
4. •
5. •
6. •
7. •

1. •
2. •

1. •
2. •
3. •
4. •

1. •

1. •
2. •
3. •

1. •
2. •
3. •

1. •
2. •
3. •

1. •

1. •

1. •
2. •
3. •
4. •
5. •

1. •
2. •
3. •
4. •
5. •
6. •
7. •
8. •
9. •
10. •
11. •
12. •
13. •
14. •
15. •
16. •
17. •

1. •

1. •
2. •
3. •
4. •
5. •
6. •

1. •
2. •

1. •
2. •
3. •

1. •
2. •
3. •
4. •
5. •
6. •
7. •
8. •
9. •
10. •
11. •

1. •
2. •
3. •

1. •
2. •

1. •
2. •

1. •
2. •
3. •
4. •
5. •
6. •
7. •
8. •
9. •

1. •
2. •
3. •
4. •
5. •
6. •
7. •
8. •
9. •
10. •
11. •
12. •
13. •
14. •

1. •
2. •
3. •
4. •
5. •

1. •

1. •

1. •
2. •
3. •
4. •

1. •
2. •

1. •
2. •
3. •
4. •
5. •

1. •
2. •
3. •
4. •

1. •
2. •

1. •

1. •
2. •
3. •

1. •

1. •

Chapter 1—Preliminary

1.1Name

These rules are the Digital ID (Accreditation) Rules 2024.

1.2Commencement

These rules commence at the same time as the Digital ID Act 2024 commences.

1.3Authority

These rules are made under section 168 of the Digital ID Act 2024 for the purposes of the provisions in the Act in which the term ‘Accreditation Rules’ occurs.

1.4Definitions

Note: A number of expressions used in these rules are defined in the Act, including the following:

(a) accredited entity;

(b) attribute;

(c) digital ID;

(d) participating relying party;

(e) personal information.

Note 2: A number of expressions used in these rules are defined in the Accreditation Data Standards, including the following:

(a) AL Table;

(b) authentication level;

(c) in-device biometric capability;

(d) out-of-band device.

1. (1)

   Expressions defined in the Accreditation Data Standards have the same meaning in these rules.

2. (2)

   In these rules:

accessibility and useability assessment means an assessment conducted in accordance with rule 3.7.

accountable executive, of an entity, means a senior executive of the entity responsible for the overall management of the entity’s DI data environment, proposed accredited services and accredited services.

Accreditation Data Standards means the Digital ID (Accreditation) Data Standards 2024.

acquired image means an image of an individual’s face that is used as a sample for biometric matching against the corresponding image from the individual’s photo ID.

ACSC means the Australian Cyber Security Centre.

Act means the Digital ID Act 2024.

alternative proofing process:see rule 5.22.

annual review: see rule 6.1.

applicant: see rule 1.9.

approved cryptography means:

1. (a)

   Australian Signals Directorate Approved Cryptographic Algorithms; and

2. (b)

   Australian Signals Directorate Approved Cryptographic Protocols,

as each is defined either in the ISM or the document Implementing Certificates, TLS, HTTPS and Opportunistic TLS published by the Australian Signals Directorate.

Note: At the time these rules were made, located at means an accredited attribute service provider.

assessing officer means a member of personnel of an applicant or accredited entity who is trained and authorised by that entity to conduct local biometric binding or manual face comparison.

assessor: see rule 3.2.

assessor’s report: see rule 3.17.

assurance assessment means a protective security assessment, fraud assessment or accessibility and useability assessment.

Australian passport has the same meaning asin the Australian Passports Act 2005.

authoritative sourcemeans a person that issues documents or other credentials containing information about an individual.

biometric binding meansthe process of confirming the link between an individual and a photo ID by conducting biometric matching for the purpose of obtaining IP2 Plus, IP3 or IP4.

Note: See item 4 of the IP Levels Table.

biometric capability, in relation to an applicant or accredited entity,means the components of the entity’s DI data environment that process or are involved in the processing of biometric information (including for biometric binding and biometric matching).

biometric matching means one-to-one comparison of an individual against the image on their photo ID.

biometric matching algorithm means the algorithm used to conduct biometric matching.

commencement of identity credential or CoI credential means a document or other credential listed in Schedule 1.

Note: A commencement of identity credential evidences an individual’s commencement of identity in Australia.

cryptographic key means a string of characters used with approved cryptography to encrypt and decrypt.

cyber security risk means the risk of a cyber security incident occurring in relation to an entity’s DI data environment, proposed accredited services or accredited services.

cyber security risk assessment: see rule 4.7.

data breach means loss or misuse of, unauthorised access to, or unauthorised modification or disclosure of, personal information held by an applicant or accredited entity.

DI data environment means digital ID data environment.

digital ID data environment means the information technology systems used for, and the processes that relate to:

1. (a)

   for an applicant—the provision of the entity’s proposed accredited services; or

2. (b)

   for an accredited entity—the entity’s accredited services.

Digital ID Rules means the Digital ID Rules 2024.

eIDVT means electronic identity document verification technology that uses non-cryptographic techniques to classify physical documents or other credentials submitted online by an individual as being genuine or not genuine.

eIDVT biometric matching means biometric matching that uses a facial image acquired from a photo ID that has been classified as a genuine document by eIDVT to match against an acquired image.

ePassport means a travel document size 3 machine readable travel document conforming to the specifications of Part 4 of the ICAO Doc 9303 Standard that additionally incorporates a contactless integrated circuit.

fraud assessment means an assessment conducted in accordance with rule 3.6.

fraud control plan: see rule 4.31.

fraud controller: see rule 4.27.

fraud management capability: see rule 4.24.

fraud risk means the risk of a digital ID fraud incident occurring.

fraud risk assessment: see rule 4.25.

hold: an entity holds personal information if the entity has possession or control of a record that contains the personal information.

ICAO Doc 9303 Standard means the standard for machine readable travel documents published by the International Civil Aviation Organisation.

Note: At the time these rules were made, located at proofing means the process to verify an attribute of an individual to generate, manage or maintain the digital ID of the individual.

identity proofing level or IP level means a level specified in the first row of the IP Levels Table.

image quality profile means the profile that captured biometric information is compared against to ensure that it meets a threshold for information quality before being used for biometric binding or authentication.

IP Levels Table means the table in rule 5.10.

ISM means the Australian Government Information Security Manual published by the ACSC.

Note: At the time these rules were made, located at 29794-5 means Part 5 (concerning face image data) of the series of standards designated ISO/IEC 29794 (concerning biometric sample quality), published by the International Organization for Standardization.

Note: At the time this instrument was made, the current version was ISO/IEC TR 29794-5:2010, located at 27001 means the standard for information security management systems, published by the International Organization for Standardization.

Note: At the time this instrument was made, the current version was ISO/IEC 27001:2022, located at

ISO/IEC 30107-1 means Part 1 (concerning framework) of the series of standards designated ISO/IEC 30107 (concerning biometric presentation attack detection), published by the International Organization for Standardization.

Note: At the time this instrument was made, the current version was ISO/IEC 30107-1:2023, located at 24745 means the standard for information security, cybersecurity and privacy protection, published by the International Organization for Standardization

Note: At the time this instrument was made, the current version was ISO/IEC 24745:2022, located at means an accredited identity service provider.

IXP means an accredited identity exchange provider.

linking credential means a document or other credential listed in Schedule 2.

Note: A linking credential demonstrates the continuity of the individual’s verified identity if that individual’s attributes have changed.

liveness detection means the measurement and analysis of biometric, biological and behavioural characteristics or involuntary or voluntary reactions of the live presentation of an individual, in order to determine if a biometric sample is being captured from a living individual who is physically present at the place and time when the biometric sample is captured.

local biometric binding meansbiometric binding conducted by and in the physical presence of an entity’s assessing officer.

manual face comparison means the process of using visual verification to compare the likeness of an individual to the individual’s claimed photo ID, conducted by, and in the physical presence of, an entity’s assessing officer.

material change, in relation to an entity, means any change that alone or cumulatively results in, or is reasonably likely to result in:

1. (a)

   a material or adverse impact on the entity’s DI data environment, proposed accredited services or accredited services; or

2. (b)

   an adverse impact on the entity’s ability to comply with the Act, these rules or the Accreditation Data Standards.

Note: The definition of ‘material change’ in these rules is different to the definition of the same expression in the Digital ID Rules.

online biometric binding means biometric binding conducted remotely via unsupervised data capture processes conducted across the internet.

penetration testing means testing conducted in accordance with Division 1 of Part 3.3 of Chapter 3.

personnel, of an entity, means:

1. (a)

   an employee of the entity; or

2. (b)

   an individual who, under a labour hire, consultancy or similar arrangement with the entity, performs work for the entity in relation to its proposed accredited services or accredited services.

photo ID means a document or other credential listed in Schedule 4.

physical authenticator: see rule 5.25.

presentation attack means the presentation of an artefact to a biometric data capture subsystem with the goal of interfering with the expected operation of the biometric capability.

presentation attack detection means automated discrimination between bona-fide presentations and presentation attacks.

presentation attack instrument means an object or biometric characteristic that is used in a presentation attack.

Privacy Actmeans the Privacy Act 1988.

proposed accredited services, in relation to an applicant, means the services proposed to be provided by the entity in its application under section 14 of the Act for accreditation as an accredited entity.

protective security assessment means an assessment conducted in accordance with Division 1 of Part 3.2 of Chapter 3.

protective security capability: see Division 1 of Part 4.1 of Chapter 4.

protective security framework: see Division 2 of Part 4.1 of Chapter 4.

PSPFmeans the Protective Security Policy Framework published bythe Australian Government.

Note 1: At the time these rules were made, located at 2: The specific controls in the PSPF to be implemented are listed in Schedule 5.

public-facing proposed accredited services, in relation to an applicant, means the proposed accredited services or elements of the entity’s information technology system that an individual directly interacts with when using, or attempting to use, the entity’s proposed accredited services.

public-facing accredited services, in relation to an accredited entity,means the accredited services or elements of the entity’s information technology system that an individual directly interacts with when using, or attempting to use, the entity’s accredited services.

Example: An example of public-facing accredited services is where an individual provides information to be verified via an ISP’s mobile app that the individual is required to download so as to access the entity’s accredited services.

public-facing information related to proposed accredited services, in relation to an applicant, means information made available by the entity to individuals when interacting with the entity’s public-facing proposed accredited services.

public-facing information related to accredited services, in relation to an accredited entity, means information made available by the entity to individuals when interacting with the entity’s public-facing accredited services.

Example: Public-facing information related to accredited services is the accredited entity’s privacy policy made available to individuals.

reporting period, for an accredited entity: see rule 6.1.

Note: Chapter 6 requires an accredited entity to conduct an annual review, and report on that review, in each 12-month reporting period.

reusable digital ID means a digital ID verified for multiple uses by binding an authenticator to the digital ID.

risk assessment means the systematic, iterative and collaborative process of identification, analysis and evaluation of risk.

source biometric matching means the process of using source verification to verify that an acquired image biometrically matches the image on the document or other credential held by the authoritative source.

source verification means the process of verifying an attribute of an individual or a document or other credential in relation to the individual:

1. (a)

   with the authoritative source for that attribute or document or other credential; or

2. (b)

   through information provided by a service that confirms the veracity of the attribute or document or other credential with an authoritative source.

Note: A service that confirms the veracity of information includes a DVS or FVS (within the meaning of those terms in the Identity Verification Services Act 2023).

special attribute: see rule 5.32.

Note: An ASP is accredited to verify and manage a special attribute of an individual such as an authorisation for, or qualification of, an individual.

statement of scope and applicability means a statement that lists:

1. (a)

   for an applicant:

   1. (i)

      each requirement in these rules and the Accreditation Data Standards with which the entity must comply in relation to its proposed accredited services if accredited; and

   2. (ii)

      the evidence that demonstrates the entity will comply with those requirements if accredited; or

2. (b)

   for an accredited entity:

   1. (i)

      each requirement in these rules and the Accreditation Data Standards with which the entity must comply in relation to its accredited services; and

   2. (ii)

      the evidence that demonstrates the entity complies with those requirements.

system security plan: see rule 4.12.

systems testing means penetration testing, useability testing or WCAG testing.

taking reasonable steps: seerule 1.5.

technical biometric matchingmeans the process of verifying that an acquired image biometrically matches the image of the individual on the document or credential, where the document or credential and the image have been verified using technical verification.

technical testing means testing of information technology systems by executing the user flows, user interactions and component interactions.

technical verification means the process of verifying, via public key infrastructure technology, physical or electronic documents or other credentials using approved cryptography.

transitioned accredited entity means an entity taken to be accredited immediately after commencement of the Actin accordance with item 2 of Schedule 1 to the Digital ID (Transitional and Consequential Provisions) Act 2024.

UitC credential means a document or other credential listed in Schedule 3.

Note: A UitC credential evidences an individual’s use in the Australian community of the individual’s identity.

useability testing means testing conducted in accordance with Division 2 of Part 3.3 of Chapter 3.

visa has the same meaning as in the Migration Act 1958 and includes an entry permit (within the meaning of that term in the Migration Act 1958 as in force immediately before 1 September 1994).

visual verification means visually confirming that a document or other credential presented by an individual in‑person, and information on that document or other credential, is legitimate.

WCAG means the Web Content Accessibility Guidelines version 2.1 published by the World Wide Web Consortium.

Note: At the time these rules were made, located at World Wide Web Consortium is commonly known as ‘W3C’.

WCAG testing means testing conducted in accordance with Division 3 of Part 3.3 of Chapter 3.

1.5Meaning of taking reasonable steps

In these rules, taking reasonable steps, in relation to a duty to ensure an identified outcome, means taking steps that are, or were at a particular time, reasonably able to be done in relation to ensuring that outcome, taking into account and weighing up all relevant matters including:

1. (a)

   the likelihood of risks to achievement of the outcome occurring;

2. (b)

   the degree of harm that might result if the outcome is not achieved;

3. (c)

   what the person who has the duty knows, or ought reasonably to know, about:

   1. (i)

      the risks to achievement of the outcome; and

   2. (ii)

      ways of eliminating or minimising the risks;

4. (d)

   the availability and suitability of ways to eliminate or minimise the risks; and

5. (e)

   after assessing the extent of the risks and the available ways of eliminating or minimising them, the cost associated with available ways of eliminating or minimising the risks, including whether the cost is grossly disproportionate to the risks.

1.6Meaning of authenticated session

For the purposes of subsection 56(3) of the Act:

authenticated session means a persistent interaction between 2 entities involved in a transaction in a digital ID system which begins with an authentication event and ends with an event that brings the authenticated session to an end.

Note: The session could terminate after a specific period, or on the occurrence of a specific event such as the individual closing the browser or logging out.

authentication event means the process of an individual using their authenticator to verify that they are the valid user of a digital ID.

1.7Incorporated instruments

1. (1)

   If a provision of these rules incorporates or applies, with or without modification, matters contained in any other instrument or other writing (incorporated instrument), then, unless the contrary intention appears in the provision, the reference to the incorporated instrument is a reference to the incorporated instrument as in force or existing from time to time.

2. (2)

   Unless the contrary intention appears in these rules, an accredited entity is not required to comply with a change to an incorporated instrument until 12 months after the change to the incorporated instrument has taken effect.

   Note: See subsection 167(3) of the Act.

3. (3)

   Subrule (2) does not apply if the incorporated instrument is an Act or a legislative instrument.

1.8

Application—transitioned accredited entities

1. (1)

   A provision in column 1 of an item in the following table applies to a transitioned accredited entity starting on the day that is 12 months after the day on which these rules commence, subject to the exception (if any) in column 2 of that item.

Application of these rules to transitioned accredited entities
Item	Column 1	Column 2
Provision	Exception
1	rule 4.14
2	rule 4.19
3	subrules 4.20(3) and (4)
4	paragraph 4.22(2)(b)
5	subrule 4.38(3)	The requirements in relation to privacy policies in this subrule apply to a transitioned accredited entity on and from the commencement of these rules.
6	subrule 4.41(3)
7	subrule 4.42(2)
8	paragraph 4.50(3)(c) and subrules 4.50(4), (5) and (6)
9	rule 4.51
10	rule 5.2
11	rule 5.7
12	subrule 5.9(2)

1. (2)

   Every provision of these rules not specified in subrule (1) applies to a transitioned accredited entity in accordance with its terms and on and from the commencement of these rules.

1.9Application—applicants

1. (1)

   These rules apply to an entity (an applicant):

   1. (a)

      that has made an application under section 14 of the Act for accreditation as an accredited entity; and

   2. (b)

      at the time the entity applies for such accreditation.

2. (2)

   These rules apply to, and in relation to, an applicant with the modifications in this rule.

3. (3)

   If, because of Chapter 2 and subrule (4):

   1. (a)

      an applicant is required to implement any measure in accordance with, or comply with, a provision in Chapter 3, 4 or 5 of these rules, or a provision in the Act or Accreditation Data Standards—the applicant must implement that measure in accordance with, or comply with, that provision as if the applicant is an accredited entity that is accredited to provide its proposed accredited services; and

   2. (b)

      the ability or capacity of an applicant to implement any measure in accordance with, or comply with, a provision in Chapter 3, 4 or 5 of these rules, or a provision in the Act or Accreditation Data Standards, is to be assessed—the assessment is to be undertaken as if the applicant were an accredited entity that is accredited to provide its proposed accredited services.

4. (4)

   For the purposes of Chapter 2, an expression in column 1 of an item in the following table that appears in Chapter 3, 4 or 5 of these rules, or in a provision of the Act or Accreditation Data Standards, applies to, or in relation to, an applicant subject to the modification in column 2 of that item.

Application of these rules to applicants
Item	Column 1	Column 2
Expression	Modification
1	accredited entity	to be taken as a reference to an applicant.
2	accredited services	to be taken as a reference to proposed accredited services.
3	ASP	to be taken as a reference to an applicant who has applied to be an ASP.
4	digital ID fraud incident	to be taken to include an act, event or circumstance that occurs in connection with a proposed accredited service of an applicant and results in any of the circumstances in paragraph (b) of the definition of ‘digital ID fraud incident’ in section 9 of the Act.
5	ISP	to be taken as a reference to an applicant who has applied to be an ISP.
6	IXP	to be taken as a reference to an applicant who has applied to be an IXP.
7	public-facing accredited services	to be taken as a reference to public-facing proposed accredited services.
8	public-facing information related to accredited services	to be taken as a reference to public-facing information related to proposed accredited services.

Chapter 2—Applying for accreditation

2.1DI data environment

For the purposes of paragraph 15(4)(d) of the Act, the Digital ID Regulator must not accredit an applicant unless the Regulator is satisfied that the applicant:

1. (a)

   has correctly identified, defined and documented the boundaries of its DI data environment, including:

   1. (i)

      the people, processes, technology and infrastructure that will manage, secure, store or otherwise interact with the information generated, collected, used, held or disclosed for the purpose of providing its accredited services, if the applicant is accredited; and

   2. (ii)

      the infrastructure owned by, and management provided by, any contractor engaged, or proposed to be engaged, by the applicant to provide a proposed accredited service, or part of a proposed accredited service, if the applicant is accredited;

2. (b)

   has limited the boundaries of its DI data environment to the extent practicable, including by:

   1. (i)

      segregating the environment from other systems;

   2. (ii)

      minimising the number of people who interact with the information referred to in paragraph (a);

   3. (iii)

      limiting the number of systems hosting, processing or accessing the information referred to in paragraph (a); and

   4. (iv)

      minimising the use of contracted service providers interacting with the information referred to in paragraph (a).

2.2

Documents to accompany application

For the purposes of paragraph 141(1)(c) of the Act, an application made by an applicant must be accompanied by:

1. (a)

   a statement of scope and applicability; and

2. (b)

   a statement, signed by the applicant’s accountable executive, attesting that:

   1. (i)

      the technical testing required by rule 2.5 has been conducted;

   2. (ii)

      the accountable executive is satisfied the results of the technical testing demonstrate that the requirements listed in subrule 2.5(2) are met; and

   3. (iii)

      if a cloud service provider has conducted penetration testing as required by paragraph 3.8(4)(a)—the applicant is satisfied that that penetration testing covers the kinds of penetration testing in subrule 3.8(2); and

3. (c)

   for biometric testing conducted as required by paragraph 2.3(3)(e), copy of reports of the testing and any required responses to the reports.

Note: An approved form for an application may require additional information and documents to be provided (see section 141 of the Act).

2.3Criteria to be met

1. (1)

   An applicant must meet the criteria in this rule.

2. (2)

   At the time an applicant applies for accreditation, the information technology system through which it will provide its accredited services if accredited must be operational.

3. (3)

   The applicant must, at the time it applies for accreditation, have conducted:

   1. (a)

      assurance assessments in accordance with Chapter 3;

   2. (b)

      systems testing in accordance with Chapter 3;

   3. (c)

      a privacy impact assessment in accordance with rule 2.4;

   4. (d)

      technical testing in accordance with rule 2.5;

   5. (e)

      if the applicant will conduct biometric binding if accredited—biometric testing in accordance with the Accreditation Data Standards;

   6. (f)

      a cyber security risk assessment in accordance with rule 4.7; and

   7. (g)

      a fraud risk assessment in accordance with rule 4.25.

2.4Privacy impact assessment

1. (1)

   The applicant must, at the time it applies for accreditation, have conducted a privacy impact assessment in accordance with this rule.

2. (2)

   The privacy impact assessment must:

   1. (a)

      assess the privacy impacts of:

      1. (i)

         the applicant’s DI data environment and the boundaries of that environment as identified, defined, documented and limited in accordance with rule 2.1; and

      2. (ii)

         the applicant’s proposed accredited services;

   2. (b)

      be conducted by a person who:

      1. (i)

         has appropriate experience, training and qualifications to conduct a privacy impact assessment;

      2. (ii)

         is external to the applicant and, if the applicant is part of a corporate group, external to the group; and

      3. (iii)

         is not, and has not, been involved in the design, implementation, operation or management of the applicant’s proposed accredited services or DI data environment; and

   3. (c)

      include:

      1. (i)

         details of the flow of personal information into, within and from the applicant’s DI data environment;

      2. (ii)

         an assessment of the relevant documentation, processes and mechanisms to facilitate the applicant’s compliance with the privacy requirements specified in Chapter 3 of the Act and Part 4.3 of Chapter 4 of these rules;

      3. (iii)

         an analysis of how the applicant’s provision of its proposed accredited services will impact the privacy of individuals and protection of personal information, if the applicant is accredited, including how the applicant will comply with any applicable requirements in Chapter 5 of these rules and the Accreditation Data Standards;

      4. (iv)

         an analysis of whether any privacy risks or impacts identified in the privacy impact assessment are necessary or unavoidable;

      5. (v)

         any recommendations made by the person who conducted the assessment, including recommendations that the applicant undertake activities to mitigate any identified privacy risks;

      6. (vi)

         whether any recommendations of the person who conducted the privacy impact assessment to mitigate any privacy risks or impacts have been accepted and, if not, why actions to address such risks or recommendations are not necessary; and

      7. (vii)

         details of consultation with relevant stakeholders.

3. (3)

   The applicant must respond in writing to the findings of the privacy impact assessment.

4. (4)

   The applicant’s response to the privacy impact assessment must be signed by the applicant’s accountable executive.

5. (5)

   For each risk or recommendation identified by the privacy impact assessment, the applicant must:

   1. (a)

      develop a risk matrix based on an established risk management framework or standard;

   2. (b)

      conduct a risk assessment;

   3. (c)

      assign a risk rating in accordance with the risk matrix developed in accordance with paragraph (a);

   4. (d)

      respond to each risk identified in the report with actions it will take to address the risk; and

   5. (e)

      respond to each recommendation in the assessment.

6. (6)

   The applicant’s response to each risk needing to be addressed and each recommendation must include:

   1. (a)

      for each risk or recommendation that the applicant will address:

      1. (i)

         details of the action the applicant will take to address the risk or recommendation;

      2. (ii)

         the timeframe in which the applicant will complete the action, having regard to the risk rating assigned for the risk or recommendation; and

      3. (iii)

         the residual risk rating expected following completion of the action; and

   2. (b)

      for each risk and recommendation that the applicant will not address:

      1. (i)

         the reasons for the applicant’s decision not to address the risk;

      2. (ii)

         details of alternative actions, if any, to be taken by the applicant; and

      3. (iii)

         the residual risk rating expected following completion of any alternative action.

2.5Technical testing

1. (1)

   The applicant must, at the time it applies for accreditation, have conducted technical testing in accordance with this rule.

2. (2)

   The technical testing of the information technology system through which the applicant will provide its accredited services must determine whether the system has the functionality necessary to meet the following requirements:

   1. (a)

      incident monitoring, detection, investigation, management and response for cyber security incidents as required by Subdivision C of Division 3 of Part 4.1 of Chapter 4;

   2. (b)

      logging requirements as required by rule 4.20;

   3. (c)

      incident monitoring, detection, investigation, management and response for fraud incidents as required by Division D of Part 4.2 of Chapter 4;

   4. (d)

      support to individuals as required by rules 4.11 and 4.30;

   5. (e)

      data minimisation requirements, as required by subrule 4.42(2); and

   6. (f)

      compliance with the Accreditation Data Standards that are specific to the kind of accredited services the applicant will provide if accredited.

3. (3)

   The applicant must record in respect of the technical testing conducted:

   1. (a)

      the test completion criteria used;

   2. (b)

      the assumptions, limitations and dependencies used;

   3. (c)

      the methodology used, including a description of the data and environment used to conduct the testing;

   4. (d)

      how each test maps to each requirement referred to in subrule (2); and

   5. (e)

      the results of the technical testing, including details of any failure to meet the requirements in subrule (2) that is identified and how this failure has been addressed.

2.6Matters to which the Digital ID Regulator must have regard

1. (1)

   For the purposes of paragraph 15(5)(a) of the Act, in deciding whether to accredit an applicant, the Digital ID Regulator must have regard to the following matters:

   1. (a)

      the level of the applicant’s tolerance of fraud risks and whether the level is likely to create an unacceptable risk in respect of the proposed accredited services to be provided by the entity if accredited;

   2. (b)

      the level of the applicant’s tolerance of cyber security risks and whether the level is likely to create an unacceptable risk in respect of the proposed accredited services to be provided by the entity if accredited; and

   3. (c)

      whether the applicant’s privacy impact assessment and the applicant’s response to that assessment identify any matters that may give rise to an unacceptable risk to the privacy of individuals.

2. (2)

   This rule is not limited by paragraph 1.9(3)(b).

2.7Matters of which the Digital ID Regulator must be satisfied

1. (1)

   For the purposes of paragraph 15(4)(d) of the Act, the Digital ID Regulator must not accredit an applicant unless it is satisfied that the information and documents provided by the applicant demonstrate that the applicant, if accredited, will be able to comply with:

   1. (a)

      the Act;

   2. (b)

      these rules; and

   3. (c)

      the Accreditation Data Standards, to the extent a standard relates to a particular activity to be conducted by the applicant.

   Note: Accredited entities must comply with the Accreditation Data Standards applicable to the accredited service being provided and the manner of providing that service (see subparagraph 5.1(1)(a)(ii)).

2. (2)

   This rule is not limited by paragraph 1.9(3)(b).

Chapter 3—Assurance assessments and systems testing

Part 3.1—General requirements

3.1Entity’s obligation

(1)

If an accredited entity is required by a provision of these rules to conduct an assurance assessment or systems testing, the entity must ensure:

1. (a)

   the process for the assurance assessment or systems testing complies with the requirements of this Chapter; and

2. (b)

   the elements of the DI data environment that are being assessed or tested meet the requirements of the Act and these rules relevant to the kind of assurance assessment or systems testing being conducted.

Note: Applicants are required to conduct assurance assessments and systems testing for their application for accreditation (see subrule 2.3(3)). Accredited entities are required, in accordance with Chapter 6, to conduct assurance assessments and systems testing for annual reviews.

1. (2)

   Each assurance assessment and systems testing must be conducted:

   1. (a)

      having regard to the requirements with which the accredited entity must comply as detailed in the entity’s statement of scope and applicability; and

   2. (b)

      in respect of the entity’s DI data environment,

as at the time the assurance assessment or systems testing is conducted.

3.2Assessors

1. (1)

   An assurance assessment and systems testing must be conducted by an individual (assessor):

   1. (a)

      who has appropriate experience, training and qualifications to conduct that kind of assessment or systems testing; and

   2. (b)

      if additional requirements relating to the assessor are specified in these rules for that kind of assurance assessment or systems testing—who meets those requirements.

2. (2)

   If requested by the assessor, an accredited entity must take reasonable steps:

   1. (a)

      to permit the assessor to have secure online access to documentation and information relevant to the assurance assessment or systems testing; and

   2. (b)

      to undertake a site visit to the entity’s premises or other location at which the accredited services are, or will be, provided.

Part 3.2—Assurance assessments

Division 1—Protective security assessment

3.3Requirements

1. (1)

   A protective security assessment must, in relation to an accredited entity:

   1. (a)

      review and assess the entity’s:

      1. (i)

         implementation of, and compliance with, the controls in the protective security framework it uses, or will use if accredited;

      2. (ii)

         protective security capability;

      3. (iii)

         compliance with the additional protective security controls in Division 2 of Part 4.1 of Chapter 4, or ability to comply if accredited;

   2. (b)

      review and address the results of the penetration testing report referred to in rule 3.10;

   3. (c)

      review and address any findings or recommendations in the entity’s report of its essential strategies review referred to in paragraph 3.4(2)(b); and

   4. (d)

      if the entity considers a control or strategy is not relevant to the entity—comply with the requirements of rule 3.5.

2. (2)

   For a protective security assessment, the assessor conducting the assessment must, in addition to any requirements relating to assessors in the applicable protective security framework:

   1. (a)

      be external to the accredited entity and, if the entity is part of a corporate group, external to the group; and

   2. (b)

      not be, or have been, involved in the design, implementation, operation or management of the accredited entity’s DI data environment or accredited services.

3. (3)

   For a protective security assessment involving ISO/IEC 27001, the assessor must also be accredited, or recognised, by the Joint Accreditation System of Australia and New Zealand to certify entities against ISO/IEC 27001.

3.4Essential strategies review and report

1. (1)

   In this rule:

Essential Eight Maturity Model and ISM Mapping document means the document titled ‘Essential Eight Maturity Model and ISM Mapping’ published by the ACSC.

Note: At the time these rules were made, located at Eight Assessment Process Guide means the document titled ‘Essential Eight Assessment Process Guide’ published by the ACSC.

Note: At the time these rules were made, located at

1. (2)

   An accredited entity must:

   1. (a)

      review and assess its compliance with rule 4.19 by conducting an assessment of its implementation and compliance with the Essential Eight Maturity Model and ISM Mapping document for ISM controls marked maturity level 2 (essential strategies review); and

   2. (b)

      provide a report to the assessor (essential strategies report).

2. (3)

   An essential strategies review must be conducted by a person who has appropriate experience, training and qualifications to conduct the review.

3. (4)

   An essential strategies report must be in the form of the assessment report template in the Essential Eight Assessment Process Guide and must include the following information:

   1. (a)

      the opinion of the person conducting the review as to whether the accredited entity has implemented and complies with the maturity level 2 controls specified in the ISM;

   2. (b)

      if an accredited entity has implemented an alternative control in place of a control specified in the ISM—a description of that control and its effectiveness at mitigating the relevant cyber security risk; and

   3. (c)

      findings and any recommendations on the accredited entity’s compliance with the Essential Eight Maturity Model and ISM Mapping document for ISM controls marked maturity level 2.

3.5If a control or strategy is not relevant to an accredited entity

1. (1)

   If an accredited entity considers that a particular protective security control in the framework it implements or strategy in rule 4.19 is not relevant to the entity, and has not or does not intend to implement that control or strategy, the entity must:

   1. (a)

      give the assessor a risk-based justification for the entity’s decision that the control or strategy is not relevant;

   2. (b)

      give the assessor details of any other controls or risk strategies taken by the entity to mitigate any risk relevant to the control or strategy that is not relevant; and

   3. (c)

      ensure the assessor includes in the protective security assessment, the assessor’s opinion as to:

      1. (i)

         the extent, if any, of risk or residual risk as a result of not implementing the requirement;

      2. (ii)

         the appropriateness of controls or risk mitigation strategies taken by the entity to mitigate any cyber security risks that the protective security control or strategy is intended to mitigate; and

      3. (iii)

         whether the entity’s decision that a particular control or strategy is not relevant to it is appropriate.

   Example: A control involving physical security may not be relevant to an entity because the entity’s personnel work remotely and the entity does not have a physical office.

2. (2)

   If the assessor does not agree that the control or strategy is not relevant to the accredited entity, the control must be implemented.

Division 2—Fraud assessment

3.6Requirements

1. (1)

   A fraud assessment must review and assess:

   1. (a)

      an accredited entity’s implementation and compliance with the fraud control requirements in Part 4.2 of Chapter 4; and

   2. (b)

      whether the entity’s fraud processes are sufficient to respond to emerging risks and threats to its DI data environment.

2. (2)

   An assessor conducting a fraud assessment must:

   1. (a)

      be external to the accredited entity and, if the entity is part of a corporate group, external to the group; and

   2. (b)

      not be, or have been, involved in the design, implementation, operation or management of the accredited entity’s DI data environment or accredited services.

Division 3—Accessibility and useability assessment

3.7Requirements

1. (1)

   This Division applies for the purposes of subsection 30(1) of the Act.

2. (2)

   An accessibility and useability assessment must, in relation to an accredited entity, review and assess:

   1. (a)

      the entity’s compliance with subsection 30(1AA) of the Act;

   2. (b)

      the entity’s implementation and compliance with rule 4.49;

   3. (c)

      for an ISP—the entity’s implementation and compliance with the additional accessibility and useability requirements in Division 4 of Part 5.1 of Chapter 5;

   4. (d)

      the findings of the WCAG testing, including actions that will address any risks and recommendations identified in the assessor’s report of the WCAG testing; and

   5. (e)

      if the entity is required to conduct useability testing—the findings of the useability testing, including actions that will address any risks and recommendations identified in the assessor’s report of the useability testing.

Part 3.3—Systems testing

Division 1—Penetration testing

3.8Penetration testing requirements

1. (1)

   Penetration testing must evaluate the effectiveness of the implementation of security controls in the information technology system through which the accredited entity provides, or will provide, its accredited services by emulating the tools and techniques of likely attackers to exploit security weaknesses.

2. (2)

   Penetration testing must include:

   1. (a)

      testing of egress and ingress points of the information technology system;

   2. (b)

      non-authenticated penetration testing (also known as black‑box testing); and

   3. (c)

      authenticated penetration testing (also known as white‑box testing).

3. (3)

   If an accredited entity uses the infrastructure of a cloud service provider as part of its information technology system within its DI data environment, the penetration testing required by subrule (2) must be conducted only on that part of the entity’s information technology system that is hosted by, or part of the tenancy with, the cloud service provider (cloud service provider’s infrastructure).

4. (4)

   However, if an accredited entity’s arrangement with a cloud service provider does not allow penetration testing by the entity of the cloud service provider’s infrastructure:

   1. (a)

      the entity must ensure the cloud service provider has conducted the kinds of penetration testing referred to in subrule (2) on that infrastructure at least once in each of the accredited entity’s reporting periods; and

   2. (b)

      the requirements in rules 3.9 and 3.10 do not apply to penetration testing conducted by the cloud service provider.

5. (5)

   The penetration testing by the accredited entity’s assessor must be conducted before the protective security assessment.

Applicants

1. (6)

   If subrule (4) applies to an applicant because of rule 2.3, the words ‘at least once in each of the accredited entity’s reporting periods’ appearing in paragraph 4(a) are to be ignored.

3.9Penetration testing assessor

Penetration testing must be conducted by an assessor who meets the following additional requirements:

1. (a)

   be external to the accredited entity and, if the entity is part of a corporate group, external to the group; and

2. (b)

   not be, or have been, involved in the design, implementation, operation or management of the accredited entity’s DI data environment or accredited services.

3.10Penetration testing report

An assessor that has completed penetration testing for an accredited entity must prepare a report of that testing that includes:

1. (a)

   a description of the tools and processes used to conduct the penetration testing;

2. (b)

   a description of the scope of the penetration testing; and

3. (c)

   the results of the penetration testing, including:

   1. (i)

      identification of any security risks or vulnerabilities in the accredited entity’s DI data environment, including in its information technology system when in operation;

   2. (ii)

      any other findings; and

   3. (iii)

      any recommendations.

Division 2—Useability testing

3.11Accessible and inclusive services

This Division applies for the purposes of subsection 30(1) of the Act.

3.12

Useability testing requirements

(1)

Useability testing of an accredited entity’s public-facing accredited services must:

1. (a)

   identify any adverse issues in the design, useability and accessibility of the entity’s public-facing accredited services; and

2. (b)

   if any adverse issues relating to useability and accessibility by individuals are identified by the assessment, make recommendations on improvements to the entity’s public‑facing accredited services to address those issues and to reduce or mitigate any useability issues identified.

1. (2)

   The useability testing must:

   1. (a)

      include testing of all user interfaces an individual will progress through when interacting with the accredited entity’s public-facing accredited services and, if applicable:

      1. (i)

         each interface involving verification or authentication in relation to an individual;

      2. (ii)

         alternative channels (if any) available to the individual to complete a specific activity;

      3. (iii)

         notices in relation to privacy, including notices or information required to be given to individuals in respect of privacy matters; and

      4. (iv)

         any other information required by these rules to be given to individuals;

   2. (b)

      involve a diverse range of individuals covering diversity in disability, age, gender and ethnicity; and

   3. (c)

      involve a wide range of devices, browser access and platforms so that the testing demonstrates a continuity of support for access to the accredited services across those devices, browsers and platforms.

   Note: Paragraph (2)(b) is made, in relation to accredited entities, for the purposes of paragraph 30(2)(c) of the Act. Paragraph (2)(c) is made, in relation to accredited entities, for the purposes of paragraph 30(2)(d) of the Act.

3.13Useability testing report

An assessor that has completed useability testing of an accredited entity’s public-facing accredited services must prepare a useability testing report that includes:

1. (a)

   a description of the scope of testing;

2. (b)

   a description of the tools and processes used to conduct the testing;

3. (c)

   the results of the testing, including:

   1. (i)

      findings and qualitative metrics; and

   2. (ii)

      identification of any accessibility or useability issues; and

4. (d)

   recommendations to address any accessibility or useability issues involving the accredited entity’s accredited services.

Division 3—WCAG testing

3.14Accessible and inclusive services

This Division applies for the purposes of subsection 30(1) of the Act.

3.15WCAG testing requirements

WCAG testing must test the extent to which an accredited entity’s:

1. (a)

   public-facing information related to accredited services on its web pages (within the meaning of that term in the WCAG) satisfies the Level A Success Criteria specified in WCAG version 2.1 in accordance with subrule 4.49(2); and

2. (b)

   public‑facing accredited services and public-facing information related to accredited services satisfy the Level AA Success Criteria specified in WCAG version 2.1 in accordance with subrule 4.49(3).

3.16WCAG testing report

An assessor that has conducted WCAG testing must prepare a WCAG testing report that includes:

1. (a)

   a description of the accredited entity’s public-facing accredited services and public-facing information related to accredited services that were tested;

2. (b)

   a description of the tools and processes used to test the compliance of the accredited entity’s public-facing accredited services and public-facing information related to accredited services with the requirements in rule 3.15; and

3. (c)

   the results of the WCAG testing, including:

   1. (i)

      the identification of any risks to accessibility by individuals when the accredited entity’s information technology system is in operation;

   2. (ii)

      any other findings; and

   3. (iii)

      any recommendations.

Part 3.4—Reports for assurance assessments and systems testing

3.17Assessor’s report

Without limiting rules 3.4, 3.10, 3.13 and 3.16, for each kind of assurance assessment and systems testing, the assessor must prepare a report (assessor’s report)for that assessment or testing that includes, the following:

1. (a)

   a summary of the activities, including any site visits and interviews, undertaken by the assessor when conducting the assurance assessment or systems testing;

2. (b)

   the dates on which the assurance assessment or systems testing was commenced and completed;

3. (c)

   details of the qualifications and experience of the assessor;

4. (d)

   details of the release number or version number of the information technology system being assessed;

5. (e)

   a description and version number of any document considered by the assessor;

6. (f)

   the evaluation or test methodology used; and

7. (g)

   the findings of the assurance assessment or systems testing, including:

   1. (i)

      details of any non-compliance with the Act, these rules and applicable Accreditation Data Standards relevant to the assurance assessment and systems testing;

   2. (ii)

      details of any risks identified by the assessor and any actions the accredited entity should take to address the risk; and

   3. (iii)

      any recommendations to the accredited entity to treat any risks or to ensure compliance with the Act and these rules relevant to the assurance assessment and systems testing.

3.18Entity’s response to an assessor’s report

1. (1)

   An accredited entity must respond in writing to the findings of each assessor’s report (entity’s response) as required by this rule.

2. (2)

   The accredited entity’s response to an assessor’s report must be signed by the entity’s accountable executive.

3. (3)

   For each risk and recommendation identified in an assessor’s report, the accredited entity must:

   1. (a)

      develop a risk matrix based on an established risk management framework or standard;

   2. (b)

      conduct a risk assessment;

   3. (c)

      assign a risk rating in accordance with the risk matrix developed in accordance with paragraph (a);

   4. (d)

      respond to each risk identified in the report with actions it will take to address the risk; and

   5. (e)

      respond to each recommendation in the report.

4. (4)

   The accredited entity’s response to each risk needing to be addressed and each recommendation must include:

   1. (a)

      for each risk or recommendation that the entity will address:

      1. (i)

         details of the action the entity will take to address the risk or recommendation;

      2. (ii)

         the timeframe in which the entity will complete the action, having regard to the risk rating assigned for the risk or recommendation; and

      3. (iii)

         the residual risk rating expected following completion of the action; and

   2. (b)

      for each risk or recommendation that the entity will not address:

      1. (i)

         the reasons for the entity’s decision not to address the risk;

      2. (ii)

         details of alternative actions, if any, to be taken by the entity and the timeframes to do so; and

      3. (iii)

         the residual risk rating expected following completion of any alternative action.

Chapter 4—Requirements for maintaining accreditation

Part 4.1—Protective security controls

Division 1—Capability

4.1

Protective security capability

(1) Protective security capability of an accredited entity means the accredited entity’s ability to manage the protective security of its DI data environment through the implementation and operation of processes and controls, including by:

1. (a)

   allocating adequate budget and resources; and

2. (b)

   providing for management oversight.

1. (2)

   An accredited entity’s protective security capability must be appropriate and adapted to respond to cyber security risks, including emerging risks, having regard to:

   1. (a)

      the extent and nature of the personal information the entity holds;

   2. (b)

      the extent and nature of cyber security risks, threats and vulnerabilities;

   3. (c)

      the potential loss or damage to one or more individuals if a cyber security incident were to occur;

   4. (d)

      the potential loss or damage to relying parties if a cyber security incident were to occur; and

   5. (e)

      the potential loss or damage to entities and individuals if a cyber security incident were to occur and result in a digital ID being compromised or otherwise rendered unreliable.

2. (3)

   An accredited entity must take reasonable steps to prevent, detect and deal with cyber security incidents, including by:

   1. (a)

      having and maintaining protective security capability;

   2. (b)

      continuously improving its protective security capability; and

   3. (c)

      identifying, treating and managing cyber security risks.

Division 2—Protective security frameworks

4.2Accredited entities must implement a security framework

An accredited entity must implement, in respect of its accredited services and DI data environment, one of the following:

1. (a)

   the PSPF, subject to the requirements in rule 4.3;

2. (b)

   ISO/IEC 27001, subject to the requirements in rule 4.4;

3. (c)

   an alternative framework, subject to the requirements in rule 4.5.

4.3Compliance with the PSPF

1. (1)

   If an accredited entity implements the PSPF for the purpose of rule 4.2, the entity must comply with, and manage and monitor, each of the controls specified in that framework that are listed in Schedule 5.

2. (2)

   Subrule (1) applies subject to rule 4.6.

3. (3)

   For the purposes of these rules:

   1. (a)

      the term ‘sensitive information’ used in the PSPF has the same meaning as ‘personal information’ in the Act;

   2. (b)

      the term ‘Australian Government resources’ used in the PSPF has the same meaning as ‘DI data environment’ in these rules;

   3. (c)

      the term ‘risks’ in the PSPF has the same meaning as ‘cyber security risks’ in these rules.

4. (4)

   In Schedule 5:

B.1 and B.1 Core requirement, in relation to a particular policy of the PSPF, mean the core requirement designated ‘B.1’ in that policy.

B.2 Supporting requirement, in relation to a particular policy of the PSPF, means the supporting requirement designated ‘B.2’ in that policy.

PSPF Policy 1 means Policy 1 (Role of accountable authority) of the PSPF.

PSPF Policy 2 means Policy 2 (Management structures and responsibilities) of the PSPF.

PSPF Policy 3 means Policy 3 (Security planning and risk management) of the PSPF.

PSPF Policy 4 means Policy 4 (Security maturity monitoring) of the PSPF.

PSPF Policy 6 means Policy 6 (Security governance for contracted goods and service providers) of the PSPF.

PSPF Policy 8 means Policy 8 (Classification system) of the PSPF.

PSPF Policy 9 means Policy 9 (Access to information) of the PSPF.

PSPF Policy 11 means Policy 11 (Robust ICT systems) of the PSPF.

PSPF Policy 12 means Policy 12 (Eligibility and suitability of personnel) of the PSPF.

PSPF Policy 13 means Policy 13 (Ongoing assessment of personnel) of the PSPF.

PSPF Policy 14 means Policy 14 (Separating personnel) of the PSPF.

PSPF Policy 15 means Policy 15 (Physical security for entity resources) of the PSPF.

Senior Executive Service has the same meaning as in the Public Service Act 1999.

Note: At the time these rules were made, all policies comprising the PSPF were located at with ISO/IEC 27001

1. (1)

   If an accredited entity implements ISO/IEC 27001 for the purpose of subrule 4.2, the entity must comply with, and manage and monitor, all the controls specified in that standard.

2. (2)

   Subrule (1) applies subject to rule 4.6.

3. (3)

   For the purposes of these rules:

   1. (a)

      the term ‘Personally Identifiable Information’ used in ISO/IEC 27001 has the same meaning as ‘personal information’ in the Act;

   2. (b)

      the term ‘information security incident’ used in ISO/IEC 27001 has the same meaning as ‘cyber security incident’ in the Act; and

   3. (c)

      the term ‘information security risk’ used in ISO/IEC 27001 has the same meaning as ‘cyber security risk’ in these rules.

4.5Implementation and compliance with an alternative framework

1. (1)

   An accredited entity may only implement an alternative framework if the entity demonstrates, in accordance with subrule (2) or (3), that the entity complies with all the same kinds of controls that would be required by either:

   1. (a)

      rule 4.3, if the entity were to implement the PSPF for the purpose of rule 4.2; or

   2. (b)

      rule 4.4, if the entity were to implement ISO/IEC 27001 for the purpose of rule 4.2.

2. (2)

   To demonstrate that the accredited entity complies with all the same kinds of controls as the PSPF for the purpose of paragraph (1)(a), the accredited entity must prepare and maintain an up-to-date document that:

   1. (a)

      maps all the controls specified in the alternative framework that must be complied with against the corresponding controls mentioned in rule 4.3; and

   2. (b)

      if the alternative framework does not require compliance with a particular kind of control mentioned in rule 4.3—specifies the relevant control mentioned in that rule.

3. (3)

   To demonstrate that the accredited entity complies with all the same kinds of controls as ISO/IEC 27001 for the purpose of paragraph (1)(b), the accredited entity must prepare and maintain an up-to-date document that:

   1. (a)

      maps all the controls specified in the alternative framework that must be complied with against the corresponding controls mentioned in rule 4.4; and

   2. (b)

      if the alternative framework does not require compliance with a particular kind of control mentioned in rule 4.4—specifies the relevant control mentioned in that rule.

4. (4)

   If an accredited entity implements an alternative framework for the purposes of rule 4.2, the entity must:

   1. (a)

      continue to comply with, and manage and monitor:

      1. (i)

         all the controls specified in that framework; and

      2. (ii)

         any controls specified in the document prepared and maintained in accordance with paragraph (2)(b) or (3)(b); and

   2. (b)

      comply with a new version of the alternative framework within the timeframe specified for that version.

5. (5)

   For the purpose of paragraph (4)(b), if a new version of the framework does not specify a timeframe for compliance, the timeframe for compliance is taken to be 12 months.

6. (6)

   Subrule (4) applies subject to rule 4.6.

4.6If a control is not relevant to an entity

An accredited entity is not required to comply with a particular control in the framework it implements if the most recent report of the assessor conducting the protective security assessment for the entity includes the assessor’s opinion that the control is not relevant to the entity because of the entity’s particular circumstances.

Note: See rule 3.5 about an assessor’s opinion that a control is not relevant to an entity.

Example: A control about managing a cloud service provider will not be relevant to an entity if the entity does not use a cloud service provider when providing its accredited services.

Division 3—Additional protective security controls

4.7

Cyber security risk assessment

1. (1)

   An accredited entity must, for each reporting period, conduct an assessment of the cyber security risks associated with its accredited services and DI data environment (cyber security risk assessment).

2. (2)

   The accredited entity must:

   1. (a)

      develop a risk matrix based on an established risk management framework or standard; and

   2. (b)

      as part of the cyber security risk assessment:

      1. (i)

         assess the entity’s cyber security risks in accordance with the risk matrix developed in accordance with paragraph (a);

      2. (ii)

         record the results of the assessment;

      3. (iii)

         determine and record the entity’s level of tolerance to cyber security risks; and

      4. (iv)

         record how the entity’s controls for cyber security risks are applied to its accredited services and DI data environment.

3. (3)

   If an ISP collects, uses, holds, discloses or destroys biometric information, the ISP must assess and record in its cyber security risk assessment the security risks, mitigation strategies and any other actions the ISP will take to address risks related to biometric information.

Applicants

1. (4)

   If subrule (1) applies to an applicant because of rule 2.3, the words ‘for each reporting period’ appearing in that subrule are to be ignored.

4.8Sharing information about risks

An accredited entity must:

1. (a)

   consider the implications that the entity’s decisions related to the management of cyber security risks have for other participants of the digital ID system in which the accredited entity operates; and

2. (b)

   share information on known cyber security risks or cyber security incidents with those participants as appropriate.

4.9Eligibility and suitability of personnel

An accredited entity must take reasonable steps to ensure the ongoing eligibility and suitability of its personnel who interact with its DI data environment.

Note: If the entity implements the PSPF, this rule may be met by the entity complying with the requirements in PSPF Policy 13 (Ongoing assessment of personnel). At the time these rules were made, located at persistent-id="av.2996672" version="_1_0">

Advice to individuals

An ISP must provide advice to individuals about how to safeguard their digital ID against cyber security risks and update that advice, as soon as practicable, as new risks and threats emerge.

4.11Support to individuals

1. (1)

   An accredited entity providing public-facing accredited services must provide support services to individuals who have been adversely affected by a cyber security incident.

2. (2)

   For the purposes of subrule (1), support services must include, at a minimum, the provision of:

   1. (a)

      one of the following:

      1. (i)

         a monitored chat function; or

      2. (ii)

         a monitored email function; or

      3. (iii)

         a call centre; and

   2. (b)

      a function that allows the individual to speak with a natural person.

Subdivision A—System security plan

4.12Requirements for system security plan

1. (1)

   An accredited entity must have, maintain and comply with a plan that meets the requirements of this Subdivision (system security plan).

2. (2)

   If an accredited entity implements the PSPF, the entity’s system security plan for these rules:

   1. (a)

      is the security plan referred to in PSPF Policy 11 (Robust ICT systems); and

   2. (b)

      must contain any other information required by these rules to be in the system security plan.

   Note: At the time these rules were made, PSPF Policy 11 (Robust ICT systems) was located at an accredited entity implements ISO/IEC 27001, the entity’s system security plan must include:

   1. (a)

      all documents and processes referred to in ISO/IEC 27001 which together comprise the entity’s ‘information security management system’ within the meaning of that term in ISO/IEC 27001; and

   2. (b)

      any other information required by these rules to be in the system security plan.

Goals and strategic objectives

1. (4)

   The entity’s system security plan must include details of:

   1. (a)

      the entity’s goals and strategic objectives to manage and improve its protective security capability; and

   2. (b)

      activities the entity will undertake to continuously improve that capability.

Destruction of biometric information

1. (5)

   If an ISP collects biometric information, the ISP’s system security plan must include details of the processes, procedures and timeframes for the destruction of that biometric information, including destruction of all copies and caches of that information.

(6) If another person collects biometric information from, or on behalf of, an ISP, the ISP’s system security plan must include details of the arrangements in place for the other person to destroy that biometric information, including all copies and caches of that information, in accordance with the same timeframes for destruction of biometric information that apply to the ISP.

Assessment of risks related to biometric information

1. (7)

   If an ISP collects, uses, holds, discloses or destroys biometric information, the ISP’s system security plan must include details of any cyber security risks, associated mitigation strategies and any other actions the ISP will take to address risks related to that biometric information, conducting biometric binding, or authentication using biometric information, including risks relating to:

   1. (a)

      using biometric matching algorithms to complete biometric binding;

   2. (b)

      using systems for presentation attack detection to complete presentation attack detection;

   3. (c)

      the capture, temporary storage, and destruction of biometric information;

   4. (d)

      the biometric matching process the entity implements; and

   5. (e)

      potential and known threats and attacks to the entity’s biometric capability;

Use of out-of-band authenticators via PSTN

1. (8)

   If an ISP authenticates an individual by use of an out‑of‑band device via the public switched telephone network (PSTN), the entity must detail in its system security plan:

   1. (a)

      the risks of using the PSTN, including but not limited to, risks associated with device swap, SIM change, number porting or other abnormal behaviour; and

   2. (b)

      risk management strategies that the entity will implement to address those risks.

4.13Review of the system security plan

1. (1)

   An accredited entity must review and update its system security plan:

   1. (a)

      at least once in each reporting period; and

   2. (b)

      as soon as practicable after:

      1. (i)

         the entity becomes aware of any cyber security incident which is of a kind not covered in the entity’s system security plan or which exceeds the entity’s recorded level of tolerance for cyber security risks;

      2. (ii)

         the entity becomes aware of any breach of a requirement specified in its system security plan; or

      3. (iii)

         any change in the entity’s organisational structure or control, functions or activities, if that change will, or is reasonably likely to, increase the level of cyber security risk.

2. (2)

   The entity’s review of its system security plan must, at a minimum:

   1. (a)

      have regard to any significant shifts in the entity’s cyber security risk, threat and operating environment;

   2. (b)

      include an assessment of the appropriateness of the existing protective cyber security control measures and mitigation controls; and

   3. (c)

      review and, if necessary, update the goals and strategic objectives in the entity’s system security plan, including:

      1. (i)

         recording whether each goal and strategic objective has been met; and

      2. (ii)

         updating the goals and strategic objectives for the next year.

   Note: If the entity implements the ISO/IEC 27001, subrule (2) would be met by the entity complying with clauses 8, 9 and 10 of ISO/IEC 27001.

3. (3)

   As soon as practicable after the entity has completed each review of its system security plan, the entity must make all necessary amendments to its system security plan.

Subdivision B—Cloud service management

4.14Selection, use and management of cloud services

1. (1)

   If an accredited entity uses cloud services as part of its DI data environment, it must have and maintain a cloud services management plan that includes policies and processes for:

   1. (a)

      the selection, use, and management of cloud services;

   2. (b)

      defining and recording all protective security controls and strategies that must be complied with in accordance with the Act, these rules and the Accreditation Data Standards in relation to the entity’s use of cloud services;

   3. (c)

      periodic penetration testing and assurance assessments for the effectiveness of the protective security controls and strategies mentioned in paragraph (b), including in relation to:

      1. (i)

         geographic location;

      2. (ii)

         management of privileged access; and

      3. (iii)

         effective destruction of data;

   4. (d)

      responding to cyber security incidents or suspected cyber security incidents involving cloud services;

   5. (e)

      the orderly migration of information to and from cloud services;

   6. (f)

      monitoring, reviewing and evaluating the ongoing use of cloud services to manage cyber security risks;

   7. (g)

      if personal information is to be collected, held, used or disclosed using cloud services;

      1. (i)

         how that information will be collected, held, used or disclosed; and

      2. (ii)

         how personal information will be destroyed once it is no longer required; and

   8. (h)

      amending or discontinuing the use of cloud services, including exit strategies for cloud services.

2. (2)

   An accredited entity must have and maintain a register of cloud service providers whose services it uses which includes the following information:

   1. (a)

      the cloud services provider’s name and cloud service name;

   2. (b)

      the entity’s purpose for using the cloud services;

   3. (c)

      the type of personal information collected, used, held or disclosed by the cloud services provider (if any);

   4. (d)

      the date for the next protective security assurance assessment of the cloud services;

   5. (e)

      contractual arrangements for the use of the cloud service by the entity; and

   6. (f)

      contact details for the cloud service provider, including emergency contact details.

   Note: If the entity implements ISO/IEC 27001, this rule would be met by the entity complying with clause 5.23 of Annex A of ISO/IEC 27001.

Subdivision C—Incident detection, investigation, response and reporting

4.15Incident monitoring and detection

1. (1)

   An accredited entity must implement and maintain appropriate mechanisms for:

   1. (a)

      preventing and detecting actual and suspected cyber security incidents; and

   2. (b)

      alerting the entity’s personnel to actual or suspected cyber security incidents.

2. (2)

   Without limiting subrule (1), the mechanisms must include an accessible process for personnel, individuals, enforcement bodies and other entities to report actual or suspected cyber security incidents to the accredited entity on a confidential basis.

4.16Incident investigation, management and response

1. (1)

   An accredited entity must implement and maintain mechanisms for investigating and dealing with cyber security incidents which relate to the accredited entity’s DI data environment.

2. (2)

   An accredited entity must investigate cyber security incidents and suspected cyber security incidents unless the incident or suspected incident has been referred to, and has been accepted by, the ACSC or an enforcement body.

3. (3)

   Without limiting subrule (1), the mechanisms must include processes and procedures to:

   1. (a)

      manage and respond to cyber security incidents and suspected cyber security incidents;

   2. (b)

      for an ISP:

      1. (i)

         identify any digital ID that has been affected by a cyber security incident; and

      2. (ii)

         suspend and prevent use of the digital ID; and

   3. (c)

      for an ASP:

      1. (i)

         identify any special attributes that have been affected by a cyber security incident; and

      2. (ii)

         suspend and prevent use of the special attribute.

4.17

Disaster recovery and business continuity management

1. (1)

   An accredited entity must have, maintain and comply with a disaster recovery and business continuity plan for its DI data environment that covers:

   1. (a)

      business continuity governance;

   2. (b)

      training requirements for members of the entity’s personnel who perform recovery tasks such as backup recovery and restoration;

   3. (c)

      recovery objectives and priorities;

   4. (d)

      backup retention and protection from loss processes;

   5. (e)

      backup recovery and restoration processes;

   6. (f)

      continuity strategies; and

   7. (g)

      testing requirements for restoration procedures.

2. (2)

   The disaster recovery and business continuity plan for the accredited entity’s DI data environment must be separate from any other plans in respect of its other business or organisational functions.

3. (3)

   An accredited entity must, at least once in each reporting period, review and test its disaster recovery and business continuity plan.

   Note: If the entity implements ISO/IEC 27001, this rule would be met by the entity complying with clauses 5.30 and 8.13 of ISO/IEC 27001.

4.18Record keeping

1. (1)

   This rule applies to cyber security incidents that cause, or are likely to cause, serious harm to one or more individuals.

2. (2)

   An accredited entity must prepare and keep records of:

   1. (a)

      any decisions to use civil, administrative or disciplinary procedures, or to take no further action, in response to a cyber security incident; and

   2. (b)

      the entity’s investigations of and responses to a cyber security incident.

(3)

For each reporting period, an accredited entity must prepare a report detailing, in respect of any accredited services provided by the accredited entity in a digital ID system other than the Australian Government Digital ID System, the following:

1. (a)

   the number of cyber security incidents that occurred in the reporting period in relation to the entity’s accredited services and DI data environment (if any); and

2. (b)

   for each incident:

   1. (i)

      the date and time of the incident;

   2. (ii)

      a description of the type of incident;

   3. (iii)

      the number of digital IDs affected (if any); and

   4. (iv)

      the severity of the incident; and

3. (c)

   a description of the measures taken by the entity in response to the incidents covered by the report.

1. (4)

   Subject to rule 7.8, a record required by this rule must:

   1. (a)

      be retained for a minimum of 3 years from the day it was generated; and

   2. (b)

      not contain biometric information.

Subdivision D—Information technology system controls

4.19Essential Eight

1. (1)

   Subject to subrule (2), an accredited entity must, in relation to its DI data environment, implement and comply with all mitigation strategies whose ‘relative security effectiveness rating’ is marked ‘essential’ in the document titled Strategies to Mitigate Cyber Security Incidents published by the ACSC.

   Note: At the time these rules were made, located at accredited entity is not required to comply with a mitigation strategy specified in subrule (1) if the most recent report of an assessor conducting a protective security assessment for the accredited entity includes the assessor’s opinion that the strategy is not relevant to the entity because of the entity’s particular circumstances.

   Note: See rule 3.5 about an assessor’s opinion that a control or strategy is not relevant to an entity.

   Example: A control about Configure Microsoft Office macro settings to block macros from the internet, and only allow vetted macros either in ‘trusted locations’ with limited write access or digitally signed with a trusted certificate, will not be relevant to an entity if the entity does not use Microsoft products within its DI data environment.

4.20Logging requirements

1. (1)

   Any information technology system through which an accredited entity provides accredited services must generate logs that record activities, exceptions, faults and events in the entity’s DI data environment.

2. (2)

   Without limiting subrule (1), the activities to be recorded must include:

   1. (a)

      any creation, update, use, disclosure or destruction of personal information;

   2. (b)

      if biometric information is collected or retained by or on behalf of an ISP—the destruction of that biometric information;

   3. (c)

      successful or failed elevation of access privileges by personnel;

   4. (d)

      additions, deletions or modifications to personnel or group permissions;

   5. (e)

      system alerts or failures related to cyber security risks; and

   6. (f)

      unauthorised attempts to access critical systems or files.

Logging implementation and monitoring plan

1. (3)

   An accredited entity must have, maintain and comply with a plan (logging implementation and monitoring plan) that details:

   1. (a)

      how the entity generates, stores, protects, monitors and analyses logs; and

   2. (b)

      how the entity monitors logs to identify any anomalous behaviour.

2. (4)

   The logging implementation and monitoring plan must be appropriate and adapted to manage cyber security risks to the entity’s accredited services and DI data environment.

   Note: If an accredited entity implements ISO/IEC 27001, subrules (1), (3) and (4) would be met by the entity complying with clauses 8.15, 8.16 and 8.17 of Annex A of ISO/IEC 27001.

3. (5)

   Each log required to be generated by this rule must include the following details for each event:

   1. (a)

      interaction type;

   2. (b)

      transaction audit identifier;

   3. (c)

      the names of any entities involved in the event;

   4. (d)

      any unique identifier used in the event;

   5. (e)

      the date and time of the event;

   6. (f)

      for an IXP—each kind of attribute conveyed for the event;

   7. (g)

      for accredited entities other than an IXP—the types of attributes requested and disclosed to each entity involved in the event; and

   8. (h)

      if the interaction type requires express consent, the audit log for that interaction must include the following as relevant to the interaction:

      1. (i)

         the date and method by which any express consent was obtained from the individual;

      2. (ii)

         the duration of the express consent; and

      3. (iii)

         whether the express consent was granted or withdrawn by the individual.

4. (6)

   A log required by this rule must include, for a kind of entity specified in column 1 of an item in the following table, a record of the matter specified in column 2 of that item.

Logging requirements
Item	Column 1	Column 2
Kind of entity	Matter to be recorded
Accredited identity service providers
1	ISP	The binding of attributes to a digital ID.
2	ISP that provides reusable digital IDs	All of the following: (a) the information required to implement and support rate limiting (see the Accreditation Data Standards); (b) the date and time the authenticator was bound to any individual’s digital ID; (c) the unique identifier assigned to each individual within the digital ID system in which the entity operates; (d) details of any physical authenticators bound to the digital ID of an individual; and (e) details of the source of any unsuccessful authentications attempted with the authenticator.
3	ISP that conducts biometric binding	Information associated with each biometric binding transaction, including the method of biometric binding used in the transaction.
4	ISP that conducts manual face comparison activities	All of the following: (a) the manual face comparison activities conducted during the biometric binding process; and (b) the assessing officer responsible for conducting any activities related to the biometric binding transaction.
Accredited attribute service providers
5	ASP	All of the following: (a) the retrieval of any special attribute by a third party; (b) the IP Level of the digital ID used to obtain any special attribute from the ASP; and (c) if available, the unique identifier assigned to the digital ID within the digital ID system in which the ASP operates.

1. (7)

   Subject to rule 7.8, a log required by paragraphs (2)(a) and (b), subrule (5) and subrule (6) must:

   1. (a)

      be retained for a minimum of 3 years from the day it was generated; and

   2. (b)

      not contain biometric information.

4.21Cryptography

An accredited entity must ensure that all personal information collected, used, held or disclosed by or on behalf of the accredited entity is protected in transit and at rest by approved cryptography.

4.22

Cryptographic standards

1. (1)

   An accredited entity must comply with Transport Layer Security 1.3 (TLS 1.3) within the meaning of that term in the ISM.

   Note: The cryptographic standards in the ISM include a requirement to implement the latest version of TLS. At the time these rules were made, the current version of TLS is version 1.3.

2. (2)

   If the entity is unable to comply with TLS 1.3 in relation to an individual because TLS 1.3 is not supported by the individual’s device, the entity must:

   1. (a)

      comply with TLS version 1.2 or higher; and

   2. (b)

      follow any relevant risk mitigation advice in the document titled Implementing Certificates, TLS, HTTPS and Opportunistic TLS published by the ACSC.

   Note: At the time these rules were made, located at key management processes and procedures

   1. (1)

      An accredited entity mustdevelop, implement and maintain documented, effective and secure cryptographic key management processes and procedures for its information technology system.

   2. (2)

      The entity’s cryptographic key management processes and procedures must cover cryptographic key lifecycle management, including:

      1. (a)

         cryptographic key generation;

      2. (b)

         registration;

      3. (c)

         distribution;

      4. (d)

         installation;

      5. (e)

         usage;

      6. (f)

         protection;

      7. (g)

         storage;

      8. (h)

         access;

      9. (i)

         revocation;

      10. (j)

          recovery; and

      11. (k)

          destruction.

      Note: If the entity implements ISO/IEC 27001, this rule would be met by the entity complying with clause 8.24 of Annex A of ISO/IEC 27001.

   Part 4.2—Fraud control requirements

   Division 1—Capability

   4.24Fraud management capability

   (1) Fraud management capability of an accredited entity means the accredited entity’s ability to manage fraud in relation to its accredited services and DI data environment through the implementation and operation of processes and controls, including by:

   1. (a)

      allocating adequate budget and resources; and

   2. (b)

      providing for management oversight.

   1. (2)

      An accredited entity’s fraud management capability must be appropriate and adapted to respond to fraud risks, having regard to:

      1. (a)

         the extent and nature of personal information that the entity holds;

      2. (b)

         the extent and nature of fraud risks, threats and vulnerabilities;

      3. (c)

         the potential loss or damage to one or more individuals if a digital ID fraud incident occurs;

      4. (d)

         the potential loss or damage to relying parties if a digital ID fraud incident occurs; and

      5. (e)

         the potential loss or damage to entities and individuals if a digital ID fraud incident occurs that results in a digital ID being compromised or otherwise rendered unreliable.

1. (d)

   if a cloud service provider conducts penetration testing as referred to in paragraph 3.8(4)(a)—the entity is satisfied that that penetration testing covers the kinds of penetration testing in subrule 3.8(2);

2. (e)

   the entity is satisfied that any condition imposed by the Digital ID Regulator relating to restricted attributes continues to be necessary and appropriate and, if not, a variation to the condition will be sought;

3. (f)

   the entity has complied with the Act, these rules and the Accreditation Data Standards during the relevant reporting period, with the exception of any non-compliance which the entity has notified to the Digital ID Regulator; and

4. (g)

   the entity is not aware of any matters or circumstances that might prevent or adversely affect the entity’s ability to comply with the Act, these rules or the Accreditation Data Standards.

Chapter 7—Other matters relating to accreditation

Part 7.1—Matters related to attributes

7.1Individuals must expressly consent to disclosure of certain attributes of individuals to relying parties

For the purposes of paragraph 45(f) of the Act, the following kinds of attributes are prescribed:

1. (a)

   to the extent not covered by section 45 of the Act, attributes of an individual that are on a document or other credential listed in Schedules 1 to 4;

2. (b)

   attributes that are derived from an attribute listed in paragraphs 45(a) to (e) of the Act or paragraph (a);

3. (c)

   a special attribute of an individual;

4. (d)

   an attribute that is self-asserted by the individual and not verified.

Example: For paragraph (b), information as to whether an individual is aged 18 or above is an attribute derived from the individual’s date of birth.

7.2Meaning of restricted attribute of an individual

For the purposes of paragraph 11(1)(f) of the Act, the following is prescribed as a restricted attribute:

1. (a)

   a number on a document or other credential listed in Schedules 1 to 4 that is a unique identifier for that particular version of the document or other credential.

Example: A card number on a driver’s licence is a unique number for that particular version of the card and is in addition to the licence number on that card.

Part 7.2—Accreditation conditions

7.3Table of accreditation conditions

For the purposes of subsection 17(5) of the Act, the accreditation of a kind of accredited entity specified in column 1 of an item of the following table is subject to the conditions specified in column 2 of the item in the circumstances (if any) specified in column 3 of the item.

Accreditation conditions
Item	Column 1 Entity	Column 2 Condition	Column 3 Circumstances
1	All accredited entities	Must not collect a restricted attribute of an individual unless the circumstances in column 3 exist	Collection of the restricted attribute is authorised by an accreditation condition imposed by the: (a) the Digital ID Regulator under subsection 17(2) of the Act; or (b) an accreditation condition imposed by these rules. Note: An accreditation condition imposed on an entity under subitem 2(b) of Schedule 1 of Part 1 of the Digital ID (Transitional and Consequential Provisions) Act 2023 is taken to have been imposed by the Digital ID Regulator under subsection 17(2) of the Act.
2	IXP	May collect a restricted attribute of an individual	Collection is for one of the following purposes: (a) providing accredited services to other participants in the digital ID system in which the IXP operates; (b) detecting, reporting or investigating a contravention, or an alleged contravention, of a provision of the Act, these rules or the Accreditation Data Standards; (c) conducting proceedings in relation to a contravention, or an alleged contravention, of a civil penalty provision of the Act; (d) detecting, reporting or investigating a digital ID fraud incident within the digital ID system in which the IXP operates; (e) detecting, reporting or investigating a cyber security incident within the digital ID system in which the IXP operates; (f) conducting an assessment of a matter referred to in paragraph 33C(1)(g) of the Privacy Act; (g) detecting, reporting, investigating or prosecuting an offence against a law of the Commonwealth, a State or a Territory; or (h) if the IXP has engaged a contractor to provide an accredited service, or part of an accredited service, and the following apply: (i) the collection is for the purposes of the contractor providing an accredited service, or part of an accredited service, of the IXP; and (ii) the contractor is contractually bound to comply with the same obligations as apply to the IXP in respect of that information.
3	IXP	May disclose a restricted attribute of an individual	Disclosure is for one of the following purposes: (a) providing accredited services to other participants in the digital ID system in which the IXP operates; (b) detecting, reporting or investigating a contravention, or an alleged contravention, of a provision of the Act, these rules or the Accreditation Data Standards; (c) conducting proceedings in relation to a contravention, or an alleged contravention, of a civil penalty provision of the Act; (d) detecting, reporting or investigating a digital ID fraud incident within the digital ID system in which the IXP operates; (e) detecting, reporting or investigating a cyber security incident within the digital ID system in which the IXP operates; (f) conducting an assessment of a matter referred to in paragraph 33C(1)(g) of the Privacy Act; or (g) detecting, reporting, investigating or prosecuting an offence against a law of the Commonwealth, a State or a Territory.
4	ASP	May collect a restricted attribute of an individual; or may collect a photo of the individual, or biometric information derived from the photo, on a document or other credential provided by the individual	Collection is for the purpose of using that restricted attribute or biometric information to verify a special attribute of the individual.
5	ISP	May collect a restricted attribute of an individual that is on, or derived from, a credential provided by the individual	Collection is for the purpose of providing the ISP’s accredited services.
6	ISP	May collect biometric information that is an acquired image provided by the individual; or may collect a photo of the individual, or information derived from the photo, on a document or other credential provided by the individual	Collection is for the purpose of verifying the identity of the individual or authenticating the individual to their digital ID
7	ISP	May disclose a restricted attribute or biometric information to an authoritative source, or to a service that confirms the veracity of an attribute or a document or credential with an authoritative source	Disclosure is for the purpose of verifying the identity of the individual.
8	All accredited entities	May disclose restricted attributes or biometric information to a contractor engaged by the accredited entity to provide an accredited service, or part of an accredited service	If: (a) the disclosure is for the purpose of the contractor providing an accredited service, or part of an accredited service, of the accredited entity; and (b) the contractor is contractually bound to comply with the same obligations as apply to the accredited entity in respect of that information.

Part 7.3—Reportable incidents

7.4Reportable incidents

An accredited entity must notify the Digital ID Regulator within 5 business days if any of the following occurs:

1. (a)

   any material change;

2. (b)

   any matter that could reasonably be considered relevant to whether the entity is a fit and proper person for the purposes of the Act, these rules and the Accreditation Data Standards; or

3. (c)

   there is a change to, or the accredited entity becomes aware of an error in, any information the entity has provided to the Digital ID Regulator.

Note: For paragraph (b), see section 12 of the Act and the Digital ID Rules which prescribe matters to which the Digital ID Regulator must have regard when considering whether an entity is a fit and proper person.

7.5Change of control for corporations

1. (1)

   Subject to subrule (2), this rule applies to:

   1. (a)

      an accredited entity that is a corporation; and

   2. (b)

      an entity that is a corporation whose accreditation is suspended;

2. (2)

   This rule does not apply to a corporation that is controlled by:

   1. (a)

      the Commonwealth or an authority of the Commonwealth;

   2. (b)

      a State or an authority of that State; or

   3. (c)

      a Territory or an authority of that Territory.

3. (3)

   However, this rule applies to a corporation mentioned in subrule (2) if, as a result of a change in control, or a future change in control, the corporation ceases to be, or will cease to be, controlled by:

   1. (a)

      for a corporation controlled by an entity mentioned in paragraph (2)(a)—an entity mentioned in paragraph (2)(a);

   2. (b)

      for a corporation controlled by an entity mentioned in paragraph (2)(b)—an entity mentioned in paragraph (2)(b); or

   3. (c)

      for a corporation controlled by an entity mentioned in paragraph (2)(c)—an entity mentioned in paragraph (2)(c).

4. (4)

   The entity must notify the Digital ID Regulator, in accordance with this rule, of a change in control, or a future change in control, of the entity.

5. (5)

   The notification must include the following information:

   1. (a)

      the entity’s name;

   2. (b)

      the contact details for the entity;

   3. (c)

      the following details in respect of each entity that, through the change or future change in control of the entity, has started or would start to control the entity (incoming entity):

      1. (i)

         the name of the incoming entity;

      2. (ii)

         the incoming entity’s ABN or ARBN;

      3. (iii)

         the address of the incoming entity’s principal place of business;

      4. (iv)

         the other contact details of the incoming entity;

      5. (v)

         if the incoming entity was incorporated outside Australia—the location of its incorporation and the address of its principal place of business in Australia;

      6. (vi)

         the business name or names of the incoming entity;

      7. (vii)

         the date on which the incoming entity was registered under the Corporations Act or other law;

      8. (viii)

         the names and director identification number of each of the directors and other officers of the incoming entity;

      9. (ix)

         in respect of each subsidiary of the incoming entity—the information specified in subparagraphs (i) to (viii); and

   4. (d)

      the date on which the change of control occurred or is expected to occur.

6. (6)

   The notification must be made:

   1. (a)

      if the entity becomes aware that, at any time in the future, a change in control of the entity will occur—within 72 hours after the entity becomes aware; or

   2. (b)

      otherwise—within 72 hours after the change in control occurs.

7. (7)

   Without limiting paragraph (6)(a), an entity is taken to be aware that a change in control of the entity will occur at the time:

   1. (a)

      a resolution is passed by the entity regarding the change in control; or

   2. (b)

      a court order regarding the change in control is made.

8. (8)

   In this rule:

ABN has the meaning given in section 9 of the Corporations Act.

ARBN has the meaning given in section 9 of the Corporations Act.

Commonwealth company has the meaning given in the Public Governance, Performance and Accountability Act 2013.

control:

1. (a)

   in relation to aCommonwealth company—has the meaning given in section 89 of the Public Governance, Performance and Accountability Act 2013;

2. (b)

   otherwise—has the meaning given in section 910B of the Corporations Act.

corporation has the meaning given in the Corporations Act.

director has the meaning given in section 9 of the Corporations Act.

officer has the meaning given in section 9 of the Corporations Act.

subsidiary has the meaning given in section 9 of the Corporations Act.

7.6Entity no longer providing accredited services

If an accredited entity intends to cease providing accredited services, the entity must inform the Digital ID Regulator of its intention and details of its plans, as soon as practicable after forming that intent.

Note: Intent may arise if an accredited entity intends to sell, or otherwise dispose of, part of its business that includes provision of its accredited services.

Part 7.4—Data standards relating to accreditation

7.7

Digital ID Data Standards Chair to make standards

1. (1)

   For the purposes of paragraph 99(1)(c) of the Act, the Digital ID Data Standards Chair must make standards, being one or more of technical, data or design standards relating to accreditation, for the matters specified in subrule (2).

2. (2)

   The matters are:

   1. (a)

      the authentication of individuals or information, including the kinds of authenticators and authentication levels to be bound to a digital ID;

   2. (b)

      the verification of information relating to an individual using biometric information of the individual;

   3. (c)

      the authentication of an individual to their digital ID using biometric information of the individual;

   4. (d)

      test standards for an entity’s information technology system utilising the entity’s biometric matching algorithm, including the testing metrics, evaluation and required minimum pass test results, and who may conduct the testing; and

   5. (e)

      test standards for an entity’s information technology system utilising the entity’s technology for presentation attack detection, including the testing metrics, evaluation and required minimum pass test results, and who may conduct the testing.

   Note: Accredited entities must comply with the Accreditation Data Standards applicable to the accredited service being provided and the manner of providing that service (see subparagraph 5.1(1)(a)(ii)).

Part 7.5—Record keeping

7.8

General record keeping requirement

An accredited entity must not destroy or de-identify information in the possession or control of the entity if:

1. (a)

   the information is personal information; and

2. (b)

   the information is not biometric information; and

3. (c)

   the information was obtained by the entity in the course of providing accredited services; and

4. (d)

   the entity is required or authorised to retain the information by or under:

   1. (i)

      the Act, these rules or the Digital ID Rules;

   2. (ii)

      a direction issued by the Digital ID Regulator under section 127 of the Act; or

   3. (iii)

      a court/tribunal order (within the meaning of the Privacy Act); and

5. (e)

   the information relates to:

   1. (i)

      any current or anticipated legal proceedings; or

   2. (ii)

      any dispute resolution proceedings; or

   3. (iii)

      a current compliance or enforcement investigation under ‘this Act’ (as defined in section 9 of the Act);

to which the entity is a party.

Schedule 1—Documents or other credentials that are a commencement of identity credential

Note: See rule 1.4 (definition of ‘commencement of identity credential’) and subparagraph 5.1(1)(a)(iii) (requirement for verification of a document or other credential).

Item	Column 1	Column 2
Document or other credential used for verification:	Must be verified by:
1	Birth certificate issued by a State or Territory government	Source verification.
2	Australian passport that is current or, if expired, no more than 3 years past the expiry date	Source verification or technical verification
3	Citizenship certificate—a notice given under section 37 of the Australian Citizenship Act 2007 stating that a person is an Australian citizen at a particular time	Source verification.
4	Australian Certificate of Registration by Descent issued by the Australian Government	Source verification.
5	Visa	Source verification, verified by a DVS (within the meaning of that term in section 15 of the Identity Verification Services Act 2023) using a current passport (including an ePassport) issued by a foreign country.
6	Certificate of Identity document issued by the Department of Foreign Affairs and Trade	Source verification.
7	Australian Document of Identity issued by the Department of Foreign Affairs and Trade	Source verification.
8	Convention Travel Document, also known as a Titre de Voyage issued by the Department of Foreign Affairs and Trade	Source verification.
9	ImmiCard issued to an individual who is not an Australian citizen, by the Department administered by the Minister administering the Migration Act 1958 to assist the individual to prove the individual’s identity	Source verification.

Schedule 2—Documents or other credentials that are a linking credential

Note: See rule 1.4 (definition of ‘linking credential’) and subparagraph 5.1(1)(a)(iii) (requirement for verification of a document or other credential).

Item	Column 1	Column 2
Document or other credential used for verification:	Must be verified by:
1	Marriage certificate issued by or on behalf of a State or Territory	Source verification.
2	Change of name certificate issued by or on behalf of a State or Territory indicating that an individual has changed the individual’s name	Source verification.
3	Proof of divorce document, issued by a court, evidencing the dissolution of the individual’s marriage	Source verification or visual verification.
4	Victims’ certificate issued under Division 375 of the Criminal Code Act 1995	Source verification or visual verification.
5	Birth certificate issued by or on behalf of a State or Territory government	Source verification.

Schedule 3—Documents or other credentials that are a UitC credential

Note: See rule 1.4 (definition of ‘UitC credential’) and subparagraph 5.1(1)(a)(iii) (requirement for verification of a document or other credential).

Item	Column 1	Column 2
Credential used for verification:	must be verified by:
1	Concession or health care card issued by Services Australia	Source verification.
2	Medicare card (as defined by section 84 of the National Health Act 1953)	Source verification.
3	Student ID card issued by an: (a) Australian secondary school: (b) technical and further education institution (however described) operated by a State or Territory government: (c) Australian university; or (d) a registered training organisation (as defined by section 3 of the National Vocational Education and Training Regulator Act 2011)	Source verification or visual verification.
4	Debit or credit card that is current and issued by an authorised deposit-taking institution (as defined by section 5 of the Banking Act 1959)	Source verification.
5	Veteran Card issued by the Department of Veterans’ Affairs	Source verification or visual verification.
6	Document evidencing an individual’s enrolment on the electoral roll maintained by the Australian Electoral Commission	Source verification.
7	Photo ID—a document or other credential listed in Schedule 4, but only if that document or other credential has not already been used for the purposes of satisfying a particular requirement of an IP level of the IP Levels Table	The verification requirements for that document or other credential specified in Schedule 4.

Schedule 4—Documents or other credentials that are a photo ID

Note: See rule 1.4 (definition of ‘photo ID’) and subparagraph 5.1(1)(a)(iii) (requirement for verification of a document or other credential).

Item	Column 1	Column 2
Documents or other credentials that contain a photo of the individual:	Must be verified by:
1	Australian passport that is current or, if expired, no more than 3 years past the expiry date	Source verification or technical verification.
2	Driver’s licence issued under the law of a State or Territory	Source verification.
3	Foreign passport, other than an ePassport, issued by the government of a foreign country	Visual verification.
4	Foreign ePassport issued by the government of a foreign country	Technical verification.
5	Convention Travel Document, also known as a Titre de Voyage, issued by the Department of Foreign Affairs and Trade	Source verification.
6	Citizenship certificate—a notice given under section 37 of the Australian Citizenship Act 2007 stating that a person is an Australian citizen at a particular time	Source verification.
7	Shooter or firearms licence issued under a law of a State or Territory	Source verification or visual verification.
8	Identity card issued under section 78 of the Aviation Transport Security Act2004 or section 137 of the Maritime Transport and Offshore Facilities Security Act 2003	Source verification.
9	Proof-of-age card issued by or on behalf of a State or Territory	Source verification or visual verification.
10	Working with children or vulnerable people card issued by or on behalf of a State or Territory	Source verification or visual verification.

11 ImmiCard issued to an individual who is not an Australian citizen, by the Department administered by the Minister administering the Migration Act 1958 to assist the individual to prove the individual’s identity Source verification.

Schedule 5—PSPF controls

Note: See rule 4.3 (compliance with the PSPF).

Item	Column 1	Column 2	Column 3	Column 4	Column 5
PSPF Policy	B.1 Core requirement	B.2 Supporting requirement	Requirement	Sub-requirement
1	PSPF Policy 1	B.1	The accountable authority of each entity must:	(a) determine their entity’s tolerance for security risks
2	PSPF Policy 1	B.1	The accountable authority of each entity must:	(b) manage the security risks of their entity, and
3	PSPF Policy 1	B.1	The accountable authority of each entity must:	(c) consider the implications their risk management decisions have for other entities, and share information on risks as appropriate.
4	PSPF Policy 2	B.1	The accountable authority must:	(a) appoint a Chief Security Officer (CSO) at the Senior Executive Service level to be responsible for security in the entity
5	PSPF Policy 2	B.1	The accountable authority must:	(b) empower the CSO to make decisions about: (i) appointing security advisors within the entity (ii) the entity’s protective security planning (iii) the entity’s protective security practices and procedures (iv) investigating, responding to, and reporting on security incidents, and
6	PSPF Policy 2	B.1	The accountable authority must:	(e) ensure personnel and contractors are aware of their collective responsibility to foster a positive security culture, and are provided sufficient information and training to support this.
7	PSPF Policy 2	Requirement 1. Security advisors	The CSO must be responsible for directing all areas of security to protect the entity’s people, information and assets. This includes appointing security advisors to support them in the day-to-day delivery of protective security and, to perform specialist services.
8	PSPF Policy 2	Requirement 2. Security procedures	Entities must develop and use procedures that ensure:	(a) all elements of the entity’s security plan are achieved
9	PSPF Policy 2	Requirement 2. Security procedures	Entities must develop and use procedures that ensure:	(b) security incidents are investigated, responded to, and reported, and
10	PSPF Policy 2	Requirement 2. Security procedures	Entities must develop and use procedures that ensure:	(c) relevant security policy or legislative obligations are met.
11	PSPF Policy 2	Requirement 3. Security training	Entities must provide all personnel, including contractors, with security awareness training at engagement and annually thereafter.
12	PSPF Policy 2	Requirement 4. Specific training	Entities must provide personnel in specialist and high-risk positions (including contractors and security incident investigators) with specific security awareness training targeted to the scope and nature of the position.
13	PSPF Policy 2	Requirement 5. General email	Entities must maintain a monitored email address as the central conduit for all security-related matters across governance, personnel, information, cyber and physical security. Note: See the guidance advice in section C.10.4 of PSPF Policy 2 to assist in implementation of this requirement.
14	PSPF Policy 3	B.1	Each entity must have in place a security plan approved by the accountable authority to manage the entity’s security risks.
15	PSPF Policy 3	B.1	The security plan must detail the:	(a) security goals and strategic objectives of the entity, including how security risk management intersects with and supports broader business objectives and priorities
16	PSPF Policy 3	B.1	The security plan must detail the:	(b) threats, risks and vulnerabilities that impact the protection of an entity’s people, information and assets
17	PSPF Policy 3	B.1	The security plan must detail the:	(c) entity’s tolerance to security risks
18	PSPF Policy 3	B.1	The security plan must detail the:	(d) maturity of the entity’s capability to manage security risks, and
19	PSPF Policy 3	B.1	The security plan must detail the:	(e) entity’s strategies to implement security risk management, maintain a positive risk culture and deliver against the PSPF.
20	PSPF Policy 3	Requirement 2. Critical assets	Entities must identify people, information and assets that are critical to the ongoing operation of the entity and the national interest and apply appropriate protections to these resources to support their core business.
21	PSPF Policy 3	Requirement 3. Risk steward	Entities must identify a risk steward (or manager) who is responsible for each security risk or category of security risk, including for shared risks.
22	PSPF Policy 3	Requirement 5. Threat levels	The security plan (and supporting security plans) must include scalable measures to meet variations in threat levels and accommodate changes in the National Terrorism Threat Level.
23	PSPF Policy 3	Requirement 6. Alternative mitigations	Where the CSO (or security advisor on behalf of the CSO) implements an alternative mitigation measure or control to a PSPF requirement, they must document the decision and adjust the maturity level for the related PSPF requirement.
24	PSPF Policy 4	B.1	Each entity must assess the maturity of its security capability and risk culture by considering its progress against the goals and strategic objectives identified in its security plan.
25	PSPF Policy 4	Requirement 1. Security maturity records	Entities must document and evidence their assessment of the entity’s security maturity.
26	PSPF Policy 6	B.1	Each entity is accountable for the security risks arising from procuring goods and services, and must ensure contracted providers comply with relevant PSPF requirements.
27	PSPF Policy 6	Requirement 1. Assessing and managing security risks of procurement	When procuring goods or services, entities must put in place proportionate protective security measures by identifying and documenting:	(a) specific security risks to its people, information and assets, and
28	PSPF Policy 6	Requirement 1. Assessing and managing security risks of procurement	When procuring goods or services, entities must put in place proportionate protective security measures by identifying and documenting:	(b) mitigations for identified risks.
29	PSPF Policy 6	Requirement 2. Establishing protective security terms and conditions in contracts	Entities must ensure that contracts for goods and services include relevant security terms and conditions for the provider to:	(a) apply appropriate information, physical and personnel security requirements of the PSPF
30	PSPF Policy 6	Requirement 2. Establishing protective security terms and conditions in contracts	Entities must ensure that contracts for goods and services include relevant security terms and conditions for the provider to:	(b) manage identified security risks relevant to the procurement, and
31	PSPF Policy 6	Requirement 2. Establishing protective security terms and conditions in contracts	Entities must ensure that contracts for goods and services include relevant security terms and conditions for the provider to:	(c) implement governance arrangements to manage ongoing protective security requirements, including to notify the entity of any actual or suspected security incidents and follow reasonable direction from the entity arising from incident investigations.
32	PSPF Policy 6	Requirement 3. Ongoing management of protective security in contracts	When managing contracts, entities must put in place the following measures over the life of a contract:	(a) ensure that security controls included in the contract are implemented, operated and maintained by the contracted provider and associated subcontractor, and
33	PSPF Policy 6	Requirement 3. Ongoing management of protective security in contracts	When managing contracts, entities must put in place the following measures over the life of a contract:	(b) manage any changes to the provision of goods or services, and reassess security risks.
34	PSPF Policy 6	Requirement 4. Completion or termination of a contract	Entities must implement appropriate security arrangements at completion or termination of a contract.
35	PSPF Policy 8	B.1	Each entity must:	(a) identify information holdings
36	PSPF Policy 8	B.1	Each entity must:	(b) assess the sensitivity and security classification of information holdings, and
37	PSPF Policy 8	B.1	Each entity must:	(c) implement operational controls for these information holdings proportional to their value, importance and sensitivity.
38	PSPF Policy 8	Requirement 7. Minimum protections and handling requirements	Entities must ensure information is transferred and transmitted by means that deter and detect compromise and that meet the minimum protection requirements set out in Annexes A to C.
39	PSPF Policy 8	Requirement 8. Disposal	Entities must ensure sensitive and security classified information is disposed of securely in accordance with the minimum protection requirements set out in Annexes A to C. This includes ensuring security classified information is appropriately destroyed when it has passed minimum retention requirements or reaches authorised destruction dates.
40	PSPF Policy 9	B.1	Each entity must enable appropriate access to official information. This includes:	(a) sharing information within the entity, as well as with other relevant stakeholders
41	PSPF Policy 9	B.1	Each entity must enable appropriate access to official information. This includes:	(b) ensuring that those who access sensitive or security classified information have an appropriate security clearance and need to know that information, and
42	PSPF Policy 9	B.1	Each entity must enable appropriate access to official information. This includes:	(c) controlling access (including remote access) to supporting ICT systems, networks, infrastructure, devices and applications.
43	PSPF Policy 9	Requirement 5. Managing access to information systems	To manage access to information systems holding sensitive or security classified information, entities must implement unique individual identification, authentication and authorisation practices on each occasion where system access is granted.
44	PSPF Policy 11	B.1	Each entity must ensure the secure operation of their ICT systems to safeguard their information and data and the continuous delivery of government business by applying the ISM’s cyber security principles during all stages of the lifecycle of each system.
45	PSPF Policy 11	Requirement 1. Authorisation of ICT systems to operate	Entities must only process, store or communicate information and data on an ICT system that the determining authority (or their delegate) has authorised to operate based on the acceptance of the residual security risks associated with its operation.
46	PSPF Policy 11	Requirement 1. Authorisation of ICT systems to operate	When establishing new ICT systems, or implementing improvements to an existing system, the decision to authorise (or reauthorise) a system to operate must be based on the ISM’s 6 step risk-based approach for cyber security.
47	PSPF Policy 11	Requirement 5. Vulnerability Disclosure Program	Entities must have in place a vulnerability disclosure program.
48	PSPF Policy 12	B.1	Each entity must ensure the eligibility and suitability of its personnel who have access to Australian Government resources (people, information and assets).
49	PSPF Policy 12	Requirement 1. Pre-employment screening	Entities must undertake pre-employment screening, including:	(a) verifying a person’s identity using the DVS (within the meaning of that term in section 15 of the Identity Verification Services Act 2023), and
50	PSPF Policy 12	Requirement 1. Pre-employment screening	(c) obtaining assurance of a person’s suitability to access Australian Government resources, including their agreement to comply with the government’s policies, standards, protocols and guidelines that safeguard resources from harm.
51	PSPF Policy 13	B.1	Each entity must assess and manage the ongoing suitability of its personnel and share relevant information of security concern, where appropriate.
52	PSPF Policy 14	B.1	Each entity must ensure that separating personnel:	(a) have their access to Australian Government resources withdrawn, and
53	PSPF Policy 14	B.1	Each entity must ensure that separating personnel:	(b) are informed of any ongoing security obligations.
54	PSPF Policy 14	Requirement 1. Sharing security relevant information, debriefs and continuing obligations	Prior to personnel separation or transfer, entities must:	(a) notify the CSO, or relevant security advisor, of any proposed cessation of employment resulting from misconduct or other adverse reasons
55	PSPF Policy 14	Requirement 2. Withdrawal of access	On separation or transfer, entities must remove personnel’s access to Australian Government resources, including:	(a) physical facilities, and
56	PSPF Policy 14	Requirement 2. Withdrawal of access	On separation or transfer, entities must remove personnel’s access to Australian Government resources, including:	(b) ICT systems.
57	PSPF Policy 14	Requirement 3. Risk assessment	Where it is not possible to undertake required separation procedures, entities must undertake a risk assessment to identify any security implications.
58	PSPF Policy 15	B.1	Each entity must implement physical security measures that minimise or remove the risk of:	(a) harm to people, and
59	PSPF Policy 15	B.1	Each entity must implement physical security measures that minimise or remove the risk of:	(b) information and physical asset resources being made inoperable or inaccessible, or being accessed, used or removed without appropriate authorisation.
60	PSPF Policy 15	Requirement 1. Physical security measures	Entities must put in place appropriate physical security measures to protect entity resources, commensurate with the assessed business impact level of their compromise.
61	PSPF Policy 15	Requirement 2. Security containers, cabinets and rooms	Entities must assess security risks and select the appropriate containers, cabinets, secure rooms and strong rooms to protect entity information and assets.
62	PSPF Policy 15	Requirement 3. Disposal	Entities must dispose of physical assets securely.