DPDP Data Retention Policy: How Long Can You Keep Personal Data?

DPDP's Retention Rules

DPDP Section 8(7) requires that personal data 'shall not be retained by a Data Fiduciary for any period longer than is necessary to satisfy the purpose for which it was processed'. There is no single maximum retention period — it depends on the purpose.

Common purpose-based retention periods: transaction records for financial services — match RBI's 10-year requirement; KYC data — match RBI KYC Master Direction (10 years after account closure); marketing emails — until unsubscribe + 1 year for evidence of consent record; customer support tickets — 2 years after ticket closure; LLM conversation logs — 30–90 days unless required for longer for audit.

Building a Retention Matrix

Create a data retention matrix: rows are personal data categories, columns are: system stored in, business purpose, legal basis, regulatory retention requirement, your retention period, deletion mechanism, last reviewed date. For each cell: choose the retention period that satisfies both the business/regulatory need and DPDP's minimum necessary principle.

Regulatory requirements override DPDP's minimisation principle: if SEBI requires a 5-year audit trail, you keep it for 5 years even if DPDP would otherwise allow less. However, once the regulatory period expires, DPDP requires deletion.

Automating Deletion

Manual deletion doesn't scale. Automate with: scheduled deletion jobs (run daily/weekly, delete records past their retention period), TTL (time-to-live) settings in your database or object store (S3 lifecycle policies, MongoDB TTL indexes, Redis TTL), and soft-delete with hard-delete scheduler (mark as deleted, propagate to backup and replicas, then physically delete after propagation window).

For LLM logs specifically: configure CrewCheck's audit log retention to match your policy. Logs older than your retention period are automatically purged. The retention config is documented at /developers.

Compliance operational checklist

DPDP Data Retention Policy: How Long Can You Keep Personal Data? should be reviewed as an operating control, not only as a reference article. The minimum checklist is a data inventory, a stated processing purpose, owner approval, PII detection at the AI boundary, redaction or tokenisation where possible, retention limits, vendor transfer records, and a tested user-rights workflow. This checklist gives engineering and compliance teams a shared language for deciding what must be blocked, what can be allowed in shadow mode, and what needs human review before production release.

For AI systems, the review should include prompts, retrieved context, tool call arguments, model responses, logs, traces, analytics events, exports, and support attachments. Many incidents happen because teams scan only the visible form field while sensitive data moves through background context or observability tooling. CrewCheck's recommended pattern is to place the scanner at the request boundary, record the policy version, and keep audit evidence that shows which identifiers were detected and what action was taken.

A practical rollout starts with representative samples from production-like traffic. Run a DPDP scan, sort findings by identifier sensitivity and blast radius, fix Aadhaar, PAN, financial, health, children's, and precise-location exposure first, then move to consent wording, retention, deletion, and vendor review. Use shadow mode when false positives could disrupt users, and promote to enforcement only after the exceptions have owners and expiry dates.

This page is educational and should be paired with legal review for final policy interpretation. The operational proof should still come from repeatable evidence: scanner results, audit exports, pull-request checks, policy configuration, and a documented owner for the workflow. That combination is what makes the content useful during buyer diligence, board review, regulatory questions, or an incident investigation.