1. I find that Regional Australia Bank Limited (respondent or RAB) breached Privacy Safeguard 11 and thereby engaged in a privacy safeguard breach relating to the Consumer Data Right (CDR) data of up to 197 CDR consumers within the meaning of

s 56ET of the Competition and Consumer Act 2010 (Cth) (CCA). 2. I further find that the respondent breached Privacy Safeguard 1. 3. In making my findings, I am satisfied that the respondent is responsible for Biza Pty Ltd's (Biza) conduct due to the operation of s 84(2) of the CCA.

1. I make the following declarations pursuant to s 52(1A)(a) of the Privacy Act 1988 (Cth)(Privacy Act):
   1. The respondent:
      1. breached Privacy Safeguard 11 by failing to take reasonable steps to ensure that the CDR data it held was accurate when preparing for and implementing the upgrade to its CDR environment on 29 March 2023, and thereby engaged in conduct constituting a privacy safeguard breach relating to the CDR data of up to 197 CDR consumers; and
      2. must not repeat or continue the abovementioned acts and practices.
   2. The respondent:
      1. reviews and considers opportunities to strengthen the terms of its contractual agreement with Biza, including the audit and monitoring activities it undertakes under that agreement, as they relate to the respondent's obligations under the CCA and Privacy Act; and
      2. implements documented processes to ensure that it proactively reviews and monitors its compliance with the Privacy Safeguards and the Australian Privacy Principles (APPs) in circumstances where it continues to outsource CDR functions to a third party.
2. I do not consider that any further declarations are necessary in circumstances where:
   1. the Incident was resolved when Biza implemented the Soyuz update on 29 June 2023;
   2. the respondent notified 181 affected CDR consumers of the Incident in accordance with its obligations under r 7.10 of the Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules); and
   3. there is presently no evidence that any of the affected CDR consumers experienced loss or damage by reason of the Incident.

1. This determination arises out of an investigation into the respondent's liability for an incident in which the CDR data of up to 197 CDR consumers was co-mingled, resulting in the disclosure by RAB of inaccurate CDR data pertaining to those consumers. Whereas the investigation establishes the role of Biza in causing the relevant incident, it was not targeted at Biza and the resulting determination does not make legal findings or declarations with respect to Biza. Neither RAB nor Biza contested any of the factual findings in this determination.
2. A number of factors were relevant to my decision not to conduct an investigation into Biza directly or to make an adverse determination against Biza. These included that Biza was not, at the time of the investigation, an Accredited Data Recipient under the CDR framework, and thus not subject to the relevant CDR rules. I saw regulatory and educative value in focusing analysis on the responsibilities of entities accredited and operating within the CDR system.
3. Inaccurate CDR data may cause significant risk for customers. Decisions based on inaccurate data could result in individuals being wrongly refused credit, which may affect their immediate access to funds, but also their longer-term credit history. It may also result in individuals being given credit that they do not have an ability to service, which could lead to default or financial hardship. For these and other reasons, the CDR framework imposes high standards on data holders to ensure the accuracy of the information they disclose, either personally or through a third-party service provider.
   1. This incident came to the OAIC's attention via a notification made by a CDR consumer of a CDR representative to the Australian Competition and Consumer Commission (ACCC). Shortly after this notification, Biza addressed the technical cause of the incident. Notwithstanding the issue having been ostensibly remedied, the OAIC considered it important that an investigation of the incident occur to identify its cause, to ensure it was not repeated, and to support trust in the CDR system's privacy safeguards.
   2. The resulting determination makes findings that a respondent is responsible for its service provider's conduct by virtue of the operation of s 84(2) of the CCA, in circumstances where the respondent outsourced the majority of its CDR compliance obligations to the service provider. I expect those findings may cause some discomfort for regulated entities, as they have for the respondent, in circumstances in which the respondent had sought via contractual provisions to shift liability for non-compliance with the CDR framework to its contracted service provider. I hope that this determination will clarify the position for outsourcing and outsourced entities and inform decisions about the governance arrangements pertaining to outsourcing going forward.
   3. A secondary issue of focus for this determination is issues relevant to entities migrating data in circumstances where there was a failure to identify and adequately remediate a software issue.

1. The respondent, Regional Australia Bank (RAB), is a data holder under the CDR framework. Under the framework it has an obligation to share customer banking data with accredited data recipients when authorised by a customer. This requirement supports enhanced competition and consumer choice in the banking sector.
2. The respondent's service provider Biza Pty Ltd's[1] (Biza), is a CDR solution provider contracted by RAB to enable RAB to meet its data holder obligations under the CDR framework. RAB became Biza's first customer in July 2020.[2]

