Data You Never Collect Costs Nothing to Protect
The cheapest record to secure is the one you never collected. Every field on every form, every log line, every CSV export sitting in a shared drive is something you now have to encrypt, back up, access-control, monitor, and one day explain to the OAIC if it leaks. Breach impact does not scale with what the attacker came for. It scales with what was in the database when they arrived.
Privacy by design is usually presented as a policy posture, something the compliance function owns. In practice it is a set of engineering decisions made at the moment a schema is drawn or a signup form is laid out, and the single highest-leverage decision available is to collect less. The Australian Privacy Principles already say this plainly. Most organisations have just never treated the words as an instruction to their developers.
APP 3 and APP 11.2 Are Engineering Requirements
APP 3 under the Privacy Act 1988 says an organisation must not collect personal information unless it is reasonably necessary for one or more of its functions or activities, with a higher bar again for sensitive information, which generally needs consent on top of necessity. That is a testable engineering requirement. Yet the necessity test is almost never applied to the artefacts that actually do the collecting: web forms, onboarding flows, support scripts, CRM field layouts, and the default configuration of every SaaS tool the business signs up for.
APP 11 gets cited for its security obligation, but its second limb matters just as much. APP 11.2 requires reasonable steps to destroy or de-identify personal information once it is no longer needed for any purpose permitted under the APPs, unless the law requires you to keep it. Across Australian small and mid-sized businesses it routinely goes unmet, and not because anyone resists it. It goes unmet because nobody ever built a deletion mechanism. Data is rarely kept by decision. It is kept by default.
The Notifiable Data Breaches scheme in Part IIIC of the Act makes the cost of that default concrete. When a breach is likely to result in serious harm, you must notify the OAIC and affected individuals as soon as practicable, and a suspected breach gives you at most 30 days to complete your assessment. Every record held past its useful life widens the pool of affected individuals and deepens the harm analysis. A decade of dormant customer records contributes nothing to the business, but every one of them counts in full when the notification letters go out.
Where Personal Information Accumulates by Default
The primary application database is rarely where the exposure lives. Across code reviews and cloud security work the same accumulation points appear in most environments, and each one represents a collection or retention decision that nobody actually made:
None of these appear in a privacy policy, and all of them sit within scope of APP 11's reasonable steps. When an incident responder maps what an attacker could reach, the sprawl is the map. The disciplined datastore with field-level encryption matters far less if last year's full customer export is sitting in a finance mailbox.
- Application logs capturing full request bodies, including passwords, tokens and form contents, shipped to a third-party log platform with its own retention settings
- Backups with no expiry, so records deleted from production live on indefinitely in nightly snapshots
- CSV exports and reporting extracts in mailboxes and SharePoint folders, outside every access control the source system enforces
- Test and staging databases seeded from production copies
- Soft-deleted rows that a flag hides from the interface but not from anyone with database access
- Third-party analytics, support desk and marketing tools, each holding its own copy of your customers under its own terms
A Retention Schedule Your Engineers Can Execute
Most retention schedules are written for auditors: a Word document listing categories and years, reviewed annually, executed never. A useful schedule is a table your engineers can implement. For each class of personal information it states the purpose served, the legal minimum retention where one exists, the event that starts the clock, the mechanism that performs the deletion, and the named owner accountable when it does not happen. The legal minimums are real constraints and cut both ways: tax records generally carry a five-year ATO requirement and employee records seven years under the Fair Work regime, so delete-by-default has to respect the floor as well as enforce the ceiling.
The mechanism column is what separates a schedule from paperwork. If deletion means someone runs a script when they remember, data will outlive its schedule forever. Workable mechanisms are boring and structural: time-to-live policies where the platform supports them, tables partitioned by month so dropping aged data is a metadata operation rather than a risky delete, lifecycle rules on object storage and log platforms, and backup expiry aligned to the same clock. A retention policy that ignores backups is a fiction. The record is not gone until the last snapshot containing it has aged out.
Designing Collection Out of the Build
The stronger move sits upstream of retention: never create the record. Three patterns cover most cases. Derive rather than store: if a workflow needs to know a customer is over 18, store the verified outcome or an age band, not the date of birth. Verify and discard: when you sight an identity document, record that the check happened, who performed it and what it concluded, not an image of the document itself. Pseudonymise analytics: product metrics almost never need a real identity attached, and a stable random identifier answers the same questions without turning your analytics platform into a secondary customer database.
Logs deserve specific attention because they are collection at industrial scale, running every second without anyone deciding anything. Redact at the source with an allowlist of fields permitted to appear, rather than a denylist of things to strip, and scrub before log lines leave the process boundary. Then challenge collection at design review the way you would challenge scope creep. A newsletter form asking for a phone number, date of birth and street address fails the APP 3 necessity test on its face, and one design conversation prevents thousands of records of future liability.
The Compliance Dividend of Holding Less
Holding less reduces breach impact directly, but the second dividend is compliance load. Certification frameworks scope effort to what you hold. An SMB1001 assessment, an ISO 27001 Statement of Applicability, a customer security questionnaire or an insurer's proposal form all become shorter and more honest when the data inventory is small and the retention schedule demonstrably executes. And when an incident does occur, the 30-day NDB assessment becomes tractable, because you can state with evidence what was held, about whom, and for how long.
The practical takeaway is to run a collection audit this quarter. List every form, integration, log pipeline and export that captures personal information, apply the APP 3 necessity test to every field, and give each surviving data class a deletion mechanism with a named owner. Treat delete-by-default as an architectural stance rather than a cleanup chore. We fold this into compliance readiness and secure build work because it is the rare control that cuts risk and cost at the same time: absence needs no patching, no monitoring and no notification letter.
This note is general information, not legal advice on your obligations under the Privacy Act 1988.