1. I find that Vinomofo Pty Ltd (respondent) interfered with the privacy of individuals, whose personal information it held in the database (as described at paragraphs [8] to [14]) within the meaning of s 13(1) of the Privacy Act 1988 (Cth) (Privacy Act) by:
   1. failing to take such steps as were reasonable in the circumstances to protect that personal information from misuse, interference and loss and from unauthorised access, modification or disclosure, in breach of Australian Privacy Principle (APP) 11.1.

1. I declare, under s 52(1A)(a) of the Privacy Act, that the acts and practices of the respondent as outlined at paragraph [1], constitute an interference with the privacy of individuals and that the respondent must not repeat or continue the acts and practices.
2. I further declare under s 52(1A)(b) of the Privacy Act that the respondent must:

1. within 90 days of the date of this determination: 1. implement security logging in all of the respondent's Amazon Web Service's (AWS) environments that store personal information; 2. apply appropriate security access settings to any database that holds the personal information collected by the respondent; 3. implement systems or controls to monitor its systems for signs of unauthorised activity 4. implement written policies and procedures that meet the minimum-security baseline requirements as set out in the Industry Standards; 5. engage an independent reviewer to review the adequacy of staff with cyber security expertise and address any shortcomings identified; and 6. promote a privacy and security aware culture by implementing an appropriate training schedule for staff. 2. within 6 months of the date of this determination, engage a suitably qualified independent reviewer, such as a privacy or cyber security expert to: 1. review the effectiveness of the respondent's implementation of the actions outlined at paragraph [3.a.i.-vi]; and 2. prepare a report that specifies the independent reviewer's findings and recommendations (review report).

1. within 14 days of the date of the review report, provide a copy of the report to the Office of the Australian Information Commissioner (OAIC);

1. within 90 days of the date of the review report, action any recommendations contained in the report; and 2. report to the OAIC on the steps it has taken to action the recommendations contained in the review report within 14 days of taking that action.

1. In this matter, the respondent, an online wine wholesaler, experienced a data breach that resulted in unauthorised access to its customers' personal information.
2. The OAIC's investigation, and my resulting determination, concerns the respondent's compliance with APP 11.1, which requires an entity that is subject to the Privacy Act to take reasonable steps to protect the personal information that it holds from misuse, interference and loss, and from unauthorised access, modification or disclosure.
3. This determination provides a clear application of APP 11.1 in the context of data migration projects, and in particular speaks to entities' obligations when using cloud infrastructure providers to house personal information. It explores the technical and organisational steps entities should consider to meet their obligations under APP 11.1.

1. The respondent is an online wine wholesaler. It is an Australian proprietary company that was registered in June 2013 and its business model involves direct engagement with wine producers to offer online deals to its customer base.[1] The respondent holds personal information on its customers including customers' names, genders, dates of birth, addresses, email addresses and phone numbers.

1. On 27 December 2018, the respondent commenced a platform transformation project (Platform Transformation Project) to upgrade its system for managing customer data, including customers' personal information (data management system).[2]
2. To implement the Platform Transformation Project, the respondent took a staged approach to migrating the data (Data Migration Project) from its legacy environment to the new production platform system (New Production Platform System).
3. To facilitate the Data Migration Project, the respondent transferred personal information to a temporary database, a PostgreSQL database (the database) provided by AWS Relational Database Service.[3]
4. The respondent initially characterised the database as a testing platform, on which personal information was held for data migration testing purposes.[4] It later clarified that the database was a "temporary migration database" and was not used for the purpose of testing nor was any testing undertaken.[5]
5. The respondent submitted that it adopted a staged approach to migrate the data using the database due to differences in the data structure between the legacy and New Production Platform system.[6] The first tranche of data was transferred to the database on 15 April 2022.[7]
6. The respondent noted that alternative approaches were not viable because it would have required the read-replica in the legacy database to be queried during low traffic hours outside of business hours, resulting in delays to the Data Migration Project and delayed security updates.[8]
7. The respondent transferred personal information to the database to facilitate the Data Migration Project and enable ongoing reporting throughout the Platform Transformation Project, specifically:
   1. customer profiles (including name, gender, date of birth, address, email addresses and phone number, but excluding customer history) on 15 and 20 April 2022; and
   2. customer lists (potentially including name and email address) on 9 August 2022.[9]

