When an access request reaches your analytics

The OPC's guidance for businesses sets out the obligation in a list rather than a paragraph. Subject to defined exemptions, an organisation must inform requesters whether it holds the personal information they are asking for, explain how it is or has been used, and provide a list of any organizations to which it has been disclosed on request, give access at minimal or no cost in a form that is generally understandable, and respond within 30 calendar days.

That second item is the one marketing operations underestimate. It is not only produce the record. It is explain the use and, on request, name the organisations the data went to. In a modern stack the data went to a lot of organisations.

The same guidance forecloses the obvious workaround: you cannot simply acknowledge within 30 days that you received the request and then take more time to actually deal with it. An acknowledgement is not a response.

One extension exists. The guidance says the 30-day limit may be extended only where responding would interfere to an unreasonable degree with your activities, would require consultations that make the deadline impracticable, or where an alternate format conversion takes significant time. In those cases you may take up to 30 additional days, and you must contact the individual within the first 30 days to explain the delay and to advise them of their right to complain to the Privacy Commissioner.

Volume is not on that list. Neither is having data spread across nine systems. The disorganisation is your problem, not the requester's.

The scope question resolves earlier than most teams expect. The OPC's position in its behavioural advertising guidelines is that information involved in online tracking and targeting for the purpose of serving behaviourally targeted advertising will generally constitute personal information, because there will often be a serious possibility that it could be linked to an individual.

So the defence that an analytics property only holds a pseudonymous identifier is weaker than it sounds, particularly once that identifier has been joined to anything. The identifiability test explicitly contemplates information in combination with other available information.

The right column above is mine, not the regulator's. It is where the work actually goes. In every access exercise I have run, the time is not spent on the CRM. It is spent on the systems nobody listed.

Free-text fields deserve their own warning. A note field on a lead record is where opinions about a person live, and the OPC's bulletin on personal information records that the same information can be personal to more than one individual, where for example it contains the views of one individual about another. Those fields are rarely reviewed before an export goes out.

The guidance lists them explicitly, and the marketing-relevant ones are few. Access may be denied where disclosure would reveal personal information about someone else, though if the third-party information can be severed you are required to provide the rest. Solicitor-client privilege applies. Confidential commercial information applies, again subject to severing where possible.

Confidential commercial information is the one people reach for, and it does not do what they want. The OPC's access bulletin summarises the case law bluntly: the standard for justifying the withholding of personal information because it would reveal confidential commercial information is very high, providing access upon request is the rule and withholding is the exception. The same bulletin records that raw data about an individual, meaning information whose disclosure would not reveal confidential practices, techniques or analysis of a commercial nature, does not fall within that exemption at all. If part of a record is genuinely commercially confidential, you sever that part and release the remainder.

The guidance also says that where you apply an exemption you must give the requester a written explanation of your decision, set out the reasons, and inform the individual of their right to complain to the Privacy Commissioner. A silent redaction is not a compliant one.

This is a good moment to be clear about the boundary of this article. It describes what the published guidance says and how it lands on a marketing stack. It is not legal advice, and whether a specific exemption applies to a specific record is exactly the sort of question to put to counsel rather than to resolve from a blog post.

A system map. One row per system that could hold personal information, the lookup key it supports, who has access to export from it, and roughly how long an export takes. Six systems at twenty minutes each is a manageable afternoon. Six systems where nobody knows the export path is a 30-day problem.

An identity resolution note. The practical obstacle is that requests arrive with an email address and half your systems key on something else. Write down how you get from an email to an analytics identifier, and whether you can at all. Where you have deliberately hashed an identifier, be honest in the map about what that does and does not let you do; that is the subject of what hashing does and does not protect.

A disclosure list. The obligation includes naming organisations the data was disclosed to on request, and that list has to come from somewhere. If you already maintain a vendor register for data processing agreements with martech vendors, the disclosure list is a view over it rather than a new artefact.

A named owner and a route in. The guidance notes that a request has to be in writing and that you may need to verify identity, and it tells you to record the date you received it. All three of those fail when a request lands in a shared inbox that a coordinator triages on Fridays.

And a rehearsal. Pick a real person who converted last month, and try to produce everything you hold about them. Time it. That number is your actual access posture, and it is usually the first time anyone in the organisation learns what the answer is.

A warehouse makes access requests easier and harder at the same time, and it is worth being precise about which.

Easier, because a well-modelled warehouse is the only place where a single query can span sources. If your identifier resolution is done once, in one place, then producing a person-level extract is a query rather than a scavenger hunt. That is a real argument for centralisation that has nothing to do with reporting speed, and it is one of the reasons a marketing data warehouse earns its keep beyond dashboards.

Harder, because a warehouse multiplies copies. Raw landing tables, staged tables, snapshots, materialised views and the extracts somebody scheduled to a spreadsheet in 2025 are all separate holdings, and a response that covers the modelled layer while missing the raw layer is incomplete.

The mitigation is a lineage habit rather than a tool. If every table records where it came from and what it is for, the set of places a person's data can be is finite and knowable. If it does not, the honest answer to an access request is a guess.

Multi-location businesses feel this hardest, because the same person can appear under several location records and the combined view is more identifying than any one of them. The reporting work behind a fifteen location clinic group is a fair illustration of how quickly per-location data becomes a person-level dataset once it is centralised, and how much easier the question becomes once the join is defined in one place.

The access right has a second half. The guidance says requesters may challenge the accuracy and completeness of the information you hold and have it amended where they show it is inaccurate or incomplete, and that where appropriate the amended information has to be sent on to parties you disclosed the original to.

In a marketing stack, that last clause is the difficult one. If a corrected record has already been uploaded into an ad platform audience, syndicated to a partner, or pushed into a warehouse that feeds a partner report, correction is a pipeline problem rather than a record edit.

The guidance also covers the disagreement case: if you and the requester cannot agree on the need for an amendment, you make a record of the unresolved challenge and, where appropriate, pass that record to third parties the original was disclosed to. A dispute you decline is still something you have to carry.

Design for this at the point where data leaves your systems rather than at the point where a correction arrives. Every outbound sync should be repeatable and keyed, which is the same property that makes idempotent loads and safe reruns worth building in the first place. A sync you cannot re-run is a correction you cannot propagate.