Retention periods and lawful basis per data class. Mapped against the live database schema in src/db/schema/. Reviewed at each release-planning gate and whenever a new table or external integration is added.
The retention principle is data minimisation under GDPR Article 5(1)(c) and storage limitation under Article 5(1)(e). Personal data is retained only as long as necessary to provide the service or to meet a specific legal obligation. Audit and compliance evidence is retained for the period required by EU AI Act Articles 12 and 18 (ten years from the last use of a high-risk system), even after the contractual relationship ends.
Data classes
Identity and account data
| Field set | Tables | Retention period | Lawful basis | Trigger |
|---|---|---|---|---|
User profile (email, name, zitadel_id) | users | Lifetime of the account; soft-delete to 90 days, then anonymised | Contract performance (Art 6(1)(b)) | Account closure or DSAR erasure request |
| Session state | si_session JWT cookie (stateless) | One hour (token TTL) | Contract performance | Token expiry; no server-side state |
| Tenant membership | tenant_members, tenant_member_roles | Lifetime of the tenant | Contract performance | Tenant deprovisioning, then anonymised within 30 days |
| Tenant identity | tenants (including erasure_salt) | Lifetime of the customer contract plus 30 days | Contract performance | Contract end; salt destruction triggers irreversible pseudonymisation |
Customer compliance data (the product output)
| Field set | Tables | Retention period | Lawful basis | Trigger |
|---|---|---|---|---|
| AI-system records | customer_systems | Tenant lifetime plus 10 years | Legal obligation — EU AI Act Art 18 (technical documentation retention) | Customer-initiated deletion respected, with audit-chain preservation |
| Section answers and evidence | customer_system_answers, customer_evidence | Tenant lifetime plus 10 years | Legal obligation — EU AI Act Art 12, 18 | Same as above |
| Classification decision records (sealed snapshots) | customer_cdrs | Tenant lifetime plus 10 years; sealed records are immutable | Legal obligation — EU AI Act Art 18 (regulator reproducibility) | Never deleted within the retention window; supersession only |
| Workflow audit chain | workflow_transitions | Tenant lifetime plus 10 years; append-only | Legal obligation — EU AI Act Art 12 (logs and oversight) | Never deleted; insert-only role enforcement at the DB layer (ADR-032) |
| Corpus-sync audit | corpus_sync_audit | Two years rolling | Legitimate interest — service-reliability evidence | Automated pruning (post-V1 follow-up) |
Operational and platform data
| Field set | Tables | Retention period | Lawful basis | Trigger |
|---|---|---|---|---|
| Platform audit events | audit_events | Tenant lifetime plus 7 years | Legal obligation — UK GDPR Art 5(2) (accountability) | Pseudonymisation on user erasure via erasure_salt; row survives |
| Identity audit events (Zitadel stream) | identity_audit_events | Two years rolling | Legitimate interest — security monitoring | Automated pruning (post-V1 follow-up) |
| Billing state | subscriptions, processed_stripe_events | Tenant lifetime plus 7 years (UK tax record-keeping) | Legal obligation — Companies Act, HMRC | Pseudonymisation of foreign-key references on tenant deprovisioning |
| Marketing-form definitions | hubspot_forms | Lifetime of the form (platform-level configuration) | Legitimate interest (marketing operations) | Manual deletion only |
Logs and observability
| Stream | Storage | Retention period | Lawful basis | Notes |
|---|---|---|---|---|
| Application logs (Pino) | Vercel log drain | 30 days | Legitimate interest (service reliability) | PII redacted at emission (email, name, IP fields) |
| Sentry error events | Sentry-managed | 90 days | Legitimate interest (service reliability) | No PII by design; events keyed by request ID |
| Transactional email logs (Resend) | Resend-managed | 30 days | Legitimate interest (service reliability) | Recipient and subject retained; bodies purged at Resend default |
| Vercel access logs | Vercel-managed | Vercel default (30 days) | Legitimate interest (service reliability) | Edge requests only |
Marketing and prospects
| Field set | Storage | Retention period | Lawful basis | Notes |
|---|---|---|---|---|
| Contact-form submissions | HubSpot | Until consent is withdrawn or 36 months | Consent / Legitimate interest | Withdrawal handled through HubSpot subscription preferences; mirrored in our hubspot_forms consent records |
| Newsletter and marketing-communication log | HubSpot | Until consent is withdrawn | Consent (Art 6(1)(a)) | Granular per-channel consent recorded |
Erasure model
Standard Intelligence applies a two-stage erasure pattern (docs/system/database.md §GDPR erasure pattern):
- Soft-delete the
usersrow (deleted_atset, PII fields cleared) on receipt of a verified erasure request. - Anonymise the user's
audit_eventsandworkflow_transitionsrows by replacingmember_idandtransitioned_bywithnulland populatingpseudonym_idwithSHA-256(actor_id ‖ tenants.erasure_salt). The chain survives with actor correlation preserved but identity removed.
Destroying the tenant's erasure_salt after the legal retention window makes re-identification cryptographically impossible. This upgrades pseudonymisation to full anonymisation as the audit-chain retention window closes.
Operational owners
- Identity, account, billing: Engineering (Martin Dean) for the platform; Finance (TBD post-funding) for billing reconciliation.
- Compliance and audit: Engineering until R3, then jointly with the compliance hire post-V1.
- Marketing: Michael Clark (Commercial).
- DPO: TBD before commercial launch.
Open items
The following retention controls are tracked outside this document and are scheduled to land before commercial launch:
- Automated pruning of
corpus_sync_auditandidentity_audit_eventsbeyond the two-year window. - Scheduled
erasure_saltdestruction job at the end of the per-tenant audit-chain retention window. - DSAR self-service flow in the tenant-admin panel (
#24). - HubSpot DSAR handler implementation (open follow-up).
This schedule is reviewed and updated at every release-planning gate.