Most teams shopping for Australian data retention compliance software start with the wrong mental model: they picture a tool that deletes old files. Real retention compliance in Australia is harder and more interesting than that, because two opposite duties apply at the same time. Some laws say keep this record for years. The Privacy Act says don't keep personal information a moment longer than you need it. Good software has to serve both — and, crucially, it can only ever be as trustworthy as the data platform it sits on top of.
What this guide covers
- The two-way nature of retention: minimum-keep vs must-delete.
- The main Australian obligations that set the clocks.
- The capabilities retention software actually needs.
- Why the sovereignty of the underlying data layer is part of compliance, not separate from it.
Retention compliance is two obligations, not one
The reason retention is genuinely hard in Australia is that you're simultaneously subject to:
- Minimum-retention rules — laws requiring you to keep certain records for a set period (tax, employment, telecommunications, health, and more).
- Data-minimisation rules — the Privacy Act requiring you to destroy or de-identify personal information once it's no longer needed.
Get either wrong and you're exposed. Delete a tax or employee record too early and you breach a retention law. Hoard personal information you no longer need and you breach Australian Privacy Principle 11.2, while quietly inflating the blast radius of any future breach. Software that only does one half of this isn't doing retention compliance — it's doing half of it.
Retention isn't "delete old data." It's "keep exactly what the law requires, for exactly as long as it requires, and no longer."
The obligations that set the clocks
There is no single national retention period in Australia — the number depends on the record and the law behind it. These are common examples, not an exhaustive or authoritative list, and you should confirm the periods that apply to your records with a qualified adviser:
| Record type | Typical minimum | Broadly under |
|---|---|---|
| Tax & financial records | ~5 years (business records) | ATO / tax lawlonger under some Corporations Act rules |
| Employee records | 7 years | Fair Work Act 2009 |
| Telecommunications metadata | 2 years | Mandatory data retention scheme |
| Health records (adult) | ~7 years after last service | State health-records laws |
| Health records (minor) | Until age 25 | State health-records laws |
| Personal info no longer needed | Destroy / de-identify | Privacy Act — APP 11.2 |
The practical lesson: retention is per-data-type. A single blanket "keep everything for 7 years" policy will both over-retain personal information and under-retain some regulated records. You need schedules that vary by category.
What retention compliance software actually needs to do
Strip away the marketing and effective retention tooling comes down to a handful of capabilities. Use this as a checklist when you evaluate anything — including us.
- Per-category retention schedules. Define a retention period per data type or table, not one rule for everything.
- Automated, enforceable expiry. When a record passes its retention date, the system should securely delete or de-identify it — automatically, not via a reminder someone ignores.
- Legal-hold overrides. The ability to suspend deletion for records under litigation, audit or a court order, then resume when the hold lifts.
- Immutable audit logs. A tamper-evident record of what was created, retained, de-identified and deleted — and when — so you can prove compliance, not just assert it.
- Backup-aware retention. Your retention policy is only real if it also governs backups. A record you "deleted" that lives forever in an unmanaged backup hasn't been deleted.
- De-identification, not just deletion. Often the right answer is to keep the row but strip the personal information — support for masking and de-identification matters.
- Verifiable data location. You can't honour a retention or destruction duty over data whose copies you can't account for.
The capability most buyers overlook: the data layer
Retention software rarely stores your data itself — it governs data that lives in a database and its backups. That means the properties of your underlying data platform are the properties of your retention compliance. Two capabilities from the managed-database layer do most of the heavy lifting:
- Point-in-time recovery with a defined window. PITR is a retention control in its own right — it defines exactly how far back recoverable history goes, which is precisely the kind of bounded, documented window auditors want to see.
- Managed, governed backups. Backups with their own retention policy close the "deleted but still in a backup" gap. Unmanaged copies are where retention promises quietly break.
We go deeper on these in What "managed PostgreSQL" actually includes.
Why sovereignty is part of retention compliance
Here's the connection buyers often miss: you can't fully control retention over data a foreign government could compel or copy. Retention and destruction duties assume you decide what happens to the data. If your platform is US-owned, the CLOUD Act means a US authority can compel production of that data regardless of your retention schedule — and if you can't account for where every backup copy sits, you can't honestly certify that "destroyed" means destroyed everywhere. Sovereignty and retention aren't separate compliance projects; sovereignty is what makes your retention guarantees credible. We unpack the jurisdiction question in Data sovereignty in Australia.
Where WattleDB fits
WattleDB isn't a turnkey records-management product — it's the sovereign data layer you build retention on. It's an Australian-owned, Australian-hosted managed PostgreSQL platform from RR Sols Pty Ltd, with automated backups, point-in-time recovery, Row-Level Security and audit-friendly logging, and no US entity anywhere in the chain. That gives your retention software the things it depends on: a bounded, documented recovery window; governed backups; the ability to enforce deletion and de-identification in SQL; and a data location you can actually attest to — all within Australian jurisdiction. The compliance workflow is yours to define; WattleDB makes sure the ground it stands on is solid and sovereign.