For the person who just received a privacy request and has eleven systems to check

Customer Privacy Requests When the Data Lives in Eleven Systems

A customer emails to ask what personal information you hold about them. Or to fix a wrong address. Or to delete everything. In a business with one system, that is ten minutes of work. In a retailer or wholesaler running Shopify, a POS, an ERP, Klaviyo, HubSpot, a helpdesk, a loyalty platform, a 3PL portal and a payment gateway, it means searching each system in turn, and the integrations that normally save you time now work against you by copying the old address back over the new one.

This page is about the operational side: knowing which system holds what, verifying who is asking, compiling a response from every system in a reasonable time, making a correction stick, handling deletion requests honestly when tax law requires you to keep some records, and logging what you did. It is general information about the Australian Privacy Principles, not legal advice, and the law is changing, so confirm your obligations with a privacy adviser.

Book a Privacy Workflow Call (03) 9003 0111

The Shape of the Problem

8 to 15 systems

Holding customer details in a typical multichannel stack

Rough guide only. It varies widely once spreadsheets, shared inboxes and courier portals are counted

30 days

The OAIC generally expects for a response

The Principles say a reasonable period. Treat 30 days as the working target and confirm with your adviser

5 years

The ATO generally expects tax records kept

Companies must also keep financial records for 7 years under the Corporations Act, which is why a deletion request rarely means deleting the invoice. Confirm specifics with your accountant

APP 11.2

Destroy or de-identify what you no longer need

Australia has no general right to erasure, but this obligation applies to organisations the Privacy Act covers, unless a law requires the information to be kept

Why Privacy Requests Get Hard Once Systems Are Connected

The obligations are not new. What changes is how many places one customer exists, and how actively your integrations keep those places in step.

Nobody can list every place a customer exists

Ask a retail team where a customer record lives and you get three answers: the online store, the POS and the email platform. The real list also includes the ERP or accounting system, the helpdesk, the loyalty app, the reviews tool, the 3PL portal that stores delivery addresses, the courier account, the payment gateway, the shared returns spreadsheet and a sales rep mailbox. An access request answered from three systems is an incomplete answer, and you usually cannot tell it is incomplete until someone builds the list.

The clock starts when the request lands, wherever it lands

Requests arrive through the contact form, a reply to a marketing email, a helpdesk ticket, a store manager, a social message or a phone call to the warehouse. Under APP 12 and APP 13 an organisation has to respond within a reasonable period, and the OAIC generally expects that to be within 30 days. If the request sits in a store inbox for two weeks before anyone recognises it as a privacy request, most of that time is already gone.

Integrations quietly undo the work

You correct a misspelt name in HubSpot. Overnight the sync from Shopify, which still holds the old spelling, writes it back. You delete a contact in Klaviyo and the next order event recreates the profile. Integrations are built to keep systems consistent, and from their point of view a corrected or removed record looks like drift to be repaired. Unless correction and deletion are designed into the sync rules, the integration will reverse them.

The law does not say what customers think it says

Many customers expect a general right to be forgotten because they have read about the European rules. Australia does not currently have a general right to erasure of that kind. What the Principles do require, under APP 11.2, is that you destroy or de-identify personal information you no longer need for a permitted purpose, unless a law requires you to keep it. Responding well means explaining that difference plainly and doing what you genuinely can.

The Six Parts of a Workable Privacy Request Process

None of these need expensive software. Most of the value is in the map and the runbook, with integration work targeted at the two or three places it genuinely saves effort or prevents a mistake.

System by system register

Build the personal data map

A single table listing every system that holds customer personal information, what it holds (name, email, phone, addresses, order history, payment tokens, loyalty balance, support transcripts, notes), which system is the source for each field, which integrations copy it where, the search key you use to find a person, whether you can export, edit and delete through the admin screen, and who has access. For a typical retailer this is one or two days of work. It is also the document the rest of the process depends on, and it doubles as preparation for a data breach assessment.

Proportionate check

Verify identity before releasing anything

Sending a customer file to the wrong person is itself a privacy incident. Match the verification to the sensitivity: for a correction to a marketing preference, confirming control of the email address on file may be enough. For a full access request that includes addresses, order history and support transcripts, ask for something only the customer would know, such as a recent order number and the delivery postcode, and send the response only to contact details already on the record. Do not collect a copy of a driver licence unless you genuinely need it, because then you are holding identity documents you also have to protect.

Compiled response

Search every system in one pass

Using the data map, a staff member searches each system by email, phone and customer number and exports what they find into a single response folder. Where the volume justifies it, an integrated search can query the systems with an API in one step and assemble a readable summary, leaving only the systems without one, such as the courier portal or the returns spreadsheet, for a manual check. The output should be in plain language: what you hold, where it came from, what it is used for, and who you share it with, not a raw database dump the customer cannot read.

Corrected at the source

Make corrections stick