1. On 25 September 2022, the respondent experienced a data breach, where an unauthorised third party (threat actor) accessed and exfiltrated data from the database (Incident).
2. On 17 October 2022, the respondent notified the OAIC of the Incident, which it had assessed as an eligible data breach.[10]
3. At the time of the Incident, the database held approximately 17GB of data, which included the personal information of approximately 928,760 individuals (customers and members) comprising:
   1. Identity information: gender, date of birth;
   2. Contact information: name, email address, phone number, residential address; and
   3. Financial information: sales order history and invoice information.[11]
4. The threat actor sought a ransom payment from the respondent for the data that was exfiltrated. The data was posted for sale on the dark web on 16 October 2022. A sample of the data posted was subsequently sold on 20 October 2022.[12]
5. In response to the data breach notification, the OAIC made preliminary inquiries of the respondent.[13] As a result of those inquiries, concerns arose in relation to the respondent's privacy practices, particularly in relation to APP 11.1.

1. On 5 April 2023, the former Australian Information Commissioner commenced an investigation under s 40(2) of the Privacy Act into the respondent's compliance with APP 11.1 during the period 1 January 2022 to 5 June 2023 (relevant period), which captured the time of the Incident.[14]
2. An initial preliminary view was issued to the respondent on 23 December 2024. The respondent made submissions in response.[15]
3. A revised preliminary view was issued to the respondent on 28 May 2025. The respondent made submissions in response.[16]

1. The APPs in Schedule 1 of the Privacy Act regulate the handling of personal information by Australian government agencies and certain private sector organisations (APP entities).
2. An APP entity is prohibited from doing an act, or engaging in a practice, that breaches an APP.[17] An act or practice of an APP entity is an interference with the privacy of an individual if it breaches an APP in relation to the personal information about an individual.[18]
3. I am satisfied that the respondent is an APP entity because it is a body corporate that is not a small business operator,[19] a registered political party, an agency, a State or Territory authority or a prescribed instrumentality of a State or Territory,[20] and had an annual turnover greater than $3 million in three consecutive years between 2019 and 2022.[21]
4. In making this determination, I have considered the Privacy Act, the Australian Privacy Principles Guidelines (APP Guidelines),[22] OAIC Guide to privacy regulatory action,[23] and material provided by the respondent.
5. For the purposes of s 43(4) of the Privacy Act and following my consideration of the submissions and evidence, 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.
6. The facts and circumstances of this matter require me to consider the relevant law, and in particular determine the answer to the following question:
   1. Did the respondent take such steps as were reasonable in the circumstances to protect the personal information it held from misuse, interference and loss, and unauthorised access, modification or disclosure (security risks), in accordance with its obligations under APP 11.1?

Did the respondent to take such steps as were reasonable in the circumstances to protect the personal information it held from security risks, in accordance with its obligations under APP 11.1?

1. It is not in dispute that the Incident involved unauthorised access to personal information that the respondent held in the database.
2. However, in determining whether the respondent breached APP 11.1 it is relevant to consider what steps the respondent took to protect the personal information it held and whether those steps were reasonable in the circumstances to protect the information it held from the security risks. The steps an APP entity is required to take to meet its obligations under APP 11.1 will depend on the circumstances.
3. The Privacy Act is not prescriptive concerning what steps will be reasonable in the circumstances. This is an objective test that has regard to how a reasonable person, who is properly informed, would be expected to act in the circumstances.[24] This is a question to be determined on a case-by-case basis and the obligation is not susceptible to reduction to fixed rules.[25] That is to say, what is reasonable is a question of fact in each individual case and includes, where relevant, taking steps to implement strategies in relation to:
   1. ICT security
   2. Governance, culture and training
   3. Internal policies, procedures and systems.[26]
