How to Implement a Data Retention Policy for SOC 2 and DPDP
Data retention requirements under SOC 2 and DPDP Act. Build a retention schedule, implement it technically, and generate audit evidence.
- SOC 2 CC6.5 requires that data is managed to protect against unauthorised access and secure disposal.
- DPDP Act Section 8(7) requires erasure of personal data once the purpose for which it was collected is fulfilled.
- Build a data retention schedule that assigns retention periods to each data category with justification.
- Technical implementation typically involves S3 Lifecycle policies, database TTL fields, and automated deletion jobs.
- Document each deletion run — this is your evidence for both SOC 2 and DPDP Act compliance.
In this guide
Why Data Retention Matters for Compliance
SOC 2 CC6.5 addresses the management of physical media and data to protect against unauthorised access and disposal. It requires documented procedures for retaining and disposing of data appropriately — retaining data only as long as necessary, then securely deleting it.
DPDP Act Section 8(7) is more explicit: Data Fiduciaries must not retain personal data beyond the period necessary to fulfil the purpose for which it was collected. After that period, the data must be erased. This creates a positive legal obligation, not just best practice.
Building a Data Inventory
Before you can set retention periods, you need to know what data you have and where it lives. A data inventory lists: data categories (personal data, financial data, log data, backup data), storage locations (production database, S3 buckets, backup storage, third-party SaaS), sensitivity level, and who owns each data category.
For a typical SaaS startup: production database (customer profiles, transaction records, usage logs), S3 (file uploads, exports, backup archives), application logs (CloudWatch, Datadog — user activity, error logs), and third-party SaaS (customer support tool with ticket history, CRM with prospect data).
Creating a Retention Schedule
For each data category, define: retention period, legal/contractual basis for the period, where it is stored, and the deletion mechanism. Example retention periods: production customer data — active account duration + 30 days after account closure. Financial transaction records — 7 years (Income Tax Act requirement in India). Application logs — 12 months. Backup archives — 90 days (rolling). Employee personal data — employment duration + 3 years.
Do not retain data without a defined retention period. Every data category without a defined period is a liability — both for DPDP Act and for SOC 2.
Technical Implementation
AWS S3: configure S3 Lifecycle rules for each bucket. For log buckets: transition to Glacier after 30 days, delete after 365 days. For backup buckets: delete after 90 days. S3 Lifecycle rules run automatically and generate CloudWatch metrics that can serve as deletion evidence.
Application databases: add a deleted_at timestamp column to personal data tables. Implement a scheduled job (Lambda function or cron job) that permanently deletes records where the archived date is older than the retention period. Log each deletion run with count of records deleted.
CloudWatch Logs: set log group retention periods in AWS Console or Terraform. This is a one-line configuration change that enforces automated log deletion.
Legal Hold and Exceptions
Legal hold: if personal data is the subject of ongoing legal proceedings, a regulatory investigation, or a legal hold notice, it must be preserved regardless of normal retention periods. Implement a legal hold flag in your data model that prevents automated deletion.
Minimum retention requirements: some data must be retained for minimum periods by law. Financial records: Income Tax Act (India) requires 6–7 years. GST records: 6 years. Document these minimum periods in your retention schedule.
Document exceptions: when data is retained beyond normal retention for legal hold or minimum retention reasons, document the specific reason, the extended retention period, and who authorised the exception.
Evidence for Auditors
SOC 2 evidence for CC6.5: your data retention policy (signed, approved, current), the data retention schedule (showing periods by data category), and evidence of retention enforcement (S3 Lifecycle policy screenshots, deletion job run logs, CloudWatch Log group retention configuration).
DPDP Act evidence: same retention schedule, plus records of any erasure requests handled and evidence of purpose-based deletion for former customers.
Store all deletion logs in a separate, tamper-evident location. The evidence of deletion must itself be retained.
Frequently Asked Questions
What retention period should we use for SOC 2 audit logs?
Does DPDP Act require us to delete all personal data after account closure?
How do we handle data retention for backups?
Do we need a data retention policy for employee data separately from customer data?
What is the penalty for not deleting personal data under DPDP Act?
Automate your compliance today
AuditPath runs 86+ automated checks across AWS, GitHub, Okta, and 14 more integrations. SOC 2 and DPDP Act. Free plan available.
Start for free