1. From 2021 to early 2022, in order to improve compliance with CDR performance requirements, the respondent commenced work to migrate to a new technical platform. The respondent's data was in a pre-production environment prior to 29 March 2023.
2. In early February 2023, Biza identified a software fault in the technical platform (the Initial Fault). On 10 February 2023 a remedial patch was deployed by Biza in response to the Initial Fault for Biza's other customers who had implemented Biza's new service deployment. However, because implementation of the respondent's platform was in pre-production and in its final stages of testing, Biza failed to identify that the respondent's pre-production environment included the adaptor containing the software issue which required patching.[3]
3. On 29 June 2023 the ACCC received a notification via the CDR Service Management Portal (Portal)[4] about an issue with the respondent's CDR consumer data transfer.[5] A CDR consumer of a CDR representative[6] had received transaction data that was not their own and contained the personal information of another CDR consumer of the respondent (Incident).
4. Upon being notified of the Incident, Biza found that it was caused by the same software issue that it had identified and resolved in relation to the Initial Fault in February 2023.[7]
5. Coincidentally, the software issue was resolved on the same day that the Incident was raised because Biza implemented a broader upgrade to the software platform (Soyuz update) for the respondent's CDR environment which included the remedial patch.
6. Based on evidence provided by the respondent and Biza, including release notes for the Soyuz update and communications between the respondent and Biza, it appears that neither party was aware that the respondent's environment also required patching, and that it was likely that the Incident would have gone unnoticed (albeit resolved by the Soyuz update) had it not been raised via the Portal.
7. The Incident was brought to the OAIC's attention by the ACCC on 29 June 2023[8] and, following preliminary inquiries, the Australian Information Commissioner (Commissioner) commenced an investigation under s 40(2) of the Privacy Act on 25 September 2023.

1. For the purposes of this determination, the following legislative frameworks apply:
   • CDR framework,
   • CCA, specifically s 84(2),
   • Privacy Safeguards, specifically 11 and 1,
   • Privacy Act.
2. The relevant factual circumstances require me to consider the operation of these legislative frameworks, and in particular determine the answers to the following questions:
   1. Was Biza an agent of the respondent pursuant to s84(2) of the CCA?
   2. If so, did Biza take reasonable steps to ensure CDR data was, having regard to the purpose for which it was held, accurate, up to date and complete pursuant to Privacy Safeguard 11?
   3. If so, did Biza take such steps as were reasonable in the circumstances to implement practices, procedures and systems that would ensure that the CDR entity complied with Part IVD of the CCA and the CDR Rules, pursuant to Privacy Safeguard 1?
3. I have considered the answers to these questions against the broader backdrop of the CDR framework, so will begin my analysis with a brief explanation of that framework.

1. The CDR framework enables individual and business consumers to opt-in to share their data with trusted third parties for the purposes the consumer has authorised. Through the CDR, consumers can choose between different products and services, and choose who has access to their data, what data can be accessed and the period for which it can be accessed. The CDR has been designed and is overseen by the Australian Government so that consumers can benefit from more competition, innovation, products and services in the marketplace. The CDR system is designed to keep data secure and protect consumers' privacy.
2. A sector must be designated by the Minister to be part of the CDR.[9] The banking sector was designated in 2019.[10] The designation instrument sets out the types of businesses that are required to share data in a CDR-compliant format at a CDR consumer's request (data holders)[11] and the classes of information that are subject to the CDR (CDR data).[12]
3. Relevantly, in the banking sector, most authorised deposit-taking institutions (ADIs) within the meaning of s 5(1) of the Banking Act 1959 (Cth) are designated data holders.
4. Entities receiving CDR data (accredited data recipient or ADR)[13] must meet strict requirements in order to be accredited by the ACCC[14] and are subject to extensive obligations under Part IVD of the CCA and the CDR Rules.
5. Broadly, the CDR framework comprises:
   1. Part IVD of the CCA, which sets out the CDR framework and includes 13 privacy safeguards which set out standards, rights and obligations in relation to CDR data for which there are one or more CDR consumers,
   2. The CDR Rules,[15] which facilitate the implementation of the CDR across the economy including by setting out requirements for accreditation and expanding on the privacy safeguards,
   3. The consumer data standards[16] made by the Data Standards Body[17], which include standards about the format and process for transferring data,
   4. The relevant delegation instrument for the sector, and
   5. The CDR Guidelines made under ss 56EQ(1)(a) of the CCA, which outline how the Commissioner will interpret and apply the privacy safeguards.[18]