The rule is simple: correct the field in the system the integration treats as the source for that field, then let the integration carry it outward, then check the downstream systems the next day. If the source is Shopify, editing the address in the ERP achieves nothing for long. Where a field is two way synced, confirm which side wins. APP 13 also expects you, if the customer asks, to take reasonable steps to tell other organisations you previously disclosed the information to, which can include your 3PL or a wholesale partner.

Delete, de-identify or retain

Handle deletion with retention in mind

For each system, decide in advance what a deletion request means. Marketing profiles, loyalty accounts, reviews and support transcripts can often be deleted outright. Order and invoice records needed for tax usually cannot, but the customer name can sometimes be de-identified in the commerce platform while the financial record in the accounting system is kept. Suppression entries are a special case: keeping a hashed email on a do not contact list is what stops the address being marketed to again, so removing it entirely can work against the customer.

Request register

Log every request and outcome

A simple register: date received, channel, request type, identity check performed, systems searched, actions taken in each, date responded, any refusal and its reason, and who handled it. It lets you show what you did if the customer complains to the OAIC, it shows where the process is slow, and over a year it tells you whether volume justifies more automation. Keep the register minimal so it does not become another store of personal information.

Common Requests and How They Should Be Handled

Task	Traditional	Done Properly	Notes
What do you hold about me	Export from the online store only	Every mapped system searched and summarised	Include support transcripts, loyalty history and addresses held by the 3PL. Those are the ones most often missed.
Fix my wrong address	Edited where the customer complained	Edited at the source, checked downstream	The classic failure is editing the helpdesk copy and watching the sync restore the old one overnight.
Delete my account	Deleted in one system, recreated by the next order sync	Deleted, de-identified or retained per system, with reasons	Explain what is kept for tax and why. Customers accept a clear reason far better than silence.
Stop emailing me and forget me	Profile deleted, address later reimported	Suppression retained, profile removed	Unsubscribe mechanics belong on the consent page linked below. Here the point is not to delete the suppression itself.
Request from a partner or parent	Answered because they sounded legitimate	Authority confirmed before anything is released	Third party requests need evidence of authority. When unsure, respond to the customer directly using contact details on file.
Former wholesale buyer contact	Ignored as not a consumer	Handled like any individual	Business contacts are individuals too. Their name, mobile and email in your ERP and CRM are personal information.
Request from a former staff member	Routed to the customer process	Referred for advice first	Employee records are treated differently under the Privacy Act. Get advice rather than applying the customer runbook.
Request mentioning a data breach	Answered as a routine access request	Escalated to the breach process	If the customer suspects their data was exposed, that triggers an assessment, not just an access response.

Where Privacy Request Handling Goes Wrong

Answering from the systems you remember

An access response built from the online store and the email platform leaves out the helpdesk transcripts, the loyalty history and the delivery addresses in the 3PL portal. The customer may already know you hold those, because they gave them to you. Work from the data map every time, and record which systems were searched so a gap can be seen and fixed rather than repeated.

Releasing data to the wrong person

Shared family email addresses, former partners, and people impersonating a customer to find a home address are real scenarios for retailers. An identity check proportionate to what you are about to release, and delivery only to contact details already on the record, prevents the worst outcome. A wrongful release may itself be a breach you need to assess under the notifiable data breaches scheme.

A correction that the integration reverses

If the corrected field is not the source of truth, the next sync restores the old value and the customer finds the mistake again on their next parcel. Document the source system for each personal field in the data map, correct there, and check every downstream system a day later. If two systems both write the same field, fix that design problem, because it will also cause errors that have nothing to do with privacy.

Deleted records resurrected by integrations

Deleting a Klaviyo profile while Shopify still holds the customer means the next order or abandoned cart event recreates it. Deleting in HubSpot while the helpdesk sync still pushes contacts back does the same. Deletion has to start at the source, propagate through every connected system in a deliberate order, and leave a suppression or tombstone marker where needed so the integration knows not to recreate the record from a stale copy.

Promising a deletion the law will not let you make

Tax records, records relevant to warranty claims or consumer guarantee disputes, and records subject to a legal hold may need to be kept. Telling a customer that everything has been deleted when the invoices are still in Xero or MYOB is worse than explaining the position honestly. Describe what was deleted, what was de-identified, what is kept, for what purpose and roughly for how long, and confirm the retention periods with your accountant or adviser.

Assuming the small business exemption applies

Businesses with annual turnover of 3 million dollars or less are generally exempt from the Privacy Act, but there are exceptions, such as businesses that trade in personal information or provide health services, and a small business related to a larger company that the Act covers is covered too. Turnover also grows, and Privacy Act reforms are ongoing, including proposals about the exemption itself. Get advice on your position, and in any case a working process protects your customer relationships whether or not it is legally required.

How Yes AI Helps With Privacy Requests Across Systems

We build the personal data map from the integrations outward

Because we work in the plumbing, we can see which systems hold which personal fields, which integrations copy them where, and which direction each sync runs. That produces a more complete map than a staff survey, and it surfaces the forgotten places such as courier accounts and export files sitting in shared drives.

