Privacy

What it is#

Privacy is four tabs for four jobs that are done by different people at different times: a queue of data-subject requests with a deadline on each, the retention policy that decides how long anything is kept at all, the legal holds that stop deletion, and the region this workspace's data sits in.

Everything an approver needs before pressing the irreversible button is on the screen: what an erasure would destroy, what it would keep, and whether a hold stops it.

How to get there#

Security → Privacy in the admin console.

privacy.request.view is deliberately withheld from the blanket viewer grant — the queue names subjects and their requests. There is no separate key for reading holds or residency; both ride on the same read key. There is no plan gate.

How to use it#

Record a request#

1. New request.
2. Choose the kind: Data export, Erasure, Workspace export or Workspace deletion.
3. Give the subject's email address. The statutory deadline and the days remaining are calculated for you and shown on the row, with a breach flag once it passes.

Produce an export#

1. Open the request and press Build export.
2. When it finishes, the row shows the package size and a download link with an expiry date.
3. Revoke link kills the link before it expires. An expired link says so rather than failing silently.

Approve an erasure#

1. On an erasure request, press Review erasure. This runs a preview and changes nothing.
2. The plan states three totals — deleted, anonymised and kept — and lists them model by model. Authored work is kept and loses its author: a time entry stays on the invoice it was billed on with "Deleted user" where the name was. Credentials, sessions, devices and encryption keys are deleted outright. Issued invoices, signatures and consent records are kept untouched, because destroying them would remove the ability to prove an obligation rather than remove the obligation.
3. Type ERASE to confirm, then Approve erasure.
4. Approving does not run it now. There is a seven-day cooling-off window first, and Cancel erasure works at any point during it.

Refuse or cancel#

Both Refuse and Cancel erasure require a written reason. It is stored on the request.

Set how long each category is kept#

1. Open Retention. Each category states what it covers, what is in force now, and its minimum in days.
2. Type a number of days, or leave it blank for "kept forever", and press Save.
3. A value below the floor is refused, and the screen says why that floor exists.
4. Recent sweeps underneath lists every nightly pass including the ones that deleted nothing — so an empty list means the sweep has not run, not that there was nothing to do.

Place a legal hold#

1. Legal holds → Place a legal hold.
2. Choose the scope: a person, or the whole workspace.
3. Write the reason. It is required, and it is what somebody reads a year later.
4. The tab leads with what is in effect — "two people are under hold" — and the rows underneath are the evidence for it. Released holds stay visible, dimmed.

Release a hold#

Release asks first and names what resumes. The data the hold was preserving can be gone by the next morning.

Pin the workspace to a region#

1. Open Residency. It opens by saying where this workspace actually is, not with a picker.
2. Pin here commits to that region. The confirmation uses the word permanent, because the API refuses to move a pin afterwards.
3. The regions list marks each one available or not built, and the panels below name the third parties that also receive data — derived from this deployment's own configuration rather than from an annex in a document.

What it affects#

• The nightly sweep. A retention value is what the sweep enforces. Shortening one starts deleting older rows in that category from the next pass.
• Legal holds outrank everything. While a hold applies, approving an erasure suspends the request instead of running it, and nothing is deleted. The plan dialog says so before you approve.
• Erasure is the one action in Projectri that cannot be undone once it runs. It reaches across the model graph: credentials, sessions, devices and encryption keys go, authored work is anonymised, financial records stay.
• Residency is a commitment made to a customer, and once pinned a second attempt is refused rather than quietly moved.
• The audit log records the acts on this screen.

On mobile#

/privacy in the Expo app carries your own data first — ask for a copy, ask for erasure, see when you will hear — and, for whoever handles them, the queue and the retention policy read-only. /admin/legal-holds places and releases holds, because a preservation notice arrives on a Friday afternoon and every hour it is not in place is an hour the sweep might delete under it. /admin/residency reads the region and can pin behind the same confirmation. The two write paths that destroy data — approving an erasure, editing retention — stay on the web.

Limits and gotchas#

• A retention floor cannot be lowered from this screen at all. The floor and its reason come from the category.
• Approving an erasure while a hold applies suspends the request. That is the correct outcome, not an error — release the hold if the hold no longer stands.
• The seven-day cooling-off window is the only chance to cancel. After it runs, there is nothing to restore from.
• An export package's download link expires. Rebuild the export rather than hunting for the old file.
• A pinned region cannot be changed later, and a workspace whose country belongs to a region we cannot serve is told so on the tab rather than finding out from a regulator.

Related#

• Account closures — the other closure queue, and what it does not do.
• Audit log — the record of every decision taken here.
• Security — sessions, devices and credentials, which an erasure destroys.
• Data and privacy — how the pieces fit together.
• Your settings — where a member asks for their own copy or closure.