Is a privacy impact assessment mandatory?

For most private businesses, it is strongly recommended rather than mandatory. Australian Government agencies have specific requirements for high privacy risk projects. The OAIC's guide sets out a ten-step process that any organisation can adapt to the size and risk of its project.

How long should we keep personal information?

There is no single universal period. Keep information as long as you need it for the purposes you collected it for and as required by law, such as tax record keeping, which is generally five years for most business records. If you are covered by the Privacy Act, APP 11.2 requires reasonable steps to destroy or de-identify personal information you no longer need, unless a law requires you to keep it.

What about backups when deleting data?

Deleting from the live system does not remove data from backups immediately. A common approach is to let backups expire on their normal schedule, prevent deleted data from being restored into live systems, and document this in your retention policy. Design restore processes to re-apply deletions.

What is a legal hold?

A legal hold suspends deletion of specific records because they may be needed for litigation, investigations or regulatory requests. Retention systems should let authorised people place and release holds on specific records, override scheduled deletion while a hold applies, and log every action.

Is privacy by design a legal requirement in Australia?

The Australian Privacy Principles require covered organisations to take reasonable steps to implement practices and systems that ensure compliance, which the OAIC links to privacy by design. The engineering practices in this guide support those obligations, but whether you comply depends on your circumstances; get legal advice.

Do Australians have a right to have their data deleted?

Not as a general right under the current Privacy Act. Individuals can request access (APP 12) and correction (APP 13), and APP 11.2 requires organisations to destroy or de-identify personal information they no longer need. A right to erasure for large digital platforms is proposed in the 2026 exposure draft reforms, which had not been introduced to Parliament at the time of writing.

Web Development6 min read

Privacy by Design in Software Development: Data Minimisation, Retention and Deletion for Australian Organisations

Privacy by design for Australian software: privacy impact assessments, data minimisation, permissions, retention and deletion, legal holds and logging.

What does privacy by design look like in practice?

Privacy by design means deciding, before building, what personal information a product needs, why, who can access it, how long it is kept and how it is deleted, and then building those decisions into the software: minimal collection, privacy-friendly defaults, role-based access, retention rules, deletion workflows that cover backups and legal holds, and logs that avoid unnecessary personal data. A privacy impact assessment is the usual starting point.

This guide is for product owners, architects and developers in Australia. Engineering recommendations here support, but do not replace, legal obligations; where the Privacy Act applies, get advice on your specific obligations. For security controls, see secure web application development.

Key takeaways

Run a privacy impact assessment early; start with a threshold assessment.
Collect only what each feature needs, and say why.
Make privacy-friendly choices the defaults.
Restrict access by role and log access to sensitive records.
Define retention per data type, with legal holds and automated deletion.
Handle backups and logs in the retention design.

Step 1: Privacy impact assessment

The OAIC's guide to privacy impact assessments sets out ten steps: threshold assessment, plan, describe the project, consult stakeholders, map information flows, analyse privacy impacts and compliance, manage risks, make recommendations, report, and respond and review (OAIC). Scale it to the project: a short threshold assessment for small changes, a full PIA for new products handling sensitive information.

Step 2: Minimise and set defaults

List each field and the purpose it serves; remove fields without one.
Prefer less identifying data: age range instead of date of birth, suburb instead of full address, where that is enough.
Make optional fields clearly optional and off by default for marketing consent.
Keep sensitive information (health, financial hardship) separate with stricter access.
Avoid sending personal information to analytics and advertising tools; see product analytics implementation.

Step 3: Permissions and logging

Use role-based access with record-level rules where needed, and review access regularly. Log access to sensitive records and administrative actions, without writing personal information into application logs unnecessarily. Mask data in non-production environments. These steps support APP 11's requirement to take reasonable steps to protect personal information (OAIC).

Step 4: Retention and deletion workflows

Retention is where many systems fail: data accumulates forever. Build retention into the data model.

Component	What to build
Retention schedule	Retention period per data type, with the reason (business need or legal requirement)
Triggers	Events that start the clock: account closure, end of contract, last activity
Deletion or de-identification jobs	Automated, logged, reversible only within a short window
Legal holds	Authorised holds on specific records that suspend deletion
Backups	Expire on schedule; restores re-apply deletions
Audit trail	What was deleted, when, under which rule, by which process

Worth noting

There is no universal retention period. Tax and business records are generally kept for five years (business.gov.au), other laws set their own periods, and where the Privacy Act applies, APP 11.2 requires destroying or de-identifying personal information you no longer need. Confirm periods for your records with your advisers.

Step 5: Rights requests and transparency

Build tools to find all records about a person across systems, so you can respond to access (APP 12) and correction (APP 13) requests and apply deletions consistently. Keep privacy notices accurate as features change, and prepare for automated decision transparency obligations from 10 December 2026 if your software makes or supports significant decisions about people. See AI governance and customer data integration.

Hypothetical example

This example is hypothetical. A tutoring marketplace runs a threshold assessment for a new feature that records lessons. The PIA concludes recordings are sensitive, so they are off by default, require parent consent for under-18 students, are visible only to the student, parent and tutor, and are deleted 90 days after the lesson unless a complaint places a hold. Backups expire within 35 days, and restore scripts re-apply deletions. Access to recordings is logged.

Common mistakes

Collecting data 'in case it is useful later'.
No retention rules, so everything is kept forever.
Deletion that ignores backups, logs and analytics copies.
Production personal data copied into test environments.
Privacy reviewed after launch rather than before design.

For related guides, see digital forms development, business continuity for backups and retention, and cyber incident response planning.

Handling access, correction and deletion requests in Australia

If the Privacy Act applies to you, individuals can ask for access to their personal information (APP 12) and for it to be corrected (APP 13). There is currently no general right to erasure in the Act, but APP 11.2 requires reasonable steps to destroy or de-identify personal information you no longer need, so many deletion requests can be handled through your retention rules.

The government released an exposure draft of further reforms (the Privacy Amendment (Personal Data Protection) Bill 2026) on 31 August 2026, proposing changes including a fair-and-reasonable test and a right to erasure for large digital platforms. At the time of writing it had not been introduced to Parliament, so treat these as proposals, not obligations, and check the current position.

Verify the requester's identity proportionately before releasing or changing data.
Keep a request log with dates, decisions and reasons.
Build a data map so requests reach every system, including integrations.
Use templates for responses and refusals with reasons.
Get advice on timeframes and exceptions for your organisation.

Request	Basis today	What the software should support
Access	APP 12	Find all records for a person across systems, export them in a readable form, record the response
Correction	APP 13	Update records everywhere they are held, note disputed corrections, notify recipients where required
Deletion	APP 11.2 (no longer needed); your policies	Delete or de-identify across systems and backups according to retention rules; explain what must be kept

Conclusion

Privacy by design is mostly about decisions made early and built into the system: what to collect, who can see it, how long to keep it and how to delete it. Start with a PIA, minimise and set protective defaults, control and log access, and engineer retention and deletion properly, then confirm legal obligations with advisers. For UK access requests under UK GDPR, see subject access request automation in the UK.

Designing privacy into a new product?

ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on privacy-conscious web applications, mobile apps and AI systems. If it would help to work through retention and access design, we are happy to talk it through.

Start a Project

FAQ

Common questions.

Privacy by design means building privacy protections into products and processes from the start rather than adding them later. The OAIC describes it as designing privacy compliance into projects that handle personal information from the beginning, and recommends privacy impact assessments as the way to understand a project's privacy effects before building.