Qantas has dodged penalties that could have run into billions of dollars after simple human error was found to be the cause of the massive 2025 data breach that affected millions of customers, and ISO27001 compliance failed to prevent.
The Office of the Australian Information Commissioner (OAIC) closed its preliminary inquiries on 16 July 2026 without launching an investigation or taking any regulatory action, finding the airline could not reasonably have foreseen or prevented the attack.
The OAIC report gives the most detailed official account yet of the incident, which struck the Salesforce customer relationship management (CRM) platform used by Qantas contact centres.
On Saturday 28 June 2025, a threat actor phoned an agent at an overseas contact centre run by a third-party provider for Qantas. The caller posed as 'Qantas IT help' checking an IT issue the agent might have been experiencing. The agent believed the caller was a legitimate Qantas employee.
The caller directed the agent to a website related to the Salesforce platform and walked them through a series of actions supposedly needed to close an IT support ticket. In the wider campaign this attack belonged to, victims were directed to the Salesforce connected app setup page and told to enter an eight-digit connection code. That code registered an attacker-controlled tool, a modified version of Salesforce's own Data Loader utility, as a trusted connected app on the victim's account.
The result was that the agent's own authenticated session authorised the connection. No password was stolen. No multi-factor authentication challenge was triggered, because the attacker never logged in. Salesforce saw only a legitimate user approving an app, and issued the attacker an OAuth token carrying all of the agent's permissions.
Those permissions were broad. As a customer service agent, the employee was authorised to view the contact profiles of Qantas customers across the CRM. The attacker's tool used that access to run bulk queries through the Salesforce API, extracting approximately 5.67 million customer records, including those of about 5.12 million Australians.
For around 4 million records the data comprised names, phone numbers, email addresses and Frequent Flyer numbers, tiers, points balances and status credits. A further 1.7 million records also held one or more of residential or business addresses, dates of birth, gender and meal preferences. No credit card, financial or passport details were stored on the platform, and no passwords or PINs were accessed.
The breach occurred despite Qantas requiring its overseas contact centre provider to maintain ISO 27001 compliance, a factor the Office of the Australian Information Commissioner (OAIC) described as "particularly relevant" in assessing whether the airline took reasonable steps. The regulator noted the standard mandates controls directly connected to the incident, covering security awareness training on phishing and social engineering, rules for managing access credentials, and data leakage prevention monitoring.
The intrusion generated two system alerts from an unusual number of failed login attempts, incidental noise rather than the access vector itself. Because the attack landed on a Saturday, the alerts sat unread until Monday morning, 30 June, when a Qantas staff member spotted them and escalated to the cybersecurity team.
Qantas froze and revoked the compromised account the same day, assessed the data exfiltration, and triggered its incident response. It disclosed the breach publicly on 2 July and notified all affected customers of the specific data types taken from 9 July.
The attack was part of a global vishing campaign against Salesforce customers attributed to the ShinyHunters group, which also claimed victims including Google, Allianz Life and LVMH brands. The Qantas data was published by the hybrid Scattered Lapsus$ Hunters extortion group on 12 October 2025 after a ransom deadline passed, despite a NSW Supreme Court injunction prohibiting its release.
Root Causes
The OAIC identified the central vulnerability as a default Salesforce configuration that allowed any end user to authorise the connection of a third-party application. Role-based access controls could not have prevented the breach, because the attacker's tool simply inherited the legitimate access of a deceived user. Salesforce has since changed that default for all its customers.
The second root cause was a training blind spot the regulator said extends across the industry. "Most social engineering training focusses on credential theft and does not usually address the less common tactic of inducing an employee to authorise access through legitimate system interactions," the report states. The attack would likely have succeeded even with standard training in place.
Two further factors amplified the damage. A single contact centre agent could see the entire customer base, so one deceived employee exposed 5.7 million records. And detection relied on login-based alerts reviewed on the next business day, giving the attacker an undisturbed window of roughly 36 hours over a weekend.
What Could Have Prevented It
The single control that would have stopped the attack outright is the one Salesforce has now made default: restricting connected app authorisation to administrators, so end users cannot approve third-party API connections. Organisations running Salesforce or similar CRM platforms can go further by allow-listing approved API clients and limiting the API Enabled permission to roles that need it.
Real-time exfiltration monitoring would have cut the breach short. Bulk extraction of millions of records via API is exactly the anomaly that Salesforce Event Monitoring and transaction security policies can flag, with automated session termination, rather than waiting for a human to read login alerts on Monday. Around-the-clock alert triage matters for the same reason, as attackers deliberately strike on weekends.
Procedural controls also had a role. A mandatory callback protocol for unsolicited IT support calls, requiring agents to verify a ticket number in the service desk system or ring back a known internal number, directly counters the pretext used. Rate limits or approval gates on mass record retrieval would have shrunk the blast radius even after the authorisation succeeded.
Since the incident Qantas has rolled out a dedicated online social engineering course for contact centre agents, reinforced with face-to-face training, addressing the consent phishing gap the OAIC identified.
The airline had spent a year exposed to the toughest penalty regime in Australian privacy law. Under section 13G of the Privacy Act, a serious interference with privacy carries a maximum penalty of the greater of $A50 million, three times any benefit obtained, or 30 per cent of adjusted turnover where that benefit cannot be valued. As IDM reported in July 2025, the turnover limb implied a theoretical maximum of about $A6.6 billion on Qantas' FY24 revenue, and more than $A7.1 billion on FY25 revenue of $A23.8 billion.
The realistic ceiling was likely $A50 million per contravention, since Qantas obtained no benefit from the attack, but contraventions can multiply. In its ongoing Medibank proceedings, the OAIC has treated each affected individual as a potential separate contravention. In the end, Qantas will pay nothing.
The regulator stressed that its report makes no concluded findings and is not an endorsement of Qantas' practices. It remains open to the OAIC to investigate later, and a representative complaint and individual complaints over the breach are still being handled separately.
"Based on the information provided, it does not appear that Qantas could have reasonably foreseen and prevented the breach in the manner that it occurred," the Commissioner concluded.
The report is available at oaic.gov.au.