Back to Blog
How-To 7 min read

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.

Key Takeaways
  • 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.

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?
Retain CloudTrail logs, application audit logs, and access logs for at least 12 months — covering one full SOC 2 observation period. Many security frameworks recommend 12 months active plus 12 months archived.
Does DPDP Act require us to delete all personal data after account closure?
Section 8(7) requires erasure when the purpose is fulfilled. For most SaaS products, account closure signals the purpose is fulfilled. However, you may need to retain minimal data for legal obligations (financial records, dispute resolution). Define a reasonable post-closure grace period (30–90 days) and then delete remaining personal data.
How do we handle data retention for backups?
A 30-day rolling backup window is a common approach: daily backups retained for 30 days, weekly backups retained for 90 days, monthly backups retained for 1 year. Personal data in backups is subject to DPDP Act erasure obligations, but overwriting individual records in encrypted backups is often not technically feasible — a documented exception with a defined backup rotation schedule is acceptable.
Do we need a data retention policy for employee data separately from customer data?
Best practice is a single data retention policy that covers all data categories, with a table listing each category and its retention period. Employee data typically has different retention requirements from customer data. Separating them in the schedule (not in separate documents) is the most practical approach.
What is the penalty for not deleting personal data under DPDP Act?
The DPDP Act includes failure to delete personal data as a potential violation. The general penalty cap of ₹250 crore applies. Practically, enforcement begins with a DPBI investigation triggered by a data principal complaint or regulatory audit.

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