4. The Federal Court of Australia (Court) has provided guidance on the approach to be taken to determine if steps taken were reasonable in the circumstances, albeit within the context of corporations law matters.[27] The Court has observed that identifying steps that could have been taken, but were not taken, can be helpful, and is an obvious way of testing the reasonableness of what was (and was not) done. However, the focus must always be on whether the steps that were taken, in their totality, were reasonable.[28] This requires consideration of whether the steps that were taken to protect personal information from the security risks[29] were commensurate to the risks presented in the relevant circumstances.[30]
5. Accordingly, I adopt this analytical approach to determine whether the steps that the respondent took were reasonable in the circumstances. It is therefore relevant for me to identify the following:
   1. what are the relevant circumstances?
   2. what steps were taken by the respondent to protect the personal information it held from security risks? and
   3. were the steps taken by the respondent, in their totality, commensurate to the security risks in relation to the personal information it held?
6. Factors that may be relevant to assessing whether particular steps were reasonable in the circumstances may include the degree of difficulty or practicability of any given step, and the costs associated with them. Additionally, a step may be reasonable but unnecessary because an APP entity is taking other steps commensurate to the risk, to which the proposed step adds nothing.[31]
7. In its response to a preliminary view I provided to the respondent on this matter, the respondent noted that the some of the legal interpretations in adjacent case law, as discussed at paragraph [32], were developed after the time of the incident in 2022. It raised concern with respect to risks that arise from applying standards that were not reflective of the applicable regulatory environment at the re[32]vant time.32 While I acknowledge the respondent's view, I do not accept that my analysis, given its regard to instructive reasoning and legislative interpretation from the Court, imports any retrospectivity.

1. In considering what steps the respondent took to protect the personal information it held and whether such steps were reasonable in the circumstances, as required by APP 11.1, I have had regard to the following circumstances:
   1. The personal information held - the personal information stored in the database related to 928,760 of the respondent's customers and members, including gender, date of birth, contact information and sales order history and invoice information.[33] The APP Guidelines consider that as the amount of personal information that is held by an entity increases, so too will the steps that is reasonable to take to protect it.[34]
   2. The nature of the entity - the respondent is a for-profit entity with, at the time of the Incident, an income of approximately $72 million per financial year[35] and approximately 120 employees.[36] I therefore consider it to be a reasonably well-resourced entity. While the respondent has clarified that it now has 50 employees, for the purposes of considering whether it took reasonable steps under APP 11.1, it is relevant to consider the nature of the entity at the time the Incident occurred.
   3. Possible adverse consequences - the respondent held a large amount of personal information about its customers and members. It is generally accepted that the unauthorised access or disclosure of personal information posed a risk of harm to affected individuals, including through identity theft or fraud, the publication and sale of their personal information on the dark web, and being targeted by online scams. More rigorous steps are generally required as the risk of adversity increases.[37]

What steps did the respondent take to protect the personal information it held from security risks?

