Data retention and erasure

oHallo stores identity events as audit data: a record of every verification attempt, lockout and accepted proof 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

Identity events are kept for 24 months by default. The current period for a workspace is shown in Settings, then Verification, then the Posture tab, in the Records row. To change it, ask your oHallo account team.

• 3 months is the shortest period available. Investigating a dispute older than that may run out of audit data.
• 3 to 11 months: the Posture tab marks the GDPR row “Aligned with”. Most disputes are short-lived, and long-tail cases may run out of context.
• 12 to 84 months: the Posture tab marks the row “Follows”. 84 months is the longest period available.

A daily sweep deletes rows past your configured cutoff, and every sweep writes an audit record of what it removed.

What a National eID verification stores

An eID verification stores its outcome and the link to your record: identity events for the request and its result, each naming the scheme that answered (for example eid:dk_mitid), and your own customer reference, read from the record you designated, which ties the conversation to that customer. The national identity number and the identifier the scheme returns are read from your record or the scheme’s answer at the moment they are needed, compared or relayed, and discarded. They are never stored, never logged, and never written to an identity event.

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. Ask your oHallo account team for a data-subject erasure against that contact id.
3. The erasure runs against that contact id, recorded with who asked for it and a free-text reason for the audit trail.
4. The endpoint hard-deletes every identity-event row bound to that contact within your account 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 sweep or a per-contact erasure, writes one audit record. These records are held under a seven-year legal hold so oHallo can answer an audit about any specific erasure. They record:

• Which workspace and account the purge belonged to.
• The reason: retention_cron for the daily sweep, dsr_erasure for an account-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.

Ask your oHallo account team for the audit record covering a specific erasure request.

When not to lower retention

If your workspace handles regulated workflows in financial services, healthcare or insurance, your compliance team likely has a minimum retention requirement above the default. Check the regulatory obligation before shortening retention below 24 months. The Posture tab is a useful sanity check and does not substitute for compliance counsel.