Data retention and erasure

The platform stores identity events as audit data: a record of every verification attempt, lockout, factor add, and risk signal that fired for a workspace. This data is PII-bearing (every row references a specific contact) and so is subject to GDPR Art. 5(1)(e) storage limitation and Art. 17 right to erasure.

Configuring retention

In Settings — Workspaces — (your workspace) — Identity & Verification — Verification settings, the Data retention row sets the number of months identity-event rows are kept. The default is 24 months.

• 3 months — the platform floor. Below this is rejected at the API layer.
• 3 to 6 months — the Compliance Posture footer marks this row “Reduced.” Investigating a customer dispute that happened more than three months ago may run out of audit data.
• 6 to 12 months — the footer marks this “Aligned with the standard’s principles.” Most disputes are short-lived but long-tail edge cases may run out of context.
• 12 to 84 months — “Follows GDPR Art. 5(1)(e).” 84 months is the platform’s maximum.

A daily retention sweep deletes rows older than your configured cutoff. The sweep is recorded in a separate audit table (identity_event_purges) that is itself retained for seven years.

Honouring an erasure request

When a data subject asks you to erase their identity-event history (typically as part of a broader account-deletion request), the operator-side process is:

1. Identify the contact id in your Contacts table.
2. Contact your platform administrator and request a DSR erasure for that contact id. (A self-service operator UI for this lands in a future release; for now this is admin-mediated.)
3. The administrator invokes the platform’s erasure endpoint with the contact id, their actor id, and a free-text reason for the audit trail.
4. The endpoint hard-deletes every identity-event row bound to that contact within your tenant and writes a meta-audit row capturing what was deleted, by whom, and when.
5. The response gives you the count of rows deleted. Use that for your own compliance record.

The identity layer purges only the identity events. Erasing the underlying contact record, the conversation history, attached documents, and other PII-bearing surfaces is a separate platform-wide DSR flow.

The audit trail

Every purge — whether the daily retention sweep or a per-contact erasure — writes one row to identity_event_purges. Rows in this table are kept for a minimum of seven years per the platform’s legal-hold default. They record:

• Which workspace and tenant the purge belonged to.
• The reason: retention_cron for the daily sweep, dsr_erasure for a tenant-invoked deletion.
• The contact id (for DSR rows) or the cutoff timestamp (for retention rows).
• The actor (operator user id or cron name).
• The number of identity-event rows actually deleted.

Auditors can query this table to confirm any specific erasure request was processed.

When not to lower retention

If your workspace handles regulated workflows (financial services, healthcare, insurance) your compliance team likely has a minimum retention requirement that exceeds the platform default. Check the regulatory obligation before lowering retention below 24 months; the Compliance Posture footer is a useful sanity check but doesn’t substitute for compliance counsel.