A Data Request From Somebody Without a Login
The export and erasure tooling here is built around a user account — somebody who signs in. A customer is a record, not an account, and the difference decides what a data request against your workspace can and cannot be answered with.
The person making the request rarely has a login. That single fact explains most of the distance between what privacy tooling does and what a privacy request needs.
There is a well-built export and erasure path in this product, and it operates on user accounts: the people in your organisation who sign in. It is the right place to start and it is worth being precise about where it stops, because the requests that arrive are rarely from the people it covers.
What the export produces
For a user account: when it was generated, the organisation, the account identifier, the current privacy state, and then the substance — name, email, country, phone, photograph, whether the account is active, when the email was verified, when the password was last set, whether multi-factor is enabled, and the creation, update and deletion timestamps.
Alongside that, the assignments: which roles the account holds within your organisation, and which warehouse, location and department it is attached to. And the devices the account has signed in from.
Roles are read through the organisation pivot
A small correctness detail with a large consequence. Role assignments are held per organisation, so the export filters them to the organisation the account belongs to. An account that has existed in more than one workspace does not leak the other one's roles into this one's export — which is precisely the kind of thing a data export is most likely to get wrong and least likely to be noticed getting wrong.
Erasure is pseudonymisation, and it says so
This is the part most worth understanding, because "delete my data" and what any auditable system can actually do are different things, and the honest version of the difference is written into the record here.
Erasing a user account does the following, in one transaction.
| What | What happens to it |
|---|---|
| Access | API tokens deleted, sessions deleted, role assignments removed, the account deactivated and soft-deleted. |
| Credentials | A fresh random password nobody holds, multi-factor secret and recovery codes cleared, social sign-in links removed, remember token cleared. |
| Identity on the account | Name and email replaced with deterministic placeholders; phone, country and photograph cleared; warehouse, location and department detached. |
| Identity in the audit trail | The actor name and email on that person's audit entries are rewritten to the placeholders. The entries themselves remain. |
| Proof it happened | An audit entry recording the erasure, carrying one-way hashes of the original name and email, the replacement address, and a set of explicit flags. |
The actions stay. The person stops being named in them.
The audit trail is the interesting tension. An audit log exists so that actions can be attributed, and a privacy request asks for a person to stop being identifiable. Removing the entries would destroy the record of what was done to your organisation's data by somebody who had access to it — which is a different obligation pulling the other way. Rewriting the actor rather than the entry keeps the sequence of actions intact and removes the name from them, which is the resolution most regimes recognise.
The erasure record itself is explicit about what it did and did not do. It states that the account was soft-deleted rather than removed, that tokens and sessions were revoked, that the account cannot be restored, that an export remains available afterwards, and that permanently removing the row requires the same approval any permanent deletion requires. Those are commitments written into the evidence rather than claims in a policy document.
The two hashes
The erasure record keeps a one-way hash of the original name and of the original email. That is a deliberate middle position and worth explaining, because at first glance it looks like keeping the thing you were asked to remove.
It is not reversible — a hash cannot be turned back into an address. What it can do is answer a specific later question: if somebody asks whether a given address was ever erased from this workspace, the answer can be produced by hashing the address they supplied and comparing. Without it, the only honest answer to "did you action my request" would be that there is a record of an erasure and no way to tell whose.
A customer is not an account
There are three ways to sign into this product: as a member of an organisation, as a supplier, or as a partner. Customers are not among them. A customer is a record holding a name, an email, a phone number, a country, an address, a currency and a credit position — and there is no account behind it.
So a data request from a customer is answered differently. What you hold about them is a record you control, in a system you administer, and the answer is produced by your own people from the customer record, the documents that reference it and whatever correspondence exists. That is a process question rather than a button, and the honest thing is to say so rather than to imply the account tooling covers it.
The request is from a staff member or ex-staff member
The account tooling covers it
Export and erasure both operate on the account, and the erasure records what it did in the audit trail.
The request is from a supplier contact
Partly — the portal login is an account
A supplier portal login is a credential that can be retired. The supplier record and the documents attached to it are business records and are treated as such.
The request is from a customer
A process, not a feature
There is no account to act on. What you hold is the customer record and the documents referencing it, and the response is assembled by your own people.
The request would remove a transaction record
A question for your advisers before anything else
Invoices, payments and tax records usually have their own statutory retention, and that obligation often outranks a request to erase. That is a legal determination rather than a system setting.
What AWRA OpsHub does today
- A data export for a user account, covering profile fields, verification and credential timestamps, role assignments scoped to the organisation, warehouse, location and department, and the devices the account has used.
- An erasure path for a user account that revokes tokens and sessions, removes role assignments, deactivates and soft-deletes the account, and clears credentials including multi-factor secrets, recovery codes and social sign-in links.
- Identity replaced with deterministic placeholders rather than nulled, so the record remains internally consistent and cannot be confused with an incomplete one.
- Actor name and email rewritten across that person's audit entries, keeping the record of what was done while removing who did it.
- An audit entry for the erasure itself, carrying one-way hashes of the original name and email so a later "was this address erased" question can be answered without retaining the address.
- Explicit flags on that record stating that the account was soft-deleted, that restoration is refused, that an export remains available, and that permanent removal requires the same approval any permanent deletion does.
- A privacy lifecycle event recorded alongside, so the request and its completion are both on the record.
- The whole erasure in one transaction, so a partial erasure is not a possible outcome.
More we can add to your workspace
- An export and erasure path for a customer record, assembling what is held about a person who has no account from the customer record and the documents referencing it.
- A data subject request register, tracking a request from receipt to response with its deadline, whoever it concerns.
- A search across records by identifier, answering "everywhere this email address appears in our workspace" as one query.
- An export for a supplier contact, matching what exists for a staff account.
- A retention-aware erasure, distinguishing what may be removed from what a statutory retention period obliges you to keep, rather than leaving that to a person to determine each time.
- A recipient list per export, recording who the export was given to and when.
Where we point you to a specialist
- We will not remove audit entries as part of an erasure. Those entries record what was done to an organisation's data by somebody who had access to it, and destroying them would defeat an obligation that pulls against the request rather than alongside it. Removing the name from the entry is the resolution, and it is the one written into the code.
- Whether a particular request must be honoured, what it covers and what statutory retention overrides it are legal determinations about your organisation in your jurisdiction. Your advisers make them. We provide the mechanisms and the evidence of what was done.
- We will not permanently remove an erased account row on request alone. Permanent deletion runs through the same approval every irreversible deletion does, with the same separation of duties, because an action that cannot be undone should not have a single person behind it.
A search across records by identifier is the piece that changes most here, because the hard part of answering any data request is establishing where a person appears — and that is a query rather than a policy.
From account tooling to request handling
The account path is complete and evidenced. What a privacy function needs beyond it is the ability to find a person who has no account, and to track a request to a deadline.
Find every appearance of an identifier
One query answering where an email address or phone number appears across records, which is the first step of every request and currently the slowest.
Export and erasure for a customer record
The same shape as the account path, for the parties who have no account and make most of the requests.
A request register with deadlines
Requests tracked from receipt to response, so a statutory clock is visible rather than remembered.
We publish scope, not dates.
Scope privacy toolingFive questions to ask about privacy tooling
Who does the tooling operate on?
A good answer sounds like
A named population.
What ours actually is
User accounts — the people who sign in. Customers and supplier contacts are records rather than accounts.
Does erasure delete the row?
A good answer sounds like
An honest description.
What ours actually is
No. It pseudonymises: credentials cleared, identity replaced with placeholders, the account deactivated and soft-deleted, and permanent removal requiring approval.
What happens to the audit trail?
A good answer sounds like
It survives, unnamed.
What ours actually is
The entries remain and the actor name and email on them are rewritten to the placeholders.
How do you prove a request was actioned?
A good answer sounds like
A record with substance.
What ours actually is
An audit entry carrying one-way hashes of the original name and email, so a later question about a specific address can be answered without the address being kept.
Can I find everywhere a person appears?
A good answer sounds like
A search, ideally.
What ours actually is
Not as one query today. It is the first item on the list of what a request-handling function needs.
Our take
What exists here is better built than most and narrower than most people assume, and both halves of that are worth saying. Erasure that pseudonymises rather than deletes, keeps the audit trail intact while unnaming the actor, and records exactly what it did — including that restoration is refused and permanent removal needs approval — is a genuinely thoughtful answer to two obligations pulling in opposite directions. It also covers people who sign in, and most data requests come from people who do not. The gap to close is not a philosophical one about erasure; it is the unglamorous ability to find every place an identifier appears, which is where the time actually goes when a request arrives and the clock has started.
Work out who your requests will come from
For most organisations running this the answer is customers and ex-staff in roughly equal measure, and the two are answered by completely different processes. Knowing that before the first request arrives is worth a great deal.
Talk through privacy requestsFrequently asked questions
Does erasing a user delete their record?
No — it pseudonymises it. Credentials are cleared, sessions and tokens revoked, role assignments removed, the identifying fields replaced with deterministic placeholders, and the account deactivated and soft-deleted. The row survives, inert and unnamed, and permanently removing it runs through the same approval any irreversible deletion requires.
Why are audit entries kept?
Because they record what was done to your organisation's data by somebody who had access to it, which is an obligation pulling against the erasure request rather than alongside it. The resolution is to rewrite the actor name and email on those entries rather than removing them — the sequence of actions stays intact and stops naming a person.
What are the hashes for?
Answering a later question without retaining the answer. A one-way hash of the original name and email means that if somebody asks whether a particular address was erased from this workspace, the address they supply can be hashed and compared. Without it, the erasure record would prove an erasure happened and could not say whose.
Can a customer request their data through this?
Not through the account tooling, because a customer has no account — there are three ways to sign in here and customer is not one of them. What you hold about a customer is a record you administer and the documents referencing it, and the response is assembled by your own people. Making that a supported path is the second item on the list above.
What about invoices and payments that name the person?
Those are usually subject to statutory retention that outranks an erasure request, and that determination belongs to your advisers rather than to a setting. It is the most common reason a request cannot be answered simply, and it is worth establishing your position before a request arrives rather than during the response window.
Is an export still possible after erasure?
Yes, and the erasure record says so explicitly. What comes back is the pseudonymised account rather than the original identity, which is the honest outcome — the export describes what the system now holds rather than what it used to.
