---
title: "Privacy"
slug: admin/privacy
url: https://projectri.com/docs/admin/privacy
section: admin
audience: admin
app_route: "/[slug]/admin/privacy"
permissions: [privacy.request.view, privacy.request.manage, privacy.retention.manage, privacy.hold.manage, privacy.residency.manage]
mobile: "/privacy"
updated: 2026-09-08
source: Projectri documentation
---

# Privacy

The data-subject request queue with its statutory clock, how long each category of data is kept, legal holds that suspend deletion, and where this workspace's data lives.

![Privacy](https://projectri.com/docs-shots/admin-privacy.png)

## 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.

| Tab | Read | Write |
|---|---|---|
| Requests | `privacy.request.view` | `privacy.request.manage` |
| Retention | `privacy.request.view` | `privacy.retention.manage` |
| Legal holds | `privacy.request.view` | `privacy.hold.manage` |
| Residency | `privacy.request.view` | `privacy.residency.manage` |

`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

> [!WARNING]
> **Closing an account and erasing a person are two separate systems, and they
> never touch.** Marking a request complete on
> [Account closures](/docs/admin/account-requests) only flips a status column: it
> removes no credentials, no devices, no encryption keys and no sign-in history,
> and it does not file an erasure request here. If somebody has asked to be
> erased, record an ERASURE request on this screen. The intended closure flow is
> to remove the membership on Members first, then mark the closure done.

- 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](/docs/admin/account-requests) — the other closure queue, and what it does not do.
- [Audit log](/docs/admin/audit-log) — the record of every decision taken here.
- [Security](/docs/admin/security) — sessions, devices and credentials, which an erasure destroys.
- [Data and privacy](/docs/features/data-and-privacy) — how the pieces fit together.
- [Your settings](/docs/workspace/settings) — where a member asks for their own copy or closure.

## Related

- [Account closures](https://projectri.com/docs/admin/account-requests.md): The queue of members who have asked for their account to be closed, with a 30-day clock on each and a note back to the person when it is closed out.
- [Audit log](https://projectri.com/docs/admin/audit-log.md): Every recorded action in this workspace, who did it and from where, with a bulk export and streaming to your own SIEM.
- [Security](https://projectri.com/docs/admin/security.md): The sign-in rules this workspace enforces, who is signed in, what machine credentials and outside applications can reach it, and the sign-in history.
- [Data and privacy](https://projectri.com/docs/features/data-and-privacy.md): Where a workspace's data lives, how long it is kept, how a person gets a copy or has it erased, and why closing an account is not the same as erasure.
- [Settings](https://projectri.com/docs/workspace/settings.md): Your own settings — profile, language and region, appearance, skills, notifications, work items, integrations, import, security, shortcuts and your data.