6. The privacy safeguards apply only in the CDR context to CDR participants. Entities that are CDR participants and also APP entities within the definition of ss 6 and 6C of the Privacy Act must continue to comply with the APPs in respect of personal information that is not CDR data. However, the privacy safeguards do not always replace the APPs in relation to CDR data and it will depend on the CDR participant's role in relation to the CDR data that will determine which set of protections apply.
7. Relevantly, data holders are required to comply with privacy safeguards 1, 10, 11 and 13, and all APPs except for APPs 10 and 13, once they are authorised or required to disclose CDR data.[19]
8. The CDR framework is co-regulated by the Office of the Australian Information Commissioner (OAIC) and the ACCC. The OAIC regulates compliance with the privacy safeguards and privacy-related CDR Rules and receives complaints from CDR consumers about the handling of CDR data by CDR participants.
9. Section 56ET of the CCA extends the application of Part V of the Privacy Act - and any other provision that relates to that Part - to an act or practice of a CDR participant that may be a breach of a privacy safeguard.

Was Biza an agent of the respondent pursuant to s84(2) CCA?

1. Section 84(2) of the CCA provides:

(2) Any conduct engaged in on behalf of a body corporate:

(a) by a director, employee or agent of the body corporate within the scope of the person's actual or apparent authority; or

(b) by any other person at the direction or with the consent or agreement (whether express or implied) of a director, employee or agent of the body corporate, where the giving of the direction, consent or agreement is within the scope of the actual or apparent authority of the director, employee or agent;

shall be deemed, for the purposes of this Act, a gas market instrument and the consumer data rules, to have been engaged in also by the body corporate. [emphasis added]

1. For the sake of completeness, the application of this section and subsequent finding of action attributable to the respondent is only for the purposes of the CCA and the CDR rules.

1. For Biza's actions to be attributable to the respondent, as a body corporate, under s 84(2) of the CCA:
   1. Biza's conduct must have been 'engaged in on behalf of' the respondent; and
   2. Biza must have been an 'agent' of the respondent or Biza must have been engaged in conduct at the direction or with the consent or agreement (whether express or implied) of a director, employee or agent of the respondent, where the giving of the direction, consent or agreement is within the scope of the actual or apparent authority of the director, employee or agent; and
   3. Biza's actions must have occurred within the scope of the 'actual or apparent authority' conferred by the respondent.
2. The respondent and Biza executed an Ongoing Services Agreement[20] and Statement of Work[21] on 29 June 2020 under which Biza was required to deliver, manage and maintain a cloud-based CDR software deployment within the respondent's information technology infrastructure to facilitate the respondent's compliance with the CDR requirements.
3. On or about 19 October 2021, those documents were replaced by a Master Services Agreement between the respondent and Biza in which Biza would manage and maintain the software deployment within its own Amazon Hosted Environment.[22] A new agreement was entered into, including the relevant amendment to the Master Services Agreement was entered into approximately a year later (together, the MSA).[23] The amendment expanded the services provided by Biza to include the provision of the software adaptor to facilitate connectivity with the respondent's core banking software.

1. I am of the view that the nature of and obligations contained in the agreements between Biza and the respondent render Biza's conduct in relation to the Incident as conduct engaged in on behalf of the respondent, in accordance with the requirements of s 84(2) of the CCA.
2. In implementing the software adaptor, Biza was acting in accordance with the requirements of the MSA to facilitate the respondent's compliance with its obligations under Part IVD of the CCA and the CDR Rules. Accordingly, the conduct occurred in the context of the respondent's business activities[24] and can be considered to have been 'engaged in on behalf of the respondent'.
3. I am also of the view that Biza was acting as an agent of the respondent when taking steps to comply with Part IVD of the CCA and the CDR Rules in respect of the respondent's CDR environment and engaging in the conduct resulting in the Incident. The provision of the software adaptor formed a part of the services that Biza was required to provide under the MSA. The MSA required Biza to perform the 'CDR Obligations', defined as the respondent's obligations under the CDR requirements which were to be performed or satisfied by services provided by Biza.[25]
4. Of note, clause 16.5 of the MSA states that 'unless expressly stated otherwise' the MSA does not create a relationship of agency between the parties. I have considered the entirety of the MSA and the broader contractual relationship between the parties. In addition, I have considered case law on the interpretation of the term 'agent' in s 84(2) of the CCA which indicates that the specific terms of an agreement are not determinative of a relationship and do not preclude a finding of agency.[26] Notwithstanding clause 16.5 of the MSA, I am satisfied that the nature of the relationship between Biza and the respondent was such that, in respect of compliance with Part IVD of the CCA and the CDR Rules, Biza was an agent of the respondent.
5. Finally, I am satisfied that Biza's actions occurred within the scope of the 'actual or apparent authority' conferred on it by the respondent. Biza's actions took place in the context of performing its contractual obligations to provide the software adaptor as part of its service offerings. The fact that obligations under the Part IVD of the CCA or the CDR Rules may not have been met as a result of the software issue does not preclude the conduct from being within the scope of the actual or apparent authority conferred by the respondent.[27]
6. For the above reasons, I am of the view that the elements of s 84(2) of the CCA are satisfied such that Biza's conduct is attributable to the respondent for the purposes of the CCA and the CDR Rules.
7. Therefore, the respondent is liable for any failings by Biza even if it had no knowledge or awareness of those matters and was not in a position to take steps to prevent or address them.