1. The OAIC's investigation considered steps the respondent had in place at the time of the Incident to assess whether it met the requirements of APP 11.1. To support this consideration, the respondent provided an outline of the technical and organisational measures it had in place at the time of the Incident.
2. However, the respondent also raised concerns about retrospectivity, similar to those described at paragraph [35], in relation to my consideration of their technical and organisational measures. It noted that APP 11.3 - which specifies that reasonable steps for the purposes of APP 11.1 include technical and organisational measures - was not in effect at the time of the Incid[38]t in 2022.38
3. APP 11.3 was indeed not in effect at the relevant time and I address it here only because it was specifically raised by the respondent. I note that APP 11.3 was not introduced as a new requirement, as specified in the relevant Explanatory Memorandum, but rather was introduced 'to give further guidance and clarification to APP entities, and to avoid doubt'.[39]
4. Moreover, the APP Guidelines with respect to APP 11 that were in place at the relevant time - made under s 28(1)(a) of the Privacy Act on 22 July 2019 - set out the reasonable steps that should be taken by an entity to secure personal information and include measures that would accurately be characterised as organisational and technical. Organisational measures, for example, is an accurate description of: 'governance, culture and training' and 'internal practices, procedures, and systems'.[40] Technical measures is an accurate description of 'ICT security', 'access security' and 'third party providers (including cloud computing)'[41].
5. The respondent's description of the technical and organisational measures it had in place at the time of the Incident included:
   1. Technical:
      1. device security for the respondent's ICT devices, including security software (Bitfender) installed on all devices, endpoint protection, access restrictions based on employee level and business requirements
      2. access security measures including Single Sign-on to authentication via Google Identity provider and multifactor authentication
      3. use of Software as a Service (SaaS) applications including data encryption within the AWS environment and email security through Google Enterprise Workspace subscription
      4. audit and logging measures for central internally built eCommerce business applications and some IT applications, with periodic reviews of authentication logs for unexpected behaviour.[42]
   2. Organisational:
      1. The respondent required all staff to complete annual training courses in relation to privacy, the Spam Act and fraud awareness. At the time of the Incident, 141 employees had undertaken all or some of these courses.[43]
      2. In September 2021, the respondent engaged a Chief Technology Officer who was responsible for governing the organisation's security principles, monitoring vulnerabilities and ensuring employees implemented best practice in relation to the use of technology. In March 2022, the respondent engaged a Head of Data & Technology Officer whose main responsibilities included data security and building data governance frameworks and alerts for data anomalies.[44]
      3. The respondent had an IT Policy[45] and Data Retention and Data Destruction Policy[46] that broadly set out the respondent's expectations in relation to the operation and use of its network and equipment, and principles and procedures governing the retention and destruction of data.
6. In relation to the Platform Transformation Project, the respondent submitted that it conducted a one-off risk assessment which reviewed the SaaS application security access layers, integration controls, and security documentation for compliance, data handling and access security, audit logging capability.[47]

Were the steps taken by the respondent, in their totality, commensurate to the security risks?

1. I acknowledge that the respondent took the steps outlined in paragraphs [41] to [42], which went some way to taking the reasonable steps required by APP 11.1. However, I am not satisfied that the respondent took such steps that were, in their totality, commensurate to the security risks and reasonable in the circumstances to protect the personal information it held.
2. In particular, I have identified the following risks that were inherent in the respondent's security framework and which do not appear to have been appropriately addressed by the steps taken by the respondent at paragraphs [41] to [42].
   1. the respondent had limited ability to monitor, detect, be alerted to, respond to and record security threats, unauthorised access or suspicious activity occurring on the database (see my analysis concerning security logging and access monitoring below at paragraphs [47] to [51] and paragraphs [58] to [64] respectively);
   2. the respondent failed to apply appropriate security controls proportionate to the level of risk occasioned by the use of cloud infrastructure (see my analysis regarding the steps the respondent could have taken with respect to cloud infrastructure security controls, below at paragraphs [52] to [57]); and
   3. the respondent's culture and business posture was not one that valued or nurtured attention to customer privacy, as exemplified by failures regarding its policies and procedures, training, and cultural approach to privacy (see my analysis addressing policies and procedures, people and culture, below at paragraphs [65] to [68] and paragraphs [69] to [73] respectively).
3. I discuss the risks inherent in the respondent's security framework and the steps that could have been taken to address them further below at paragraphs [47] to [73]. In undertaking this analysis, I have had regard to the circumstances outlined at paragraph [36], and the cybersecurity and information security standards and frameworks which existed at the time of the Incident and applicable to the[48]espondent, specif[49]ally, NIST CSF,48 IS[50]7000 series,49 the Essential Eight50 and the Information [51]curity Manual (Industry Standards)51.
4. In my view, taking into consideration the relevant standards and frameworks and the respondents' circumstances, there were other steps the respondent could have taken to protect personal information from the security risks, as set out below. Having regard to these steps that could have been taken, but were not, I consider that the totality of the steps taken by the respondent to protect the personal information it held were not commensurate to the risks presented in the circumstances. In order to protect the personal information it held from the security risks identified in paragraph [44], the respondent could have taken the following steps, or some combination thereof:
   1. further or additional security logging capability;
   2. adopting appropriate cloud infrastructure security controls;
   3. using access monitoring controls to alert the respondent to suspicious or unauthorised activity;
   4. implementing and using more robust security policies and procedures; and
   5. addressing a poor culture of information security awareness and capability.

