21 October 2026 · Conversational AI

Data Deletion Requests in Australia: What Your Business Must Do

Australia has no general right to erasure, but APP 11.2 still shapes how you handle deletion requests. Here is a practical guide for enterprise teams.

Australia has no general “right to be forgotten”. A customer can ask you to delete their personal information, but the Privacy Act 1988 (Cth) does not give them an absolute right to have it erased. What it does give them is an organisation that must destroy or de-identify personal information once it is no longer needed, unless a legal exception applies. That duty is the real driver of every deletion request you will handle, and it applies whether or not anyone asks.

This guide is for enterprise IT, privacy and operations managers. It explains what the law requires, how to build a workable deletion process, and where AI-driven channels such as voice, SMS, email and chat make the job harder or easier.

TL;DR

There is no GDPR-style right to erasure in Australia today. APP 11.2 requires reasonable steps to destroy or de-identify personal information you no longer need, unless you must keep it by law.
A deletion request is best treated as a trigger to test whether you still need the data, then to act, document and reply.
Backups, archives, email accounts and call recordings count. Plan for them from the start.
Reform is moving toward a right to seek erasure, so a process built now is cheaper than one rushed later.
Aim to respond within 30 days. It is a benchmark, not a statutory deadline.

Is there a right to erasure in Australia?
What the law asks of you when a request arrives
Destroy, de-identify or put beyond use?
The hidden problem: backups, archives and inboxes
A deletion request process that holds up
Why a retention policy beats ad hoc deletion
Where reform is heading
Our perspective: deletion starts with where your data lives
How automation can help you handle requests
Quick checklist for your next quarter
FAQ
Sources

Is there a right to erasure in Australia?

Not in the way Europe has one. The OAIC’s own guidance for Australian entities dealing with the GDPR notes that the GDPR gives people a right to require deletion in certain circumstances. The Privacy Act has no equivalent, but APP 11.2 requires an entity that holds personal information to take reasonable steps to destroy it or ensure it is de-identified. Justice Connect’s guide to requesting deletion explains the same point from the individual’s side. A person can ask, and an organisation has to think carefully, but the person cannot simply demand.

In practice, this means three things for your business:

The duty is yours, not the customer’s. You must destroy or de-identify information once it is no longer needed for any purpose the APPs allow you to use or disclose it for. A customer’s request is strong evidence that you should look again at whether you still need it.
Legal retention overrides deletion. If an Australian law or a court or tribunal order requires you to keep the information, APP 11.2 does not require you to destroy it.
Other regimes may apply. If you also handle data of people in the EU, GDPR obligations may sit on top. Our GDPR versus Australian Privacy Act checklist maps the differences for compliance teams. Sector rules, such as those in the Consumer Data Right framework, carry their own obligations.

What the law asks of you when a request arrives

The OAIC’s guide to securing personal information sets the test: take reasonable steps to destroy or de-identify once the information is no longer needed for any permitted purpose. “Reasonable” depends on your circumstances, including the sensitivity of the data, the volume you hold, and how hard destruction is in your systems. The OAIC’s APP 11 guidelines also point to verifying and documenting when and what personal information is destroyed or de-identified. Treat that record as part of the job.

For each request, work through four questions:

Do we still need it? Check every purpose: service delivery, billing, dispute handling, fraud prevention.
Must we keep it? Look for statutory retention periods, such as tax, corporate or health records rules relevant to your sector.
Can we destroy it, or only de-identify it? Both satisfy APP 11.2 when done properly.
What do we tell the person? If you keep some data, explain the category and the reason in plain language.

What about the timeline?

The current Privacy Act sets no statutory deadline for responding to a deletion request. The OAIC’s exposure draft of the Children’s Online Privacy Code includes a formal request-to-destroy process for personal information about a child. It is a draft and applies only to certain services, but it is a fair signal of where expectations are heading. Our advice is to adopt a 30-day target as your internal standard, tell the person early if you need longer, and keep a log of the dates.