Did Biza take reasonable steps to ensure CDR data was, having regard to the purpose for which it was held, accurate, up to date and complete pursuant to Privacy Safeguard 11?

1. Privacy Safeguard 11 is set out in section 56EN of the CCA. Section 56EN(1) of the CCA states that if a data holder of CDR data is required or authorised under the CDR Rules to disclose the CDR data, the data holder must take reasonable steps to ensure CDR data is, having regard to the purpose for which it is held, accurate, up to date and complete.
2. Section 56EC(4)(b) of the CCA states that if s 56EN applies to a disclosure of CDR data by a data holder of the CDR data, then APP 10 does not apply to the data holder in relation to the disclosure of the CDR data.
3. The CDR Guidelines outline the requirements of the reasonable steps test to ensure the quality of CDR data.[28] Relevantly, the CDR Guidelines state that CDR data is inaccurate if it contains an error or defect or is misleading and provides an example of factual inaccuracy where a consumer's contact details, account, income, assets, payment, or repayment history is incorrect.[29]
4. The CDR Guidelines provide examples of reasonable steps entities should consider, including ensuring internal practices, procedures and systems are commensurate with other reasonable steps the entity is taking to ensure the quality of CDR data the entity is authorised or required to disclose.[30]

1. The respondent held customer information and transaction data for the purpose of providing banking services to its customers. In circumstances where the respondent was an ADI and therefore a data holder for the purposes of the CDR, that customer information and transaction data became CDR data once disclosed in accordance with a valid request. The respondent was required to disclose CDR data under rule 4.6 of the CDR Rules when CDR consumers authorised the disclosure of CDR data to respective third parties.[31] In doing so, it relied on Biza's services.
2. Biza was aware that the respondent was the first non-major bank to 'Go Live with the Consumer Data Right' and that its 'consumer base are more inclined to utilise the services provided by Data Recipients.'[32] Given their respective roles in the CDR regime, the respondent and Biza ought to have been aware of the importance of maintaining accurate CDR data and the potentially significant consequences that could arise from the co-mingling of CDR data. Notably, the co-mingling of CDR data presented a real risk that the CDR data disclosed in response to a request from an ADR would be inaccurate, which could in turn jeopardise consumers' applications for credit or financial products and undermine trust in the CDR more broadly.
3. In my view, it was reasonable for Biza, as the respondent's agent, to have implemented practices, procedures and systems to verify, audit and monitor the quality of CDR data, particularly in the context of its services maintaining its clients' CDR environments and addressing system issues which could compromise data quality.[33] Upon being alerted to and resolving the Initial Fault in February 2023, Biza ought to have taken steps to ensure that the software issue impacting the accuracy of CDR data was not introduced in the CDR environments of its other clients. It could have reasonably done so by ensuring that the patched software was implemented in all upgrades, including those in pre-production, thereby mitigating the risk of co-mingling further CDR data. Checks ought to have been undertaken prior and subsequent to future software upgrades.
4. Such steps were reasonable in circumstances where:
   1. Biza had a relatively small client base, noting that the respondent was Biza's oldest client[34]
   2. they were not impracticable or cost prohibitive
   3. the consequences of not taking such steps had the potential to cause significant harm for affected CDR consumers.