1. Unauthorised access of personal information can be detected by reviewing a record of system activities, such as an audit log. Maintaining a record of system activities is often the best way for reviewing activity on a computer system to detect and investigate privacy incidents.[52]
2. According to Industry Standards, the minimum controls expected of an organisation like the respondent with respect to security logging included:
   1. logging all events where a user is performing read, create, modify, or delete actions to databases containing personal information;
   2. retaining event logs for a minimum of 1 year; and
   3. storing event logs in a centralised and secure information system.[53]
3. In the circumstances of the Incident, the respondent submitted that it had limited security logging capability in relation to the database. The respondent claimed that detailed logging was in place for its central internally built eCommerce business applications, but some databases, including the database impacted by the Incident, did not have logging enabled.[54]
4. Logging functionalities in an AWS database, whilst not configured by default, can be enabled by AWS CloudTrail, which tracks actions performed by a user, role, or an AWS service and can log details for 90 days, including the IP address from which a request is made, the date and time of an action.[55] It is my view that enabling CloudTrail would not have been a complex process, as it only required a user to log in to their AWS account and update the properties of the relevant AWS database.
5. With the absence of security logging, the threat actor was able to gain access to and exfiltrate the respondents customer database without detection.

1. The database was provided by AWS Relational Database Service, operating within the AWS cloud environment. The database was used by the respondent as a temporary migration database to facilitate the Data Migration Project as part of its Platform Transformation Project.
2. Cloud computing offers a range of potential benefits to an entity, including improvements to the entity's cyber security posture and mitigation of cyber threats, particularly where the entity does not have the resources or capability to develop its own cloud storage. Organisations that store data in the cloud are responsible for maintaining the appropriate security configurations of their cloud infrastructure.[56]
3. Having regard to the circumstances outlined at paragraph [36], it was reasonable for the respondent to have applied appropriate security controls to its cloud infrastructure, on which the database was located, by:
   1. hosting databases that stored personal information in a virtual private cloud (VPC) that is isolated and not accessible via the internet; or
   2. implementing a web application firewall for any database not isolated from the internet; and[57]
   3. encrypting any personal information stored in the databases.[58]
4. When an AWS database is created, the default settings are set to private and the database can only be accessed within a specified AWS VPC.[59] AWS by default, also encrypts all databases with an industry standard encryption algorithm on creation.[60] The respondent has advised that settings for AWS were not updated to support VPC by default until 11 March 2013.[61]
5. However, at the time of the incident, the database was poorly configured and:
   1. was not hosted on a VPC or isolated from the internet;
   2. did not have web application firewall in place, and
   3. did not have encryption enabled.[62]
6. The respondent has noted that no reconfiguration of the security settings took place before the incident. The database was created outside of a VPC due to the legacy nature of the AWS account, which did not have a VPC as default when it was created in 2012. Consequently, the respondent's legacy databases, including the database, were not attached to any VPC as default.[63]

1. Where an organisation stores content in an environment that is not intended to be disclosed to the public, it is reasonable to regularly review and monitor the environment, to ensure the content is not being accessed by unauthorised persons.[64]
2. Security access monitoring detects unauthorised access to personal information. Use of proactive security monitoring to identify possible unauthorised access is a reasonable step for entities that use systems or databases which hold large amounts of personal information.[65]
3. In the circumstances of the Incident, the respondent submitted that it did not apply access monitoring controls to its AWS environment on which the database was stored.[66] This led to the respondent's inability to monitor, be alerted to, and respond to unauthorised access or suspicious activity.
4. Based on a [redacted] submitted by the respondent, the Incident occurred on 25 September 2022.[67] However, it was only when a sample of data was published online on 16 October 2022 that the respondent confirmed that its database had been compromised.[68]
5. In light of the circumstances I have outlined at paragraph [36] it was reasonable for the respondent to have taken steps to ensure that the following access monitoring controls were in place to detect anomalous activity and possible unauthorised access:
   1. a centralised access monitoring platform for security alerts for databases with sensitive customer data and business-critical systems;
   2. real-time alerts from its monitoring platform; and
   3. actioning of these alerts on the basis of their criticality level (for example, alerts rated as high or critical severity to be actioned immediately).[69]
