Privacy and retention

The record of processing is code

Memnox keeps its Article 30 record as code, and a test asserts it covers every table that exists. Storing something new without classifying it fails the build.

The consequence is the part you can use: the register cannot drift from reality, so when you hand it to an auditor you are not hoping somebody remembered to update a spreadsheet. Ask for it first.

Every table is classified four ways.

What kind of personal data

Lawful basis

contract · legitimate_interest · legal_obligation · not_applicable.

How it is erased

Strategy

delete

Rows can simply go

crypto_shred

Deleting would break an integrity guarantee

not_applicable

Nothing personal to erase

Crypto-shredding exists because of the audit chain. Each event's hash covers its content, so removing a row breaks every hash after it. Instead the row stays and its key is destroyed: the content becomes unreadable, and the chain still verifies.

That is an honest trade rather than a workaround. You get erasure of the content and preservation of the proof that something happened.

Encryption at rest

Coverage

encrypted

The record blob goes through the codec

lookup_key

Personal, but readable because it is the lookup key

metadata_only

Deliberately readable: index keys, foreign keys, timestamps

Subject requests

Subject kinds: person, cloud_user, org, workspace, agent.

Export returns everything held about that subject, table by table.

Erasure applies the per-table strategy from the inventory and returns a receipt, which tables were touched, how many records, and by which strategy. Keep the receipt; it is the evidence the request was honoured.

Console → Settings → Privacy, running a subject export with the resulting receipt

screenshot slot, save as public/screens/…png and set src

Both operations are admin-only and audited. The receipt is the artefact to hand back to whoever made the request.

Retention

Two independent sweeps, and they are not the same thing.

Source events are pruned to your plan's historyDays.

Audit events are pruned to the deployment's --audit-retention-days. The Postgres delete is batched so it never holds a long table lock, and one distributed lock keeps a single pod sweeping at a time.

bash

memnox serve --audit-retention-days 365    # 0 keeps everything

Decide this deliberately. Both "keep for seven years" and "keep for ninety days" are defensible; "nobody chose" is the one that causes trouble.

Tenant purge

Removing an organization entirely is its own operation, with its own receipt listing every table purged. It is not a cascade delete somebody hopes covered everything.

What Memnox never stores

Provider credentials. The integration provider holds them; nothing is written here. See Integrations.
Raw tool-call arguments. Argument matching happens in-process on your machine; the SDK strips arguments before any request leaves it.
Card details. The payment provider holds them.

Security posture

The full picture of what is held and where.

For compliance and legal

Turning all of this into evidence somebody will accept.