How data actually leaks, and the controls that stop it

It's easy to imagine breaches as sophisticated, movie-style hacks. The Australian data tells a more mundane and more useful story. According to the Office of the Australian Information Commissioner (OAIC), organisations reported more than 1,100 notifiable data breaches in 2024, the highest annual total since the scheme began in 2018 (OAIC). Malicious or criminal attacks remain the leading cause, and within those, the OAIC reports that phishing and compromised or stolen credentials are the most common methods, while human error continues to account for a large share (OAIC H2 2024 report). System faults, by contrast, make up only a few per cent.

Two Australian cases that show the pattern

The country's two most consequential breaches both trace to unglamorous root causes. In the Optus breach of September 2022, the personal information of around 9.5 million current and former customers was exposed; the widely reported root cause was a coding error in the access controls of a dormant, internet-facing API, a surface that was reachable when it shouldn't have been (overview). Weeks later, Medibank disclosed a breach affecting 9.7 million current and former customers, including sensitive health data; entry was gained using compromised credentials. Neither needed a zero-day. One was an exposed surface; the other was a stolen key to the front door.

Control 1 — Shrink and close the attack surface

The Optus lesson is blunt: every internet-reachable endpoint is a liability, and the dangerous ones are the endpoints you've forgotten. Databases should never be openly reachable from the public internet; access should be mediated, network-restricted, and inventoried. On a managed platform this means per-database network isolation so one database can't be reached from another's context, and no "public by default" exposure. The fewer doors, the fewer forgotten ones.

Control 2 — Assume credentials will be stolen

Phishing and stolen credentials lead the OAIC's cause list, and Medibank is the case study. You can't prevent every credential theft, so design for it: enforce multi-factor authentication, scope credentials tightly, rotate them, and never let a single leaked secret unlock everything. A stolen password should open a small, well-fenced room, not the whole building.

Control 3 — Least privilege, enforced in the database

Most breaches get worse because the compromised account could see far more than its job required. The database is the right place to enforce limits, not just the application. Row-Level Security (RLS) in PostgreSQL restricts which rows a given role can read or write, so a compromised application user, or a bug in your code, can't quietly read every tenant's data. It turns "one account, all the data" into "one account, only its slice." WattleDB supports RLS on every database; see multi-tenant data isolation with RLS.

Control 4 — Encrypt the sensitive fields so a breach yields gibberish

Every control above reduces the chance of a breach. Encryption reduces the impact if one happens. If personal-data fields are encrypted with a key the database provider never holds, then an attacker who exfiltrates the data, or a stolen backup, or an insider, gets ciphertext, not names and Medicare numbers. This is client-side encryption, and it's the difference between a breach that's an operational incident and one that's a front-page disclosure. You keep exact-match search through blind indexes. Note the honest boundary: at-rest encryption doesn't do this, because the provider holds that key.

Control 5 — Isolate, monitor, and be able to recover

Three more that consistently separate a contained incident from a catastrophic one:

• Tenant isolation, so a compromise of one customer's data can't traverse into another's. Separate databases with separate credentials beat one shared database trusting application logic.
• Audit logging, so you can see who accessed what. You can't investigate, or prove the scope of, a breach you didn't log.
• Backups and point-in-time recovery, so ransomware or destructive actions don't end you. PITR lets you rewind to just before the damage. (Recovery won't un-expose leaked data, that's what the controls above are for, but it's essential for the destructive cases.)

The uncomfortable through-line: who can be compelled, and who holds the key

There's a category the technical controls don't cover: lawful access. A provider that can read your data can be compelled to hand it over, and for foreign-owned providers that reach extends across borders, the US CLOUD Act is the clearest example. Two structural choices address it: hosting with a provider that has no foreign entity in its ownership chain, and encrypting sensitive fields with keys you hold so there's nothing readable to compel in the first place.

The short version

Breaches are mostly boring: exposed surfaces, stolen credentials, over-broad access. The defences are correspondingly concrete, close the doors, assume passwords leak, enforce least privilege in the database, encrypt the sensitive fields, isolate tenants, log access, and keep recoverable backups. WattleDB is built around these, sovereign Australian hosting, Row-Level Security, isolated databases, audit logging, and cross-state backups with PITR, with client-held encryption coming to shrink the blast radius further. None of it is exotic. That's the point: most breaches are prevented by doing the ordinary things properly.