India's DPDP Transition Is Underway: What Document Evidence Should Teams Prepare?
Connect notices, privacy requests, processor records, and deletion decisions before the May 2027 operational phase
Published
A customer in India asks which personal data your organisation holds, withdraws consent for one use, and requests erasure. The account record is in a CRM, supporting documents are in a repository, and a service provider holds another copy. Prepare an evidence trail that connects the original notice, the request, each system owner's decision, and the confirmed outcome.
India's Digital Personal Data Protection (DPDP) Act, 2023 governs digital personal data. Its terminology calls the individual a Data Principal, the organisation deciding the purpose and means of processing a Data Fiduciary, and a service acting on its behalf a Data Processor. The Act (PDF), sections 2 and 3, sets out these roles and scope, including certain processing outside India connected with offering goods or services to people in India. Assess your activities and any exemptions before assigning obligations.
Separate the implementation phases
The November 2025 notifications do not activate every obligation at once. Read MeitY's Act commencement notification (PDF) alongside rule 1 of the DPDP Rules, 2025 (PDF). The phases below are a planning summary; use the applicable notification and current text to set your legal calendar.
- November 2025 · Initial phase
Institutional framework
Specified definitions, Board provisions, and enabling provisions commence. This establishes the framework rather than bringing every operational duty into force.
- November 2026 · One year
Consent-manager phase
Specified consent-manager provisions and rule 4 commence. This is a distinct phase, rather than the general deadline for all Data Fiduciary operations.
- May 2027 · Eighteen months
Operational phase
The remaining specified provisions, including the main processing duties and individual rights, commence with the corresponding rules.
A statutory Consent Manager is a Board-registered role, as defined in section 2(g) of the Act. Keeping consent evidence in a document system does not make the system a registered Consent Manager. Use MeitY's official document collection, including the December 2025 corrigendum, when confirming current requirements. Existing sector and other legal duties need their own assessment during the transition.
Build a connected evidence model
Start with one processing activity, such as customer onboarding. Assign an owner and link its purpose, personal-data categories, notice, consent or other permitted use, source systems, processors, and retention authority. The following fields are a proposed operational model, rather than a prescribed statutory template.
| Record | Useful evidence and relationships |
|---|---|
| Notice and consent history | Effective notice version, purpose, language, presentation event, consent action or withdrawal, timestamp, and source-system reference. |
| Privacy request | Request scope, proportionate identity checks, responsible owner, systems searched, reviewed decision, response, and delivery result. |
| Processor relationship | Relevant processing activity, contract version, security review, operational contact, and incident or deletion confirmations. |
| Retention decision | Affected records, approved rule and authority, triggering event, any exception, review date, and disposition result. |
| Incident record | Awareness time, affected activities, protected evidence, review decisions, communications, and follow-up actions. |
Use stable references to source records where possible. Copying every customer document into a broadly accessible privacy register creates another sensitive collection to govern. Separate the permissions and retention of the case file, the source data, and any response package.
Work through a request across three systems
Consider a fictional subscription business with a CRM account, onboarding documents in FormKiQ, and an external support platform. A customer withdraws optional marketing consent and asks for erasure. Treat withdrawal, the erasure assessment, and any continuing processing as separately recorded decisions.
Open and scope the case
Create case CASE-2026-00001, record the request and verification result, and identify the relevant account. Link the effective notice and consent events without exposing unrelated customer files to the case worker.
Assign actions to the system owners
Route the marketing withdrawal to the responsible application owner. Ask the CRM, document, and support owners to identify affected records and report proposed actions. Capture acknowledgments and failures as case evidence.
Review what can be erased and what must remain
Have the privacy owner approve the applicable retention assessment. If a transaction record must remain under an identified rule, record its authority, restricted purpose, access policy, and review trigger. Do not use a generic “business need” label as the retention decision.
Confirm the result before closing
Collect completion results from each system and processor, issue the approved response, and assign unresolved actions. A timeout or queued deletion remains open until the team can establish its outcome. Keep only the case evidence justified by its own retention rule.
This is a workflow rehearsal, not a legal conclusion that every record in the example can be erased. Measure where ownership, identity matching, approvals, or completion evidence breaks down, then fix those steps before scaling the process.
Govern deletion and retained evidence together
The Rules include retention requirements as well as erasure provisions. Rules 6 and 8 address specified security and processing records, including one-year retention requirements. Have the privacy owner translate the applicable provisions into record-specific schedules. An erasure request should reach that assessment rather than trigger an unconditional purge.
Document the retained subset
Identify the precise records, legal authority, permitted use, and review trigger. Restrict access and stop unrelated processing when the approved decision requires it.
Track completion beyond the repository
Include connected applications, processors, exports, and backup handling in the approved plan. Record what was completed, what remains protected under a schedule, and who owns follow-up.
FormKiQ's Records Management Business Solution manages retention schedules, holds, review, and disposition. Configure those controls to the approved record classes and connect external completion evidence to the case. Coordinate incident evidence with the response team so the privacy case does not become an uncontrolled copy of security logs.
Rehearse a retrievable case before the operational phase
- Confirm applicability, relevant implementation phases, and accountable privacy and system owners.
- Reconstruct the effective notice and processing purpose for a representative customer record.
- Complete a protected test request across the CRM, document repository, and a processor.
- Test a retention exception, including restricted access and the next review trigger.
- Make an integration fail and verify that the case stays assigned until its outcome is known.
- Retrieve the approved response and completion evidence without assembling a new audit pack.
Prepare evidence as part of the work
Use the transition to make one privacy workflow work from intake through reviewed completion. A connected record of the notice, request, system actions, retention decision, and response gives teams something they can operate and explain when a customer, reviewer, or regulator asks what happened.
Regulatory material reviewed: November 12, 2026. This guide proposes an operational evidence model. Confirm applicable commencement, current notifications, exceptions, and sector requirements with Indian privacy counsel.