Compliance with backd

Apps that handle personal data usually have to answer four questions: what do you hold about me, did I agree to this, stop using my data for that and delete me. backd builds the mechanisms once; the decisions stay yours.

What backd provides, and what stays yours#

What counts as a person’s data#

A user’s data is, by default, the documents whose _meta.owner is that user (whatever their on_owner_delete action), the documents where their id or email is listed in a pull or unset field of an erase policy, and the files those documents hold, plus the account itself: identities, sessions, devices, second-factor status, consents, audit records about them and the function invocations they made. Credentials, tokens, secrets and other people’s details are never part of it.

Override it per collection in its collection.yaml:

personal_data:
  export: exclude
  reason: "fraud scores: exempt from access requests under …"

or keep a collection but only the person’s own part (fields: [title, notes], with a reason). backd refuses to start without the reason. See Personal data scope.

A checklist per collection#

Ask of each collection:

1. Does it hold other people’s data next to the owner’s? (comments, reviews, shared notes.) Then narrow it with fields, or the whole document goes to whoever owns it. This matters most in collections of an organization: their documents are shared by design, and the scope report marks every one that is exported whole.
2. Is there a legal reason not to give it? Declare export: exclude with that reason; a request can ask why.
3. Is the person named elsewhere (an array of members, a paid_by field)? That is what pull and unset in on_owner_delete are for, and they also bring those documents into the scope.
4. Does it hold files? They follow their documents.

Then read backd compliance scope --realm <r> (or GET /_admin/compliance/scope): every collection with what is included, which fields and every exclusion with its reason, and a ! on organization collections exported whole (organization: true in the API). The personal data export builds exactly that, and chapter 26 of the tutorial puts it behind a button.

Consents#

Texts live with the config, backd records each acceptance and keeps what proves it, and apps, rules and functions use it. Read Consents for the whole mechanism. In short:

• Sign-up takes the consents accepted (consents: { terms: "2026-10" }); a required one that is missing or outdated is 400 consent_required.
• A new version with reaccept: true asks people again at their next sign-in, and refuses open sessions after reaccept_by.
• Withdrawal is DELETE /_auth/consents/<name> for optional consents; rules see user.consents and hasConsent; ctx.email.send and ctx.push.send take requires_consent.
• Consents given outside the app are recorded by an administrator with the evidence.

Retention#

Where backd keeps personal data, for how long, and who decides:

The periods are legal decisions for you. backd’s defaults are conveniences, not advice.

Recipes#

A newsletter that respects a withdrawal#

1. Declare an optional consent (marketing) and its text; put the checkbox in the sign-up form and a switch on the account page (backd.consents.accept / withdraw).
2. In the function that sends, say whose consent it needs: ctx.email.send({ kind: "newsletter", to_user: id, requires_consent: "marketing" }). A member who withdrew is skipped and the call answers no_consent.
3. The tutorial’s chapter 17 builds exactly this.

Updating the terms#

1. Add the folder _realm/consents/terms/<new version>/<locale>.md for every language, move current, and add reaccept: true (and a reaccept_by date) if people have to agree again.
2. Deploy. Members are asked at their next sign-in; open sessions are refused after the date until they accept.
3. Tell them if you want: backd consents notify --realm <r> --consent terms.
4. Keep the old folder: it is the proof of what earlier members accepted.

Answering a request about a person#

1. Check who asks. That is on you: the self-service export proves it is the account holder; a request from a third party is yours to verify before you press anything.
2. Make the copy. backd user export --realm <r> --email <e> --ticket <your reference> --out request.zip builds the personal data export and writes it for you. The person is told by email that a copy was prepared, with your reference. If an inquiry must not warn them, --no-notify --reason "…" keeps the reason in the audit record, apart from the other requests.
3. Read it before you send it. It is a zip with a README.html that explains each part and lists what is left out and why. Check that it holds what the law expects you to give, and decide how you deliver it: backd hands it to you, never to the person.
4. For consents given by phone or paper, record them with their evidence: backd consents record.
5. For erasure, backd user delete --realm <r> --email <e> --yes applies the policies and reduces the consent records; the retention table above says what remains and for how long.

Without turning the export on you can still assemble an answer from GET /_admin/users/{id} and /identities, /sessions, /devices, /consents and /owned.

Minors#

Age checks and parental consent belong to the app: backd has no notion of a person’s age. If you need them, collect the date or the guardian’s consent in your own collections or with a function, and record guardian consents with backd consents record and their evidence.