EdTech Data Retention Schedule

Under DPDP, “store forever just in case” is no longer a strategy—it’s a liability. Here is how to build a compliant Retention Schedule for EdTech.

Auto-Erasure

Rule 8 introduces mandatory auto-erasure if a user doesn’t interact for a specified period.

Pre-Erasure Notice

You must notify the user at least 48 hours before their data is wiped, giving them a chance to login.

Security Baselines

You must retain traffic & security logs for at least 1 year to detect unauthorized access.

Purpose Tied

Retention must be strictly tied to a specified purpose. Once the purpose ends, the data must go.

The Design Strategy

Think in five buckets (easy for product + legal + engineering):

  1. Account & identity data (login, parent verification status)
  2. Learning & academic data (progress, submissions, attendance)
  3. Communications (support tickets, chats, class recordings)
  4. Payments & transactions (course purchase/subscription events)
  5. Security & audit logs (access logs, admin actions, proctoring events)

Then define for each bucket:

  • Purpose
  • Retention Trigger
  • Retention period
  • Deletion method
  • Exception (if another law or active dispute requires longer retention)

The Master Schedule

Use this as a baseline and adjust based on your exact purposes, contracts, and other applicable laws.

Data categoryWhat it includesKeep untilSuggested retention logic
User account datamobile/email, profile, roleaccount active + limited post-closure windowretain while account is active; on closure, erase after defined window unless legal necessity
Parent consent evidenceconsent ledger events, notice version shownaudit defensibilityretain as long as needed to demonstrate lawful processing (often longer than normal account data)
Learning progressscores, course progress, certificatesstudent expects continuityretain while account active; if inactive for long period, erase in phases (archive → erase)
Proctoring artefactssession recordings, screenshots, flagsdispute window endskeep minimal artefacts; strict retention + auto-delete; treat as high-risk
Payments/order eventspurchase confirmation, payment + delivery eventscompliance/audit needskeep at least 1 year from transaction/event date (Rule 8 baseline + illustration pattern)
Support ticketsgrievances, complaints, resolutionsgrievance SLA + auditretain through resolution + defined audit window
Security & access logslogin logs, admin actions, access trailssecurity monitoringretain 1 year (baseline under security safeguards) unless another law requires otherwise

Tip for EdTech: use two layers of retention

Layer 1: “User-facing data” (erase sooner)
Layer 2: “Security/audit logs” (keep longer, access-controlled)

Quick checklist

  • Retention is tied to a specified purpose
  • You can justify why each category is retained
  • Security logs retained 1 year (baseline), unless law requires otherwise
  • Transaction/order event records retained at least 1 year (baseline pattern)
  • Auto-erasure after inactivity has 48-hour pre-erasure notifications (where you use that pattern)
  • Deletion is provable (logs + deletion receipts)

FAQ

Rule 8(1) is framed for certain classes of Data Fiduciaries and purposes listed in the Third Schedule. Even if your EdTech isn’t in those classes, the design pattern (time-bound retention + inactivity triggers + pre-erasure notice) is a strong compliance approach.

Not safely. Your default should be: keep only as long as needed for the specified purpose, plus security/audit baselines and any longer retention required by other applicable laws.

Need a custom Retention Matrix?

We define the triggers, periods, and database specs for your specific data flows.

Get Retention Schedule