These rules are the Digital ID (Accreditation) Rules 2024.
1.3 Authority
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.4 Definitions
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:
(1) Expressions defined in the Accreditation Data Standards have the same meaning in these rules.
(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:
(a) Australian Signals Directorate Approved Cryptographic Algorithms; and
(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 .
Subdivision Subdivision B - Digital ID (Accreditation) Rules 2024 - Cloud service management | Zoe
ASP 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 as in the Australian Passports Act 2005.
authoritative source means a person that issues documents or other credentials containing information about an individual.
biometric binding means the 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:
(a) for an applicant—the provision of the entity’s proposed accredited services; or
(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.
identity 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.
ISO/IEC 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.
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.
ISO/IEC 24745 means the standard for information security, cybersecurity and privacy protection, published by the International Organization for Standardization
ISP 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 means biometric 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:
(a) a material or adverse impact on the entity’s DI data environment, proposed accredited services or accredited services; or
(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.
non‑corporate Commonwealth entity has the same meaning as in the Public Governance, Performance and Accountability Act 2013.
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:
(a) an employee of the entity; or
(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 Act means 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 means:
(a) the PSPF; or
(b) ISO/IEC 27001; or
(c) an alternative framework (see rule 4.5).
protective security framework control means:
(a) a relevant PSPF control; or
(b) a control specified in ISO/IEC 27001; or
(c) a control specified in an alternative framework (see rule 4.5).
PSPF means the Protective Security Policy Framework published by the Australian Government.
Note 2: At the time subrule 1.7(2) commenced, the current version of the PSPF was the PSPF published on 24 July 2025.
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.
Note: 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.
Note: Example: Public‑facing information related to accredited services is the accredited entity’s privacy policy made available to individuals.
relevant PSPF control: see rule 4.3.
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:
(a) with the authoritative source for that attribute or document or other credential; or
(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:
(a) for an applicant:
(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
(ii) the evidence that demonstrates the entity will comply with those requirements if accredited; or
(b) for an accredited entity:
(i) each requirement in these rules and the Accreditation Data Standards with which the entity must comply in relation to its accredited services; and
(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: see rule 1.5.
technical biometric matching means 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 Act in 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 https://www.w3.org/TR/WCAG21/. 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.5
Meaning 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:
(a) the likelihood of risks to achievement of the outcome occurring;
(b) the degree of harm that might result if the outcome is not achieved;
(c) what the person who has the duty knows, or ought reasonably to know, about:
(i) the risks to achievement of the outcome; and
(ii) ways of eliminating or minimising the risks;
(d) the availability and suitability of ways to eliminate or minimise the risks; and
(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.6 Meaning 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.7 Incorporated instruments
(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) Unless the contrary intention appears in these rules, an accredited entity is not required to comply with:
(a) a change to the PSPF made after this subrule commences until 3 months after that change has taken effect; and
(b) a change to any other incorporated instrument until 12 months after that change to the incorporated instrument has taken effect.
Note 1: See subsection 167(3) of the Act.
Note 2: At the time this subrule commenced, the current version of the PSPF was the PSPF published on 24 July 2025.
(3) Subrule (2) does not apply if the incorporated instrument is an Act or a legislative instrument.
1.7A Modifications of the PSPF
For the purposes of the incorporation or application of the PSPF by these rules, the PSPF is subject to the following modifications:
(a) a reference to Australian Government resources or Australian Government people and resources in the PSPF is taken to be a reference to DI data environment (within the meaning of these rules);
(b) a reference to risk in the PSPF is taken to be a reference to cyber security risk (within the meaning of these rules).
1.7B Modifications of ISO/IEC 27001
For the purposes of the incorporation or application of ISO/IEC 27001 by these rules, that standard is subject to the following modifications:
(a) a reference to Personally Identifiable Information in the standard is taken to be a reference to personal information (within the meaning of the Act);
(b) a reference to information security incident in the standard is taken to be a reference to cyber security incident (within the meaning of the Act);
(c) a reference to information security risk in the standard is taken to be a reference to cyber security risk (within the meaning of these rules).
1.8 Application—transitioned accredited entities
(1) A provision in column 1 of an item in the following table applies to a transitioned accredited entity on and after 30 November 2025, subject to the exception (if any) in column 2 of that item.
(1A) Rule 5.7 and subrule 5.9(2) apply to a transitioned accredited entity on and after 30 November 2026.
(2) Every provision of these rules not specified in subrules (1) or (1A) applies to a transitioned accredited entity in accordance with its terms and on and from the commencement of these rules.
1.9 Application—applicants
(1) These rules apply to an entity (an applicant):
(a) that has made an application under section 14 of the Act for accreditation as an accredited entity; and
(b) at the time the entity applies for such accreditation.
(2) These rules apply to, and in relation to, an applicant with the modifications in this rule.
(3) If, because of Chapter 2 and subrule (4):
(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
(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) 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.
<table cellspacing="0" cellpadding="0" style="width:100%; border-collapse:collapse"><thead><tr><td colspan="3" style="width:343.55pt; border-top:1.5pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Application of these rules to applicants</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Item</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Column 1</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Column 2</span></p></td></tr><tr><td style="width:24.65pt; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span></span></p></td><td style="width:116.8pt; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Expression</span></p></td><td style="width:180.5pt; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Modification</span></p></td></tr></thead><tbody><tr><td style="width:24.65pt; border-top:1.5pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>1</span></p></td><td style="width:116.8pt; border-top:1.5pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>accredited entity</span></p></td><td style="width:180.5pt; border-top:1.5pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>to be taken as a reference to an applicant.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>2</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>accredited services</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>to be taken as a reference to proposed accredited services.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>3</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ASP</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>to be taken as a reference to an applicant who has applied to be an ASP.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>4</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>digital ID fraud incident</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>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</span><span> </span><span>9 of the</span><span> </span><span>Act.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>5</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ISP</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>to be taken as a reference to an applicant who has applied to be an ISP.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>6</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>IXP</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>to be taken as a reference to an applicant who has applied to be an IXP.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>7</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>public</span><span>‑</span><span>facing accredited services</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>to be taken as a reference to public</span><span>‑</span><span>facing proposed accredited services.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>8</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>public</span><span>‑</span><span>facing information related to accredited services</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>to be taken as a reference to public</span><span>‑</span><span>facing information related to proposed accredited services.</span></p></td></tr></tbody></table>
Chapter 2—Applying for accreditation
2.1 DI 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:
(a) has correctly identified, defined and documented the boundaries of its DI data environment, including:
(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
(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;
(b) has limited the boundaries of its DI data environment to the extent practicable, including by:
(i) segregating the environment from other systems;
(ii) minimising the number of people who interact with the information referred to in paragraph (a);
(iii) limiting the number of systems hosting, processing or accessing the information referred to in paragraph (a); and
(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:
(a) a statement of scope and applicability; and
(b) a statement, signed by the applicant’s accountable executive, attesting that:
(i) the technical testing required by rule 2.5 has been conducted;
(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
(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
(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.3 Criteria to be met
(1) An applicant must meet the criteria in this rule.
(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) The applicant must, at the time it applies for accreditation, have conducted:
(a) assurance assessments in accordance with Chapter 3;
(b) systems testing in accordance with Chapter 3;
(c) a privacy impact assessment in accordance with rule 2.4;
(d) technical testing in accordance with rule 2.5;
(e) if the applicant will conduct biometric binding if accredited—biometric testing in accordance with the Accreditation Data Standards;
(f) a cyber security risk assessment in accordance with rule 4.7; and
(g) a fraud risk assessment in accordance with rule 4.25.
2.4 Privacy impact assessment
(1) The applicant must, at the time it applies for accreditation, have conducted a privacy impact assessment in accordance with this rule.
(2) The privacy impact assessment must:
(a) assess the privacy impacts of:
(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
(ii) the applicant’s proposed accredited services;
(b) be conducted by a person who:
(i) has appropriate experience, training and qualifications to conduct a privacy impact assessment;
(ii) is external to the applicant and, if the applicant is part of a corporate group, external to the group; and
(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
(c) include:
(i) details of the flow of personal information into, within and from the applicant’s DI data environment;
(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;
(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;
(iv) an analysis of whether any privacy risks or impacts identified in the privacy impact assessment are necessary or unavoidable;
(v) any recommendations made by the person who conducted the assessment, including recommendations that the applicant undertake activities to mitigate any identified privacy risks;
(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
(vii) details of consultation with relevant stakeholders.
(3) The applicant must respond in writing to the findings of the privacy impact assessment.
(4) The applicant’s response to the privacy impact assessment must be signed by the applicant’s accountable executive.
(5) For each risk or recommendation identified by the privacy impact assessment, the applicant must:
(a) develop a risk matrix based on an established risk management framework or standard;
(b) conduct a risk assessment;
(c) assign a risk rating in accordance with the risk matrix developed in accordance with paragraph (a);
(d) respond to each risk identified in the report with actions it will take to address the risk; and
(e) respond to each recommendation in the assessment.
(6) The applicant’s response to each risk needing to be addressed and each recommendation must include:
(a) for each risk or recommendation that the applicant will address:
(i) details of the action the applicant will take to address the risk or recommendation;
(ii) the timeframe in which the applicant will complete the action, having regard to the risk rating assigned for the risk or recommendation; and
(iii) the residual risk rating expected following completion of the action; and
(b) for each risk and recommendation that the applicant will not address:
(i) the reasons for the applicant’s decision not to address the risk;
(ii) details of alternative actions, if any, to be taken by the applicant; and
(iii) the residual risk rating expected following completion of any alternative action.
2.5 Technical testing
(1) The applicant must, at the time it applies for accreditation, have conducted technical testing in accordance with this rule.
(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:
(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;
(b) logging requirements as required by rule 4.20;
(c) incident monitoring, detection, investigation, management and response for fraud incidents as required by Division D of Part 4.2 of Chapter 4;
(d) support to individuals as required by rules 4.11 and 4.30;
(e) data minimisation requirements, as required by subrule 4.42(2); and
(f) compliance with the Accreditation Data Standards that are specific to the kind of accredited services the applicant will provide if accredited.
(3) The applicant must record in respect of the technical testing conducted:
(a) the test completion criteria used;
(b) the assumptions, limitations and dependencies used;
(c) the methodology used, including a description of the data and environment used to conduct the testing;
(d) how each test maps to each requirement referred to in subrule (2); and
(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.6 Matters to which the Digital ID Regulator must have regard
(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:
(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;
(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
(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) This rule is not limited by paragraph 1.9(3)(b).
2.7 Matters of which the Digital ID Regulator must be satisfied
(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:
(a) the Act;
(b) these rules; and
(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) This rule is not limited by paragraph 1.9(3)(b).
Chapter 3—Assurance assessments and systems testing
Part 3.1—General requirements
3.1 Entity’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:
(a) the process for the assurance assessment or systems testing complies with the requirements of this Chapter; and
(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.
(2) Each assurance assessment and systems testing must be conducted:
(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
(b) in respect of the entity’s DI data environment,
as at the time the assurance assessment or systems testing is conducted.
3.2 Assessors
(1) An assurance assessment and systems testing must be conducted by an individual (assessor):
(a) who has appropriate experience, training and qualifications to conduct that kind of assessment or systems testing; and
(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) If requested by the assessor, an accredited entity must take reasonable steps:
(a) to permit the assessor to have secure online access to documentation and information relevant to the assurance assessment or systems testing; and
(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.3 Requirements
(1) A protective security assessment must, in relation to an accredited entity:
(a) review and assess the entity’s:
(i) compliance with the protective security framework controls it complies with, or will comply with if accredited, for the purposes of rule 4.2;
(ii) protective security capability;
(iii) compliance with the additional protective security controls in Division 3 of Part 4.1 of Chapter 4, or ability to comply if accredited;
(b) review and address the results of the penetration testing report referred to in rule 3.10;
(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
(d) if the entity considers a control or strategy is not relevant to the entity—comply with the requirements of rule 3.5.
(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:
(a) be external to the accredited entity and, if the entity is part of a corporate group, external to the group; and
(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) 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.4 Essential strategies review and report
(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.
(2) An accredited entity must:
(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
(b) provide a report to the assessor (essential strategies report).
(3) An essential strategies review must be conducted by a person who has appropriate experience, training and qualifications to conduct the review.
(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:
(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;
(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
(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.5 If a control or strategy is not relevant to an accredited entity
(1) If an accredited entity considers that a particular protective security framework control or strategy in rule 4.19 is not relevant to the entity, and has not or does not intend to comply with that control or strategy, the entity must:
(a) give the assessor a risk‑based justification for the entity’s decision that the control or strategy is not relevant;
(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
(c) ensure the assessor includes in the protective security assessment, the assessor’s opinion as to:
(i) the extent, if any, of risk or residual risk as a result of not complying with the control or strategy;
(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
(iii) whether the entity’s decision that a particular control or strategy is not relevant to it is appropriate.
Note: 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) If the assessor does not agree that the control or strategy is not relevant to the accredited entity, the control must be complied with.
Division 2—Fraud assessment
3.6 Requirements
(1) A fraud assessment must review and assess:
(a) an accredited entity’s implementation and compliance with the fraud control requirements in Part 4.2 of Chapter 4; and
(b) whether the entity’s fraud processes are sufficient to respond to emerging risks and threats to its DI data environment.
(2) An assessor conducting a fraud assessment must:
(a) be external to the accredited entity and, if the entity is part of a corporate group, external to the group; and
(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.7 Requirements
(1) This Division applies for the purposes of subsection 30(1) of the Act.
(2) An accessibility and useability assessment must, in relation to an accredited entity, review and assess:
(a) the entity’s compliance with subsection 30(1AA) of the Act;
(b) the entity’s implementation and compliance with rule 4.49;
(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;
(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
(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.8 Penetration testing requirements
(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) Penetration testing must include:
(a) testing of egress and ingress points of the information technology system;
(b) non‑authenticated penetration testing (also known as black‑box testing); and
(c) authenticated penetration testing (also known as white‑box testing).
(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) 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:
(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
(b) the requirements in rules 3.9 and 3.10 do not apply to penetration testing conducted by the cloud service provider.
(5) The penetration testing by the accredited entity’s assessor must be conducted before the protective security assessment.
Applicants
(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.9 Penetration testing assessor
Penetration testing must be conducted by an assessor who meets the following additional requirements:
(a) be external to the accredited entity and, if the entity is part of a corporate group, external to the group; and
(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.10 Penetration testing report
An assessor that has completed penetration testing for an accredited entity must prepare a report of that testing that includes:
(a) a description of the tools and processes used to conduct the penetration testing;
(b) a description of the scope of the penetration testing; and
(c) the results of the penetration testing, including:
(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;
(ii) any other findings; and
(iii) any recommendations.
Division 2—Useability testing
3.11 Accessible 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:
(a) identify any adverse issues in the design, useability and accessibility of the entity’s public‑facing accredited services; and
(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.
(2) The useability testing must:
(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:
(i) each interface involving verification or authentication in relation to an individual;
(ii) alternative channels (if any) available to the individual to complete a specific activity;
(iii) notices in relation to privacy, including notices or information required to be given to individuals in respect of privacy matters; and
(iv) any other information required by these rules to be given to individuals;
(b) involve a diverse range of individuals covering diversity in disability, age, gender and ethnicity; and
(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.13 Useability 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:
(a) a description of the scope of testing;
(b) a description of the tools and processes used to conduct the testing;
(c) the results of the testing, including:
(i) findings and qualitative metrics; and
(ii) identification of any accessibility or useability issues; and
(d) recommendations to address any accessibility or useability issues involving the accredited entity’s accredited services.
Division 3—WCAG testing
3.14 Accessible and inclusive services
This Division applies for the purposes of subsection 30(1) of the Act.
3.15 WCAG testing requirements
WCAG testing must test the extent to which an accredited entity’s:
(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
(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.16 WCAG testing report
An assessor that has conducted WCAG testing must prepare a WCAG testing report that includes:
(a) a description of the accredited entity’s public‑facing accredited services and public‑facing information related to accredited services that were tested;
(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
(c) the results of the WCAG testing, including:
(i) the identification of any risks to accessibility by individuals when the accredited entity’s information technology system is in operation;
(ii) any other findings; and
(iii) any recommendations.
Part 3.4—Reports for assurance assessments and systems testing
3.17 Assessor’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:
(a) a summary of the activities, including any site visits and interviews, undertaken by the assessor when conducting the assurance assessment or systems testing;
(b) the dates on which the assurance assessment or systems testing was commenced and completed;
(c) details of the qualifications and experience of the assessor;
(d) details of the release number or version number of the information technology system being assessed;
(e) a description and version number of any document considered by the assessor;
(f) the evaluation or test methodology used; and
(g) the findings of the assurance assessment or systems testing, including:
(i) details of any non‑compliance with the Act, these rules and applicable Accreditation Data Standards relevant to the assurance assessment and systems testing;
(ii) details of any risks identified by the assessor and any actions the accredited entity should take to address the risk; and
(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.18 Entity’s response to an assessor’s report
(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) The accredited entity’s response to an assessor’s report must be signed by the entity’s accountable executive.
(3) For each risk and recommendation identified in an assessor’s report, the accredited entity must:
(a) develop a risk matrix based on an established risk management framework or standard;
(b) conduct a risk assessment;
(c) assign a risk rating in accordance with the risk matrix developed in accordance with paragraph (a);
(d) respond to each risk identified in the report with actions it will take to address the risk; and
(e) respond to each recommendation in the report.
(4) The accredited entity’s response to each risk needing to be addressed and each recommendation must include:
(a) for each risk or recommendation that the entity will address:
(i) details of the action the entity will take to address the risk or recommendation;
(ii) the timeframe in which the entity will complete the action, having regard to the risk rating assigned for the risk or recommendation; and
(iii) the residual risk rating expected following completion of the action; and
(b)
for each risk or recommendation that the entity will not address:
(i) the reasons for the entity’s decision not to address the risk;
(ii) details of alternative actions, if any, to be taken by the entity and the timeframes to do so; and
(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:
(a) allocating adequate budget and resources; and
(b) providing for management oversight.
(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:
(a) the extent and nature of the personal information the entity holds;
(b) the extent and nature of cyber security risks, threats and vulnerabilities;
(c) the potential loss or damage to one or more individuals if a cyber security incident were to occur;
(d) the potential loss or damage to relying parties if a cyber security incident were to occur; and
(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.
(3) An accredited entity must take reasonable steps to prevent, detect and deal with cyber security incidents, including by:
(a) having and maintaining protective security capability;
(b) continuously improving its protective security capability; and
(c) identifying, treating and managing cyber security risks.
Division 2—Protective security framework controls
4.2 Accredited entities must comply with protective security framework controls
(1) If an accredited entity is not a non‑corporate Commonwealth entity, the entity must comply, in respect of its accredited services and DI data environment, with either:
(a) all of the controls specified in ISO/IEC 27001 in accordance with that standard; or
(b) the controls of an alternative framework in accordance with rule 4.5.
(2) If an accredited entity is a non‑corporate Commonwealth entity, the entity must comply, in respect of its accredited services and DI data environment, with the relevant PSPF controls in accordance with the PSPF.
(3) This rule applies subject to rule 4.6.
4.3 Relevant PSPF controls
Each of the requirements in the PSPF mentioned in the following table is a relevant PSPF control:
4.5 Implementation and compliance with an alternative framework
(1) An accredited entity (other than a non‑corporate Commonwealth entity) may only comply with the controls of an alternative framework if the entity demonstrates, in accordance with subrule (2), that the entity complies with all the same kinds of controls specified in ISO/IEC 27001.
(2) To demonstrate that the accredited entity complies with all the same kinds of controls specified in ISO/IEC 27001, the entity must prepare and maintain an up‑to‑date document that:
(a) maps all the controls specified in the alternative framework that must be complied with against the controls specified in ISO/IEC 27001; and
(b) if the alternative framework does not require compliance with a particular kind of control in ISO/IEC 27001—specifies that particular control.
(3) However, the controls specified in an alternative framework must not include a relevant PSPF control.
(4) If an accredited entity complies with the controls of an alternative framework for the purposes of paragraph 4.2(1)(b), the entity must:
(a) continue to comply with:
(i) all the controls specified in that framework; and
(ii) any controls specified in the document prepared and maintained in accordance with paragraph (2)(b) of this rule; and
(b) comply with a new version of the alternative framework within the timeframe specified for that version.
(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.
4.6 If a control is not relevant to an entity
An accredited entity is not required to comply with a particular protective security framework control 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.
Note: 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.
(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) The accredited entity must:
(a) develop a risk matrix based on an established risk management framework or standard; and
(b) as part of the cyber security risk assessment:
(i) assess the entity’s cyber security risks in accordance with the risk matrix developed in accordance with paragraph (a);
(ii) record the results of the assessment;
(iii) determine and record the entity’s level of tolerance to cyber security risks; and
(iv) record how the entity’s controls for cyber security risks are applied to its accredited services and DI data environment.
(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
(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.8 Sharing information about risks
An accredited entity must:
(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
(b) share information on known cyber security risks or cyber security incidents with those participants as appropriate.
4.9 Eligibility 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.
4.10 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.11 Support to individuals
(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) For the purposes of subrule (1), support services must include, at a minimum, the provision of:
(a) one of the following:
(i) a monitored chat function; or
(ii) a monitored email function; or
(iii) a call centre; and
(b) a function that allows the individual to speak with a natural person.
Subdivision A—System security plan
4.12 Requirements for system security plan
(1) An accredited entity must have, maintain and comply with a plan that meets the requirements of this Subdivision (system security plan).
(2) If an accredited entity complies with the relevant PSPF controls for the purposes of rule 4.2:
(a) the entity’s system security plan is the security plan referred to in section 3.1 of the PSPF (which deals with security planning); and
(b) that plan must contain any other information required by these rules to be included in the entity’s system security plan.
(3) If an accredited entity complies with ISO/IEC 27001 for the purposes of rule 4.2, the entity’s system security plan must include:
(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
(b) any other information required by these rules to be in the system security plan.
Goals and strategic objectives
(4) The entity’s system security plan must include details of:
(a) the entity’s goals and strategic objectives to manage and improve its protective security capability; and
(b) activities the entity will undertake to continuously improve that capability.
Destruction of biometric information
(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
(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:
(a) using biometric matching algorithms to complete biometric binding;
(b) using systems for presentation attack detection to complete presentation attack detection;
(c) the capture, temporary storage, and destruction of biometric information;
(d) the biometric matching process the entity implements; and
(e) potential and known threats and attacks to the entity’s biometric capability;
Use of out‑of‑band authenticators via PSTN
(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:
(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
(b) risk management strategies that the entity will implement to address those risks.
4.13 Review of the system security plan
(1) An accredited entity must review and update its system security plan:
(a) at least once in each reporting period; and
(b) as soon as practicable after:
(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;
(ii) the entity becomes aware of any breach of a requirement specified in its system security plan; or
(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) The entity’s review of its system security plan must, at a minimum:
(a) have regard to any significant shifts in the entity’s cyber security risk, threat and operating environment;
(b) include an assessment of the appropriateness of the existing protective cyber security control measures and mitigation controls; and
(c) review and, if necessary, update the goals and strategic objectives in the entity’s system security plan, including:
(i) recording whether each goal and strategic objective has been met; and
(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) 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.14 Selection, use and management of cloud services
(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:
(a) the selection, use, and management of cloud services;
(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;
(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:
(i) geographic location;
(ii) management of privileged access; and
(iii) effective destruction of data;
(d) responding to cyber security incidents or suspected cyber security incidents involving cloud services;
(e) the orderly migration of information to and from cloud services;
(f) monitoring, reviewing and evaluating the ongoing use of cloud services to manage cyber security risks;
(g) if personal information is to be collected, held, used or disclosed using cloud services;
(i) how that information will be collected, held, used or disclosed; and
(ii) how personal information will be destroyed once it is no longer required; and
(h) amending or discontinuing the use of cloud services, including exit strategies for cloud services.
(2) An accredited entity must have and maintain a register of cloud service providers whose services it uses which includes the following information:
(a) the cloud services provider’s name and cloud service name;
(b) the entity’s purpose for using the cloud services;
(c) the type of personal information collected, used, held or disclosed by the cloud services provider (if any);
(d) the date for the next protective security assurance assessment of the cloud services;
(e) contractual arrangements for the use of the cloud service by the entity; and
(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.15 Incident monitoring and detection
(1) An accredited entity must implement and maintain appropriate mechanisms for:
(a) preventing and detecting actual and suspected cyber security incidents; and
(b) alerting the entity’s personnel to actual or suspected cyber security incidents.
(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.16 Incident investigation, management and response
(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) 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) Without limiting subrule (1), the mechanisms must include processes and procedures to:
(a) manage and respond to cyber security incidents and suspected cyber security incidents;
(b) for an ISP:
(i) identify any digital ID that has been affected by a cyber security incident; and
(ii) suspend and prevent use of the digital ID; and
(c) for an ASP:
(i) identify any special attributes that have been affected by a cyber security incident; and
(ii) suspend and prevent use of the special attribute.
4.17 Disaster recovery and business continuity management
(1) An accredited entity must have, maintain and comply with a disaster recovery and business continuity plan for its DI data environment that covers:
(a) business continuity governance;
(b) training requirements for members of the entity’s personnel who perform recovery tasks such as backup recovery and restoration;
(c) recovery objectives and priorities;
(d) backup retention and protection from loss processes;
(e) backup recovery and restoration processes;
(f) continuity strategies; and
(g) testing requirements for restoration procedures.
(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) 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.18 Record keeping
(1) This rule applies to cyber security incidents that cause, or are likely to cause, serious harm to one or more individuals.
(2) An accredited entity must prepare and keep records of:
(a) any decisions to use civil, administrative or disciplinary procedures, or to take no further action, in response to a cyber security incident; and
(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:
(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
(b) for each incident:
(i) the date and time of the incident;
(ii) a description of the type of incident;
(iii) the number of digital IDs affected (if any); and
(iv) the severity of the incident; and
(c) a description of the measures taken by the entity in response to the incidents covered by the report.
(4) Subject to rule 7.8, a record required by this rule must:
(a) be retained for a minimum of 3 years from the day it was generated; and
(b) not contain biometric information.
Subdivision D—Information technology system controls
4.19 Essential Eight
(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.
(2) An 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.
Note: 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.20 Logging requirements
(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) Without limiting subrule (1), the activities to be recorded must include:
(a) any creation, update, use, disclosure or destruction of personal information;
(b) if biometric information is collected or retained by or on behalf of an ISP—the destruction of that biometric information;
(c) successful or failed elevation of access privileges by personnel;
(d) additions, deletions or modifications to personnel or group permissions;
(e) system alerts or failures related to cyber security risks; and
(f) unauthorised attempts to access critical systems or files.
Logging implementation and monitoring plan
(3) An accredited entity must have, maintain and comply with a plan (logging implementation and monitoring plan) that details:
(a) how the entity generates, stores, protects, monitors and analyses logs; and
(b) how the entity monitors logs to identify any anomalous behaviour.
(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.
(5) Each log required to be generated by this rule must include the following details for each event:
(a) interaction type;
(b) transaction audit identifier;
(c) the names of any entities involved in the event;
(d) any unique identifier used in the event;
(e) the date and time of the event;
(f) for an IXP—each kind of attribute conveyed for the event;
(g) for accredited entities other than an IXP—the types of attributes requested and disclosed to each entity involved in the event; and
(h) if the interaction type requires express consent, the audit log for that interaction must include the following as relevant to the interaction:
(i) the date and method by which any express consent was obtained from the individual;
(ii) the duration of the express consent; and
(iii) whether the express consent was granted or withdrawn by the individual.
(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.
<table cellspacing="0" cellpadding="0" style="width:100%; border-collapse:collapse"><thead><tr><td colspan="3" style="width:343.55pt; border-top:1.5pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Logging requirements</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Item</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Column 1</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Column 2</span></p></td></tr><tr><td style="width:24.65pt; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span></span></p></td><td style="width:116.8pt; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Kind of entity</span></p></td><td style="width:180.5pt; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Matter to be recorded</span></p></td></tr></thead><tbody><tr><td style="width:24.65pt; border-top:1.5pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span></span></p></td><td colspan="2" style="width:308.1pt; border-top:1.5pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span style="font-weight:bold">Accredited identity service providers</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>1</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ISP</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>The binding of attributes to a digital ID.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>2</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ISP that provides reusable digital IDs</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>All of the following:</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(a)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>the information required to implement and support rate limiting (see the Accreditation Data Standards);</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(b)</span><span style="width:2.54pt; text-indent:0pt; display:inline-block"> </span><span>the date and time the authenticator was bound to any individual’s digital ID;</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(c)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>the unique identifier assigned to each individual within the digital ID system in which the entity operates;</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(d)</span><span style="width:2.54pt; text-indent:0pt; display:inline-block"> </span><span>details of any physical authenticators bound to the digital ID of an individual; and</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(e)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>details of the source of any unsuccessful authentications attempted with the authenticator.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>3</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ISP that conducts biometric binding</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>Information associated with each biometric binding transaction, including the method of biometric binding used in the transaction.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>4</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ISP that conducts manual face comparison activities</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>All of the following:</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(a)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>the manual face comparison activities conducted during the biometric binding process; and</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(b)</span><span style="width:2.54pt; text-indent:0pt; display:inline-block"> </span><span>the assessing officer responsible for conducting any activities related to the biometric binding transaction.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span></span></p></td><td colspan="2" style="width:308.1pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span style="font-weight:bold">Accredited attribute service providers</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>5</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ASP</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>All of the following:</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(a)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>the retrieval of any special attribute by a third party;</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(b)</span><span style="width:2.54pt; text-indent:0pt; display:inline-block"> </span><span>the IP Level of the digital ID used to obtain any special attribute from the ASP; and</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(c)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>if available, the unique identifier assigned to the digital ID within the digital ID system in which the ASP operates.</span></p></td></tr></tbody></table>
(7) Subject to rule 7.8, a log required by paragraphs (2)(a) and (b), subrule (5) and subrule (6) must:
(a) be retained for a minimum of 3 years from the day it was generated; and
(b) not contain biometric information.
4.21 Cryptography
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) 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) 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:
(a) comply with TLS version 1.2 or higher; and
(b) follow any relevant risk mitigation advice in the document titled Implementing Certificates, TLS, HTTPS and Opportunistic TLS published by the ACSC.
4.23 Cryptographic key management processes and procedures
(1) An accredited entity must develop, implement and maintain documented, effective and secure cryptographic key management processes and procedures for its information technology system.
(2) The entity’s cryptographic key management processes and procedures must cover cryptographic key lifecycle management, including:
(a) cryptographic key generation;
(b) registration;
(c) distribution;
(d) installation;
(e) usage;
(f) protection;
(g) storage;
(h) access;
(i) revocation;
(j) recovery; and
(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.24 Fraud 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:
(a) allocating adequate budget and resources; and
(b) providing for management oversight.
(2) An accredited entity’s fraud management capability must be appropriate and adapted to respond to fraud risks, having regard to:
(a) the extent and nature of personal information that the entity holds;
(b) the extent and nature of fraud risks, threats and vulnerabilities;
(c) the potential loss or damage to one or more individuals if a digital ID fraud incident occurs;
(d) the potential loss or damage to relying parties if a digital ID fraud incident occurs; and
(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.
(3) An accredited entity must take reasonable steps to prevent, detect and address digital ID fraud incidents, including by:
(a) having and maintaining fraud management capability;
(b) continuously improving its fraud management capability; and
(c) identifying, treating and managing fraud risks.
Division 2—Fraud controls
4.25 Fraud risk assessment
(1) An accredited entity must, for each reporting period, conduct an assessment of the fraud risks associated with its accredited services and DI data environment (fraud risk assessment).
(2) The accredited entity must:
(a) develop a risk matrix based on an established risk management framework or standard; and
(b) as part of the fraud risk assessment:
(i) assess the entity’s fraud risks in accordance with the risk matrix developed in accordance with paragraph (a);
(ii) record the results of the assessment;
(iii) determine and record the entity’s level of tolerance to fraud risks; and
(iv) record how the entity’s controls for fraud risks are applied to its accredited services and DI data environment.
(3) If an ISP collects, uses, holds, discloses or destroys biometric information, the ISP must assess and record in its fraud risk assessment the fraud risks, mitigation strategies and any other actions the ISP will take to address risks related to biometric information.
Applicants
(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.26 Sharing information about risks
An accredited entity must:
(a) consider the implications that the entity’s decisions related to the management of fraud risks have for other participants of the digital ID system in which the accredited entity operates; and
(b) share information on known fraud risks or digital ID fraud incidents with those participants as appropriate.
4.27 Fraud controller
(1) An accredited entity must have a key position of fraud controller held by a senior officer of the entity (fraud controller).
(2) The fraud controller must have responsibility for:
(a) managing fraud risks; and
(b) facilitating the entity’s compliance with the fraud control requirements specified in this Part.
(3) The fraud controller must have appropriate qualifications and experience to effectively carry out the duties specified for the position in this Part and the entity’s fraud control plan.
(4) Details of the fraud controller must be included in the accredited entity’s fraud control plan.
4.28 Fraud awareness training
An accredited entity must ensure that each of its personnel whose duties relate to its accredited services or DI data environment successfully complete appropriate training in relation to the management of fraud risks:
(a) before starting work on those duties; and
(b) at least once in every 12‑month period thereafter.
4.29 Advice to individuals
An ISP must provide advice to individuals about how to safeguard their digital ID against digital ID fraud risks and update that advice, as soon as practicable, as new risks and threats emerge.
4.30 Support to individuals
(1) An accredited entity providing public‑facing accredited services must provide support services to individuals who have been adversely affected by a digital ID fraud incident.
(2) For the purposes of subrule (1), support services must, at a minimum, include the provision of:
(a) one of the following:
(i) a monitored chat function; or
(ii) a monitored email function; or
(iii) a call centre; and
(b) a function that allows the individual to speak with a natural person.
Division 3—Fraud control plan
4.31 Fraud control plan
(1) An accredited entity must have, maintain and comply with a plan that details the entity’s key fraud risks and the structures, controls and strategies the entity has in place to counter fraud in relation to its accredited services and DI data environment (fraud control plan).
(2) An entity of the kind specified in column 1 of an item in the following table must, at a minimum, detail each matter specified in column 2 of that item in the fraud control plan.
<table cellspacing="0" cellpadding="0" style="width:100%; border-collapse:collapse"><thead><tr><td colspan="3" style="width:343.55pt; border-top:1.5pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><a id="_Ref142597343"><span>Fraud control plan requirements</span></a></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Item</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Column 1</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Column 2</span></p></td></tr><tr><td style="width:24.65pt; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span></span></p></td><td style="width:116.8pt; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Kind of entity</span></p></td><td style="width:180.5pt; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="TableHeading"><span>Matter to be detailed</span></p></td></tr></thead><tbody><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span></span></p></td><td colspan="2" style="width:308.1pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span style="font-weight:bold">Risks</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>1</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>Accredited entity</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>All of the following:</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(a)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>any fraud risks, threats and vulnerabilities, including any fraud risks eventuating through other entities interacting with the entity’s DI data environment, that may impact the entity’s DI data environment;</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(b)</span><span style="width:2.54pt; text-indent:0pt; display:inline-block"> </span><span>an assessment of the significance of any fraud risks, threats and vulnerabilities;</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(c)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>the strategies and controls the entity uses, or proposes to use, to manage the fraud risks, threats and vulnerabilities identified under paragraph (a), including strategies and controls to implement and maintain a positive fraud risk culture;</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(d)</span><span style="width:2.54pt; text-indent:0pt; display:inline-block"> </span><span>the entity’s level of tolerance of fraud risks;</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(e)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>the risk ratings and scale the entity uses, or will use, when assessing the severity of a digital ID fraud incident; and</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(f)</span><span style="width:4.21pt; text-indent:0pt; display:inline-block"> </span><span>the entity’s key positions with responsibility for managing fraud risks and the duties of those positions.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span></span></p></td><td colspan="2" style="width:308.1pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span style="font-weight:bold">Goals and strategic objectives</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>2</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>Accredited entity</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>All of the following:</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(a)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>the entity’s goals and strategic objectives to manage and improve its fraud management capability; and</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(b)</span><span style="width:2.54pt; text-indent:0pt; display:inline-block"> </span><span>the steps that the entity is taking, or proposes to take, to continuously improve its fraud management capability;</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="page-break-inside:avoid; page-break-after:avoid"><span></span></p></td><td colspan="2" style="width:308.1pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt; page-break-after:avoid"><span style="font-weight:bold">Personnel and training</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>3</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>Accredited entity</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>The strategies and controls the entity has used, or will use, to ensure the entity’s personnel whose duties relate to the entity’s DI data environment successfully complete appropriate training in relation to the prevention and management of fraud risks.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span></span></p></td><td colspan="2" style="width:308.1pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span style="font-weight:bold">Digital ID fraud incident management</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>4</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>Accredited entity</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>The strategies and controls the entity has used, or will use, for managing and investigating digital ID fraud incidents and reporting digital ID fraud incidents to the Digital ID Regulator.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span></span></p></td><td colspan="2" style="width:308.1pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span style="font-weight:bold">Biometric binding</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>5</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ISP that collects, holds, uses, discloses and destroys biometric information</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>Details of the ISP’s approach to the use of biometric information for digital ID fraud risk management activities.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>6</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ISP that conducts manual face comparison</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>All of the following:</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(a)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>details of the procedures the ISP has implemented or will implement to detect any fraudulent activities by assessing officers when those officers are conducting manual face comparison; and</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(b)</span><span style="width:2.54pt; text-indent:0pt; display:inline-block"> </span><span>a description of each location at which the entity undertakes or will undertake biometric binding.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>7</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ISP that conducts eIDVT</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>All of the following:</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(a)</span><span style="width:3.1pt; text-indent:0pt; display:inline-block"> </span><span>the risks, threats and vulnerabilities specific to the use of eIDVT; and</span></p><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt"><span>(b)</span><span style="width:2.54pt; text-indent:0pt; display:inline-block"> </span><span>the processes and procedures the ISP uses, or will use, to ensure the destruction of acquired images of processed photo IDs.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>8</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ISP</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>The process the ISP has undertaken or will undertake to meet the requirements in items</span><span> </span><span>1 to 9 in the IP Levels Table relevant to the identity proofing levels the accredited entity is accredited to provide.</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="page-break-inside:avoid; page-break-after:avoid"><span></span></p></td><td colspan="2" style="width:308.1pt; border-top:0.75pt solid #000000; border-bottom:0.75pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext" style="margin-left:14.2pt; text-indent:-14.2pt; page-break-inside:avoid; page-break-after:avoid"><span style="font-weight:bold">In</span><span style="font-weight:bold">‑</span><span style="font-weight:bold">device biometric capability</span></p></td></tr><tr><td style="width:24.65pt; border-top:0.75pt solid #000000; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>9</span></p></td><td style="width:116.8pt; border-top:0.75pt solid #000000; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>ISP that conducts authentication using in</span><span>‑</span><span>device biometric capability</span></p></td><td style="width:180.5pt; border-top:0.75pt solid #000000; border-bottom:1.5pt solid #000000; padding-right:5.4pt; padding-left:5.4pt; vertical-align:top"><p class="Tabletext"><span>The risks, threats and vulnerabilities specific to the entity’s use of in</span><span>‑</span><span>device biometric capability.</span></p></td></tr></tbody></table>
Assessment of risks related to biometric information
(3) If an accredited entity collects, uses, holds, discloses or destroys biometric information, the entity’s fraud control plan must also include details of digital ID fraud risks and associated mitigation strategies and any other actions the entity will take to address risks related to that biometric information and to conducting biometric binding or using biometric information for authentication, including risks relating to:
(a) using biometric matching algorithms to complete biometric binding;
(b) using systems for presentation attack detection to complete presentation attack detection;
(c) any capture, temporary storage, and destruction of biometric information;
(d) any biometric matching process the entity implements;
(e) any potential and known threats and attacks to the entity’s biometric capability; and
(f) using any manual processes conducted by assessing officers to complete local biometric binding.
4.32 Review of entity’s fraud control plan
(1) An accredited entity must review and update its fraud control plan:
(a) at least once in each reporting period; and
(b) as soon as practicable after:
(i) the entity becomes aware of any digital ID fraud incident which is of a kind not covered in the entity’s fraud control plan or which exceeds the entity’s recorded level of tolerance of fraud risks;
(ii) the entity becomes aware of any breach of a requirement specified in its fraud control plan; and
(iii) any change in the entity’s organisational structure or control, functions or activities, if that change will, or is reasonably likely to, increase fraud risks to the entity’s accredited services or DI data environment.
(2) The entity’s review of its fraud control plan must, at a minimum:
(a) have regard to any significant shifts in the entity’s fraud risk, threat and operating environment;
(b) include an assessment of the appropriateness of the existing fraud control measures and mitigation controls; and
(c) review and, if necessary, update the goals and strategic objectives in the entity’s fraud control plan, including:
(i) recording whether each goal and strategic objective has been met; and
(ii) updating the goals and strategic objectives for the next year.
(3) As soon as practicable after the entity has completed each review of its fraud control plan, the entity must make all necessary amendments to its fraud control plan.
(4) Any changes to the entity’s fraud control plan must be approved in writing by the entity’s fraud controller.
Division 4—Incident detection, investigation, response and reporting
4.33 Incident monitoring and detection
(1) An accredited entity must implement and maintain appropriate mechanisms for:
(a) preventing and detecting digital ID fraud incidents; and
(b) alerting the entity’s personnel to digital ID fraud incidents.
(2) Without limiting subrule (1), the mechanisms must include an accessible process for personnel, individuals, enforcement bodies and other entities to report digital ID fraud incidents to the accredited entity on a confidential basis.
4.34 Incident investigation, management and response
(1) An accredited entity must investigate digital ID fraud incidents unless the incident has been referred to, and has been accepted by, an enforcement body.
(2) An accredited entity must ensure that its personnel whose duties relate to conducting fraud investigations are appropriately qualified and trained to carry out those duties.
(3) An accredited entity must implement and maintain mechanisms for responding to digital ID fraud incidents, including procedures that:
(a) document the entity’s processes for responding to digital ID fraud incidents and how it will investigate such incidents; and
(b) include appropriate criteria for making timely decisions at each critical stage in response to a digital ID fraud incident.
(4) If an accredited entity cannot investigate a digital ID fraud incident because the entity does not hold any personal information relevant to the incident, the entity must take reasonable steps to assist with the fraud investigation being conducted by other participants in the same digital ID system.
Note: Example: Reasonable steps may include providing information relevant to the incident to another participant in the digital ID system if the entity is authorised to disclose such information.
4.35 Record keeping
(1) An accredited entity must keep records of:
(a) decisions to use civil, administrative or disciplinary procedures, or to take no further action, in response to a digital ID fraud incident; and
(b) the entity’s investigation of and responses to digital ID fraud incidents.
(2) 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:
(a) the number of digital ID fraud incidents that occurred in the reporting period in relation to the entity’s accredited services and DI data environment (if any); and
(b) for each incident:
(i) the date and time of the incident;
(ii) a description of the type of incident;
(iii) the number of digital IDs affected (if any); and
(iv) the severity of the incident; and
(c) a description of the measures taken by the entity in response to the incidents covered by the report.
(3) Subject to rule 7.8, a record required by this rule must:
(a) be retained for a minimum of 3 years from the day it was generated; and
(b) not contain biometric information.
Part 4.3—Privacy
4.36 Privacy governance code
In this Division:
privacy governance code means the Privacy (Australian Government Agencies — Governance) APP Code 2017.
agency has the same meaning as in the privacy governance code.
4.37 Compliance with privacy governance code
An accredited entity which is not an agency must comply with the privacy governance code in respect of its accredited services and DI data environment as if the entity were an agency for the purposes of the code.
Note: The privacy governance code includes requirements that agencies have a privacy officer, privacy champion, privacy management plan, register of privacy impact assessments, privacy education and training. Agencies must also conduct a privacy impact assessment for all high privacy risk projects and regularly review their internal privacy processes.
4.38 Privacy policy
(1) An accredited entity must have, maintain and comply with a privacy policy covering its accredited services and DI data environment.
(2) The entity’s privacy policy must:
(a) be written in a clear and simple manner, using plain language that is easy to understand;
(b) provide sufficient detail about the collection, use and disclosure of personal information related to the entity’s accredited services so as to enable an individual to understand how their personal information is collected, used and disclosed; and
(c) be separate to the privacy policy for its other business and organisational functions.
(3) An entity which is accredited as more than one kind of accredited entity, must have and maintain either:
(a) separate privacy policies and privacy management plans for each kind of accredited entity it is accredited as; or
(b) distinct sections in its privacy policy and privacy management plan for each kind of accredited entity it is accredited as.
4.39 Review
An
accredited
entity must review its privacy policy and privacy management plan at least once in each reporting period.
4.40 Providing information about express consent
An accredited entity that provides public
‑
facing accredited services and is required to obtain the express consent of an individual must ensure that the process for an individual to provide express consent, or to withdraw or vary that consent, is described in clear, simple and accessible terms.
4.41 Duration of express consent
(1) This rule applies
if an individual gives an accredited entity express consent for the future collection, use or disclosure of the individual’s personal information.
(2)
An accredited entity providing public
‑
facing accredited services must provide the individual with a clear and simple process to vary or withdraw any consent given in accordance with subrule
(1).
(3)
Consent given in accordance with subrule
(1) expires at the earliest of the following:
(a)
the end of the period of consent specified by the individual (if any) when the individual gave their consent or at any time afterwards;
(b)
if the individual has varied their consent—the end of the period of consent specified by the individual (if any) when the individual varied their consent;
(c)
the end of the period of consent specified by the accredited entity when the entity collected the individual’s consent;
(d) either:
(i) if the accredited entity is an ASP and the individual declares in their consent that their use of the entity’s accredited services is for or on behalf of a business (including a business carried on by that individual)—7 years after the consent was initially given; or
(ii) otherwise—12 months after the consent was initially given.
(4) An accredited entity must not rely on consent given
in accordance with subrule
(1) if that consent has
been withdrawn or has expired.
4.42 Data minimisation principle
(1) An accredited entity must only collect personal information that is reasonably necessary for the entity to provide its accredited services.
(2) If an accredited entity discloses personal information to a relying party for the purposes of the relying party providing a service to an individual, or enabling the individual to access a service, the accredited entity must ensure that the personal information disclosed is limited to the information that is necessary by:
(a) ensuring that the accredited entity’s information technology system allows the relying party to only select the attributes of the individual that the relying party requires to provide the service, or access to the service, to that individual; and
(b) ensuring that the accredited entity provides only the selected attributes to the relying party.
4.43 Disclosure of personal information for fraud activities
An accredited entity must notify individuals that the entity may use and disclose the individual’s personal information to prevent, detect, manage and investigate digital ID fraud incidents.
4.44 Privacy awareness training
An accredited entity must ensure that each of its personnel whose duties relate to its accredited services or DI data environment complete privacy awareness training covering the entity’s privacy policy, privacy management plan and compliance with the additional privacy safeguards in Chapter 3 of the Act and this Part:
(a) before starting work on those duties; and
(b) at least once in every 12‑month period thereafter.
4.45 Data breach response plan
(1) An accredited entity must have, maintain and comply with a data breach response plan that includes a description of the actions to be taken by the entity in the event of a data breach or suspected data breach involving its accredited services or DI data environment.
(2) The data breach response plan must:
(a) identify the roles and responsibilities of any personnel involved in managing a data breach;
(b) include both a communication plan and guidance for personnel as to when and how information related to a data breach is to be:
(i) escalated within the entity;
(ii) notified to individuals affected by the data breach;
(iii) notified to a third party, including any notifications required by law; and
(c) not be inconsistent with the entity’s fraud control plan or system security plan.
(3) For the avoidance of doubt, if an accredited entity uses an enterprise or organisation level data breach response plan, that plan must comply with this rule.
(4) An accredited entity must review and, if required, update its data breach response plan at least once in each reporting period.
4.46 Record keeping
(1) An accredited entity must:
(a) keep records of its decisions to use civil, administrative or disciplinary procedures, or to take no further action, in response to a data breach; and
(b) keep records of the entity’s investigation of and response to data breaches.
(2) Subject to rule 7.8, a record required by this rule must:
(a) be retained for a minimum of 3 years from the day it was generated; and
(b) not contain biometric information.
Part 4.4—Accredited services must be accessible and inclusive
4.47 Application
This Part applies for the purposes of subsection 30(1) of the Act.
4.48 Reporting on accessibility
Once in each reporting period, an accredited entity must prepare a report detailing:
(a) any reasonable steps taken by the entity during that reporting period to ensure its accredited services are accessible for individuals who experience barriers when creating or using a digital ID; and
(b) any reasonable steps the entity proposes to take in the next reporting period to improve the accessibility of its services.
Note 1: See subsection 30(1AA) of the Act.
Note 2: The report must be included in the annual report provided to the Digital ID Regulator as part of the entity’s annual review–see Chapter 6.
4.49 Accessibility requirements
(1) An accredited entity must:
(a) provide individuals with a clear and simple description of the entity’s accredited services;
(b) present public‑facing information related to accredited services in a clear and simple manner, using plain language that is easy to understand; and
(c) take reasonable steps to ensure public‑facing information related to accredited services is available in multiple accessible formats.
(2) For the purposes of paragraph 30(2)(a) of the Act, an accredited entity must comply with Level A conformance specified in WCAG Version 2.1 by ensuring public‑facing information related to accredited services on its web pages (within the meaning of that term in the WCAG) satisfy the Level A Success Criteria specified in WCAG version 2.1.
(3) An accredited entity must take reasonable steps to ensure public‑facing accredited services and public‑facing information related to accredited services satisfy the Level AA Success Criteria as specified in WCAG version 2.1.
(4) For the purposes of paragraph 30(2)(b) of the Act, an accredited entity providing public‑facing accredited services and public‑facing information related to accredited services, when considering the accessibility of those services and information, must have regard to:
(a) item 3 (Information and the operation of the user interface must be understandable) of the WCAG;
(b) the ‘Optional Components of a Conformance Claim’ as specified in the WCAG; and
(c) the World Wide Web Access: Disability Discrimination Act Advisory Notes published by the Australian Human Rights Commission.
Note 2: See also Division 2 (Useability testing) and Division 3 (WCAG testing) of Part 3.3 of Chapter 3, which set out requirements to test compliance with requirements related to accessible and inclusive accredited services.
(5) For the purposes of paragraph 30(2)(e) of the Act, an accredited entity providing public‑facing accredited services must:
(a) provide assisted digital support to individuals who may experience barriers when creating or using a digital ID; and
(b) publish details of such support.
Note: Example: Assisted digital support may include a monitored email address, a monitored chat function, call centre or a telephone support line. Alternative channels may include an in‑person shopfront.
(6) An accredited entity providing public‑facing accredited services must have written processes and procedures to:
(a) allow individuals to seek assistance or otherwise resolve disputes or complaints in relation to the entity’s public‑facing accredited services;
(b) obtain and record feedback from individuals about the useability and accessibility of the entity’s public‑facing accredited services; and
(c) if appropriate, incorporate such feedback into the design of its DI data environment.
Part 4.5—Biometric information: testing and fraud activities
4.50 Requirements if biometric information is used for testing activities
(1) For the purposes of paragraph 49(6)(c) of the Act, an accredited entity that uses biometric information of an individual for the purpose of undertaking testing in relation to the information must comply with this rule.
Note: Section 51 of the Act specifies when biometric information must be destroyed.
Purposes for which testing may be conducted
(2) An accredited entity may only undertake testing using biometric information for one or more of the following purposes:
(a) to identify whether the thresholds of its technology for presentation attack detection are set correctly, including whether active ‘spoofing’ attacks on the technology will be correctly rejected;
(b) to identify issues associated with the performance and accuracy of its technology for presentation attack detection;
(c) to optimise its technology for presentation attack detection to improve its useability, performance and accuracy;
(d) to optimise controls that account for variances in image quality;
(e) to identify issues associated with the performance and accuracy of the biometric matching algorithm;
(f) to optimise the biometric matching algorithm to improve its performance and accuracy; or
(g) to measure any system demographic biases related to the quality of the biometric information.
Circumstances in which testing is conducted
(3) Testing using biometric information must be conducted only in the following circumstances:
(a) if the testing is unable to be conducted effectively using relevant and representative synthetic or anonymised biometric data rather than biometric information of an individual;
(b) by a person with appropriate skills, experience and qualifications to conduct the testing; and
(c) in accordance with:
(i) the entity’s system security plan;
(ii) a policy for working with human test subjects published by a national or international body; and
(iii) a plan (testing plan) that includes the information specified in subrule (4).
(4) A testing plan must include the following information:
(a) the objectives of the testing;
(b) the methodology to be used to conduct the testing, including:
(i) the source and type of test data used; and
(ii) a description of the biometric information and the sample sizes to be used;
(c) the frequency and duration of the testing;
(d) how the biometric information will be stored and protected during the period of the testing; and
(e) how the biometric information will be destroyed at the end of the testing period.
Note: For paragraph (4)(d), ISO/IEC 24745 outlines how to protect biometric information that is stored.
(5) An accredited entity must ensure that any testing using biometric information is conducted in accordance with the requirements of one or more policies covering the ethical use of biometric information, being policies and guidelines that ensure biometric systems do not selectively disadvantage or discriminate against any group.
Reporting of test results
(6) For each reporting period, the accredited entity must prepare a report detailing the results of any testing using biometric information conducted in that reporting period and containing the following information:
(a) the total number of transactions involving biometric information;
(b) the number of transactions that were tested;
(c) the number of individuals whose biometric information was used for testing;
(d) whether the testing resulted in the entity taking any action to respond to issues identified during the testing;
(e) an assessment of whether the retention, use and disclosure of the biometric information for testing continues to be an effective mitigation measure against digital ID fraud risks, when balanced against the cyber security risk of retaining the biometric information; and
(f) in respect of testing conducted for a purpose specified in paragraph (2)(c), (d) or (f)—whether the testing effectively and ethically detected and corrected any bias identified in the biometric matching algorithm or presentation attack detection technology so as not to selectively disadvantage or discriminate against any group whose biometric information is used.
Note: Example: For paragraph (e), the entity’s assessment could include consideration as to whether tests using biometric information has improved the thresholds of the presentation attack detection system to effectively reject malicious actors.
4.51 Requirements if biometric information is used for fraud activities
For the purposes of paragraph 49(8)(c) of the Act, an accredited entity that uses biometric information of an individual for the purposes of preventing or investigating a digital ID fraud incident must conduct the digital ID fraud risk management activities in accordance with written ethical principles aimed at avoiding disadvantage to, or discrimination against, individuals.
Note: Section 51 of the Act specifies when biometric information must be destroyed.
Part 4.6—Review of DI data environment and statement of scope and applicability
4.52 DI data environment
At least once in each reporting period, an accredited entity must review the boundaries of its DI data environment:
(a) in accordance with rule 2.1 as if the references in that rule to ‘applicant’ were to the ‘accredited entity’; and
(b) update the documented boundaries of its DI data environment to ensure it has correctly and completely defined and documented the boundaries of the DI data environment as at the time of the review.
4.53 Statement of scope and applicability
An accredited entity must review its statement of scope and applicability for completeness and accuracy:
(a) when it becomes aware of a material change to the extent and nature of threats to its DI data environment; or
(b) if no such material changes occur—at least once in each reporting period.
Chapter 5—Requirements when providing accredited services
Part 5.1—Accredited identity service providers
Division 1—Generating, managing, maintaining or verifying a digital ID
5.1 General requirements
(1) When generating a digital ID, an ISP must:
(a) unless the ISP is generating a digital ID in accordance with an alternative proofing process:
(i) comply with the requirements in this Part applicable to the accredited service being provided and the manner of providing that service;
(ii) comply with the Accreditation Data Standards applicable to the accredited service being provided and the manner of providing that service; and
(iii) verify the identity of the individual using only documents or other credentials of a kind listed in Schedules 1 to 4 which are verified in accordance with the requirement in column 2 of the relevant schedule; and
(b) at the time of generating the digital ID:
(i) bind an identity proofing level to the digital ID by complying with each requirement specified as ‘must’ or ‘yes’ in the column of the IP Levels Table for the relevant identity proofing level to be bound to the digital ID;
(ii) for a reuseable digital ID—bind one or more authenticators to the digital ID; and
(c) must not assert an identity proofing level or authentication level for a digital ID unless:
(i) other than if the ISP is generating a digital ID in accordance with an alternative proofing process—each of the requirements in the IP Levels Table for that identity proofing level has been met; and
(ii) each of the requirements in the AL Table for that authentication level has been met.
(2) An ISP must not assert that its processes for a particular identity proofing level creates assurance for that level that is similar or equivalent to a higher identity proofing level.
5.2 Digital IDs and children
(1) An ISP must not generate a digital ID for an individual who is less than 15 years old.
(2) If the ISP is generating a digital ID for an individual at IP Level 1, the ISP will not breach subrule (1) if it requires the individual seeking to generate a digital ID to confirm that they are 15 years or over and the individual gives that confirmation in writing.
Note: For IP Level 1, the individual is not required to provide identity documentation to the ISP that would allow the ISP to independently verify the individual’s age.
5.3 One‑off digital IDs
(1) An ISP accredited to generate a digital ID that is to be used once only must not retain an attribute of an individual once the attribute has been disclosed to the relying party in a transaction, unless the ISP is required or permitted to retain the attribute in accordance with subrule (2).
(2) For the purpose of subrule (1):
(a) the ISP may retain the attribute for the purposes of preventing or investigating a digital ID fraud incident for a maximum period of 30 days commencing the day after the attribute is disclosed to the relying party in a transaction; and
(b) the ISP must retain the attribute if the ISP is required by law (including the Act and these rules) to retain the attribute.
5.4 Use of a reusable digital ID
(1) An ISP must not use a reuseable digital ID of an individual if more than 5 years have elapsed since the digital ID was created.
(2) Subrule (1) does not apply if:
(a) the digital ID was proofed to IP1 Plus or IP2;
(b) the ISP verified a document or other credential of the individual listed in Schedules 1 to 4 of these rules within 5 years from the date that the digital ID was created; and
(c) less than 5 years have elapsed since the ISP last verified a document or other credential of the individual listed in Schedules 1 to 4 of these rules.
(3) Subrule (1) does not apply if:
(a) the digital ID was proofed to IP2 Plus, IP3 or IP4;
(b) the ISP conducted biometric binding in respect of the digital ID within 5 years from the date that the digital ID was created; and
(c) less than 5 years have elapsed since the ISP last conducted biometric binding in respect of the digital ID.
(4) If a reuseable digital ID was created before the commencement of these rules:
(a) a reference to an ISP in this rule is taken, for the purpose of this rule, to include a reference to that entity at a time before the entity was accredited in accordance with the Act; and
(b) a reference to an IP level in this rule and in the definition of ‘biometric binding’ is taken, for the purpose of this rule, to be a reference to an equivalent level of identity proofing.
5.5 Step‑up of an identity proofing level
(1) An ISP may step‑up an individual’s identity proofing level for a reuseable digital ID if:
(a) the step‑up is requested by the individual;
(b) the ISP is accredited to conduct identity proofing at the higher identity proofing level; and
(c) before starting the step‑up process, the individual authenticates to the required authentication level of the higher identity proofing level as required by item 14 in the IP Levels Table.
(2) When completed, the ISP must notify the individual of the new identity proofing level bound to their digital ID.
5.6 Updating and correcting attributes
(1) An ISP must allow an individual to update or correct an attribute that the ISP has bound to the individual’s digital ID.
(2) Before binding the updated or corrected attribute to the digital ID of the individual, the ISP must:
(a) require the individual to authenticate to the authentication level already bound to the digital ID; and
(b) verify the attribute in accordance with the relevant requirements in the IP Levels Table.
(3) If the individual’s names (family names, given names) or date of birth are not consistent across documents or other credentials presented for verification, the ISP must conduct further verification using a linking credential and must do so in accordance with the requirements in the IP Levels Table.
5.7 Suspending the use of a digital ID
If an individual requests that an ISP temporarily suspend the use of the individual’s digital ID, the ISP must:
(a) confirm the legitimacy of the request;
(b) as soon as practicable after confirming the legitimacy of the request, suspend the use of the digital ID;
(c) following the suspension, notify the individual of the suspension and the process to resume their digital ID.
Note: See rule 5.9 for resumption of a suspended digital ID.
5.8 Digital IDs affected by a fraud or cyber security incident
(1) If the verification of, update to, or use of, a digital ID is identified as a suspected digital ID fraud incident or a suspected cyber security incident, an ISP must:
(a) verify that the digital ID has not been compromised;
(b) take reasonable steps to confirm that the individual has effective control of their digital ID; and
(c) if the ISP has not been able to confirm that the individual has effective control of their digital ID, suspend the use of the digital ID.
Suspected compromised digital ID
(2) If an ISP detects a digital ID fraud incident or cyber security incident in relation to an individual’s digital ID and suspects that the digital ID has been, or is likely to be, compromised, the ISP must suspend the use of that digital ID.
5.9 Resuming the use of a digital ID
(1) When resuming the use of a digital ID that was temporarily suspended in accordance with rule 5.7, the ISP must ensure:
(a) the individual completes identity proofing at the identity proofing level of the suspended digital ID and that the attributes presented by the individual can be linked to the attributes which comprise the suspended digital ID; or
(b) the individual completes biometric binding using a document or other credential whose attributes can be linked to the current attributes which comprise the suspended digital ID.
(2) When resuming the use of a digital ID that was suspended in accordance with subrule 5.8, the ISP must ensure the individual completes identity proofing at the identity proofing level of the suspended digital ID.
(3) The ISP is not required to resume the use of a digital ID that was suspended if the ISP no longer holds the information that would enable it to do so.
Division 2—Identity proofing and use of credentials
Subdivision A—Identity proofing
5.10 IP Levels Table
(1) The IP Levels Table:
(a) specifies 6 identity proofing levels and the requirements to be met for each of those identity proofing levels when an ISP is binding an identity proofing level to a digital ID of an individual; and
(b) specifies minimum requirements for each identity proofing level.
(2) The requirements in the IP Levels Table do not restrict an ISP from applying, for a particular proofing level, the requirements for a higher proofing level (subject to the entity’s accreditation conditions).
Note: Example: An ISP may use biometric binding to verify the identity of the individual as part of their fraud controls for IP2, although that is not required for IP2. However, the ISP cannot do so unless authorised to collect the biometric information by an accreditation condition and cannot assert that its IP2 assurance is similar or equivalent to a higher IP level (see subrule 5.1(2)).