A runbook your team can follow without us

A step by step process for access, correction and deletion requests, written for the customer service lead rather than a lawyer, with the identity check, the systems to search in order, the source system for each field and a response template. We work alongside your privacy adviser on the legal content rather than replacing them.

Integration changes so corrections and deletions hold

We adjust sync rules so corrections flow from the source, add tombstone or suppression handling so deleted customers are not recreated, and where request volume justifies it, build an integrated lookup that compiles results from every API connected system. These run on a managed cloud automation layer we operate, with logging.

An honest view of how much to automate

If you receive five requests a year, a well maintained data map and runbook is usually the right answer, and we will say so. If you receive many, or your systems make manual search slow, targeted automation of the search and the deletion cascade can make sense. We size it to your actual volume.

From First Request to a Repeatable Process

Five steps. The map and runbook typically take two to four weeks, and any integration changes follow from what the map reveals.

Map every system and every flow

We list each system holding customer personal information, the fields it holds, the source of truth for each field and every integration that moves them. Spreadsheets, inboxes and partner portals included.

Agree identity checks and intake

One intake point for privacy requests, a way for staff in stores and the warehouse to recognise and forward them, and identity checks proportionate to what will be released.

Write the runbook and retention rules

Per system: how to search, export, correct, delete or de-identify, and what must be kept and why. Retention periods are confirmed with your accountant and privacy adviser before anything is deleted.

Fix the sync rules and train the team

Corrections flow from the source, deletions cascade without resurrection, and the people handling requests practise on a test record before a real one arrives.

Log, review and keep the map current

Every request goes in the register. The map is updated whenever a system is added or removed, and the process is reviewed at least yearly or when the law changes.

FAQ

How long do we have to respond to a customer privacy access request?

The Australian Privacy Principles require an organisation to respond to an access request under APP 12, and a correction request under APP 13, within a reasonable period. The OAIC generally expects organisations to respond within 30 days. Complex requests may take longer, in which case it is sensible to tell the customer early and explain why. The practical lesson for a multi system business is that the clock runs from when the request arrives, so staff in every channel need to recognise a privacy request and forward it quickly.

Can we charge a customer for an access request?

Generally an organisation cannot charge a customer for making an access request, and cannot charge for correcting information. It may be able to charge a fee for giving access, but the fee must not be excessive, and many businesses choose not to charge at all because the request volume is low. Check the current position with your privacy adviser before setting a fee.

Does a customer in Australia have a right to have their data deleted?

Australia does not currently have a general right to erasure like the one in European law. However, APP 11.2 requires an organisation to take reasonable steps to destroy or de-identify personal information it no longer needs for any permitted purpose, unless a law or court order requires it to be kept. In practice, when a customer asks for deletion, most businesses delete or de-identify what they genuinely no longer need, keep what they must for tax and other legal reasons, and explain the difference.

We have to keep invoices for tax. How do we handle a deletion request?

The ATO generally expects business records relevant to tax to be kept for 5 years, and companies must keep financial records for at least 7 years under the Corporations Act 2001, so invoices and the financial transactions behind them usually stay. What can often go is everything around them: the marketing profile, the loyalty account, saved addresses, support transcripts once any dispute window has passed, reviews and analytics identifiers. In some commerce platforms the customer can be de-identified while the order record remains. Confirm with your accountant which records must be kept in which system and for how long, then write that into your deletion runbook.

Why does a customer we deleted keep reappearing?

Because an integration recreated them. Most syncs are designed to make sure every system has every customer, so if the record still exists in the source system, or a new event such as an order or a support ticket arrives, the profile is rebuilt downstream. The fix is to delete or de-identify at the source first, cascade through the connected systems in a deliberate order, and keep a suppression or tombstone marker that tells the integration not to recreate that person from stale data.

Does the small business exemption mean we can ignore this?

Businesses with annual turnover of 3 million dollars or less are generally exempt from the Privacy Act, but there are exceptions, including businesses that provide a health service or trade in personal information, businesses that provide services under a Commonwealth contract, and businesses that opt in. Privacy Act reforms are ongoing and the exemption has been under review, so get advice on your current position. Separately, customers expect a sensible answer regardless, and a business that cannot find or correct a customer record has an operational problem as much as a legal one.

How does this relate to the notifiable data breaches scheme?

They are separate obligations that share the same foundation. Under the notifiable data breaches scheme, an organisation covered by the Privacy Act must notify affected individuals and the OAIC when an eligible data breach is likely to result in serious harm, and must assess a suspected breach promptly. The personal data map you build for privacy requests is the same map you need to work out what was exposed in a breach. Also note that releasing a customer file to the wrong person while answering a request can itself be a breach that needs assessing.

Know Where Every Customer Record Lives Before the Next Request

Book a call. We will map which of your systems hold customer personal information, how the integrations move it, and where a correction or deletion would currently fail. The map is yours either way.