Destroy, de-identify or put beyond use?

Three outcomes are realistic. Choosing among them is where most enterprise teams get stuck.

Option	What it means	Best used when	Watch out for
Destruction	Information is irretrievably deleted	You have no purpose or obligation to keep it	Copies in backups, logs, email and exports
De-identification	Information no longer relates to an identifiable person	The dataset still has analytical value	Re-identification risk must be very low
Put beyond use	Access is restricted, logged and audited so the data is effectively siloed	Legacy systems where full destruction is not technically possible	Needs real controls, not just a policy statement

De-identification is a process, not a rename

The OAIC’s guidance on de-identification and the Privacy Act makes clear that stripping out names is rarely enough. You need to remove direct identifiers and apply technical and contextual controls so the risk of re-identification is very low. A transcript with the name removed but the address, employer and unusual circumstances intact is still personal information.

When you cannot delete

Some older systems cannot delete a single record without breaking something else. In those cases, the OAIC’s guidance recognises putting information beyond use as a legitimate approach. That means restricting access, logging every touch and keeping an audit trail. It is a fallback for genuine technical limits, not a way to avoid the work. Record why destruction was not possible and review the decision when you next upgrade the system.

The hidden problem: backups, archives and inboxes

Most failed deletions are not in the main database. They sit in the places nobody thinks about:

backup tapes and cloud snapshots
archived email and shared mailboxes
exported spreadsheets and BI extracts
call recordings and chat transcripts
test and staging environments loaded with production data
vendor systems, including outsourced contact centres and AI tools

Backups and archives fall under the same obligation as live systems. That matters beyond deletion requests. Ghost data that you should have destroyed will still count in a breach. The OAIC’s Notifiable data breaches report for July to December 2023 reminds entities of their APP 11.2 obligations to destroy or de-identify information they no longer need. If a breach hits old data, you may have to assess and potentially notify about information you never needed to keep. Our guide to notifiable data breaches for compliance teams covers that assessment, and real examples of breach consequences show what it costs.

The practical fix is to build destruction, or the ability to put data beyond use, into backup rotation at design stage. Retrofitting it after a request lands is slow and expensive.

A deletion request process that holds up

Here is a workable sequence for an enterprise team.

Receive and log. Accept requests through every channel your customers use: web form, email, phone, SMS, chat. Log the date and channel on day one.
Verify identity. Confirm the requester is the person, or an authorised representative, before you disclose or delete anything. Proportion the checks to the sensitivity of the data.
Locate the data. Search every system, including the hidden places listed above. A current data map makes this a task of hours rather than weeks.
Assess need and retention. Apply the four questions above. Involve legal for any record with a statutory retention period.
Act. Destroy, de-identify or put beyond use. Instruct vendors to do the same for data they hold for you.
Document. Record what was done, when, by whom, and what was kept and why.
Reply. Tell the person the outcome in plain language, ideally within 30 days. If you refuse or only partly comply, explain, and point to the avenues for complaint, including the OAIC.

Two cautions. First, a refusal should rest on a documented reason, such as a legal retention requirement, not on inconvenience. Second, if the person is also asking what you hold about them, that is a separate access request, so handle the two together but track them separately.

Why a retention policy beats ad hoc deletion

The cheapest deletion request is the one that needs almost no work, because the data was already gone. The OAIC treats regular auditing of data stores as part of systemic compliance under APP 1.2, and a retention schedule is how you make that real. A schedule assigns each data category a purpose, a retention period and a destruction method, and it lowers the damage if you suffer a security incident. There is less data to leak, and less to assess afterwards.

If you run chatbots or voice agents, the transcripts and recordings they generate need their own schedule. Our 30 day chatbot retention plan aligns with OAIC and National Archives guidance. Call recordings bring further rules, which we cover in our guide to call recording compliance in Australia.

