A retention schedule becomes useful only when it can drive behaviour in real systems. A sentence saying data is kept “as long as necessary” may state a principle, but it does not tell an engineer when a clock starts, a support lead which record is covered, or an auditor how deletion was verified. A practical schedule connects purpose, record class, trigger, period, exceptions, systems, owner, deletion method, and evidence.
This guide is role-neutral. It does not decide whether a particular organisation or activity falls into a statutory category, nor does it prescribe a retention period. Those decisions depend on current law, other obligations, and the facts.
What should a retention schedule actually contain?
Build the schedule around record classes that teams can recognise. “Customer data” is usually too broad. Account profile, billing record, support attachment, access log, marketing suppression record, and identity-verification evidence may have different purposes and system paths.
| Field | What to record | Why it matters |
|---|---|---|
| Record class | A recognisable group of records | Gives operators a usable scope |
| Purpose | The approved operational reason | Anchors necessity review |
| Systems | Primary, replica, archive, export, vendor | Prevents partial deletion |
| Trigger | Event that starts the clock | Makes timing repeatable |
| Period or rule | Counsel-approved duration or condition | Drives execution |
| Exception | Hold, dispute, fraud, statutory duty | Prevents improper disposal |
| Method | Delete, anonymise, aggregate, restrict | Defines the action |
| Owner | Accountable business and technical roles | Creates follow-through |
| Evidence | Log, report, ticket, sample test | Supports verification |
Use a controlled vocabulary, but allow notes for unusual systems. Record the source and approval date for each rule. If a period is under review, mark it as unresolved rather than inserting a convenient number.
Which official DPDP sources should shape the workflow?
Start with the official Digital Personal Data Protection Act, 2023 on India Code. Check current rules, notifications, and corrigenda through MeitY’s data protection framework and the eGazette portal. Commencement is staged, so the legal register should link an operational requirement to the controlling text and effective date rather than assuming the entire framework began at once.
The DPDP framework is not the only source that can matter. Tax, employment, sectoral, corporate, limitation, regulatory, security, and litigation duties may require preservation or affect disposal. Qualified counsel should resolve overlaps. The schedule should capture the resulting decision and source, not try to automate legal interpretation.
Where security logs fall within the official direction’s scope, consult the CERT-In directions under section 70B and related official FAQs. Do not treat one log-retention requirement as a universal period for all personal data.
How do teams discover copies before setting deletion rules?
Follow data from collection to final disposal. Interview people who operate the systems, not only policy owners. The same record may appear in a production database, search index, analytics platform, support ticket, data warehouse, exported spreadsheet, email attachment, mobile device, backup, and processor environment.
A discovery workflow can proceed as follows:
- Choose one business process, such as account closure.
- List every collection point and field group.
- Trace API calls, batch transfers, exports, and manual handoffs.
- Identify derived fields, caches, replicas, logs, and backups.
- Record system owners and available deletion controls.
- Compare the observed path with the existing inventory.
- Resolve unknown destinations before approving the schedule.
Do not promise immediate deletion if a backup architecture cannot perform it. Instead, document the actual behaviour, restrict restoration and access, define expiry, and assess the arrangement against current requirements. Policy language should match the tested system.
How should retention triggers be written?
A clear trigger is an event that a system or owner can observe. “After the relationship” is ambiguous if an account remains dormant, a subscription ends, a dispute continues, and finance records remain active.
Useful trigger patterns include account closure confirmed, contract terminated, transaction completed, support case closed, consent withdrawn, purpose completed, employee separation recorded, or legal hold released. A trigger may require a precedence rule. For example, deletion could run after the standard period only when no approved hold or statutory preservation rule applies.
Write trigger logic in plain language before translating it into code:
When the account-closure event is confirmed, start the approved period for the account-profile class. Before disposal, check the active-hold register. If a hold applies, restrict the relevant record and route it to the hold owner. Otherwise, execute the approved deletion method and save the run evidence.
This structure exposes dependencies. It also gives a reviewer something concrete to test.
How are legal holds and other exceptions controlled?
Exceptions should be narrow, authorised, searchable, and reversible. A blanket “do not delete” flag can quietly defeat the entire programme.
The exception record should include matter or reason, affected record classes, systems, custodian or population, issuing authority, start date, review date, access restrictions, and release instruction. Notify relevant system owners when the scope changes. On release, calculate the correct next action under the schedule rather than restarting every clock automatically.
Keep the preserved copy separate where practical and restrict it to the approved purpose. A legal hold is not permission for unrestricted reuse. Maintain an audit trail for issuance, acknowledgement, changes, and release.
What does a reliable deletion workflow look like?
Deletion is a controlled change. Start with a dry run that reports eligible records without removing them. Sample the result with business, privacy, and technical owners. Check exclusions, foreign keys, dependent objects, audit needs, and recovery behaviour.
A production run should record:
- schedule rule and version;
- system and record class;
- eligibility window and trigger;
- approved exceptions applied;
- count or bounded description of records selected;
- method executed and job identifier;
- errors, retries, and unresolved copies;
- operator and approval where required; and
- verification result and evidence location.
Deletion may mean secure removal, while another approved method could involve irreversible anonymisation or aggregation. Test whether the output can reasonably be linked back using data the organisation or relevant recipients possess. Simply removing a name or moving a file to an archive is not automatically anonymisation or deletion.
How should deletion be verified without retaining the deleted data?
Evidence should prove the process without rebuilding the dataset. Preserve rule versions, job logs, timestamps, error summaries, sampled identifiers transformed through an approved non-reversible method where appropriate, and reviewer sign-off. Avoid putting raw personal data into tickets merely to show that it was removed elsewhere.
Verification needs several views. Query the primary store, inspect search and cache behaviour, test user interfaces and APIs, check downstream syncs, confirm processor action, and understand backup expiry. A failed downstream call should create a visible exception, not disappear inside a “completed” status.
Use a periodic control test:
| Test | Evidence | Failure response |
|---|---|---|
| Eligibility | Sample agrees with trigger and rule | Pause run and correct logic |
| Holds | Active scope excluded | Restore or preserve, investigate |
| Completeness | Known stores covered | Add destination and remediate |
| Vendor action | Confirmation or API evidence | Escalate contract workflow |
| Recovery | Deleted data does not silently return | Fix restore procedure |
Who should own retention operations?
Ownership is distributed. Legal and privacy teams can interpret requirements and approve rule logic. Records or information-governance teams may maintain taxonomy. Business owners explain purpose. Engineering and IT implement controls. Security governs logs and incident evidence. Procurement connects processor commitments. Internal audit or control testing can challenge the design and operation.
Use one accountable owner per rule and named operational owners per system. A governance group should review unresolved conflicts, overdue implementations, exception ageing, failed deletion jobs, and material architecture changes. Dashboards should link to evidence and show uncertainty, not just completion percentages.
The DPDP compliance software guide describes a wider control system for privacy work. Gotham’s workflow overview, security information, and privacy page provide additional context for evaluating operational tooling.
How can an organisation start with one defensible slice?
Choose a bounded lifecycle with a clear trigger, such as a closed support case or terminated trial account. Map every copy, approve the rule, build a dry run, test exclusions, execute on a small population, and inspect evidence. Record surprises and update the inventory before expanding.
Then repeat by risk and operational readiness. This produces working controls sooner than writing a large schedule that no system can execute. Review rules when purposes, products, law, vendors, or architecture change.
For help structuring evidence-led compliance workflows, talk to Gotham or explore Gotham’s compliance practice. This educational guide is not legal advice, and no example period or workflow should be adopted without a current, fact-specific review.
