Privacy & Data Rights

The problem

A data-subject request arrives by email on a Friday. Someone has to work out which of forty systems hold that person’s details, export them by hand, and be confident nothing was missed. The clock is one month and nobody is tracking it.

Erasure is harder. “Delete the user” is the wrong answer — the invoices have to survive, the audit trail has to survive, and the ticket history belongs partly to other people. So the request goes into a spreadsheet, a database row gets its name blanked, and nobody can say afterwards whether the password-reset token, the calendar OAuth refresh token or the push-notification device registration went with it.

The uncomfortable version of the question is the one a regulator asks: show me what you deleted.

What Solidlio does about it

Any signed-in person can request a copy of their data or ask for erasure from a page in their own portal — no ticket, no email thread. Exports are produced by a background job every five minutes, stored, and delivered by a time-limited link that streams through an authenticated route rather than a public storage URL.

Erasure runs against a written contract of 38 record types, each marked erased, anonymised or retained with a stated reason. The contract is not documentation that describes the code — it is the code, and the same list is served to the data subject over the API before they decide to ask. Every run returns a coverage report of rows actually affected, which is stored on the request and written to the audit log.

Requests carry a stored 30-day deadline, so the platform queue can show what is overdue rather than leaving it to be discovered.

Capabilities

How it works

1. The person asks. From Privacy in their portal they request an export (JSON or CSV) or an erasure. The page is reachable by every role, including customers — the routes carry no role floor, because a data subject is often the least privileged person in the system.
2. The export is built. A job sweeps pending requests every five minutes, ordered by statutory deadline, collects strictly subject-scoped data, writes the file to object storage under the tenant’s key prefix, and emails a link.
3. The file is delivered. The link streams through an authenticated, subject-scoped route — never a public URL — and stops working after 7 days. Platform administrators cannot use it; the artefact belongs to the subject.
4. Erasure waits. An erasure request sits for 30 days. The subject can cancel from the same page at any point in that window.
5. An administrator carries it out. Two deliberate steps on the platform queue: close the cooling-off window (which deletes nothing), then execute. The confirmation states exactly what will be deleted and what will be kept.
6. The result is recorded. Credentials, sessions, login history, devices, third-party access tokens and personal content are deleted; the identity on business and financial records is severed; audit rows survive with their identifiers stripped. The coverage report is stored on the request.

What erasure actually reaches

Erasure that only blanks a name is the failure mode this design exists to avoid. Because the person record is anonymised rather than deleted — the alternative would cascade away a tenant’s invoices and audit trail — the work is in the tables that hold independent copies of personal data.

Erasure and the audit trail

These obligations conflict, and the product takes a position rather than avoiding the question.

An audit log a subject can delete is not an audit log — it would let a person erase the evidence of their own actions, and destroy the record of the erasure itself. So audit rows are retained, and the identity in them is severed the same way as everywhere else: the log continues to say “this actor did this” while no longer naming a human. The free-text IP and user-agent columns on the subject’s own rows are cleared, because those are independent copies that severing the person record does not reach.

What survives is the action, the entity and the timestamp — enough to reconstruct the history, not enough to re-identify. The same reasoning applies to financial records: the invoice survives, the person named on it does not.

Buyers whose legal position requires deletion of audit and financial records should know this is not what the product does.

Compliance and audit

Every action writes an audit row carrying the actor, the data subject, the legal basis, the region, the IP address and the user agent. Recorded actions:

Consent records store the exact text agreed to and the privacy-policy version, alongside the timestamp, IP address and region — which is what makes a consent record evidential rather than merely a flag.

Editions

Data-subject rights are not plan-gated on any tier. There is no entitlement or plan check on any privacy request — a statutory right that a billing tier can switch off would not be a right.

Note on regulatory language

This datasheet describes mechanisms, not certifications. Solidlio provides data export, consent recording and withdrawal, erasure with a published coverage contract, deadline tracking and an audit trail. Whether that satisfies a given obligation under GDPR, CCPA, PIPEDA or any other regime depends on how you deploy and operate it, and is a determination for your own counsel.