6. Had the respondent enabled the appropriate logging and access monitoring controls on the database, it would have been more likely to proactively detect and respond to the unauthorised access and exfiltration.
7. At the time of the Incident, the respondent failed to apply reasonable access monitoring controls to the AWS environment which stored the personal information.

1. Entities should document the internal practices, procedures and systems used to protect personal information. The documentation should be regularly reviewed and updated and outline the personal information security measures that are established and maintained against the risks and threats to personal information.[70]
2. The respondent provided the OAIC with a Security Audit report dated 31 August 2021. The Security Audit report stated that formal security policies and procedures governing the respondent's business operations did not exist.[71] Critically, it outlined that the respondent did not have any policies or procedures documenting information security, security roles and responsibilities, or the acceptable use of assets such as laptops, emails or passwords.[72]
3. While I acknowledge the respondent's claim that it did have an active IT Policy in place at the time of the audit,[73] the occurrence of the Incident despite the Policy brings into question its effectiveness. Similarly, I acknowledge the respondent's affirmation that all staff were trained on data protection at the time of the Incident through the privacy training module delivered by 'Safetrac'.[74]
4. Noting the nature and volume of personal information the respondent routinely collected for its business activities, it is my view that it was reasonable for the respondent to have implemented documented practices, procedures and systems to ensure a consistent approach to the security of personal information. Having documented security policies and procedures is a basic security safeguard, particularly for an organisation holding significant amounts of personal information.

1. Security policies and practices are only effective when properly and consistently implemented and followed by employees. Security governance arrangements should include appropriate training, resourcing and management focus to foster a privacy-and security-aware culture. Insufficient interest in personal information security from staff, in particular senior management, can lead to threats to the security of personal information being ignored and not properly attended to.[75]
2. At the time of the Incident, the respondent's management team responsible for cyber security comprised of 3 individuals including the Head of Data and Technology and Head of Engineering. Both positions were staffed by former engineers with no formal qualification or certifications in cyber security.[76]
3. Additionally, the respondent categorised its public facing privacy policy under the title 'The boring stuff', noting that "We're impressed with your commitment... But the good stuff is all up there, buddy. [Emoji: Finger pointing up]. Since you're here, check out these links and boring bits, if you're into that kind of thing."[77] The respondent confirmed that this content has since been removed from its privacy policy.[78] I acknowledge the respondent's submission that this content was intended to contrast 'serious legal and service links' - including privacy - with the product-focused "fun" content; and that it removed this content to avoid misinterpretation rather than to reflect a change in its commitment to privacy or internal standards.[79]
4. I also acknowledge the respondent's advice in response to my preliminary view that prior to the Incident, the respondent did not appear to consider its customers' privacy as a business priority. The respondent stated that because of COVID-19 where offices in Victoria were shut down during extended lockdowns, upgrading its telephone system had to take operational priority to maintain continuity of service.[80] I understand that COVID-19 impacted the respondent and prompted the urgent need to upgrade its telephone system to facilitate remote working.
5. However, I maintain that there was an unacceptable delay by the respondent in uplifting its security posture prior to commencement of the Data Migration Project and the transfer of the first tranche of data to the database in April 2022. The respondent was aware of the deficiencies in its security governance and that it needed to uplift its security posture at least 2 years prior to the Incident. The respondent was also aware of the areas where significant security risks existed that required urgent attention following the Security Audit Report which was issued a year prior to the incident. [81] At the time the Security Audit Report was issued in August 2021, this was toward the end of the COVID-19 lockdowns in Melbourne, which commenced in March 2020.[82]

1. I find that the during the relevant period, the totality of steps taken by the respondent were not reasonable in the circumstances to protect the personal information it held from misuse, interference and loss and unauthorised access, modification or disclosure.