5. Despite becoming aware of the software issue in February 2023 and remedying that fault for three other clients by implementing the remedial patch, Biza failed to implement the patched software when it upgraded the respondent's CDR environment on 29 March 2023.
6. Biza had an obligation under the MSA to 'ensure that all fixes, patches, new versions, releases or updates in respect of Services provided to the [respondent] have been appropriately tested (including web application testing) and code reviewed...'[35] Despite this contractual obligation, no testing or code review that was undertaken identified that the version of the software deployed in the respondent's CDR environment was unpatched.[36] As noted in its internal investigation report, Biza's tracing processes in relation to 'critical incidents' were deficient as they applied beyond the 'production' environment.[37] Additionally, there was 'not a final Go Live check' before the respondent's platform went into production on 29 March 2023 and the issue was not identified.[38]
7. The unpatched software operated in the respondent's CDR environment between 29 March 2023 and 29 June 2023. During this period, neither the respondent nor Biza identified that the unpatched software was co-mingling CDR data when the respondent was required to respond to CDR data requests from an ADR, or on behalf of an ADR's CDR representatives. As a result, the CDR data that the respondent disclosed about affected CDR consumers was not accurate, having regard to the purpose for which it is held by the respondent, being to provide a banking service to its customers.
8. It is evident that reasonable steps were not taken as required by Privacy Safeguard 11. As a result, the CDR data of up to 197 CDR consumers was inaccurate at the time it was disclosed under rule 4.6 of the CDR Rules between 29 March 2023 and the Soyuz update on 29 June 2023.
9. I have considered whether the respondent took reasonable steps to satisfy itself and ensure the accuracy of its CDR data, as required by Privacy Safeguard 11. In my view, the respondent took reasonable steps in circumstances where it:
   1. entered into a contractual arrangement with Biza, evidenced by the MSA, which outlined the roles and responsibilities of each party,
   2. regularly met with Biza to discuss the status of projects and provide feedback,[39]
   3. was required to approve any updates that Biza intended to make to the respondent's CDR environment, including those which could impact the accuracy of the CDR data it held,[40]
   4. had its Integration and Architecture Department assess, classify and/or investigate any errors identified by Biza through its testing process before any updates were approved and deployed.[41]
10. Given the respondent was not notified of the co-mingling data issue which occurred during the Initial Fault, I am not satisfied that there were other reasonable steps that the respondent could have taken to prevent such an issue impacting the accuracy of the CDR data it held. Nevertheless, the respondent is liable for Biza's conduct in circumstances where it entered into a contractual arrangement with the third party to undertake relevant functions.

1. On balance I find that the respondent, by virtue of Biza's conduct, failed to take reasonable steps to ensure that the CDR data it held was accurate, having regard to the purpose for which it was held, in breach of Privacy Safeguard 11.

Did Biza take such steps as were reasonable in the circumstances to implement practices, procedures and systems that would ensure that the CDR entity complied with Part IVD of the CCA and the CDR Rules, pursuant to Privacy Safeguard 1?

1. Section 56ED of the CCA creates Privacy Safeguard 1 which involves the open and transparent management of CDR data.
2. Among other things, Privacy Safeguard 1 requires a CDR entity (which includes a data holder such as the respondent) to take such steps as are reasonable in the circumstances to implement practices, procedures and systems that will ensure that the CDR entity complies with Part IVD of the CCA and the CDR Rules.[42]
3. Privacy Safeguard 1 applies to a data holder in parallel with APP 1.[43]
4. The CDR Guidelines state that in order to comply with Privacy Safeguard 1, CDR entities need to proactively consider, plan and address how to implement any practices, procedures and systems that ensure compliance with the CDR system, including the privacy safeguards and the CDR Rules.[44] Consequently, compliance with Privacy Safeguard 1 should be understood as a matter of good governance.
5. Determining the steps that will be reasonable in the relevant circumstances requires an assessment of factors which may include:
   1. the CDR Rules and other legislative obligations that apply to the CDR entity
   2. the nature of the CDR entity
   3. whether the CDR entity is handling, or will soon handle, CDR data
   4. the amount of CDR data handled by the CDR entity
   5. the possible adverse consequences for a consumer in the case of a breach
   6. the practicability of a particular step, including the time and cost involved.[45]

1. As noted above, the respondent is an ADI that is a data holder within the meaning of

