User data has a bounded retention period enforced by a purge mechanism or a committed retention schedule
Why it matters
SOC 2 C1.2 requires that confidential information be disposed of when it is no longer needed, and "show me your retention schedule and the mechanism that enforces it" is a standard confidentiality-section request; this check evidences C1.2 directly (ISO 27001 A.8.10 and NIST SI-12 map the same obligation). AI-generated and vibe-coded apps fail this almost universally: coding assistants scaffold tables that only ever grow (users, sessions, events, messages, request logs) because every training example inserts and none deletes, so the default posture is indefinite retention of everything, which inflates breach blast radius, storage cost, and GDPR storage-limitation exposure with every day the app runs. One passing leg of this check is an evidence-pointer: where retention is enforced by a managed platform or an operations habit rather than repo-visible code, a committed retention schedule document naming data classes and periods is the evidence, which is exactly the artifact a SOC 2 auditor will ask for. This check is deliberately distinct from account-deletion-coded in this same audit: that one is user-initiated erasure on request (GDPR Art. 17); this one is systematic retention bounds for data nobody asked to delete.
Severity rationale
Medium because unbounded retention does not itself expose data, but it silently compounds breach blast radius and regulatory exposure over time and leaves the C1.2 disposal criterion with zero evidence until a purge mechanism or schedule exists.
Remediation
Pick the cheapest leg that fits your stack. Code leg: add a scheduled purge, for example a vercel.json crons entry pointing at app/api/cron/purge-expired/route.ts that runs DELETE FROM sessions WHERE created_at < now() - interval '90 days' (or the Prisma/Drizzle equivalent), or a cron.schedule(...) call in a pg_cron migration under supabase/migrations/. Storage leg: a Mongo TTL index (expireAfterSeconds), a DynamoDB TTL attribute in your IaC, or Redis EXPIRE on user-data keys. Evidence leg: commit docs/ops/data-retention.md listing each stored data class (accounts, sessions, analytics events, logs, backups) with its retention period and how disposal happens, including "retained indefinitely" entries where that is a deliberate choice. Platform-enforced retention documented in that file is acceptable auditor evidence; undocumented defaults are not.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the SOC 2 Technical Readiness Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- soc2:2017 · C1.2 — Confidentiality — disposal of confidential information
- iso-27001:2022 · A.8.10 — Information deletion
- nist:rev5 · SI-12 — Information Management and Retention
Taxons
History
- 2026-07-03·v1.0.0·Initial soc2-readiness v1 authoring — bounded retention via scheduled purge, database-level TTL, or a committed retention schedule doc, kept explicitly distinct from user-initiated account deletion.·by soc2-readiness-v1-build