1. As I have found that the respondent interfered with the privacy of individuals, I have a discretion under s 52(1A) of the Privacy Act to make one or more declarations. Consequently, I have made declarations at paragraphs [2] and [3] of 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 1800 228 333.

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] ASIC Organisational & Business Search, accessed 16 April 2025.

[2] Response to First s 44(1) Notice dated 17 July 2023 - letter from the respondent to the OAIC.

[3] Response to First s 44(1) Notice dated 17 July 2023 - letter from the respondent to the OAIC.

[4] Notifiable Data Breach Form submitted by the respondent 17 October 2022 (OAIC Reference DBN22/01026), Response to preliminary inquiries dated 2 November 2022 (OAIC Reference APP-PI22/0035) and Response to First s 44(1) Notice dated 17 July 2023 - Appendix F, Cyber Response to customer communications.

[5] Respondent' s submissions in response to the revised preliminary view dated 25 June 2025.

[6] Respondent's submissions in response to the initial preliminary view dated 31 January 2025.

[7] Response to First s 44(1) Notice dated 17 July 2023 - letter from the respondent to the OAIC.

[8] Respondent's submissions in response to the initial preliminary view dated 31 January 2025.

[9] Response to First s 44(1) Notice dated 17 July 2023 - letter from the respondent to the OAIC.

[10] Notifiable data breach form submitted by the respondent 17 October 2022 (OAIC Reference DBN22/01026).

[11] Notifiable data breach form submitted by the respondent 17 October 2022 (OAIC Reference DBN22/01026).

[12] Response to First s44(1) Notice dated 17 July 2023 - Appendix D: [redacted].

[13] Letter from the OAIC to the respondent - Preliminary Inquiries dated 26 October 2022.

[14] Letter from the OAIC to the respondent - s 43(1AA) Notice dated 5 April 2023.

[15] Respondent's submissions in response to the initial preliminary view dated 31 January 2025.

[16] Respondent' s submissions in response to the revised preliminary view dated 25 June 2025.

[17] Privacy Act s 15.

[18] Privacy Act s 13.

[19] Privacy Act s 6D(1).

[20] Privacy Act s 6C (1).

[21] Respondent's submissions in response to the initial preliminary view dated 31 January 2025.

[22] OAIC Australian Privacy Principles guidelines.

[23] OAIC Guide to privacy regulatory action.

[25] Australian Securities and Investments Commission v R M Capital Pty Ltd [2024] FCA 151, [86].

[27] Australian Securities and Investments Commission v Firstmac Ltd [2024] FCA 747; Australian Securities and Investments Commission v R M Capital Pty Ltd [2024] FCA 151.

[28] Australian Securities and Investments Commission v R M Capital Pty Ltd [2024] FCA 151, [80].

[29] i.e., risk of misuse, interference and loss, and unauthorised access, modification or disclosure.

[30] Australian Securities and Investments Commission v R M Capital Pty Ltd [2024] FCA 151, [85].

[31] Australian Securities and Investments Commission v R M Capital Pty Ltd [2024] FCA 151, [78].

[32] Respondent' s submissions in response to the revised preliminary view dated 25 June 2025.

[33] Notifiable data breach form submitted by the respondent 17 October 2022 (OAIC Reference DBN22/01026).

[35] Respondent's submissions in response to the initial preliminary view dated 31 January 2025.

[36] Response to Second s 44(1) Notice dated 29 April 2024 -Privacy Fraud Safetrac Completion report.

[38] Respondent' s submissions in response to the revised preliminary view dated 25 June 2025.

[39] Explanatory Memorandum, Privacy and Other Legislation Amendment Bill 2024, [99].

[40] APP Guidelines Ch 11 v1.2 (July 2019 - October 2025) [11.8].

[41] APP Guidelines Ch 11 v1.2 (July 2019 - October 2025) [11.8].

[42] Response to First s44(1) Notice dated 17 July 2023 - letter from the respondent to the OAIC.

[43] Response to Second s 44(1) Notice dated 29 April 2024 - Privacy Fraud Safetrac Completion report.

