How long you must keep customer data, and when keeping it becomes the risk

The third condition is where the conflict lives. Australian law does require records to be kept, sometimes for years, and while those obligations run they suspend the duty to dispose. The rules worth putting in a schedule are the ones you can state precisely, with a source and with the event the period runs from.

Each rule attaches to a defined class of record. Section 286 covers the records that explain a company's transactions and financial position, s 262A covers records relevant to a tax position, and s 535 covers employee records. None of them reaches your CRM notes, support transcripts, call recordings, session logs or the photographs a customer uploaded with a warranty claim. The claim that everything is kept for seven years because of the ATO takes one statute, applies it to the whole estate, and manufactures the liability the disposal obligation exists to remove.

Employee records carry an exemption running the other way. Under s 7B(3) of the Privacy Act, an act or practice of an organisation that is directly related to a current or former employment relationship, and to an employee record it holds, is exempt from the APPs, so APP 11.2 does not drive disposal of those records at a private sector employer. The Fair Work period becomes a floor with no privacy ceiling above it. The exemption is also narrower than people assume: it does not reach job applicants or contractors, and agencies do not have it at all.

Two further pulls sit outside the table. A Commonwealth record cannot be destroyed without authorisation from the National Archives under the Archives Act 1983 (Cth), and each state and territory runs an equivalent regime through its own archives authority, so work delivered under a government contract can create records where destruction is a permission you apply for. Separately, the general limitation period for an action founded on simple contract or tort is six years in every state, s 10 of the Limitation of Actions Act 1974 being the Queensland provision, which is why schedules default to the end of the relationship plus six or seven years. That default is a risk judgement, and it belongs in the schedule labelled as one.

Reconciliation happens at the level of the data class, and the column most schedules omit is the basis: the statute and section, the contract clause, or the documented risk judgement standing behind the number in the period column. Without it nobody can review the schedule, because every period on it looks equally authoritative. Classes sharing a system routinely get different answers, since an invoice line and the free text delivery instruction beside it are not the same class. APP 11.2 sets the floor and the longest statutory rule that genuinely applies sets the ceiling. Nothing obliges you to sit at the ceiling, and most schedules do because the ceiling is the only number anyone wrote down.

Where a statute does force you past the point of need, the data should change state. A retention obligation is a carve-out from the duty to dispose and it is not authority to keep using the information for purposes that have ended. Holding an invoice for five years under tax law says nothing about continuing to market to that customer, including them in a training dataset, or leaving their details searchable by every support agent. The implementation is a restricted state: the record carries a flag marking it retained under obligation, access narrows to the people who need it for that obligation, and it drops out of exports, analytics feeds and outbound systems.

The clock column decides whether any of this can be built. Almost none of those periods run from the date the row was created, which is often the only date the schema stores, so implementing a schedule usually starts with adding the triggering event as a real column and backfilling it. Until that column exists, every deletion job approximates the law with whichever timestamp was convenient.

APP 11.2 accepts de-identification as an alternative to destruction, which is why it gets claimed so often. The bar sits in s 6(1) of the Privacy Act: information is personal information if it is about an identified individual or an individual who is reasonably identifiable, and it is de-identified once it is no longer about such an individual. Reasonably identifiable is assessed in context, including what else is available to whoever ends up holding the data. The first failure is pseudonymisation reported as de-identification, because replacing names with tokens while keeping the mapping table means you still hold the key.

The second failure is uniqueness in the fields nobody thought of as identifiers. Date of birth, postcode, gender, first and last transaction dates and a device identifier all survive removal of the name, and in combination they single out individuals in a dataset of very ordinary size. The tails are worst, where a rare diagnosis or an unusually large transaction is an identifier on its own. Free text defeats the exercise outright, because a support transcript or a clinical notes column carries names, addresses and relationships that no column-level rule will find.

Apply one test before claiming it: can any process, dataset, key or staff member in the business re-attach an identity to a row, and would the result still be re-identifiable in the hands of the party who will hold it? If the answer is yes, you have retained personal information under a label saying you did not, which is worse than keeping it openly. The extract escapes your retention job, sits outside the access controls applied to the source, and if it leaks you assess and notify on it like any other personal information. The de-identification framework the OAIC published with CSIRO's Data61 treats the question as a function of the data and its release environment together.

Deleting from the primary database is where most implementations stop. Soft deletes are the first gap, because a deleted_at timestamp or an is_active flag removes the row from the application and from nothing else, which is what a large share of account deletion features actually do. Search indexes hold their own copy of every field they index and do not follow a database delete, and caches and dead letter queues hold payloads for as long as their own settings allow.