s 56AJ of the CCA and therefore has obligations under the CDR Rules, CCA and the Privacy Act. The respondent provides banking services and has been handling CDR data since it completed the integration and deployment of Biza's CDR solution in 2020, which enabled the respondent to share CDR data with ADRs.[46] 2. Relevantly, the co-mingling of CDR data had the potential to adversely impact affected CDR consumers. In particular, there was a real risk that the respondent would provide inaccurate information about an affected CDR consumer in response to a CDR data request, which would in turn inform decisions made about or information provided to that consumer, for example whether a customer was approved for credit or a financial product. This risk was recognised in Biza's information classification policy, indicating that it was aware of the serious impact of the unauthorised disclosure of CDR data on CDR consumers[47] and had already been realised and addressed by Biza as a result of the Initial Fault,[48] albeit not disclosed to the respondent. 3. The steps taken in relation to the respondent's compliance with Part IVD of the CCA and the CDR Rules included: 1. implementing the MSA, which outlined the roles and responsibilities of each party and required Biza to 'implement and maintain appropriate administrative, physical and technical security safeguards...to protect the confidentiality, integrity and availability of Client Data' in delivering CDR services to the respondent.[49] 2. regularly meeting with Biza to discuss the status of projects and provide feedback,[50] 3. approving any updates that Biza intended to make to the respondent's CDR environment,[51] 4. assessing, classifying and/or investigating any errors identified by Biza through its testing process before any updates were approved and deployed.[52] 4. Further, in responding to the specific compliance issues identified as a result of the Initial Fault, Biza: 1. developed the remedial patch which was promptly deployed to the environments of its clients that were in production, 2. conducted an internal 'postmortem' review which identified the root cause of the issue and its impact, and canvassed a number of recommended actions in order to prevent and/or respond to future incidents which included: 1. implementing a dedicated channel for incident communications for any similar future incident management, 2. introducing an interim category to identify inadvertent data leakage incidents, 3. seeking to update information on reporting obligations for incidents and related timeframes, 4. defining roles and responsibilities for incident management.[53] 5. I am of the view that the steps outlined at paragraphs [67] and [68] were reasonable in the circumstances and went some way to ensuring that the respondent complied with Part IVD of the CCA and the CDR Rules. 6. However, in circumstances where the respondent outsourced the relevant services to Biza and Biza was aware of the software issue which had caused the Initial Fault, I am of the view that it was also reasonable for Biza to have also implemented practices, procedures and systems to: 1. document known issues or incidents impacting the quality of CDR data, in addition to any critical fixes that needed to be deployed to all customers to ensure the accuracy of CDR data, 2. communicate such issues or incidents, together with any critical fixes, to relevant areas of its business to ensure that they were specifically considered in the context of other projects or activities, particularly as they may have related to other clients or systems that were not in 'production' but may still be affected by the issues, 3. to the extent that it was appropriate for the purposes of testing and obtaining approval in respect of system upgrades, communicate such issues or incidents to its clients 4. ensure that it was aware of and complied with its contractual obligations to notify its clients about incidents affecting the broader Biza environment.[54] 7. In my view the abovementioned steps were neither time nor cost prohibitive. 8. On the evidence currently available to me, I am of the view that Biza failed to effectively implement such reasonable steps to ensure compliance with Part IVD of the CCA and the CDR Rules. In particular, Biza failed to: 1. document details of the remedial patch in the Soyuz update or earlier release notes, 2. identify that the respondent's pre-production environment included the adaptor containing the software issue which required patching, or that the software issue was subsequently introduced to the respondent's production environment on 29 March 2023 3. inform the respondent of the software issue until inquiries were made following the Incident.[55] 9. Biza's internal incident report acknowledged that the Incident 'highlighted a process failure in Pre-production to Production release procedures' and identified a number of learnings. In particular, and as noted above, Biza's tracing processes in relation to 'critical incidents' were found to be deficient as they applied beyond the 'production' environment.[56]

1. I find that the respondent, by virtue of Biza's conduct, failed to take such steps as were reasonable in the circumstances to implement practices, procedures or systems that would ensure compliance with Part IVD of the CCA and the CDR Rules, in breach of Privacy Safeguard 1.

Privacy Act

1. Part V of the Privacy Act sets out the Commissioner's investigative powers and includes the power for the Commissioner to commence an investigation on her own initiative,[57] compel information and documents in relation to an investigation[58] and make a determination at the conclusion of an investigation.[59]
2. On 10 October 2023, a delegate of the Commissioner commenced an investigation into the respondent's acts and practices under s 40(2) of the Privacy Act.
3. On 17 December 2024, a preliminary view was sent to the respondent and Biza for comment.
4. On 17 January 2025, Biza responded to the preliminary view. Biza did not make any submissions in relation to the substantive elements of the preliminary view, rather they advised remedial acts undertaken since the Incident.
5. On 7 February 2025 the respondent responded to the preliminary view. Broadly, the respondent did not agree that Biza was an agent for the purposes of s 84(2) of the CCA and, therefore, did not accept that liability for Biza's acts and omissions necessarily flowed to it. Specifically, the respondent did not agree there was a relationship of implied agency between it and Biza.
6. In making this determination, I have considered the following:
   • information and submissions provided by the parties
   • OAIC Guide to Privacy Regulatory Action,[60]
   • Consumer Data Right Privacy Safeguard Guidelines (CDR Guidelines)[61], and
   • Compliance and Enforcement Policy for the Consumer Data Right.[62]