[44] Response to Second s44(1) Notice dated 29 April 2024 - letter from the respondent to the OAIC, Table 7.

[45] Response to Second s44(1) Notice dated 29 April 2024 -respondent's IT Policy.

[46] Response to Second s44(1) Notice dated 29 April 2024 -respondent's Data Retention and Destruction Policy.

[47] Response to First s44(1) Notice dated 17 July 2023 - letter from the respondent to the OAIC.

[48] NIST Cybersecurity Framework (since 2014), ISO 27001:2013, The Australia Information Security Manual (ISM) (since 2020), (ISM-0859 and ISM-1537).

[49] Information Security Standards (since1995).

[50] Australian Cyber Security Centre Essential Eight Maturity Model (since 2017).

[51] Information Security Manual (since 2016).

[52] OAIC Guide to securing personal information, 'Audit logs, audit trails and monitoring access'.

[53] NIST Cybersecurity Framework (since 2014), ISO 27001:2013, The Australia Information Security Manual (ISM) (since 2020), (ISM-0859 and ISM-1537).

[54] Response to First s44(1) Notice dated 17 July 2023 - letter from the respondent to the OAIC.

[55] AmazonS3 Enabling CloudTrail logging for s3 buckets accessed 21 November 2024.

[56] OAIC Notifiable Data Breaches Report: January to June 2024, Misconfiguration of cloud-based data holdings.

[57] What is Amazon VPC accessed 20 December 2024, NIST Cybersecurity Framework (since 2014), PR.AC-7; ISO 27001:2013, A.9.4.2; Essential Eight Maturity Level One.

[58] NIST Cybersecurity Framework (since 2014), PR.DS-1; ISO 27001:2022, 8.11.

[59] AWS Default VPC components accessed 20 December 2024.

[60] Protecting data with encryption - Amazon Simple Storage Service accessed 20 December 2024.

[61] Respondent's submissions in response to the initial preliminary view dated 31 January 2025.

[62] Response to First s44(1) Notice dated 17 July 2023 - Appendix D: [redacted].

[63] Respondent's submissions in response to the initial preliminary view dated 31 January 2025.

[64] OAIC Guide to securing personal information, Access security.

[65] OAIC Guide to securing personal information, Access security.

[66] Response to First s44(1) Notice dated 17 July 2023 - letter from the respondent to the OAIC.

[67] Response to First s 44(1) Notice dated 17 July 2023 - Appendix D: [redacted].

[68] Letter from the respondent to the OAIC - Response to First s44(1) Notice dated 17 July 2023 - Appendix D: [redacted].

[69] NIST Cybersecurity Framework (since 2014): DE.CM-3 and DE.CM-7; ISO 27001:2013, A.12.4.1.

[70] OAIC Guide to securing personal information, Internal practices, procedures and systems.

[71] Response to Second s44(1) Notice dated 29 April 2024, Brennan IT, 'Security Audit Report' dated 31 August 2021.

[72] Response to Second s44(1) Notice dated 29 April 2024, Brennan IT, 'Security Audit Report' dated 31 August 2021.

[73] Respondent's submissions in response to the initial preliminary view dated 31 January 2025.

[74] Respondent's submissions in response to the initial preliminary view dated 31 January 2025.

[75] OAIC Guide to securing personal information, Governance, culture and training.

[76] Response to Second s44(1) Notice dated 29 April 2024- letter from respondent: Annexure D.

[77] Internet Archive Wayback Machine, Vinomofo Australia website 30 September 2022.

[78] Respondent's submissions in response to the initial preliminary view dated 31 January 2025.

[79] Respondent' s submissions in response to the revised preliminary view dated 25 June 2025.

[80] Respondent' s submissions in response to the revised preliminary view dated 25 June 2025.

[81] Response to Second s44(1) Notice dated 29 April 2024, Brennan IT, 'Security Audit Report' dated 31 August 2021.

[82] See, for example, ABC News, Melbourne marks 200 days of COVID-19 lockdowns since the pandemic began, accessed 2 October 2025.