Where reform is heading

The 2023 Privacy Act Review Report proposed improving individuals’ control over their personal information, including a right to seek erasure, and strengthening the requirement to destroy or de-identify information when it is no longer needed. According to a 2026 legal summary of the reform program, the first tranche of reforms is law, including a statutory tort for serious invasions of privacy, while a second tranche has been promised but no bill had been introduced when that article was written. Check the current status before you finalise your plans.

For enterprise managers, the direction is clear enough to plan around. A model based on “no longer needed” is likely to be joined by something more consumer-driven. Businesses that already log requests, map data and document destruction will adapt with a policy update. Businesses that do not will face a rebuild.

Our perspective: deletion starts with where your data lives

We build a private cloud conversational AI platform hosted entirely in Australia, and we see the same pattern in the enterprises we speak with. Deletion requests are rarely hard because of the law. They are hard because nobody can say with confidence where a customer’s data has gone.

Our perspective: deletion starts with where your data lives — overview diagram

A voice call becomes a recording, a transcript, a CRM note and an automated follow-up SMS. If those pieces sit across several vendors, some of them offshore, a single request becomes a hunt across jurisdictions. That is why we argue that data sovereignty is a deletion issue as much as a security one. When your data stays in one Australian environment under your control, you can find it, restrict it and destroy it, and you can prove you did. Our guides on Australian data sovereignty and preventing offshore data transfers set out the questions to put to any vendor.

Our advice to IT and operations leaders is simple. Decide retention periods before you deploy a new channel, not after. Ask every vendor how a single person’s records are removed, and ask to see it done. And treat the 30-day response as a design requirement for your systems, not a target for your staff to hit by heroics.

— Sowrabh

How automation can help you handle requests

Automated channels create data, so they should also help you manage it. A conversational AI platform can take a deletion request by voice, SMS, email or chat, log it with a timestamp, check the requester’s identity and route it to your privacy team with the CRM record attached. Done well, that shortens the “receive, log and locate” steps and leaves people to make the judgement calls.

Deletion request intake and routing workflow

Our platform runs voice, SMS, email and live chat agents integrated with your CRM, hosted in Australia, with SOC 2 certification. For organisations that need tighter control still, we offer on-premises deployment. If you work in a regulated sector, see how it applies in healthcare or banking and finance, or explore the full platform and book a conversation with our team.

Quick checklist for your next quarter

Write down who owns deletion requests and who covers when they are away.
Build or refresh your data map, including vendors, backups and recordings.
Publish a retention schedule with a purpose, period and method per data category.
Test one end-to-end deletion in a live-like environment and time it.
Add destruction or put-beyond-use steps to backup rotation.
Check contracts so vendors must act on your deletion instructions.
Review the position on reform before each planning cycle.

FAQ

Can a customer force my business to delete their data in Australia?

Not under a general right to erasure, because the Privacy Act does not provide one. However, APP 11.2 requires you to take reasonable steps to destroy or de-identify information you no longer need, unless you must keep it by law. A customer’s request often prompts exactly that review, so you should treat it seriously and respond in writing.

How long do I have to respond to a deletion request?

There is no statutory timeframe in the current Privacy Act. The exposure draft of the Children’s Online Privacy Code shows the direction of regulatory thinking for children’s data. As a sensible internal standard, aim to respond within 30 days and tell the person early if a complex request needs longer.

Is de-identifying data the same as deleting it?

For APP 11.2 purposes, either can meet the obligation, but de-identification must be done properly. The OAIC expects direct identifiers to be removed and the risk of re-identification to be very low. Removing a name from a record that still contains other identifying details usually will not be enough.

Do backups and archives have to be deleted too?

They fall under the same obligations as live systems. If irretrievable destruction is not technically possible, putting the data beyond use, with restricted access and audit trails, is a recognised alternative. Build that into your backup rotation so you are not improvising when a request arrives.