The analytical estate is harder, because it was built to remember. Change data capture pipelines carry a delete downstream as an event, and the warehouse patterns that consume those events commonly write a tombstone row while keeping the prior values in history, so the warehouse retains exactly what the primary just destroyed. Unless somebody wrote the deletion path for the warehouse specifically, deletion has not happened there, and that is usually the copy with the longest retention and the broadest access.

Then there are the copies nobody classifies as systems: the exported spreadsheet in a shared drive, the generated PDF in object storage, the error tracker that captured a full request body with user context attached, the transactional email provider that retains message content, and the mailbox. For many businesses the mailbox holds more customer personal information than the CRM does, and no retention job has ever touched it. Mail and collaboration platforms apply their own retention settings, and whatever those settings say is the real answer for that copy.

Backups are the honest hard case, and the OAIC's guidance on APP 11 gives a workable position. Where personal information sits in a backup that cannot practicably be destroyed on demand, you can treat it as put beyond use, provided you are not able and will not attempt to use or disclose it, no other entity can access it, it is protected by appropriate security, and you commit to destroying it once that becomes possible. That holds only where the backup cycle is short and enforced. Restoring a snapshot taken before a deletion also reinstates the records you destroyed, so the restore runbook needs a step that re-applies the deletion set.

Commercial agreements and data processing terms routinely require return or deletion of the other party's data within a stated window after termination, with certification on request. The drafting varies and the operational question does not: what will you be able to prove. You need to show which systems held the data, that deletion ran in each of them, when it ran and who ran it, and what remains and on what basis. All of it depends on a current record of where the data went, which is the artefact most suppliers find they do not have on the day the request arrives.

The commitment you will breach is the one with no backup carve-out and no allowance for records held under statute. A promise to permanently delete everything within 30 days, given by a business running a 35 day backup chain, is a promise to something that will not happen, and a certificate saying all data has been permanently destroyed while that chain still holds the records is a false statement in a contract file until the first copy surfaces. The defensible version describes what happened: the systems in scope, the method used in each, and every residual copy with the date it expires.

A schedule in a document discharges nothing by itself. What discharges it is a job on a timer, so the implementable form of a schedule is metadata: every store holding personal information is tagged with its class, and each class carries its triggering event, period and basis. The job then needs four properties before anyone will let it run against production. It supports a dry run that reports what it would remove by class and by count without removing anything. It acts in bounded batches, so a wrong boundary date cannot empty a table before anyone notices. It halts and alerts when a run's volume departs sharply from recent runs, because zero rows usually means a broken query and ten times the usual volume means a broken date calculation. It honours legal holds recorded in a register with an owner, a reason and a review date, since a hold nobody lifts is indefinite retention with a compliance justification stapled to it.

Deletion also has to fan out. A delete in the primary should enqueue deletion in the warehouse, the search index, object storage, the mail and messaging providers and every third party system, with retries and monitoring, because a fan-out that is fire and forget fails silently and surfaces years later when somebody searches for a customer who was supposedly removed. Where a store genuinely cannot delete on demand, cryptographic erasure is often the practical answer: encrypt per tenant or per subject with a key you control, then destroy the key. That works only where the key was scoped to that subject from the beginning and no other copy of the key or the plaintext exists.

Test it the way you test a restore: take a subject deleted six months ago, search every store and every processor for their identifiers, and write down what came back. That record, and the run history behind it, is what an assessor or a regulator asks for once the policy has been produced and answered nothing, so the job should emit a record on every execution covering start and finish times, the class processed, the boundary date used, counts removed per store, fan-out results, failures, and the identity that initiated the run. Log identifiers and counts and never the values destroyed, or the evidence of deletion becomes a durable copy of the deleted data. Retention evidence generally needs keeping longer than the data it describes, so decommissioning a platform includes exporting its run history first.

The engineering is the same discipline as an audit trail, which is why we tend to build them together. The operations and compliance portal we built and run for GRM LAW, a Brisbane law firm, records state changes on an append-only audit ledger, and the staff portal we built for Stone Leaf Capital, an Australian capital-markets firm, carries a compliance audit log capturing actor, action, and before and after state. Aurii, our own clinical software venture, runs tamper-evident audit trails over tenant health data hosted on Azure in Australia.

In compliance readiness work and in the systems we build, a retention schedule is treated as a build item: classes tagged in the schema, a job that executes them, a hold register with named owners, and a run history someone outside the team can read. The questions to take into your own estate are narrow. Which class does this field belong to, what event starts its clock, which provision sets its period, and when did the job last remove anything under it. Where no such job exists, the schedule is a statement of intent, and closing that gap is engineering work.