Data requests

A data request (a data-subject request) is a person asking what the workspace holds about them, or asking for it to be erased. Owners handle requests under Trust → Data requests (/trust/data-requests). Any member can make a request about themselves under Trust → Your data and account (/trust/your-data): see Asking for your own data.

Kinds of request

A request is about one person:

• a member, identified by their Clerk user ID;
• a contact or a membership, once the modules that hold them are part of your workspace.

A request is due 30 days after it is received. The list shows each request's status (open, completed, cancelled) and its due date. A request the person made themselves is marked Asked by the person.

Asking for your own data

Any member can ask, for themselves, under Trust → Your data and account:

• Ask for a copy of my data logs a copy (export) request about you.
• Ask to erase my data asks you to confirm, then logs an erasure request about you.

Each request is logged like one an owner records: received now, due in 30 days. The owners of the organization see it under Trust → Data requests and handle it as below. For a copy, an owner downloads the ZIP and gives it to you. For an erasure, an owner first removes your roles, then erases your data. The page lists your requests with their status and due date. While a request of one kind is open, you cannot ask for the same kind again.

In your personal workspace you are the only member and its owner, so there is nothing to ask: download everything under Admin → Exports, and close the workspace instead (Closing an organization).

When your data has been erased, the request no longer carries your user ID, so it leaves your list.

Handling a request

1. Open a request. Choose the kind and the person, and record when the request was received.
2. Review what was found. The request page lists, per record type, how many records name the person and what erasure will do with them:
   • Delete: the rows go.
   • Names removed (anonymize): the rows stay, and the columns that name the person become erased:<request ID>. Who created an issue becomes erased:…, but the issue stays.
   • Retain: the rows are kept, and the page shows why.
3. Export or erase.
   • Export downloads the ZIP. Every download is recorded in the access log.
   • Erase asks you to type the person's ID back as confirmation. Everything happens in one step: either all of it or none. The request is then completed, and dsr.completed is emitted.
4. Close without acting on a request that was withdrawn or made in error (it is marked cancelled).

Opening, exporting, erasing and cancelling are each recorded in the audit log.

What is in the export

Records that are about the person, such as their notifications, are exported whole. Records that only name the person carry three things:

• the record's id;
• its date;
• namedIn, the fields that name the person (for example, who created an issue).

The rest of such a record is the organization's own work.

If an information barrier excludes you from some projects, records in those projects are left out of the export you download. manifest.json gives the number per record type (withheld), and the README says how many records were left out. A download with records left out does not complete the request: ask an owner the barrier does not name to download the complete export.

The archive is built when it is downloaded and is not stored.

Rules

• Erasure applies only in this workspace. The same person may belong to other workspaces; their records there are untouched.
• Some records are kept, with the reason shown on the request:
  • the audit trail, which records who changed what and is kept for its own retention period (Retention);
  • the conflict register (interests, disclosures, recusals and barriers), which is the organization's governance record.
• Remove a member from the workspace before erasing them. Revoke all their roles under Admin → Members and roles. Erasure is refused while they still hold one.
• Erasure does not delete their sign-in account. The sign-in account is separate, and the person deletes it themselves (Deleting your account). Erasing their data here does not stop them signing in to other workspaces.
• Files in storage (uploaded documents, finished workspace exports) are not changed by erasure. Workspace exports expire on their own.

Deleting your account

Trust → Your data and account lists the steps under Delete your account. Do them in this order, because after the last one you cannot sign in:

1. Ask each organization you belong to to erase your data. In each one, open Trust → Your data and account and choose Ask to erase my data.
2. Close your personal workspace. Switch to it, open the same page, type the workspace's name and choose Ask to close my personal workspace. The platform team closes it, and erases its data 90 days later (Closing an organization).
3. Delete your sign-in account. Choose Open account settings, open Security and choose Delete account. This cannot be undone.

Steps 1 and 2 ask for your data to be removed; deleting the sign-in account does not remove it by itself. Where the platform's operator has connected it to account deletion, deleting the account also does the asking for you, in case you skipped a step:

• your roles end in every organization you belonged to, so nobody sees you as a member any more;
• each organization gets a request to erase your data, which its owners handle like any other (due in 30 days, under Trust → Data requests), unless one you made is still open;
• your personal workspace gets a request to close it, for the platform team.

The owners of an organization see the request as asked by you, recorded in the audit log as done by the system when your account was deleted.