Skip to main content

Manage Privacy, Retention and Offboarding

Before you start​

Sign in as an administrator for the intended tenant. Verify the tenant slug and subject identifiers before making changes. Erasure and final offboarding delete data; use a disposable subject/tenant for learning, and confirm the exact real target before submitting a destructive action.

Inspect storage and set audit retention​

  1. Open Admin → Storage (/admin?tab=storage). Read measured usage, the measurement time, effective limit and warnings. A missing snapshot is not zero.
  2. Open Retention & Alerts (/admin?tab=retention-alerts). Enter your tenant slug, choose Audit retention class, enter days, and select Apply.
  3. Repeat only for other classes you intend to change. The classes have independent windows: audit events, IP addresses and user agents.

Example: select User agents and 30 days. Expected result: Retention policy applied for that class. This form permits 1–365 days and controls audit data, not general event retention. Applying policy does not prove cleanup has already completed. Tenant storage inspection does not grant platform quota-edit authority.

Open Admin → Privacy Controls (/admin?tab=privacy-controls).

  • To record consent, enter your tenant slug, the known subject ID and a concrete purpose such as product-analytics, then choose Grant consent.
  • To map an external identifier, enter the tenant slug and an external ID from your source system, then select Map. Success exposes a hash prefix, not a replacement subject ID to guess or paste into another request.
  • To request erasure, use the verified subject ID and a reason, then select Submit erasure. Keep the returned request identifier and inspect progress under Privacy Erasure. Submission is not evidence of completed deletion.

For example, use a disposable test subject whose identifier you already know. Record its consent purpose, then request its erasure only when you intend to remove that subject's data. If the form fails, correct the reported identifier, permission or validation problem; do not broaden the target to make it succeed.

Use Admin → Audit Log to inspect authorized accountability records. Retention and privacy restrictions may limit which details remain visible.

Offboard a tenant​

Open Admin → Offboarding (/admin?tab=offboarding). Scheduling and cancelling an effective date are separate controls from the return-and-delete workflow. An RFC3339 schedule example is 2027-01-31T18:00:00Z; choose your actual agreed date and include a reason. A scheduled status is not completed offboarding.

For Return and permanently delete tenant data:

  1. Enter the exact tenant slug and select Start export.
  2. Preview scope. Stop if the preview is partial or incomplete.
  3. Build and download the verified export. Save it securely and check that you can retain/use it before acknowledging receipt.
  4. Acknowledge the saved export and proceed to deletion confirmation only when you intend to permanently revoke credentials and delete tenant data.
  5. Enter the exact requested DELETE <tenant-slug> confirmation and execute.
  6. Retain the completed receipt/checksum. A prior export or confirmation screen is not proof that execution completed.

Example: for a disposable tenant example-test, the final phrase is DELETE example-test. Never use this example against an unrelated tenant. If preview/export fails, preserve the request ID and resolve the error before continuing. A schedule cancellation does not restore data already deleted.