Odido data breach: Kamerbrief confirms BSN exposure was worse than initially disclosed
TL;DR
In early February 2026, attackers accessed a Salesforce-based customer system at Dutch telecom operator Odido and exfiltrated data on approximately 6.2 million current and former customers. ShinyHunters claimed responsibility and demanded a ransom, which Odido refused. On 9 April 2026, a Kamerbrief from two state secretaries confirmed that burgerservicenummers were in the stolen dataset, contradicting Odido's earlier public statements and matching what RTL Nieuws reported in late February.
Incident Response PlaybookExpand
- Confirm the intrusion and isolate the affected customer system. Preserve evidence before any remediation.
- Pull audit logs from the SaaS platform (Salesforce in this case), including API activity, export history, and authentication events.
- Identify all compromised accounts and service identities. Revoke sessions, rotate credentials, enforce MFA, review OAuth app consents.
- Determine the attacker timeline, dwell time, and what was actually exfiltrated versus what was accessible.
- Run structured forensic evidence collection across the tenant and connected systems.
- Before any public disclosure, confirm the scope of the exposed fields across all record types. Former customers still in the system count.
- Engage legal counsel and, where ransom is involved, specialist counsel. Refusal is a legitimate position; the decision belongs with the board, not the IR team.
- Notify the Autoriteit Persoonsgegevens within 72 hours. Notify law enforcement (OM, politie cybercrime).
- Draft external communications that match what forensics have established, not what is convenient. Err on the side of over-disclosure.
- Monitor leak sites and dark web channels. Extortion groups typically publish in stages.
- Review data retention practices. If former customers are in the leak, the root cause is partly a retention-policy failure.
- Post-incident review that covers the disclosure track as carefully as the technical track.
The Odido data breach, as of April 2026
The Odido data breach is one of the largest incidents to hit a Dutch telecom operator in recent memory. On 9 April 2026, demissionary state secretaries Arno Rutte (Justice and Security, VVD) and Eddie van Marum (Interior, BBB) answered Kamervragen from members of parliament about the incident. Their written response confirmed that burgerservicenummers (BSN, the Dutch citizen service number) are present in the stolen dataset.
That confirmation matters for two reasons. It contradicts Odido's public statements in February, when the company said BSN were not among the exfiltrated data. And it aligns with what RTL Nieuws established on 25 February 2026 by analysing the dataset directly.
What happened, on an updated timeline
Attackers gained unauthorised access to a Salesforce-based customer system at Odido on or around 7 to 8 February 2026. Odido detected the access and, on 9 February, filed a notification with the Autoriteit Persoonsgegevens, the Dutch data protection authority.
ShinyHunters, a known criminal group, claimed responsibility. Ransom demands were reported variously at seven figures and, later, around half a million euros. According to NOS, Odido refused to pay. That is the correct call, and we will not pretend otherwise.
On 25 February, RTL Nieuws reported that its analysis of the published dataset contained burgerservicenummers. This contradicted Odido's earlier framing. Between 26 and 27 February, ShinyHunters began publishing portions of the data on a dark web forum. By 2 March, according to Telecompaper and other outlets, the full dataset had been released.
The scope, per Dutch media coverage, is approximately 6.2 million accounts, including former customers whose data had been retained in the system. Data exposed includes names, addresses, email addresses, phone numbers, dates of birth, bank account numbers (IBAN for approximately 340,000 customers per RTL Nieuws), passport or ID document numbers, and a small number of BSN belonging to former ZZP'ers (self-employed individuals) whose pre-2020 BTW numbers contained their BSN by construction.
BNR Nieuwsradio quoted privacy lawyer Menno Weij of The Data Lawyers on the BSN question: "Je BSN krijg je maar één keer in je leven." That is the heart of why BSN exposure is a different category of harm. You can issue a new bank card. You cannot issue a new BSN.
The Autoriteit Persoonsgegevens is investigating Odido's retention practices: specifically, why former customers were still in the system at all. The Openbaar Ministerie has opened a separate criminal investigation.
How the attack worked
Odido has described the incident as unauthorised access to a customer system built on Salesforce. The company has not disclosed the precise entry method. Broader rumours about the wider Salesforce supply chain have circulated in various reports; those are reported claims, not confirmed facts, and we will leave them as such.
What is worth saying in plain terms: when a single SaaS customer-data system holds complete profiles on 6.2 million people including former customers, the compromise of that system is the worst case by design, not by bad luck.
Who is affected
Around 6.2 million current and former Odido customers. The data enables a broad range of fraud scenarios: targeted phishing using accurate personal details, fake direct debit requests, impersonation of Odido customer service, and, because passport numbers are included, a subset of higher-effort identity-fraud attempts. BSN exposure adds a specific category of risk around tax and benefit fraud that is much harder for affected individuals to mitigate.
What this means for your organisation
The useful lessons from the Odido story are not about telecom security. They are about disclosure discipline and data retention.
Initial disclosure scope is almost always wrong, and usually too small. In the first 72 hours after discovering an intrusion, a company is under pressure from three directions at once: regulators want a notification, customers want clarity, and the legal team wants nothing said that cannot be retracted. The result is that the first public statement describes what is confirmed in those 72 hours, which is consistently less than what forensics will eventually establish. That is not always dishonest. It is often just premature. The problem is that the correction, when it comes, and it almost always comes, damages trust more than the breach itself. Odido's BSN denial, corrected first by RTL Nieuws and now by a Kamerbrief, is a textbook case.
Data retention is a cheap control that is routinely neglected. The reason former customers from years ago are in this leak is not a security failure. It is a retention-policy failure. Under AVG, personal data should not be kept longer than necessary for the purpose for which it was collected. "We might need the customer record if they come back" is not a lawful purpose. Retention reviews are boring work with no glamour attached, and they are consistently among the highest-impact changes a Dutch organisation can make for the cost.
The BSN question deserves board-level attention. If your organisation holds BSN for employees, contractors, or customers, your breach-impact assessment needs to treat that field differently from all other personal data, because the remediation path for affected individuals is so much narrower. Encrypting, segregating, and minimising the storage of BSN is one of the clearest risk-reduction moves available.
Organisations that want incident response capacity that treats the disclosure and regulator track as seriously as the technical track, so that version two of the story does not contradict version one, can engage SecDesk directly through response.secdesk.com. That is what the first week of an incident like this needs.
Talk to a senior responder about Odido data breach: Kamerbrief confirms BSN exposure was worse than initially disclosed.
Schedule a response callNeed incident response?
- Two-hour SLA
- Dutch senior responders