7. For the purposes of s 43(4) of the Privacy Act, I am satisfied that:
   1. the acts and practices to which the investigation relates can be adequately determined in the absence of a hearing with the respondent; and
   2. there are no unusual circumstances that would warrant holding a hearing before making this determination.

Section 96 of the Privacy Act 1988 (Cth) states that a party may apply to have a decision under s 52(1) or (1A) to make a determination reviewed by the Administrative Review Tribunal (ART). The ART provides independent merits review of administrative decisions and has power to set aside, vary, or affirm a privacy determination. An application to the ART must be made within 28 days after the day on which the person is given the privacy determination (s 18(1) of the Administrative Review Tribunal Act 2024 (Cth); r 5(3) Administrative Review Tribunal Rules 2024 (Cth)). An application fee may be payable when lodging an application for review to the ART. Further information is available on the ART's website (www.art.gov.au) or by telephoning 1300 366 700.

A party may also apply under s 5 of the Administrative Decisions (Judicial Review) Act 1977 (Cth) to have the determination reviewed by the Federal Circuit and Family Court of Australia or the Federal Court of Australia. The Court may refer the matter back to the OAIC for further consideration if it finds the Information Commissioner's decision was wrong in law or the Information Commissioner's powers were not exercised properly. An application to the Court must be lodged within 28 days of the date of the determination. An application fee may be payable when lodging an application to the Court. Further information is available at https://www.fcfcoa.gov.au/gfl and www.federalcourt.gov.au/.

1. At paragraph 1, delete 's 56T' and replace with 's 56ET'.
2. At paragraph 4, amend 'APPs' to 'Australian Privacy Principles (APPs)'.
3. At paragraph 5 delete 'CDR Rule 7.10' and insert 'r 7.10 of the Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules)'.
4. At paragraph 9, amend 'Australian Competition and Consumer Commissioner' to 'Australian Competition and Consumer Commission'.
5. At paragraph 12, remove capitalisation in 'It'.
6. At paragraph 20, amend 'Commissioner' to 'Australian Information Commissioner (Commissioner)'.
7. At paragraph 27, amend 'Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules)' to 'CDR Rules'.
8. At paragraph '46', delete 's 56EN(1)' and replace with 's 56EN'.
9. At paragraph '75', amend 'Australian Information Commissioner's (Commissioner)' to 'Commissioner's'.

[2] https://www.regionalaustraliabank.com.au/the-inside-story/articles/regional-australia-bank-becomes-cdr-compliant.

[3] D2023/028073 - Biza signed response to OAIC's s 44(1) notice, page 4.

[4] The CDR Service Management Portal is provided by the ACCC for CDR participants to communicate technical incidents between each other, or with the ACCC CDR Technical Operations team.

[5] D2023/015314 - Ticket number CDR-4003.

[6] As defined at rule 1.10AA of the CDR Rules.

[7] D2023/028073 - Biza response to OAIC s 44(1) notice, page 2.

[8] D2023/015459 - Letter from third party to the ACCC dated 12 April 2023 responding to request about incorrect CDR transaction data.

[10] The banking sector was designated by the Consumer Data Right (Authorised Deposit-Taking Institutions) Designation 2019.

[11] The term 'data holder' is defined in s 56AJ of the CCA.

[12] The term 'CDR data' is defined in s 56AI of the CCA.

[13] The term 'accredited data recipient' is defined in s 56AK of the CCA.

[14] See Division 3, Part IVD of the CCA. Under s 56AC the Data Recipient Accreditor may accredit a person if satisfied that the person meets the criteria for accreditation specified in the CDR Rules. The 'Data Recipient Accreditor' may be appointed by the Minister under s 56CG(1), but if no such appointment is made, s 4 of the CCA defines the ACCC is the Data Recipient Accreditor.

[15] https://www.legislation.gov.au/F2020L00094/2022-02-01/text.

[16] https://consumerdatastandardsaustralia.github.io/standards/#introduction

[17] Home | Data Standards Body

[18] Version 4.0 is applicable for this matter - https://www.oaic.gov.au/consumer-data-right/consumer-data-right-guidance-for-business/consumer-data-right-privacy-safeguard-guidelines.

[19] CCA s 56EC(4). See also the OAIC's Guide to Privacy for Data Holders available at https://www.oaic.gov.au/consumer-data-right/consumer-data-right-guidance-for-business/privacy-obligations/guide-to-privacy-for-data-holders#section-what-privacy-obligations-in-the-cdr-system-apply-to-data-holders.

