governance
Personal-data governance across GDPR and PDPA — told once, then mapped.
| Status | reference — this page documents no API of its own; each right it names is implemented on the linked service page. |
| Cluster | time-and-audit |
| Cross-cuts | the Enclave key hierarchy, the forget erasure service, and the consent / portability / withdrawal rights services. |
| Companion | deletion — the vocabulary (erase vs. delete vs. tombstone) this page uses precisely. |
What this page is
Data-protection regimes — the EU's GDPR and Thailand's PDPA among them — grant a data subject a set of rights over their personal data: to have it erased, to see the record of what was consented to, to receive a portable copy, and to withdraw from further processing. This page tells the compliance story once — how a zero-knowledge, encrypt-before-store vault satisfies those rights structurally rather than by policy — and then maps each right to the service page that implements it. It documents no API of its own.
The two regimes are named deliberately. GDPR (Articles 15–20 in particular) and PDPA share the same core rights vocabulary; where an obligation is regime-specific it is called out on the relevant service page rather than duplicated here.
Crypto-shred: how erasure actually happens
In an encrypt-before-store design there is no privileged server that can reach into a backend and scrub a row — the store only ever holds ciphertext, and the keys live in the client's memory. So erasure is implemented cryptographically: destroy the key a record was encrypted under and the ciphertext left behind is unrecoverable noise. This is crypto-shred, and it is what makes the right to erasure enforceable against untrusted storage — an S3 bucket, a synced replica, a backup tape — that you cannot reach in to edit.
The unit that makes this per-subject rather than all-or-nothing is the per-record content key (CEK): with per-record keys enabled, each record body is encrypted under its own key, itself wrapped under the collection key, so destroying one record's wrapped CEK renders only that record undecryptable while every other record stays readable (the mechanism is described in full on Enclave → Per-record keys). Erasing a subject then means shredding the wrapped keys of exactly that subject's records and rewriting each envelope as a tombstone — ciphertext and wrapped key stripped — so the record reads as permanently gone rather than merely hidden. The forget service performs this cascade and emits a tamper-evident ledger proof of it.
To find a subject's records without decrypting the whole vault, forget maintains a reserved index, and that index is itself built to leak as little as possible:
A reserved
_subject_indexcollection (own DEK) maps each subject to its[{collection, id}]refs. The entry id is an HMAC-SHA256 of the subject id keyed by the index DEK — so someone with store access cannot dictionary-test whether a known subject is present — and the entry body is encrypted and length-padded so the ciphertext does not reveal the record count.
Mapping the rights
Each data-subject right maps to one implementing surface. Follow the link for the API, the guarantees, and the gotchas; this table is only the index.
| Obligation (GDPR / PDPA) | noy-db mechanism | Where it's documented |
|---|---|---|
| Right to erasure ("right to be forgotten") | Crypto-shred cascade over a subject's records, with a ledger proof of erasure | forget |
| Record of consent | Per-operation consent audit trail written while a consent scope is active | consent |
| Right to data portability | Export of a subject's accessible data as a portable artefact | portability |
| Right to withdraw / object | Unilateral or approval-gated withdrawal of a member from a vault | withdrawal |
| Deletion vocabulary | Precise terms — erase vs. delete vs. tombstone vs. crypto-shred | deletion |
| What is protected, and from whom | The vault's threat model: what the store can and cannot observe | threat model |
See also
- forget — the erasure cascade and its ledger proof.
- consent · portability · withdrawal — the remaining rights services.
- Enclave — the per-record CEK and tombstone mechanics crypto-shred relies on.
- deletion — the deletion vocabulary used precisely above.
- threat model — what a storage backend can and cannot learn.