The Requester Who Is Not a User
A help desk is the fastest-filling store of personal data in an operations system, and most of it belongs to people who have no account and never will. Ours handles them well in every respect but one — the tools that answer a data-subject request take a user account as their argument, and a person who emailed you does not have one.
Everything else in an operations system holds data about people you have a relationship with. Employees you pay. Customers you invoice. Suppliers you buy from. The help desk is different: it holds data about anybody at all who decided to get in touch, and it acquires them faster than any other module, one form submission at a time, with no approval step and nobody deciding to onboard them.
For a group operating across the East African Community that is a more interesting problem than it first appears, because a single support queue serving Nairobi, Kampala, Kigali and Dar es Salaam is one inbox answering to more than one legal regime at once. The people writing into it are covered by the rules of where they are, not where your server is or where your head office is registered.
What this post will not tell you
Which statute covers which of your requesters, or what it obliges you to do. Kenya's regime is written up elsewhere on this site with its sources attached; the other members are not, and we do not publish statutory claims we cannot date and source. This post is about a property of the software that is true regardless of which regime you are under, and it is one you can verify in ten minutes.
The two kinds of requester, and why the difference is structural
A ticket can be raised by somebody signed in, or by anybody at all through the public support form. Those two paths store the requester in genuinely different ways, and the difference is not cosmetic.
A signed-in requester is stored as a reference. The ticket records which user raised it and nothing else about them; the name and email on screen are read through that link. A public requester is stored as a copy. The form requires a name and an email address, both are written onto the ticket row, and no account exists anywhere.
That single difference decides everything that follows, because our privacy tooling operates on accounts.
Erasure takes a user. The public requester is the one person in the system who was never given one.
What the tools actually do
There are two of them, they are real, and they do what they say — for accounts. The export assembles a user's profile, their roles and assignments, their registered devices and their audit activity, and hands it over as a file. The erasure clears their tokens and sessions, strips their role assignments, anonymises the actor fields on every audit log entry they generated, replaces the identifying fields on the user record and deactivates it.
Both take a user as their argument. Neither accepts an email address. And here is the part worth checking on any system, not only ours: the export contains no tickets at all. Somebody with an account who asks for everything you hold about them receives their profile, their devices and their audit trail, and nothing about the support conversations they had with you — which for most people is the part with the actual content in it.
| Requester | How identity is stored | Reachable by export | Reachable by erasure |
|---|---|---|---|
| Signed-in user | A reference to their account | Their profile and audit trail — but no tickets | Yes, for identity; their ticket content is untouched |
| Employee with no login | An employee reference, user id usually empty | No account to export | No account to erase |
| Public form submitter | Name and email copied onto the ticket | No account to export | No account to erase |
| A person named inside a ticket body | Free text | Not modelled at all | Not modelled at all |
That last row is not a product defect so much as an honest limit worth stating out loud, because it is true of every help desk ever built and rarely admitted: the richest personal data in a ticket is usually in the description, written by somebody describing a situation involving other people. No system resolves that with a database column.
The part that surprised us
A ticket is not in the trash system. Every record type that can be deleted, restored, permanently destroyed under a refusal, or frozen under a legal hold is registered in one place — items, vendors, customers, users, assets and a handful of others. Tickets are not among them.
And there is no retention policy for tickets either. The retention engine ships forty-two default policies and not one of them is ticket-shaped, which is consistent with its design — the defaults deliberately govern logs and sessions and queue jobs rather than business records — but it does mean a support ticket raised by a member of the public in 2026 is still there, in full, with their name and email address on it, for as long as the organization exists.
Neither of those is a bug. Both are the absence of a decision, and the absence has a shape: the one record type that routinely holds data about non-users is the one with no deletion path, no retention timer and no hold mechanism.
A public requester can follow their ticket without an account
A signed tracking link valid for ninety days, reissued whenever they reply. No password, no registration, and no dormant account created just to let somebody ask a question.
A public ticket links itself to a customer when the email matches
So a support conversation with an existing customer is attached to them rather than floating loose.
Data export for a user account
Profile, roles and assignments, devices and audit activity, produced on request as a file.
Erasure for a user account
Tokens and sessions cleared, role assignments removed, audit-log actor fields anonymised, identifying fields on the account replaced, the account deactivated.
Tickets included in a data export
They are not. A subject access request answered from this tool returns no support history, which is usually the part the person was asking about.
Any erasure path for a requester with no account
The function takes a user. For a public requester there is no user to pass it, so this is not a gap in coverage — there is no entry point.
A ticket in the trash system
Tickets are not registered, so there is no soft delete, no restore, no permanent-delete refusal and no legal hold available for one.
A retention period for tickets
None ships and none can be configured, because the retention engine works from a policy list that has no ticket entry.
What AWRA OpsHub does today
- A public support path that does not force an account on anybody, with a time-boxed signed link rather than a registration wall, which is the right design and the reason the gap below exists at all.
- Ticket identity is modelled properly — four distinct requester shapes, each stored as itself rather than flattened into one text field.
- Data export and erasure for user accounts, both real, both audited, both producing evidence entries.
- Erasure reaches the audit trail, anonymising the actor fields on every entry an erased user generated rather than leaving their name scattered through it.
- Attachments and comments are permissioned, so ticket content is not readable by anybody who happens to have a link.
What it does not do
- Support history is absent from the data export. A user asking for everything held about them gets no tickets.
- No erasure entry point for a requester without an account, which is the majority of people a public help desk hears from.
- Tickets have no deletion path at all — not soft, not permanent, and not under hold, because they are not registered with the trash system.
- Tickets are on no retention timer, so a name and email address submitted through a public form persist indefinitely by default.
- Nothing identifies personal data inside a ticket body, which is where most of it actually lives.
- No per-country handling of any of this. One help desk, one behaviour, whichever member state the requester writes from.
Not ours, by choice
- We will not tell you which regime covers a given requester or what it obliges you to do. That turns on where they are and what you do with the data, it has real consequences, and it belongs to your adviser.
- We do not describe this product as compliant or non-compliant with any data protection regime. What we will do is tell you precisely what the tooling takes as its input, which is a narrower claim and a checkable one.
Five questions worth asking any help desk vendor
What does your erasure function take as its argument — an account, or a person?
What a straight answer sounds like
One word. Ours is an account.
Why it matters
It determines whether the tool can be pointed at the majority of people in a public help desk, and it is answerable in one sentence by anybody who has read the code.
Run an export for a user who has raised three tickets. Are the tickets in it?
What a straight answer sounds like
A file, opened, in front of you.
Why it matters
Support history is the part a person is usually asking about. An export without it answers a different question from the one that was asked.
How do I delete a single ticket, and who is allowed to?
What a straight answer sounds like
A demonstration, or an admission. Ours is an admission.
Why it matters
A record type with no deletion path cannot be corrected, redacted or removed however good the reason.
What is the retention period on a ticket, and where is it set?
What a straight answer sounds like
A number and a screen, or "there is not one".
Why it matters
Indefinite retention is a decision even when nobody made it, and it is the default in more systems than admit it.
If my group spans four countries, does the help desk behave differently by requester country?
What a straight answer sounds like
Almost certainly no. Get it said.
Why it matters
A single queue applying a single behaviour across several regimes is normal and workable — but you should know it is what you are buying.
Four, and the first two are corrections rather than features
These are unusually well-specified for a buildable list, because the audit that produced this post also produced the scope. The order below is the order we would do them in.
Tickets in the data export
A user's support history included in the export they already receive — subjects, descriptions, comments and attachment references. The export exists, the permission model exists, and this is the part of a subject access request that people actually mean. We would treat it as a correction rather than a feature.
An erasure that takes an email address
A path that operates on a requester rather than an account: find every ticket carrying that address, redact the requester name and email, and record what was done. Larger than it sounds because it needs a decision about ticket bodies — which we would want to make with you rather than for you, since redacting free text is a judgement about evidence as much as about privacy.
Tickets in the trash system
Registering tickets brings soft delete, restore, a permanent-delete refusal, an audit trail and legal holds all at once, because that machinery is already built and already applies to ten other record types. This is mostly registration rather than construction.
A retention period for tickets
Once tickets are in the trash system a retention policy follows the same shape as every other. What it should be set to is your adviser's question, not ours — but the mechanism should exist so the answer can be applied.
What we will not do is put a compliance badge on the result. These four make the tooling able to answer a request. Whether your answer satisfies your regulator depends on your regime, your data and your advice, and a vendor claiming otherwise is selling you a risk they have not priced.
Talk to us about help desk data handlingThe verdict
The public support path is one of the better-designed parts of this product — no forced account, a signed link that expires, automatic linking to a customer when the email matches. Every part of it anticipates somebody who does not have a login. And then the privacy tooling, built separately and earlier, takes a login as its argument. Nothing here is negligent; it is two reasonable designs meeting at a seam nobody walked across until we audited it for this post. If you run a regional help desk, the question to put to every vendor on your list is the narrow one rather than the grand one: not "are you compliant", but "what does your erasure function take as its argument".
Bring us your actual support volumes
How many tickets arrive from people with no account, from how many countries, and what you are required to be able to do about them. We will tell you which of the four builds above you need and which you do not, before you commit to anything.
Talk to us about the help desk