[20] D2023/028622 - Respondent's Ongoing Service Agreement with Biza executed on 29 June 2020.

[21] D2023/028623 - Statement of Work dated 29 June 2020 issued pursuant to the Ongoing Services Agreement between the respondent and Biza.

[22] D2023/028624 - Master Services Agreement between the respondent and Biza executed on 19 October 2021.

[23] D2023/028626 - Amendment Agreement between the respondent and Biza executed on 18 October 2022.

[24] See consideration of the phrase 'on behalf of' in s 84(2) in ACCC v Phoenix Institute of Australia Pty Ltd [2021] FCA 956.

[25] D2023/028624 - Master Services Agreement between the respondent and Biza executed on 19 October 2021, Appendix A, clauses 1.3 and 18.1.

[26] See South Sydney District Rugby League Football Club Ltd v News Ltd [2000] FCA1541 and Australian Competition and Consumer Commission v Cornerstone Investment Aust Pty Ltd (In Liq) (No 4) [2018] FCA 1408.

[27] Ex parte Colonial Petroleum Oil Pty Ltd [1944] NSWStRp 16; (1944) 44 SR (NSW) 306, cited with approval in Phoenix at paragraph 90.

[31] CDR Rule 4.6 requires data holders to disclose CDR data in response to a consumer data request.

[32] D2023/028079 - Biza's internal investigation report dated 29 June 2023, page 4.

[34] D2023/028617 - Erroneous Data Sharing Incident Summary, Impact, page 2.

[35] D2023/028624 - Master Services Agreement between the Respondent and Biza, Appendix A, clause 4(h)(i).

[36] D2023/028617 - Erroneous Data Sharing Incident Summary, Root Cause and Lessons Learned, page 3-4.

[37] Noting the comment that the Incident 'highlighted a process improvement within Biza regarding track and tracking of critical incidents to builds to environments beyond those declared Production.' See D2023/028079 - Biza's internal investigation report dated 29 June 2023, page 5.

[38] D2023/028079 - Biza's internal investigation report dated 29 June 2023, page 4.

[39] D2023/028641 - Supplier Scorecard - Biza, pages 1-3.

[40] D2024/014501 - Respondent's letter to the OAIC dated 15 May 2024, p 4.

[41] D2024/014501 - Respondent's letter to the OAIC dated 15 May 2024, p 4.

[43] Subsection 53EC(5), Note 1 of the CCA.

[46] https://www.regionalaustraliabank.com.au/the-inside-story/articles/regional-australia-bank-becomes-cdr-compliant.

[47] D2023/028086 - Biza's Information Classification Policy, approved 6 February 2023, pages 4- 5.

[48] D2023/028078 - Biza 'Erroneous Data Sharing' report dated 9 February 2023; D2023/028091 and D2023/028092 - Change documentation for affected clients 1 and 2 in response to the Initial Incident dated 10 February 2023.

[49] D2023/028624 - Master Services Agreement between the respondent and Biza executed on 19 October 2021, Appendix A, clause 4(a)(i).

[50] D2023/028641 - Supplier Scorecard - Biza, pages 1-3.

[51] D2024/014501 - Respondent's letter to the OAIC dated 15 May 2024, p 4.

[52] D2024/014501 - Respondent's letter to the OAIC dated 15 May 2024, p 4.

[53] D2023/028078 - Biza 'Erroneous Data Sharing' report dated 9 February 2023.

[54] Noting that Biza was required under the MSA to notify the respondent of information security incidents occurring in Biza's environment within twenty four hours of becoming aware of the incident. See D2023/028624 - Master Services Agreement between the respondent and Biza executed on 19 October 2021, Appendix A, clause 4(k)(i).

[55] D2024/014501 - Respondent's letter to the OAIC dated 15 May 2024, page 4.

[56] Noting the comment that the Incident 'highlighted a process improvement within Biza regarding track and tracking of critical incidents to builds to environments beyond those declared Production.' See D2023/028079 - Biza's internal investigation report dated 29 June 2023, page 5.

[57] Privacy Act s 40(2).

[58] Privacy Act s 44(1).

[59] Privacy Act s 52(1A).

[60] December 2024 version - Guide to privacy regulatory action - OAIC.

[61] Version 4.0 - https://www.oaic.gov.au/consumer-data-right/consumer-data-right-guidance-for-business/consumer-data-right-privacy-safeguard-guidelines.

[62] https://www.cdr.gov.au/resources/guides/compliance-and-enforcement-policy.