Bichon Docs
Compliance Suite

Bichon can record a GDPR Article 17 erasure request and delete the exact messages it names, leaving an audit record of who asked, what was searched for, and why the operator believes no statutory retention obligation applies. This is an Enterprise feature.

An erasure is not a bulk delete with a nicer name. A normal delete removes messages; an erasure removes them and records the legal basis on the same tamper-evident trail. The record is the artifact the workflow exists to produce.

Workflow

  1. Search for the data subject's mail and select the messages to erase.
  2. Choose Record a GDPR erasure request from the bulk actions menu (WebUI), or call the API directly.
  3. Supply:
    • Data subject — the person the request concerns (required).
    • How the messages were identified — e.g. sender/recipient address and date range.
    • Assessment — why no statutory retention obligation covers these messages (required and non-empty; this is the basis the approver signs).
  4. The message set is frozen at submission. Only the selected message IDs are erased; later imports, syncs, or deletions do not change it.
  5. If dual control covers gdpr.erasure, the request is queued for a second person. If it does not, the erasure runs immediately on the submitter's signature and is still recorded as an unaccompanied request.

The interface refuses an empty message set, an unnamed subject, and an empty assessment.

Dual control

When gdpr.erasure is listed in the dual-control policy, submitting returns a pending request:

{ "ok": false, "pending": true, "request_id": "…", "expires_at": 1760000000 }

A different user must approve it. The approver must state a decision note — the basis on which the erasure is lawful — and that note is recorded in the approval ledger and the audit trail. Self-approval is blocked; break-glass follows the normal dual-control rules.

When the operation is not gated, the response contains the result directly:

{ "ok": true, "pending": false, "result": { … } }

ok means every requested message was deleted. A per-account failure detail is returned when one account could not be fully erased.

Messages in an account under legal hold cannot be deleted. An erasure that includes such an account reports the failure rather than silently skipping or partially deleting; release the hold first if the erasure is legally required.

Deletion in Bichon is permanent — there is no trash, recycle bin, or undo. A backup restore is the only way to recover erased messages, from a restore point made before the erasure.

Permissions

  • Enterprise license.
  • The caller must hold data:delete on every account named in the request. A batch mixing an authorized and an unauthorized account is refused, not partially submitted.

API

MethodPathDescription
POST/api/v1/approvals/erasure-requestsRecord (and possibly execute) an erasure request

Request body:

{
  "subject": "person@example.com",
  "criteria": "all mail to or from person@example.com, 2024-01-01 to 2025-12-31",
  "assessment": "No invoices or statutory records are attached; retention duty does not apply.",
  "messages": {
    "12": ["<envelope-id>", "<envelope-id>"],
    "27": ["<envelope-id>"]
  }
}

messages maps account id to the frozen list of envelope IDs. The response is always HTTP 200; use pending to distinguish a queued request from an executed one.

Audit events

  • gdpr.erasure_requested — records the subject, criteria, assessment, account IDs, message count, whether it was queued, and the request id. Emitted before the branch, so a direct erasure still leaves the record.
  • Normal message-deletion events for each erased message, plus approval events when dual control is involved.

See Audit Log & Integrity and SIEM Forwarding.

On this page