Data requests

Platform → Data requests is “subject access, rectification and erasure against a statutory clock — and the register that says what we hold, why, and for how long.”

Two permissions, and they are not nested

Permission	Covers
gdpr.process	Answering a request.
audit.read	The register: the personal-data declaration, the Article 30 record of processing activities, the retention policies and the erasure log.

An auditor holds the second and not the first, and that is the point of the split: they can read what this platform holds, why, and for how long, without being able to erase anybody’s records or assemble an export of their life.

The tab strip is built from what your account actually holds.

Tabs

Tab	Needs	What it is
Requests	gdpr.process	The queue.
Personal data	audit.read	Every registered column, by table, and whether it is retained.
Article 30	audit.read	The record of processing activities.
Retention	audit.read	The policies, and what is due to be swept.
Erasure log	audit.read	What has been erased.

Why the register sits beside the queue

Because the queue cannot be worked without it:

• An erasure’s completion is refused as a full completion when the register says a column is retained.
• Resolving a subject’s records is refused when the register’s two halves disagree about a table.
• An export’s contents are whatever the register declares exportable.

An operator who has to leave the request to find out what the register says is an operator who will guess.

The request lifecycle

A sequence of decisions against a statutory clock: record → verify → resolve → export → complete, with extend available once.

0. Record the request

Record a data subject request — “somebody has asked us something about their own data. This starts the statutory clock.”

Field	Notes
What they asked for	“An erasure is the only type that destroys anything, and it is the only one whose completion can.”
Who they are	“Which kind of record the request is about. It decides what can later be resolved from the register.”
Merchant	For a merchant, or a portal user of one: search by name or code. For a merchant, “the merchant account the request is about”; for a portal user, “the account the person is a user of.”
Portal user	For a portal user: chosen from that merchant’s users, by name and email.
Their email address or phone number / The record’s id	For anyone else. Email or phone is the readable route — “what they transacted with, as they gave it.” A customer or end-user id has no list to choose from, so it is still typed.
When it reached us	“Leave blank for now. The statutory clock runs from this, so a letter opened on Monday that arrived on Saturday must say Saturday.”
What they actually said	“In their words. A request paraphrased into a type and nothing else cannot be checked against what was answered — which is the check a complaint turns on.”

The arrival date is not the date you typed it in

Backdating it to when the request genuinely reached us shortens the deadline shown on the queue, which is the point: the clock is theirs, not ours. A request logged late with today’s date reads as comfortably inside its month while in fact being days from breach.

1. Verify the identity

“Say how you established that this is the person whose data it is.”

Fact / field	Notes
They say they are	The identifier on the request.
Merchant	Whose account the data sits in.
What they asked	Their own words.
How the identity was established	“What you saw, not a category. A document on a video call, a reply from the address of record, a signed letter with a certified copy — and what it was checked against.”

This is the step that prevents the worst outcome

Handing somebody else’s personal data to a stranger who asked nicely is a breach you caused, not one you suffered. “Email matched” is not identity verification when the request arrives by email.

2. Extend, if it genuinely needs longer

“A complex request may run to three months from the date it reached us. No further.”

Field	Notes
Reached us	“What the clock runs from.”
Extend to	Prefilled with the full two further months, already capped.
Why it needs longer — in words the requester will read	—

Recording the extension does not tell them

Article 12(3) requires the requester be told of the extension and the reasons within the first month. The text you write here is what goes to them — but somebody still has to send it. Recording it here is not notice.

2a. Resolve their records

What the register can actually find for this subject, which is what an export is assembled from.

Field	Notes
Kind of subject	“The register raises an error on a type it does not declare, rather than returning nothing.”
Merchant	For a merchant subject: search by name or code.
Their primary key	For any other subject. “The record’s id, filled in from the request when it named one. NOT an email address — the register resolves rows, and deciding which row is a person is your judgement, recorded in the verification.”

An error here is the register telling you it does not declare that subject type. It is a register problem, not a missing person: fix the declaration rather than working around it.

Consent history is read on the same page, keyed by the subject, and takes one optional narrowing field:

Field	Notes
One purpose in particular	“Naming a purpose also returns the CURRENT position for it, read outside the window — which is the single fact a ‘were we allowed to send that’ question turns on.”

A request that names no subject the register can be read for shows the panel empty and says so, rather than implying consent was never recorded.

3. Assemble the export

This is the most damaging object this platform can produce

By construction: one file, one person, every record. The audit entry is written before the data is returned, because that entry is the only evidence anybody ever assembled it — and it is what both a leak investigation and a subject access request start from.

Field	Notes
The controller this document names	“The legal entity answering the request. Article 15(1) requires it be stated, and it differs per deployment — which is why it is not a constant.”
Why this is being assembled	Required, and written to the audit log before the data is returned.

The screen does not offer a download, deliberately. The contents are shown here to be reviewed before they leave. The correct path is:

1. Review what was assembled.
2. Write it to private storage.
3. Record the storage key and an expiry against the request.
4. Send the subject a short-lived link — not the file.

A browser download button would produce an unexpiring copy in somebody’s Downloads folder, synced to wherever that folder syncs, with nothing anywhere recording that it exists.

Assembling is also not sending. Nothing about it tells the requester anything.

4. Complete it

Field	Notes
What is being recorded	The outcome.
Why, in your own words	“Goes in the audit log, alongside the deadline and whether it was met. This is what a complaint six months from now is answered from.”
Why it is being refused — the requester is given this	“Say which exemption or which fact it rests on. A refusal the requester cannot understand is a refusal they will complain about, and the complaint is answered from this sentence.”
What was kept, and under what obligation	For a partial erasure.
Where the export was written	“The private storage key, if an export was assembled and stored. Leave blank if nothing was written.”
When the link stops working	Required here even though the platform would allow it to be omitted — “an export link that never expires is a copy of somebody’s life sitting in a bucket.”
Internal notes	“Not shown to the requester. For whoever reads this request next.”

A completion recorded as full while the register says a column is retained is refused. That is the register doing its job: say what was kept and under what obligation instead.

The register

Personal data

Every registered column, by table, and whether it is retained. This is what an export may contain and what an erasure must clear.

Article 30

The record of processing activities. Each one shows whose data, what kind, the lawful basis and — where that basis is a legitimate interest — the balancing test, which is “the first thing a regulator looks for”. Plus who else sees it, whether it leaves the country and under what safeguard, how long it is kept, the owner, how it is protected, and when it was last reviewed.

An activity not reviewed recently is flagged. That flag is the whole value of the tab: an Article 30 record that nobody has looked at in two years is a document a regulator will read more carefully than you have.

Retention

Each policy: what it covers, how long, and counted from — “compare the cutoff below against THIS column, not against created_at, unless the basis says creation.” Then the cutoff as of now (“anything older than this date is due to be swept”), what happens then, under what obligation, and whether it is in force.

The corresponding destructive action for KYC documents lives in KYC → Retention, with the documents it is about.

Erasure log

What has actually been erased. The counterpart to the requests queue, and the answer to “did this erasure happen”. It is paged.

A purged Ghana Card appears as document_number_sealed erased from kyc_documents, with the number’s keyed digest rather than the number. See Purging a document.

Working a request

1. Verify identity properly, and write what you actually saw.
2. Read the register for the tables involved before promising anything.
3. Extend only if it is genuinely complex — and make sure somebody tells the requester within the first month.
4. Assemble the export, review it, store it, record the key and an expiry.
5. Complete with a reason that would answer a complaint, and name what was kept and why.

Never let the clock run out silently. A missed statutory deadline is a regulatory matter whatever the eventual answer would have been.