{"id":"F2024L01430","name":"Digital ID Rules 2024","slug":"digital-id-rules-2024","collection":"legislative_instrument","jurisdiction":"commonwealth","status":"in_force","isInForce":true,"actNumber":null,"makingDate":null,"administeringDepartment":null,"currentVersion":{"id":105430,"registerId":"commonwealth-F2024L01430-current","compilationNumber":null,"startDate":"2026-04-03","status":"InForce","reasons":null,"registeredAt":null},"sections":[{"sectionNumber":"1.1","sectionType":"section","heading":"Name","content":"#### 1.1 Name\n\n These rules are the Digital ID Rules 2024.","sortOrder":0},{"sectionNumber":"1.3","sectionType":"section","heading":"Authority","content":"#### 1.3 Authority\n\n 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 ‘Digital ID Rules’ occurs.","sortOrder":1},{"sectionNumber":"1.4","sectionType":"section","heading":"Definitions","content":"#### 1.4 Definitions\n\n> Note 1: A number of expressions used in these rules are defined in section 9 of the Act, including the following:\n\n (a) accredited entity;\n (b) accredited service;\n (c) cyber security incident;\n (d) digital ID;\n (e) digital ID fraud incident;\n (f) participating relying party.\n\n> Note 2: A number of expressions used in these rules are defined in rule 1.4 of the Accreditation Rules, including the following:\n\n (a) DI data environment;\n (b) identity proofing level;\n (c) public-facing accredited services;\n (d) public-facing information related to accredited services.\n (1) Unless otherwise specified, expressions defined in the Accreditation Rules have the same meaning in these rules.\n (2) In these rules:\n\n> Accreditation Data Standards means the Digital ID (Accreditation) Data Standards 2024.\n\n> Accreditation Rules means the Digital ID (Accreditation) Rules 2024.\n\n> Act means the Digital ID Act 2024.\n\n> AGDIS Data Standards means the Digital ID (AGDIS) Data Standards 2024.\n\n> associated person, of an entity, means any of the following:\n\n (a) a person who makes, or participates in making, decisions that affect:\n (i) the entity’s management of its DI data environment; or\n (ii) for a participating relying party—the performance of the entity’s functions when operating in the Australian Government Digital ID System; or\n (b) a person who has the capacity to significantly affect:\n (i) the entity’s management of its DI data environment; or\n (ii) for a participating relying party—the performance of the entity’s functions when operating in the Australian Government Digital ID System; or\n (c) a person who would be a person mentioned in paragraphs (a) or (b) if the entity was an accredited entity or a participating relying party; or\n (d) if the entity is a body corporate—a person who:\n (i) is an associate (within the meaning of the Corporations Act) of the entity; or\n (ii) is an associated entity (within the meaning of the Corporations Act) of the entity.\n\n> authentication level has the same meaning as in the Accreditation Data Standards.\n\n> Corporations Act means the Corporations Act 2001.\n\n> IXP means an accredited identity exchange provider.\n\n> material change has its ordinary meaning.\n\n> Note: The definition of ‘material change’ in these rules is different to the definition of the same expression in the Accreditation Rules.\n\n> material effect, in relation to the operation of the Australian Government Digital ID System, includes:\n\n (a) any degradation or loss of functionality within the Australian Government Digital ID System; and\n (b) any detrimental effect on the ability of an entity that participates in the Australian Government Digital ID System to access the System.\n\n> pairwise identifier, in relation to an individual, means an identifier that:\n\n (a) identifies the individual to an accredited entity or a participating relying party; and\n (b) cannot be correlated with:\n (i) the individual’s identifier used by a different accredited entity or participating relying party; or\n (ii) another individual’s identifier.\n\n> participating entity means an entity that holds an approval to participate in the Australian Government Digital ID System.\n\n> Privacy Act means the Privacy Act 1988.\n\n> receiving entity: see rule 1.5.\n\n> reportable incident requirement means a requirement in these rules in respect of an incident specified in Chapter 4.\n\n> streamlined application: see rule 1.5.\n\n> transferring entity: see rule 1.5.","sortOrder":2},{"sectionNumber":"1.5","sectionType":"section","heading":"Meaning of streamlined application","content":"#### 1.5 Meaning of streamlined application\n\n In these rules, streamlined application means an application under section 61 of the Act made by an entity (the receiving entity) where:\n (a) the receiving entity is of a kind mentioned in paragraph (c), (d), (e), (f) or (g) of the definition of entity in the Act; and\n (b) a participating relying party (the transferring entity) that is an entity of a kind mentioned in one of those paragraphs is approved to provide, or to provide access to, one or more services within the Australian Government Digital ID System (the approved services); and\n (c) a function of the transferring entity that includes the provision of the approved services is, or is reasonably expected to be, transferred to the receiving entity as a result of a machinery of government change; and\n (d) the application is for an approval to provide, or to provide access to, one or more of the approved services.\n\nChapter 2—Fit and proper person considerations","sortOrder":3},{"sectionNumber":"2.1","sectionType":"section","heading":"Application of this Chapter","content":"#### 2.1 Application of this Chapter\n\n (1) For the purposes of paragraph 12(a) of the Act, this Chapter specifies the matters to which the Digital ID Regulator must have regard when considering whether the person is a fit and proper person for the purposes of the Act, these rules, the Accreditation Rules, the Accreditation Data Standards and the AGDIS Data Standards.\n\n> Note: In deciding whether to accredit an entity, suspend or revoke the accreditation of an entity, approve an entity to participate in the Australian Government Digital ID System, or suspend or revoke the approval of an entity to participate in the Australian Government Digital ID System, the Digital ID Regulator may have regard to whether the entity is a fit and proper person (see subsections 15(5), 25(4), 26(3), 62(2), 71(3) and 72(3) of the Act).\n\n (2) For the avoidance of doubt, this Chapter does not limit the matters to which the Digital ID Regulator may have regard when considering whether the person is a fit and proper person for the purposes of the Act, these rules, the Accreditation Rules, the Accreditation Data Standards and the AGDIS Data Standards.","sortOrder":4},{"sectionNumber":"2.2","sectionType":"section","heading":"Mandatory relevant matters","content":"#### 2.2 Mandatory relevant matters\n\n (1A) This rule does not apply in relation to a streamlined application.\n (1) In having regard to whether an entity is a fit and proper person, the Digital ID Regulator must have regard to the following matters:\n (a) whether the entity, or an associated person of the entity, has, within the previous 10 years, been convicted or found guilty of:\n (i) a serious criminal offence; or\n (ii) an offence of dishonesty;\n against any law of the Commonwealth or of a State or Territory, or a law of a foreign jurisdiction;\n (b) whether the entity, or an associated person of the entity, has been found to have contravened:\n (i) a law relevant to the management of its DI data environment; or\n (ii) a similar law of a foreign jurisdiction;\n (c) whether the entity, or an associated person of the entity, has been the subject of:\n (i) a determination under paragraph 52(1)(b), or any of paragraphs 52(1A)(a) to (d), of the Privacy Act; or\n (ii) a finding or determination of a similar nature under a similar law of a State or Territory or a foreign jurisdiction;\n (d) if the entity is a body corporate—whether any of the directors of the entity, or of an associated person of the entity:\n (i) has been disqualified from managing corporations; or\n (ii) is subject to a banning order;\n (e) whether the entity, or an associated person of the entity, has a history of insolvency or bankruptcy;\n (f) whether the entity, or an associated person of the entity, has been the subject of a determination made under an external dispute resolution scheme that:\n (i) included a requirement to pay compensation; and\n (ii) was, at the time the determination was made:\n (A) recognised under section 35A of the Privacy Act; or\n (B) recognised under section 56DA of the Competition and Consumer Act 2010;\n (g) if the entity has made an application under section 14 of the Act for accreditation as an accredited entity—whether the entity’s application was refused;\n (h) if the entity has made an application under section 61 of the Act for approval to participate in the Australian Government Digital ID System—whether the entity’s application was refused;\n (i) if the entity is or has been an accredited entity—whether the entity’s accreditation is or has been suspended or revoked;\n (j) if the entity is or has been approved to participate in the Australian Government Digital ID System—whether the entity’s approval is or has been suspended or revoked.\n (2) Subrule (1) does not affect the operation of Part VIIC of the Crimes Act 1914 or a corresponding provision of an Australian or a law of a foreign country.\n\n> Note: Part VIIC of the Crimes Act 1914 includes provisions that, in certain circumstances, relieve persons from the requirement to disclose spent convictions and require persons aware of such convictions to disregard them.\n\n (3) In this rule:\n\n> banning order has the same meaning as in the Corporations Act.\n\n> director has the same meaning as in the Corporations Act.\n\n> serious criminal offence means an offence for which, if the act or omission had taken place in the Jervis Bay Territory, a person would have been liable, on first conviction, to imprisonment for a period of not less than 5 years.\n\n> Note: The Jervis Bay Territory is mentioned because it is a jurisdiction in which the Commonwealth has control over the criminal law.","sortOrder":5},{"sectionNumber":"2.3","sectionType":"section","heading":"Mandatory relevant matters—government entities affected by a machinery of government change","content":"#### 2.3 Mandatory relevant matters—government entities affected by a machinery of government change\n\n (1) This rule applies in relation to a streamlined application.\n (2) In considering whether the receiving entity is a fit and proper person, the Digital ID Regulator must have regard to whether the approval of the corresponding transferring entity to provide, or to provide access to, services within the Australian Government Digital ID System, has ever been suspended or revoked.\n\nChapter 3—Participation in the Australian Government Digital ID System","sortOrder":6},{"sectionNumber":"Part 1","sectionType":"part","heading":"Applications for approval to participate","content":"## Part 1—Applications for approval to participate","sortOrder":7},{"sectionNumber":"3.1","sectionType":"section","heading":"Application of this Part","content":"#### 3.1 Application of this Part\n\n (1) This Part does not apply in relation to a streamlined application.\n (2) For the purposes of paragraph 62(1)(f) of the Act, this Part prescribes additional requirements that must be met before the Digital ID Regulator may approve an entity to participate in the Australian Government Digital ID System.\n\n> Note: An application for approval to participate in the Australian Government Digital ID System made under section 61 of the Act must be accompanied by any information or documents required by this Part (see paragraph 141(1)(c) of the Act). The Digital ID Regulator is not required to make a decision on the application until the information or documents are provided (see subsection 143(2) of the Act).","sortOrder":8},{"sectionNumber":"3.2","sectionType":"section","heading":"Applications for approval to participate—all entities","content":"#### 3.2 Applications for approval to participate—all entities\n\n Before approving an application for approval to participate in the Australian Government Digital ID System, the Digital ID Regulator must be satisfied that the entity has in place effective written procedures to notify the System Administrator as soon as practicable of:\n (a) any proposed change to the entity’s information technology system that interacts with the Australian Government Digital ID System, if the change will, or could reasonably be expected to, have a material effect on the operation of the Australian Government Digital ID System; and\n (b) any planned or unplanned outage or downtime affecting the entity’s information technology system, if the outage or downtime will, or could reasonably be expected to, have a material effect on the operation of the Australian Government Digital ID System.","sortOrder":9},{"sectionNumber":"3.3","sectionType":"section","heading":"Applications for approval to participate—relying parties","content":"#### 3.3 Applications for approval to participate—relying parties\n\n (1) Before a relying party applies for approval to participate in the Australian Government Digital ID System, the entity must conduct a risk assessment to identify, evaluate and manage the risks of:\n (a) a cyber security incident; and\n (b) a digital ID fraud incident;\n occurring in connection with a service that the entity intends to provide, or provide access to, within the Australian Government Digital ID System.\n (2) A relying party that has made an application for approval to participate in the Australian Government Digital ID System must, at the time it makes the application, have all of the following:\n (a) a written cyber security plan approved by the entity’s governing body that addresses at least the following:\n (i) management of any risks identified when conducting the risk assessment referred to at paragraph (1)(a);\n (ii) prevention, identification, investigation and management of cyber security incidents, including incidents notified to the entity by the System Administrator, if the entity is approved to participate in the Australian Government Digital ID System; and\n (iii) the frequency with which the entity will review the plan, being at least once per year; and\n (b) a written digital ID fraud management plan approved by the entity’s governing body that addresses at least the following:\n (i) management of any risks identified when conducting the risk assessment referred to at paragraph (1)(b);\n (ii) prevention, identification, investigation and management of digital ID fraud incidents, including incidents notified to the entity by the System Administrator, if the entity is approved to participate in the Australian Government Digital ID System; and\n (iii) the frequency with which the entity will review the plan, being at least once per year; and\n (c) a written disaster recovery and business continuity plan approved by the entity’s governing body that addresses at least the following:\n (i) disaster recovery procedures for critical functions of the entity’s information technology system within the Australian Government Digital ID System; and\n (ii) the frequency with which the entity will review the plan, being at least once per year.","sortOrder":10},{"sectionNumber":"Part 2","sectionType":"part","heading":"Approval to participate","content":"## Part 2—Approval to participate","sortOrder":11},{"sectionNumber":"3.4","sectionType":"section","heading":"Conditions on approval to participate","content":"#### 3.4 Conditions on approval to participate\n\n (1) For the purposes of subsection 64(5) of the Act, the approval of an entity described in column 1 of an item of the following table is subject to the conditions specified in column 2 of the item.\n\n```html\n

Participation conditions

Item

Column 1

Column 2

Entity

Condition

1

Participating relying party

The entity must notify the Digital ID Regulator of a proposed change to its contact details no later than 7 days after the change takes effect.

2

Participating relying party

(a) The entity must notify the System Administrator, in accordance with subrule (2), of the following incidents that have occurred, or are reasonably suspected of having occurred:

(i) any proposed change to the entity’s information technology system that interacts with the Australian Government Digital ID System, if the change will, or could reasonably be expected to, have a material effect on the operation of the Australian Government Digital ID System; and

(ii) any planned or unplanned outage or downtime affecting the entity’s information technology system, if the outage or downtime will, or could reasonably be expected to, have a material effect on the operation of the Australian Government Digital ID System.

(b) The notification must be made no later than 5 business days after the earliest of the following:

(i) the entity becomes aware that the incident has occurred; or

(ii) the entity reasonably suspects that the incident has occurred.

3

Participating relying party

The entity must collect and store the pairwise identifier issued to the relying party in relation to each individual to enable the entity to comply with the reportable incident requirement mentioned in paragraph 4.2(3)(k).

\n```\n\n (2) The notification must include the following information:\n (a) the entity’s name;\n (b) the contact details for the entity;\n (c) if the incident relates to an associated person of the entity—the name and contact details of the associated person; and\n (d) a description of the incident;\n (e) the following details of the incident:\n (i) the date and time of the incident; and\n (ii) the date on which the entity became aware of the incident.\n\nChapter 4—Reportable incidents","sortOrder":12},{"sectionNumber":"4.1","sectionType":"section","heading":"Application of this Chapter","content":"#### 4.1 Application of this Chapter\n\n For the purposes of subsection 78(1) of the Act, this Chapter prescribes arrangements relating to the notification and management of incidents that have occurred, or are reasonably suspected of having occurred, in relation to the Australian Government Digital ID System.\n\n> Note: An entity is liable to a civil penalty if the entity is subject to a requirement under rules made for the purposes of subsection 78(1) and the entity fails to comply with the requirement (see subsection 78(4) of the Act).","sortOrder":13},{"sectionNumber":"4.2","sectionType":"section","heading":"Cyber security incidents and digital ID fraud incidents","content":"#### 4.2 Cyber security incidents and digital ID fraud incidents\n\n (1) This rule applies to:\n (a) a participating entity;\n (b) an entity whose approval to participate is suspended; and\n (c) an entity whose approval to participate has been revoked, but only in respect of incidents that have occurred, or are reasonably suspected of having occurred, while the entity was participating in the Australian Government Digital ID System.\n (2) The entity must notify the System Administrator, in accordance with this rule, of any of the following:\n (a) a cyber security incident; or\n (b) a digital ID fraud incident;\n if the incident occurred, or is reasonably suspected of having occurred, in relation to any accredited services:\n (c) for an accredited entity—provided by the entity within the Australian Government Digital ID System; or\n (d) for a participating relying party—received by the entity within the Australian Government Digital ID System.\n (3) The notification must include the following information:\n (a) the entity’s name;\n (b) the contact details of the entity;\n (c) the services affected by the incident;\n (d) a description of the incident;\n (e) the following details of the incident, so far as they are known to the entity:\n (i) the date and time of the incident;\n (ii) the date on which the entity became aware of the incident;\n (iii) the method or source of detection of the incident;\n (iv) the severity of the incident;\n (v) whether the incident has been resolved; and\n (vi) if the incident has been resolved—how it was resolved and how long the entity took to resolve it;\n (f) each digital ID affected by the incident;\n (g) for each individual whose digital ID is affected by the incident:\n (i) if the individual has been informed of the incident—when the individual was informed of the incident; and\n (ii) if the individual has not been informed of the incident—why the individual has not been informed of the incident;\n (h) any relevant identity proofing level and authentication level and, if an individual’s digital ID has been re-proofed because of the incident, the date that occurred;\n (i) the measures that the entity has taken and plans to take to deal with the incident, including any action the entity has taken or will take to reduce the risk to the accredited services the entity provides or receives within the Australian Government Digital ID System;\n (j) whether the incident has been referred to an enforcement body or law enforcement agency and, if so, the body or agency to which the incident was referred and the date and time of that referral; and\n (k) if the entity is a participating relying party—the pairwise identifier issued to the relying party in relation to each individual associated with the incident.\n (4) The notification must be made as soon as practicable after, and in any event no later than 1 business day after, the entity becomes aware that an incident has occurred or reasonably suspects an incident has occurred.\n (5) The notification may be given orally. However, if it is given orally, a written notification must be given no later than 3 business days after the oral notification.\n (6) If it is not reasonably practicable for the entity to provide some or all of the information required by subrule (3) (required information) within the period specified in subrule (4) or (5), the entity is taken to comply with subrule (3) if the entity:\n (a) provides an interim notification by the time required by subrule (4) or (5) that includes as much of the required information as is reasonably available to the entity at the time the interim notification is given;\n (b) takes reasonable steps to obtain the outstanding required information as soon as reasonably practicable; and\n (c) provides any outstanding information as soon as reasonably practicable, and in any event within 48 hours of the outstanding information becoming available to the entity.\n (7) If the System Administrator receives a notification under subrule (2), the System Administrator may direct any entity of a kind mentioned in subrule (1) who has interacted with a digital ID affected by the incident to conduct an investigation into the incident.\n (8) If the System Administrator directs an entity to conduct an investigation into an incident under subrule (7), that entity must:\n (a) begin conducting the investigation as soon as reasonably practicable; and\n (b) provide the System Administrator with a summary of the findings of the investigation as soon as reasonably practicable after the investigation is complete.\n (9) However, if an investigation under subrule (7) is not completed within the period of 28 days beginning on the day the System Administrator directs the entity to conduct the investigation, the entity must update the System Administrator on the progress of the investigation:\n (a) immediately after the end of that period; and\n (b) at least once after the end of any subsequent period of 28 days until the investigation is complete.","sortOrder":14},{"sectionNumber":"4.3","sectionType":"section","heading":"Other incidents","content":"#### 4.3 Other incidents\n\n (1) This rule applies to:\n (a) a participating entity; and\n (b) an entity whose approval to participate is suspended;\n in respect of incidents that have occurred, or are reasonably suspected of having occurred, while the entity was participating in the Australian Government Digital ID System.\n (2) The entity must notify the Digital ID Regulator, in accordance with this rule, of the following incidents:\n (a) any material change in the entity’s circumstances that might affect its ability to comply with its obligations under the Act, these rules, the Accreditation Rules, the Accreditation Data Standards and the AGDIS Data Standards;\n (b) any matter that could reasonably be considered relevant to whether the entity is a fit and proper person for the purposes of the Act, these rules, the Accreditation Rules, the Accreditation Data Standards and the AGDIS Data Standards, including matters involving an associated person of the entity; and\n (c) any material change to, or error in, any of the information provided to the Digital ID Regulator.\n (3) If the entity is an accredited entity—the entity must notify the System Administrator, in accordance with this rule, of the following incidents:\n (a) any proposed change to the entity’s information technology system that interacts with the Australian Government Digital ID System, where the change will, or could reasonably be expected to, have a material effect on the operation of the Australian Government Digital ID System; and\n (b) any planned or unplanned outage or downtime affecting the entity’s information technology system, where the outage or downtime will, or could reasonably be expected to, have a material effect on the operation of the Australian Government Digital ID System.\n (4) The notification must include the following information:\n (a) the entity’s name;\n (b) the contact details for the entity;\n (c) if the incident relates to an associated person of the entity—the name and contact details of the associated person;\n (d) a description of the incident; and\n (e) the following details of the incident:\n (i) the date and time of the incident; and\n (ii) the date on which the entity became aware of the incident.\n (5) The notification must be made no later than 5 business days after the earliest of the following:\n (a) the entity becomes aware that the incident has occurred; or\n (b) the entity reasonably suspects that the incident has occurred.","sortOrder":15},{"sectionNumber":"4.4","sectionType":"section","heading":"Other digital ID systems","content":"#### 4.4 Other digital ID systems\n\n (1) This rule applies to:\n (a) an accredited entity that holds an approval to participate; and\n (b) an accredited entity whose approval to participate is suspended.\n (2) The entity must notify the Digital ID Regulator, in accordance with this rule, if:\n (a) the entity uses an information technology system to provide services within the Australian Government Digital ID System; and\n (b) the entity proposes to use that information technology system to provide or receive services within a digital ID system other than the Australian Government Digital ID System (other digital ID system).\n (3) The notification must include the following information:\n (a) the entity’s name;\n (b) the contact details for the entity;\n (c) a description of:\n (i) the services to be provided or received by the entity within the other digital ID system; and\n (ii) any accredited services provided by the entity that are the same as or similar to the services to be provided or received by the entity within the other digital ID system;\n (d) details of the entity providing or managing the other digital ID system;\n (e) the nature of the proposed use of the other digital ID system;\n (f) the likely effect of the entity’s use of the other digital ID system on the levels of the entity’s risk of:\n (i) a cyber security incident; and\n (ii) a digital ID fraud incident; and\n (g) details of how the entity:\n (i) will clearly distinguish information flows within the Australian Government Digital ID System from information flows within the other digital ID system;\n (ii) will clearly distinguish between accredited services provided in the Australian Government Digital ID System and services provided within the other digital ID system;\n (iii) will ensure that information held by the entity for the purposes of the Australian Government Digital ID System is able to be located and distinguished from information held by the entity for the purposes of the other digital ID system; and\n (iv) will meet its obligations under the Act, these rules, the Accreditation Rules, the Accreditation Data Standards and the AGDIS Data Standards in respect of its accredited services.\n\n> Note: Example: For subparagraphs (g)(i) and (ii), an information barrier.\n\n (4) The notification must be made no later than 28 days before the proposed use of the other digital ID system.\n (5) In this rule:\n\n> other digital ID system has the meaning given in paragraph (2)(b).","sortOrder":16},{"sectionNumber":"4.5","sectionType":"section","heading":"System Administrator may give information","content":"#### 4.5 System Administrator may give information\n\n (1) The System Administrator may give information notified to it under rule 4.2 or subrule 4.3(3) to the Digital ID Regulator, the Minister or to a participating entity.\n\n> Note: These notifications relate to cyber security incidents and digital ID fraud incidents, proposed changes to the entity’s information technology system and planned or unplanned outages or downtime affecting the entity’s information technology system.\n\n (2) If the System Administrator acquires information about a cyber security incident or a digital ID fraud incident otherwise than by a notification under rule 4.2 or subrule 4.3(3), the System Administrator may give the information to a participating entity.\n (3) The System Administrator may only give information under this rule if it considers it appropriate to do so to protect the security, integrity or performance of the Australian Government Digital ID System.\n\n> Note: This subrule does not limit the functions of the System Administrator under the Act, which include sharing information with the Minister, the Digital ID Regulator, the Digital ID Data Standards Chair and the Information Commissioner to assist them to exercise their powers or perform their functions under the Act (see subsection 95(i) of the Act).\n\n (4) For the purposes of paragraph 78(2)(g) of the Act, a person or body to whom the System Administrator may give information under this rule is authorised to collect the information.\n\n> Note: This rule does not limit the functions of the Digital ID Regulator under the Act, which include sharing information with the Minister, the System Administrator, the Digital ID Data Standards Chair and the Information Commissioner to assist them to exercise their powers or perform their functions under the Act (see subsection 91(f) of the Act).\n\nChapter 4A—Redress framework","sortOrder":17},{"sectionNumber":"4A.1","sectionType":"section","heading":"Application of this Chapter","content":"#### 4A.1 Application of this Chapter\n\n (1) For the purposes of subsection 88(1) of the Act, this Chapter provides for a redress framework for incidents that occur in relation to accredited services of accredited entities that are provided within the Australian Government Digital ID System.\n (2) This Chapter applies to an ASP or an ISP that is one of the following:\n (a) a participating entity;\n (b) an entity whose approval to participate is suspended;\n (c) an entity whose approval to participate has been revoked.\n\n> Note 1: This Chapter deals with cyber security incidents and digital ID fraud incidents that occur in certain circumstances. Rule 4.2 (Cyber security incidents and digital ID fraud incidents) of these rules and rules 4.11 (Support to individuals), 4.30 (Support to individuals) and 5.8 (Digital IDs affected by a fraud or cyber security incident) of the Accreditation Rules also deal with cyber security incidents and digital ID fraud incidents.\n\n> Note 2: Part 5 of this Chapter does not apply to an ASP or an ISP whose approval to participate is suspended or has been revoked (see rule 4A.6).","sortOrder":19},{"sectionNumber":"4A.2","sectionType":"section","heading":"Notifying affected individuals of incidents","content":"#### 4A.2 Notifying affected individuals of incidents\n\n (1) This rule applies if a cyber security incident or a digital ID fraud incident occurs, or is reasonably suspected of having occurred, in relation to an accredited service provided by an entity to which this Chapter applies within the Australian Government Digital ID System.\n (2) The entity must make reasonable attempts to notify each individual affected by the incident.\n (3) Subrule (2) does not apply if the entity is satisfied that:\n (a) there is a likelihood of the individual suffering an adverse outcome as a result of the entity attempting to notify the individual of the incident; or\n (b) notifying the individual will, or could reasonably be expected to, have a material effect on the operation of the Australian Government Digital ID System.\n\n> Note 1: If an entity notifies an individual under subrule (2), the entity must also provide certain information, support and assistance to the individual (see rule 4A.5).\n\n> Note 2: Material effect, in relation to the operation of the Australian Government Digital ID System, is defined in subrule 1.4(2).","sortOrder":21},{"sectionNumber":"Part 3","sectionType":"part","heading":"Referring unresolved technical issues to the System Administrator","content":"## Part 3—Referring unresolved technical issues to the System Administrator","sortOrder":22},{"sectionNumber":"4A.3","sectionType":"section","heading":"Unresolved technical issues must be referred to the System Administrator","content":"#### 4A.3 Unresolved technical issues must be referred to the System Administrator\n\n (1) This rule applies if:\n (a) a cyber security incident or a digital ID fraud incident occurs, or is reasonably suspected of having occurred, in relation to an accredited service provided by an entity to which this Chapter applies within the Australian Government Digital ID System; and\n (b) as a result of the incident, an individual is unable to use their digital ID due to a technical issue with the entity’s service that is within the control of the entity or another entity to which this Chapter applies.\n (2) The entity must refer the technical issue to the System Administrator:\n (a) as soon as reasonably practicable after the entity becomes aware of the issue; and\n (b) if the entity became aware of the issue because of a complaint made by the individual—in any case within 28 days after the complaint is made.\n (3) However, the entity must refer the issue to the System Administrator under subrule (2) only if:\n (a) the entity is reasonably satisfied that the technical issue cannot be resolved without referring it to the System Administrator; and\n (b) the entity has complied with rule 4A.5 (if applicable) in relation to the incident.\n\n> Note: Rule 4A.5 is applicable if the entity became aware of the issue because of a complaint made by the individual (see paragraph 4A.5(1)(b)).","sortOrder":23},{"sectionNumber":"4A.4","sectionType":"section","heading":"System Administrator may recommend a resolution","content":"#### 4A.4 System Administrator may recommend a resolution\n\n (1) If the System Administrator receives a referral from an entity under rule 4A.3, the System Administrator may recommend a course of action to the entity to resolve the technical issue.\n (2) Without limiting subrule (1), a course of action recommended by the System Administrator may include that the entity do any of the following:\n (a) provide the individual an explanation of the circumstances giving rise to the technical issue;\n (b) issue an apology to the individual.","sortOrder":24},{"sectionNumber":"Part 4","sectionType":"part","heading":"Providing information, support and assistance to individuals affected by incidents","content":"## Part 4—Providing information, support and assistance to individuals affected by incidents","sortOrder":25},{"sectionNumber":"4A.5","sectionType":"section","heading":"Providing information, support and assistance to individuals affected by incidents","content":"#### 4A.5 Providing information, support and assistance to individuals affected by incidents\n\n (1) This rule applies if:\n (a) an entity notifies an individual about an incident under subrule 4A.2(2); or\n (b) an entity becomes aware of a technical issue mentioned in rule 4A.3 because of a complaint made by an individual.\n (2) The entity must:\n (a) direct the individual to any relevant public resources, including the information published by the entity on the resolution of incidents and the entity’s complaints processes; and\n (b) if the individual is unable to use their digital ID due to a technical issue with the entity’s service that is within the control of another entity to which this Chapter applies—provide reasonable assistance to help the individual identify that other entity and its contact details.","sortOrder":26},{"sectionNumber":"Part 5","sectionType":"part","heading":"Policies relating to incidents and complaints","content":"## Part 5—Policies relating to incidents and complaints","sortOrder":27},{"sectionNumber":"4A.6","sectionType":"section","heading":"Application of this Part","content":"#### 4A.6 Application of this Part\n\n Despite subrule 4A.1(2), this Part does not apply to an ASP or an ISP that is one of the following:\n (a) an entity whose approval to participate is suspended;\n (b) an entity whose approval to participate has been revoked.","sortOrder":28},{"sectionNumber":"4A.7","sectionType":"section","heading":"Policies relating to the identification etc. of incidents","content":"#### 4A.7 Policies relating to the identification etc. of incidents\n\n An entity to which this Part applies must develop and publish policies relating to the identification, management and resolution of cyber security incidents and digital ID fraud incidents that occur, or are reasonably suspected of having occurred, in relation to the accredited services provided by the entity within the Australian Government Digital ID System.","sortOrder":29},{"sectionNumber":"4A.8","sectionType":"section","heading":"Policies relating to complaints by individuals","content":"#### 4A.8 Policies relating to complaints by individuals\n\n (1) An entity to which this Part applies must develop and publish policies relating to complaints by individuals relating to cyber security incidents and digital ID fraud incidents that occur, or are reasonably suspected of having occurred, in relation to the accredited services provided by the entity within the Australian Government Digital ID System.\n (2) Without limiting subrule (1), the policies must deal with the following matters:\n (a) the process by which an individual may make a complaint to the entity, including the contact details that an individual may use for that purpose;\n (b) procedures for dealing with complaints made by individuals and a simplified outline of those procedures;\n (c) timeframes for resolving complaints made by individuals.\n (3) An entity may comply with subrule (1) by developing and publishing a policy relating to complaints by individuals:\n (a) generally; or\n (b) in relation to other matters as well as the matters mentioned in subrules (1) and (2).\n\nChapter 5—Trustmarks","sortOrder":30},{"sectionNumber":"5.1","sectionType":"section","heading":"Application of this Chapter","content":"#### 5.1 Application of this Chapter\n\n (1) For the purposes of subsection 117(1) of the Act, this Chapter specifies the digital ID trustmark that may be used by an accredited entity and the conditions and requirements in relation to the use or display of that digital ID trustmark.\n (2) For the purposes of paragraph 168(1)(b) of the Act, this Chapter also specifies the digital ID trustmark that may be used by an entity specified in rule 5.4 (authorised entity) and the conditions in relation to the use or display of that digital ID trustmark.\n\n> Note: An entity is liable to a civil penalty if:\n\n (a) an entity uses a digital ID trustmark, but the entity is not authorised by subsection 118(1) of the Act to use the digital ID trustmark (see subsection 118(2) of the Act); or\n (b) an entity is required by these rules to display a digital ID trustmark in circumstances specified in these rules and the entity fails to comply with the requirement (see section 119 of the Act).\n (3) To avoid doubt, this Chapter does not affect or limit a right or remedy provided by any other law of the Commonwealth or a law of a State or Territory.\n (4) In this Chapter:\n\n> authorised entity has the meaning given by subrule 5.1(2).\n\n> Digital ID Accreditation Trustmark has the meaning given by rule 5.2.","sortOrder":31},{"sectionNumber":"5.2","sectionType":"section","heading":"Digital ID trustmark","content":"#### 5.2 Digital ID trustmark\n\n The digital ID trustmark (Digital ID Accreditation Trustmark) specified in item 1 of Schedule 1 may be used by an accredited entity and an authorised entity.","sortOrder":32},{"sectionNumber":"5.3","sectionType":"section","heading":"Use or display of digital ID trustmark—accredited entities","content":"#### 5.3 Use or display of digital ID trustmark—accredited entities\n\n (1) This rule prescribes the conditions and requirements in relation to the use or display of the Digital ID Accreditation Trustmark by an accredited entity.\n Accredited identity exchange providers\n (2) The Digital ID Accreditation Trustmark may only be used or displayed by an IXP:\n (a) on public-facing accredited services of the IXP;\n (b) on any document that contains public-facing information related to accredited services concerning:\n (i) the accredited services of the IXP; or\n (ii) the accredited services of another accredited entity that is operating within the same digital ID system as the accredited services of the IXP.\n\n> Note: Example: Subparagraph (2)(b)(ii) allows an IXP to publish a list of its service providers and identify which of those providers are accredited entities by using the Digital ID Accreditation Trustmark.\n\n Accredited entities\n (3) If an accredited entity uses or displays the Digital ID Accreditation Trustmark, the accredited entity must also:\n (a) use and display a hyperlink to the Digital ID Accredited Entities Register near the Digital ID Accreditation Trustmark;\n (b) if a document on which the Digital ID Accreditation Trustmark is or can be printed—use and display the internet address of the Digital ID Accredited Entities Register near the Digital ID Accreditation Trustmark; and\n (c) if the accredited entity also provides a service that is not an accredited service—take reasonable steps to ensure when using or displaying the Digital ID Accreditation Trustmark that it is clear which service is an accredited service and which service is not an accredited service.\n (4) An entity ceases to be permitted to use or display the Digital ID Accreditation Trustmark within 7 days of the entity’s accreditation being suspended or revoked.","sortOrder":33},{"sectionNumber":"5.4","sectionType":"section","heading":"Use or display of digital ID trustmark—authorised entities","content":"#### 5.4 Use or display of digital ID trustmark—authorised entities\n\n (1) This rule prescribes the conditions in relation to the use or display of the Digital ID Accreditation Trustmark by an authorised entity.\n (2) For the purposes of this rule, the following entities are authorised entities:\n (a) the Digital ID Regulator;\n (b) the System Administrator;\n (c) the Information Commissioner;\n (d) the Secretary;\n (e) the Digital ID Data Standards Chair.\n (3) The Digital ID Accreditation Trustmark may only be used or displayed by an authorised entity for the following purposes:\n (a) the performance of functions under or in relation to the Act;\n (b) education in relation to ‘this Act’ (as defined in section 9 of the Act);\n (c) promotion of the objects of ‘this Act’ (as defined in section 9 of the Act).\n\nChapter 6—Record-keeping","sortOrder":34},{"sectionNumber":"6.1","sectionType":"section","heading":"Application of this Chapter","content":"#### 6.1 Application of this Chapter\n\n (1) For the purposes of subsection 135(3) of the Act, an entity specified in subrule (2) must keep records of the kind, for the period and in the manner prescribed by this Chapter.\n (2) Subject to subrule (3), this Chapter applies to:\n (a) an entity that holds an approval to participate in the Australian Government Digital ID System;\n (b) an entity whose approval to participate in the Australian Government Digital ID System is suspended; and\n (c) an entity whose approval to participate in the Australian Government Digital ID System has been revoked.\n (3) This Chapter does not apply to a relying party.\n (4) For the avoidance of doubt, if the accreditation of an entity is suspended or revoked, this Chapter continues to apply to the entity after its accreditation has been suspended or revoked.","sortOrder":35},{"sectionNumber":"6.2","sectionType":"section","heading":"Record keeping requirements","content":"#### 6.2 Record keeping requirements\n\n (1) An entity must keep a prescribed record for whichever of the following periods ends later:\n (a) the period of 3 years that starts on the day the record was created;\n (b) the period of 3 years that starts on the day the record was last used by the entity for the purpose of providing a service that the entity is or was accredited to provide.\n (2) An entity must not destroy or de-identify information contained in a prescribed record if:\n (a) the information is personal information; and\n (b) the information is not biometric information; and\n (c) the information was obtained by the entity in the course of providing accredited services; and\n (d) the entity is required or authorised to retain the information by or under:\n (i) the Act, these rules or the Accreditation Rules;\n (ii) a direction issued by the Digital ID Regulator under section 127 of the Act; or\n (iii) a court/tribunal order (within the meaning of the Privacy Act); and\n (e) the information relates to:\n (i) any current or anticipated legal proceedings; or\n (ii) any dispute resolution proceedings; or\n (iii) a current compliance or enforcement investigation under ‘this Act’ (as defined in section 9 of the Act);\n to which the entity is a party.\n (3) In this rule:\n\n> prescribed record, in relation to an entity, means a record that:\n\n (a) is a log required by subrule 4.20(7) of the Accreditation Rules; and\n (b) contains personal information.\n\nChapter 7—Application, saving and transitional provisions","sortOrder":36},{"sectionNumber":"7.1","sectionType":"section","heading":"Application of amendments made by the Digital ID Amendment (Redress Framework and Other Measures) Rules 2025","content":"#### 7.1 Application of amendments made by the Digital ID Amendment (Redress Framework and Other Measures) Rules 2025\n\n (1) In this rule:\n\n> amending Rules means the Digital ID Amendment (Redress Framework and Other Measures) Rules 2025.\n\n> commencement day means the day on which the amending Rules commence.\n\n (2) Subrules 4.2(7), (8) and (9), as added by the amending Rules, apply in relation to notifications received on or after the commencement day.\n (3) Rules 4A.2 and 4A.3, as inserted by the amending Rules, apply in relation to incidents that occur, or are reasonably suspected of having occurred, on or after the commencement day.\n (4) Rules 4A.7 and 4A.8, as inserted by the amending Rules, apply to entities to which Part 5 of Chapter 4A applies on and after 1 July 2026.","sortOrder":37}],"analysis":{"flash_summary_failed":{"failed":true,"reason":"A positive credit balance is required for all requests, including BYOK, so fallback providers remain available. Add credits at https://vercel.com/d?to=%2F%5Bteam%5D%2F%7E%2Fai%3Fmodal%3Dtop-up to continue.","source":"analysis-cron"},"flash_summary":{"complexity_score":7,"scope_assessment":{"changed":true,"description":"This version expands the regulatory scope beyond basic participation and technical reporting. The insertion of a dedicated redress framework (Chapter 4A) creates new duties to notify affected individuals, refer unresolved technical problems to the System Administrator, provide assistance and publish incident and complaints policies (rules 4A.2–4A.8). The rules also tighten incident reporting mechanics (detailed content and 1 business day deadlines in rule 4.2) and add explicit obligations on interoperation with other digital ID systems (rule 4.4). Transitional rule 7.1 confirms that these redress and investigation provisions are later additions. Together, these changes move the instrument from a technical/operational rule set toward a broader consumer‑protection and remediation regime, increasing compliance obligations, record‑keeping burdens and the Regulator/System Administrator’s supervisory role."},"complexity_factors":["Extensive cross‑references to the Digital ID Act 2024, the Accreditation Rules, Accreditation Data Standards and AGDIS Data Standards (see rule 1.4 and notes)","Multiple categories of entities with different obligations (accredited entities, participating relying parties, participating entities generally, ASP/ISP, authorised entities, entities with suspended/revoked approvals)","Several distinct reporting timelines and formats (1 business day for major incidents, oral then 3 business days for follow‑up, 5 business days for other incidents, 28 days for investigations and for notice of other system use, 7 days for trustmark cessation) (rules 3.4, 4.2, 4.3, 4.4, 5.3)","Nested and detailed reporting content requirements with many subitems (rule 4.2(3) contains 11 subitems including technical details and pairwise identifiers)","Special streamlined application pathway for machinery‑of‑government transfers with separate fit‑and‑proper checks (rules 1.5 and 2.3)","New redress framework (Chapter 4A) layered on top of existing incident rules, with provisions phased in by transitional rules (Chapter 7)","Record‑keeping rules that include retention periods, exceptions and interaction with other obligations (rule 6.2 with multiple conditions)","Conditional powers for the System Administrator to direct investigations and share information (rules 4.2(7)–(9), 4.5), creating procedural complexity","Trustmark design/use rules that include display, linking and post‑suspension cessation requirements (Chapter 5)","Multiple exceptions and discretionary provisions (e.g., non‑notification if likely to cause adverse outcome or materially affect System operations — rule 4A.2(3)), increasing interpretive burden"],"plain_english_summary":"**What these rules do (mechanics)\n\n- Establish the detailed operational rules for participants in the Australian Government Digital ID System (the System). They sit under the Digital ID Act and fill out how the Act is to be applied in practice (rule 1.3).\n\n- Define key terms and cross‑refer to definitions in the Act and the Accreditation Rules and Data Standards (rule 1.4).\n\n- Set fit‑and‑proper screening matters the Digital ID Regulator must consider when deciding whether to accredit or approve an entity to take part in the System (Chapter 2, notably rule 2.2). This includes criminal convictions, insolvency history, privacy determinations and previous refusals or suspensions of accreditation/approval. There is a narrower test for certain government transfers (streamlined applications) (rules 1.5 and 2.3).\n\n- Prescribe application and approval requirements for entities that want to participate in the System. Examples:\n - Entities must have procedures to notify the System Administrator about IT changes or outages that could materially affect the System (rule 3.2).\n - Relying parties must complete risk assessments and hold written cyber security, fraud management and disaster recovery/business continuity plans approved by their governing body before applying (rule 3.3).\n - Approvals come with conditions: short notification deadlines for contact‑detail changes, incident reporting duties and a requirement to store pairwise identifiers (rule 3.4).\n\n- Set mandatory incident notification and management rules (Chapter 4):\n - Participating entities (and some entities whose approval is suspended or revoked, for incidents that occurred while participating) must notify the System Administrator of cyber security incidents and digital ID fraud incidents with detailed content and tight timeframes — as soon as practicable and no later than 1 business day after awareness, with written follow‑up if the first notice was oral (rule 4.2(4)–(6)). Notifications must include technical details, affected digital IDs and, for relying parties, pairwise identifiers (rule 4.2(3)(f)–(k)).\n - Other types of material incidents (e.g. material changes to circumstances, matters bearing on fit‑and‑proper status, errors in information supplied to the Regulator) must be notified to the Digital ID Regulator, usually within 5 business days (rule 4.3).\n - Accredited entities proposing to use the same IT to connect to other digital ID systems must notify the Regulator in advance, supply risk and segregation details and describe how information flows will be separated (rule 4.4).\n - The System Administrator may share incident information with the Regulator, Minister or participating entities when appropriate to protect System security or integrity (rule 4.5).\n\n- Introduces a redress framework for incidents affecting accredited services (Chapter 4A):\n - Entities must try to notify affected individuals of incidents (rule 4A.2), unless doing so would cause harm or materially affect System operations.\n - Entities must refer unresolved technical issues that stop an individual using their digital ID to the System Administrator, and the System Administrator may recommend remedies (rules 4A.3–4A.4).\n - Entities must provide information and assistance to affected individuals and publish policies on incident identification, management, resolution and complaints handling (rules 4A.5, 4A.7–4A.8).\n\n- Specify a single official trustmark (Digital ID Accreditation Trustmark) and rules about where and how accredited or authorised entities may display it, plus an obligation to link to the Digital ID Accredited Entities Register (Chapter 5, rules 5.2–5.4).\n\n- Set record‑keeping requirements for accredited entities and other approved participants (but not relying parties): certain logs containing personal information must be kept for at least 3 years and cannot be destroyed or de‑identified in specified circumstances (Chapter 6, rule 6.2).\n\n- Include transitional provisions that bring some new requirements (notably the redress rules) into effect from specified dates and tie certain new subrules to later commencement (Chapter 7).\n\nWho is affected\n\n- Accredited entities (those that provide identity verification services within the System).\n- Participating relying parties (organisations that accept Digital IDs to deliver services).\n- Entities approved to participate whose approvals are suspended or revoked (limited duties continue for incidents that occurred while participating).\n- Certain government entities using streamlined applications (machinery‑of‑government transfers have lighter fit‑and‑proper checks but still require checking of the transferring entity’s history) (rules 1.5, 2.3).\n- Authorised public bodies (Regulator, System Administrator, Information Commissioner, Secretary, Data Standards Chair) for limited trustmark use (rule 5.4).\n\nWhy it matters (policy claims made in the instrument, and how they map to costs, incentives and trade‑offs)\n\n- Claim: Improve System security, resilience and user protection by imposing fast incident reporting, preparedness requirements, and a redress/assistance framework (see rules 3.3, 4.2, 4A.2–4A.8).\n - Trade‑offs and costs: Entities must invest in governance (governing‑body approved plans), monitoring and reporting systems to meet very short reporting timeframes (1 business day for incident notification at rule 4.2(4)). This creates ongoing compliance costs (policy teams, logging, legal and technical workflows) and may favour larger organisations with existing security teams. The requirement to retain detailed logs for at least 3 years (rule 6.2) increases storage and discovery costs, and the prohibition on destroying/de‑identifying certain personal information in specified circumstances raises records‑management burdens.\n - Incentives: Short deadlines and the threat of civil penalties (see note at rule 4.1) incentivise rapid detection and escalation; they also create incentives to invest in detection capability over other risk controls. Requiring pairwise identifiers to be stored by relying parties (rule 3.4 item 3 and 4.2(3)(k)) facilitates incident investigation but increases the amount of identifiable data retained by private parties, raising privacy and breach impact concerns.\n\n- Claim: Provide clarity and consumer support after incidents by obliging notification to affected individuals and by publishing complaint/incident policies (rules 4A.2, 4A.5, 4A.7–4A.8).\n - Trade‑offs and costs: Notifying individuals and maintaining published complaint mechanisms raises operational costs and potential liabilities. The exception allowing non‑notification where notification would likely cause an adverse outcome or materially affect System operation (rule 4A.2(3)) gives discretion that reduces some operational strain but creates judgment calls and legal risk about when non‑notification is justified.\n\n- Claim: Preserve System integrity when entities use the same technical infrastructure with other digital ID systems by requiring advance notice and segregation measures (rule 4.4).\n - Trade‑offs and costs: Operators that want to interoperate with other systems must document segregation and additional risk measures ahead of time, which may slow commercial integration projects and increase compliance costs. The rule addresses cross‑system contamination risk but imposes administrative friction on multi‑system operators.\n\n- Claim: Improve market transparency with a single trustmark and public register (Chapter 5).\n - Effects on private enterprise: Accredited entities must follow display rules and link to the public register (rules 5.3(3)(a)–(b)), which increases transparency about accreditation status. Misuse or post‑suspension display carries civil‑penalty exposure, creating a compliance discipline.\n\nWho pays, who decides, and behaviour that changes\n\n- Who pays: Participating entities (accredited entities, relying parties) bear the compliance costs — preparing and maintaining cyber, fraud and business continuity plans (rule 3.3); implementing monitoring and fast reporting systems (rule 4.2); storing pairwise identifiers and retention of logs (rules 3.4 item 3; 6.2); and publishing policies and complaint handling (rules 4A.7–4A.8).\n- Who decides: The Digital ID Regulator and the System Administrator exercise decision and supervisory powers — Regulator decides about fit‑and‑proper and approvals (Chapter 2) and receives notifications; the System Administrator receives technical incident notifications, may direct investigations (rule 4.2(7)) and share information (rule 4.5), and can recommend remedies under the redress framework (rule 4A.4).\n- Behaviour changes: Entities will need faster detection/escalation, greater record retention, clearer public communications about accreditation, and segregation of information where services connect to other digital ID systems.\n\nImplementation risks and interaction with other laws\n\n- Tight deadlines (1 business day for incident notification) create operational risk for organisations that do not have mature detection and reporting systems (rule 4.2(4)). Interim notification rules ease this a little (rule 4.2(6)), but compliance still requires resource investment.\n- Overlap with the Privacy Act and sector‑specific regulators may require coordination (rules 1.4 note, rule 2.2(c) references Privacy Act determinations). Entities will need to manage multiple reporting obligations and legal interfaces.\n- Discretionary exceptions (e.g. not notifying individuals where notification would cause adverse outcome or materially affect System operation — rule 4A.2(3)) reduce rigid outcomes but introduce legal uncertainty about acceptable practice.\n\nConcrete citations to important mechanics (examples)\n\n- Fit and proper matters: rule 2.2.\n- Risk assessments and governing‑body approved plans required before applying (relying parties): rule 3.3.\n- Incident notification content and deadlines (1 business day; interim notifications; pairwise identifier requirement): rule 4.2(3)–(6) and rule 3.4(1) item 3.\n- Notifications of other material changes to the Regulator (5 business days): rule 4.3(2) and (5).\n- Redress duties to notify affected individuals and to refer unresolved technical issues to the System Administrator: rules 4A.2–4A.4.\n- Trustmark use and display obligations, including duty to link to public register: rules 5.2–5.4 and 5.3(3)(a)–(b).\n- Record‑keeping obligations and retention periods: rule 6.2.\n- Transitional timing for redress amendments: rule 7.1.\n\nNet effect in plain terms\n\n- These Rules make participation in the Digital ID System operationally binding: institutions must show preparedness (plans, risk assessments), detect and report incidents rapidly, keep specified records, help affected individuals in many circumstances, and follow precise rules about the trustmark. That raises compliance and operational costs for participants, accelerates information flows to regulators and the System Administrator, and creates clearer expectations about incident response and consumer support. The rules allocate decision authority to the Digital ID Regulator and the System Administrator and impose tighter reporting and record‑keeping obligations on private and public entities that participate in the System."},"kimi_summary":{"content_quality":"ok","complexity_score":7,"scope_assessment":{"changed":false,"description":"The legislation appears consistent with its original intent as subsidiary rules made under the Digital ID Act 2024. The inclusion of Chapter 4A (Redress Framework) and Chapter 7 (transitional provisions) represents natural evolution of the regulatory framework rather than scope creep. The rules remain focused on operational requirements for the Digital ID system, accreditation standards, and consumer protections as contemplated by the parent Act."},"complexity_factors":["Extensive cross-referencing to the Digital ID Act 2024, Accreditation Rules, Accreditation Data Standards, and AGDIS Data Standards","Multiple nested definitions including 'associated person' with four sub-paragraphs and recursive references to other legislation (Corporations Act, Privacy Act)","Conditional application rules throughout (e.g., streamlined applications vs standard applications, suspended/revoked entities vs current participants)","Detailed notification requirements with specific timeframes (1 business day, 3 business days, 5 business days, 28 days, 48 hours) varying by incident type","Table-based condition structures in Chapter 3 with entity-specific obligations","Exception to exception logic in incident reporting (e.g., rule 4.2(6) interim notification provisions)","Overlapping but distinct obligations between accredited entities and participating relying parties requiring careful parsing","Transitional provisions with specific commencement dates and retrospective application rules"],"plain_english_summary":"This legislation sets operational rules for Australia’s Digital ID system, regulating who can join, security and incident‑reporting obligations, consumer protection and redress, and use of the accreditation trustmark and records. It governs how organisations must prevent, report and remedy cyber incidents and ID fraud.\n\nIt affects accredited identity providers, relying parties (businesses and agencies), individual users, and the Digital ID regulator/system administrator — strengthening security, accountability and clear remedies when IDs fail or are compromised."}},"importantCases":[],"_links":{"self":"/api/acts/digital-id-rules-2024","history":"/api/acts/digital-id-rules-2024/history","analysis":"/api/acts/digital-id-rules-2024/analysis","conflicts":"/api/acts/digital-id-rules-2024/conflicts","importantCases":"/api/acts/digital-id-rules-2024/important-cases","documents":"/api/acts/digital-id-rules-2024/documents"}}