The Request Arrives at the Help Desk
A consumer privacy request does not arrive through a privacy console. It arrives as a support ticket, from somebody who has never logged in. Our help desk can identify that person and put a clock on the reply — and our export and erasure tooling is built around user accounts, which is the one thing they do not have.
The email says: please tell me what information you hold about me, and then delete it. It does not cite a statute, it is not addressed to a privacy officer, and it does not arrive anywhere special. It lands in support, between a delivery query and a complaint about a damaged box, and from that moment a period is running whether or not anybody has noticed.
This is a North American post because the pattern is now unavoidable there — California's law started it and several states have since passed their own — and because the operational consequence is the same wherever you are: the obligation lands on the help desk, and the help desk is not usually where the tooling is.
Nothing here says whether any of it applies to you. Coverage turns on your revenue, how many people's data you handle, where they live and what sector you are in, and it differs between states. That is your counsel's determination. What follows is about where a request lands and what your records can do about it, which is a question you can answer yourself.
What California actually requires, and of whom
The state's Attorney General sets out the shape plainly. A consumer is a natural person who is a California resident — a human being, not a company, and still a resident if they are temporarily elsewhere. That person may ask to know what is collected about them and how it is used, ask for it to be deleted, ask for it to be corrected, opt out of its sale or sharing, limit the use of sensitive information, and not be penalised for having asked.
A business has 45 calendar days to respond, extendable by a further 45 if it tells the consumer. Ninety days at the outside, and the outside is only available to somebody who noticed the first period and acted inside it.
The word doing the work is "natural person"
Not user. Not account holder. Not customer, even. A person who filled in a form, bought something once at a counter, or emailed to ask a question is a natural person whose data you now hold, and none of those acts creates a login. So the population that can send you one of these requests is strictly larger than the population your software knows how to look up — and for most businesses it is larger by an order of magnitude.
Where the request lands, in our product
Our help desk turns out to be well suited to receiving one, which is worth saying before the part that is not.
A ticket can name its requester in several ways: a user with a login, an employee, a customer record, or — and this is the useful one — just a name and an email address, with no underlying record at all. Somebody who has never bought anything and never registered can raise a ticket and be identified on it. That is exactly the shape a privacy request has.
A ticket also carries a first-response deadline, a resolution deadline, and a breach notification. So the machinery for "this must be answered by a date, and somebody must be told if it is not" exists and runs today.
And then it pauses
The ticket clock can be paused. That is correct behaviour for a service-level target — when you are waiting on the customer for information, most support organisations stop the clock, and any other design punishes the team for somebody else's delay.
It is the wrong behaviour for a statutory period. A legal deadline does not stop because you asked a question and are waiting for a reply. Identity verification is a legitimate and often necessary step, and the days it consumes are still days. So the one clock in our product that could carry this obligation is a clock designed to be stoppable, which means a ticket can be inside its target and outside the period at the same time — and the field that would tell you so does not exist.
A service target pauses. A statutory period does not. Ours is the first kind.
The part that is pointed the wrong way
We do have data export and erasure tooling. It is real: it assembles what is held, it writes an audit record of the request and of the action, and erasure overwrites the identifying fields rather than dropping a row and leaving dangling references. For what it covers, it is better than most.
What it covers is users. Both operations take a user account and every lookup inside them runs on the user identifier — sessions, activity history, the columns recording who did what. It is built, end to end, around somebody who can log in.
Customers, in our schema, have no user account. There is no column linking a customer record to a login, because a customer is a party you trade with rather than somebody who signs in. That is a reasonable model and it is almost certainly the right one. It also means the export and erasure tooling cannot be pointed at a customer at all — not "does it partially", not "needs a flag switched on". The function signature takes a user, and a customer cannot be turned into one.
| Who sends these requests | What our tooling can do for them |
|---|---|
| A staff member with a login | Export and erase, with an audit trail |
| A vendor portal user | Export and erase, with an audit trail |
| A customer you invoiced | Nothing. There is no account to resolve them to. |
| A person who bought once at a till | Nothing, and there may be no record beyond a sale |
| A person who only ever emailed you | Nothing, though the ticket itself holds their name and address |
Read the table as a whole and the shape is clear: the rows we can serve are the people who work for you, and the rows we cannot are the people you serve. The tooling is not weak — it is aimed at the population least likely to ever use it.
We should be exact about what we are claiming. This is a fact about a function signature and a missing column, both of which are readable in the code. It is not a report of a request anybody failed to answer, and we are not aware of one. The mechanism is what we are describing, not an incident.
The harder half nobody sells you
Even with the tooling pointed correctly, one problem stays, and it is worth understanding before anybody buys anything on the strength of a privacy feature.
A person's data is not in one place. The same human being may be a customer record, a name on three invoices, an email address on a mailing list, a phone number on a delivery note, a face in a photograph attached to a ticket, and a free-text mention in the notes field of a sales order. An export that returns the customer record and stops has answered a smaller question than the one asked. A deletion that removes the customer record and leaves the notes has not deleted anything, it has orphaned it.
Any vendor telling you this is a button is describing the easy tenth of it. The honest version is that it needs a definition of which fields across which tables constitute a person, maintained as the schema grows — and that definition is the deliverable, not the button on top of it.
Questions worth asking, and the second is the one that finds things out
Can you export everything you hold about a person who has never had a login?
What you will hear
Yes, with the person identified by email or by customer record.
How to read it
Almost every product answers this for accounts, because accounts are what products are built around. The people who send these requests mostly do not have one. Ours cannot.
Show me the list of fields that would come back.
What you will hear
An actual list, maintained somewhere, that names tables and columns.
How to read it
If there is no list, the export is whatever somebody remembered to include when they wrote it, and it silently stopped being complete the next time a table was added.
Does your deadline clock pause?
What you will hear
A distinction between the support target, which should pause, and a statutory period, which should not.
How to read it
One clock cannot serve both. If there is only one, find out which kind it is. Ours pauses.
What happens to my invoices if a customer asks to be deleted?
What you will hear
A clear answer that some records are retained for other legal reasons, and how the system distinguishes those from the rest.
How to read it
A system that will delete anything on request is more dangerous than one that will not, because accounting records generally have to survive. The right answer is nuanced; "yes, all of it" is not.
Who gets told a request has arrived?
What you will hear
A route that does not depend on the person who opened the email recognising what it was.
How to read it
This is where these obligations actually fail — not in the tooling, in the triage. A request that sits in a queue as an ordinary query has already spent its first fortnight.
What AWRA OpsHub does today
- A help desk that can identify a requester by user, by employee, by customer record, or by a bare name and email address with no record behind it.
- First-response and resolution deadlines on every ticket, with breach notification.
- Data export and erasure for user accounts, with an audit record of the request and the action, and erasure that overwrites identifying fields rather than dropping the row.
- A trash and retention layer with per-module policies, so what is removed and what is retained is a configured decision rather than an accident.
What it does not do
- Any export or erasure for a person who is not a user account. Customers have no link to one, so the tooling cannot be aimed at them.
- Any distinction between a pausable service target and a statutory period that does not pause. There is one clock and it is the first kind.
- Any request type that marks a ticket as a data request, so nothing routes one differently from an ordinary query.
- Any maintained definition of which fields across which tables constitute a person, which is the prerequisite for a complete export of anybody.
- Any identity verification step for a requester.
Not ours, by choice
- Nothing here is legal advice and this post does not say whether any privacy law applies to you. Coverage differs by state and turns on facts about your business.
- We will not describe this product as making anybody compliant with any privacy statute, including for the user accounts the tooling does cover.
- We have no reference customer in the United States or Canada.
The prerequisite is a maintained definition of which fields across which tables constitute a person, and it is the deliverable rather than the plumbing — everything else on this list is small once it exists and unreliable before it does. After that: export and erasure that accept a customer or a bare email address rather than only a user account; a second, non-pausing clock for a statutory period alongside the support target that should keep pausing; and a request type on a ticket so one can be routed the moment it arrives rather than when somebody recognises it. We would scope and price that as a piece of work with a written specification, a timeline and a price agreed before anything starts, and no dates on a public page.
We found this by reading a North American obligation against our own code rather than because anybody asked. The tooling we have is genuinely good and genuinely aimed at the wrong population, which is a failure mode a feature list cannot show you — both products have a tick in the privacy row.
Our take
Ask a vendor to export everything they hold about somebody who has never logged in. It is one question, it takes a minute, and it separates a product with a privacy console from a product that can answer the request you will actually receive. Ours has the console and cannot answer the request, and the clock we would answer it against is one that stops when we are waiting for you.
If these requests reach your support queue
Tell us what a person looks like in your data — which records, which free-text fields — and we will tell you what a complete answer would take. That definition is most of the work and it is worth having whoever builds the rest.
See plans & pricing