One customer record, seven places the DPDP Act reaches it

Somebody in Pune fills in the contact form on your website on a Tuesday afternoon. By Friday their name, number and message are in your CRM, your inbox, a call recording, an AI assistant's history and last night's backup. You approved none of those places one by one. Your tools put the record there.

The Digital Personal Data Protection Act 2023 reaches that record at those places, and it asks something different at each. This note follows the record in the order a company finds out what it owes.

What is in force, and who can enforce it

The Rules and the commencement notification, G.S.R. 843(E), both published on 13 November 2025, switch the Act on in three steps.

• 13 November 2025: the definitions and the Board's constitution (sections 18 to 26, Rules 1, 2 and 17 to 21).
• 13 November 2026: registration of Consent Managers (section 6(9), Rule 4).
• 13 May 2027: everything a company does day to day, and the Board's power to inquire and fine (sections 3 to 17 other than 6(9), sections 28 to 34, Rules 3 and 5 to 16).

Eighteen months from 13 November 2025 is 13 May 2027, counted from the date of publication as Rule 1(4) does. In January 2026 the ministry floated a twelve month period, which would pull the date forward to 13 November 2026. We found no notification making that change on 15 October 2026, so plan for 13 May and watch for the other.

A penalty needs a duty in force, a Board to inquire, and a finding under section 33(1) that the breach is significant. Section 33 starts on 13 May 2027, and the Board has no members yet: on 6 May 2026 the ministry invited applications for one Chairperson and four Members, and we found no appointment on 15 October 2026. Until then section 43A of the Information Technology Act 2000 still applies, and the DPDP Act omits it from 13 May 2027 (section 44(2)(a)).

The date still binds you in practice. A customer's procurement team will not wait for a Board, and if a customer has sent you a DPDP clause, the contract already holds you to the Act.

The form: consent or a listed use, and nothing else

A person fills in your contact form. Section 4(1) lets you process what they typed on one of two grounds: they consented, or the use is one of the certain legitimate uses listed in section 7. The Act has no legitimate interest ground and no contract ground, and a company working from a GDPR programme will look for both.

Section 7(a) covers this form. A person who voluntarily gives you their details for a specified purpose lets you use them for that purpose. They asked for a callback, so you may call back. Adding them to a newsletter is a second purpose, and it needs their consent.

If consent is the ground, section 6(1) asks for consent that is free, specific, informed, unconditional and unambiguous, given by a clear affirmative action and limited to the data necessary for the stated purpose. Section 5 and Rule 3 put an itemised notice before the request, and section 6(4) makes withdrawal as easy as giving consent.

Section 6(10) puts the burden of proof on you. If consent is the ground and a question arises, the company must prove that it gave notice and that the person consented. A tick box with no record behind it proves nothing.

Good practice. Keep, for each person, the time, the version of the notice they saw and what they agreed to.

The vendors: an agreement does not move the duty

By Friday the record has left the building. The CRM vendor holds it, the email platform sends from it and the telephony provider recorded the call. Each is a Data Processor under section 2(k).

Section 8(1) makes the company responsible for processing done by its processors "irrespective of any agreement to the contrary". An indemnity clause can move the cost of a failure to the vendor, and the duty stays with you. Section 8(2) allows a processor only under a valid contract.

Take a company with forty software subscriptions. It has at least forty processors, and some of them sit on somebody's card and never reached IT. Section 11(1)(b) entitles a person to the identity of every Data Fiduciary and Data Processor their data was shared with, and a company that cannot list its processors cannot answer.

Good practice. Keep a register with one row per tool: what personal data it holds, the contract that covers it, the region it runs in and who in the company owns it. The sections below ask for it again.

The AI assistant: the Act is silent, and the general duties apply

Somebody in sales pastes the enquiry into an AI assistant to draft a reply, and a scoring model ranks the lead.

The ordinary duties apply to an AI tool as they do to a spreadsheet. The words artificial intelligence, algorithm and profiling do not appear in the Act, and a person has no right to object to an automated decision. The Rules use "algorithmic software" once, in Rule 13(3), for Significant Data Fiduciaries only, a class the government had not notified when we checked. Five ordinary duties reach an AI tool in everyday use.

1. The contract. Section 8(2) needs a valid contract with the processor, and a free personal account an employee opens to paste customer text into is not one the company holds. Our reading: in the ordinary case that is a gap, although no ruling has tested the point.
2. The purpose. Consent covers the specified purpose in the notice (section 2(za)) and no other. Tuning a model on enquiries has no consent behind it unless the notice says so.
3. The decision. Section 8(3) requires the data to be complete, accurate and consistent where it is likely to be used to make a decision that affects the person. A model that ranks leads or shortlists candidates makes that kind of decision.
4. The logs. Rule 6(1)(b) and (c) ask for logs that detect unauthorised access, and staff on personal accounts leave no company log.
5. The exit. When a person withdraws consent, sections 6(6) and 8(7)(b) oblige the company to make its processors stop and erase. Our reading: a vendor that trains its own models on your prompts pursues a purpose of its own, which takes it outside the definition of a Data Processor in section 2(k) and puts the disclosure to it in your notice.

Ask every AI vendor three questions in writing. Do you keep prompts and outputs, and for how long? Do you train on them? Can you erase one named person's data and show us that you did?

The border: transfers are open until the government names a country

Many AI tools process abroad. Section 16(1) lets the government restrict transfers to countries it names by notification, and allows the rest. We found no country named on 15 October 2026. Section 16(2) leaves any stricter sector rule standing, such as the Reserve Bank's April 2018 direction that payment data be stored in India.

That puts the region on your register. If a country is notified, a region column lets you list the affected tools in an afternoon.

The delete button: a one year minimum, and no stated maximum

The enquiry went nowhere. Months later the person is still in your systems.

Section 8(7) tells the company to erase personal data when consent is withdrawn, or as soon as it is reasonable to assume the purpose is no longer served, and to have its processors erase it too. Two rules sit on top.

The first is a ceiling for a few. Rule 8 and the Third Schedule set a three year limit for large e-commerce entities, online gaming intermediaries and social media intermediaries only. Every other company gets the section 8(7) standard and no number.

The second is a floor for every company. Rule 8(3) requires you to keep personal data, traffic data and processing logs for at least one year, for the purposes in the Seventh Schedule, before erasing them. The Rules' own illustration is an e-book platform that keeps a customer's order details for a year after she deletes her account.

Good practice. Give every kind of record two figures in the retention schedule: the shortest time a law makes you keep it, and the longest you can defend keeping it. Somebody has to decide the gap and write it down.

Then find where the record lives. The CRM row is the easy one. The mailbox, the call recording, the vector index an AI search tool built from them and the backup are harder. Deleting a row does not delete an embedding made from it, and we know of no reliable way to remove one person's influence from a trained model short of retraining it.

Records collected before the Act need a separate pass. Section 5(2) protects consent given before commencement, if you send those people a notice as soon as reasonably practicable, and it says nothing about data collected with no consent at all, such as a purchased list. Sort the old CRM into rows with a consent record and rows without.

The question: you answer an access request from your register

A year on, the person writes to ask what you hold on them and who you gave it to. Section 11 entitles them to a summary of the data and the processing, and to the identities of everyone it was shared with. Section 12 adds correction and erasure.

Rule 9 requires you to publish the contact details of a person who can answer questions. Rule 14(3) requires a published grievance process that responds within ninety days at most, and section 13(3) obliges the person to use it before going to the Board, so your grievance desk is the first place a complaint lands.

Good practice. Put a named person and a monitored address in the Rule 9 notice, and send yourself a request before a customer does.

The breach: a six hour clock today and a seventy-two hour clock from May 2027

Section 2(u) defines a personal data breach to include accidental disclosure and loss of access, not only theft. A ransomware attack that locks the CRM is a breach even if no one reads a row, and so is a reply sent to the wrong customer.

Section 8(5) requires reasonable security safeguards, and Rule 6(1) sets the minimum: encryption or masking, access control, logs and monitoring, backups, one year of log retention and security terms in each processor contract.

Section 8(6) and Rule 7 require the company to tell each affected person without delay, and to tell the Board without delay and again within seventy-two hours with the cause, the mitigation and the fix.

The other clock belongs to CERT-In. Its directions of 28 April 2022 already require a reportable cyber incident to be reported within six hours of noticing it, and they apply today. A breach at a vendor remains the company's to report (sections 8(1) and 8(6)), so the contract should oblige the vendor to tell you without delay.

Good practice. Write the runbook before the incident, name who calls whom, and put both clocks at the top.

The penalty schedule ranks the work for you

The Act enforces its duties through one table. The Schedule has seven rows.

• Failing to take reasonable security safeguards (section 8(5)): up to 250 crore rupees.
• Failing to tell the Board and affected people about a breach (section 8(6)): up to 200 crore rupees.
• Failing the duties on children's data (section 9): up to 200 crore rupees.
• Failing the extra duties of a Significant Data Fiduciary (section 10): up to 150 crore rupees.
• A Data Principal failing their duties under section 15: up to ten thousand rupees.
• Breaching a voluntary undertaking the Board accepted (section 32): up to the amount that applied to the original breach.
• Any other provision of the Act or the Rules: up to 50 crore rupees.

The last row carries most of the Act's duties: notice, consent, erasure, processor contracts, access and the grievance process. The privacy notice and the consent banner are where most companies start, and they carry the lowest ceiling that applies to a company. The two largest ceilings attach to protecting the data and to telling people when you failed. By the ceilings, the Act puts security and incident handling first and consent second.

Treat the figures as ceilings. Section 33(1) lets the Board penalise only a breach it finds significant, after a hearing, and section 33(2) tells it to weigh gravity, duration, the type of data, repetition, any gain made and whether the company mitigated the harm and how fast it acted. Nothing in the Schedule scales with the number of people affected or with turnover. A company that kept records can show its mitigation under section 33(2)(e) and offer a voluntary undertaking under section 32.

Before 13 May 2027, in the order of the ceilings

1. Secure the record. Check the company against the Rule 6(1) list and write the breach runbook with both clocks.
2. Build the register. One row per tool, AI tools staff use without telling anyone included.
3. Put a ground against every purpose. Consent or a section 7 use. Where it is neither, stop or ask.
4. Fix the form and keep the proof. Rewrite the notice to Rule 3 and log each person's choice.
5. Write the retention schedule. Two figures per record, and a sort of the legacy data.
6. Name the person who answers. Publish the Rule 9 contact and the grievance route, and test them.

Doing this yourself

If you run a CRM, a mail platform and a handful of vendors under written contracts, and every AI tool in use came through the company, most of this is a spreadsheet and the vendor invoices. Do it yourself and send the result to somebody who will be rude about it. If the register turns up AI tools no one chose, vendors with no contract or a legacy list with no consent record, outside help is worth paying for at that point. Our governance practice does that work.

We built AIAuditSense to check a website, repository or product description against the Act, with each gap tied to a clause. Its inputs are the notice, the forms and the code. Your vendor contracts, your backups and what a salesperson pastes into which window sit outside them, so it covers the first stop on the record's route and none of the others.

Sources and when we checked them

• Digital Personal Data Protection Act 2023, Gazette of India, 11 August 2023. Checked 15 October 2026.
• Digital Personal Data Protection Rules 2025, G.S.R. 846(E), 13 November 2025. Checked 15 October 2026.
• Commencement notification G.S.R. 843(E), 13 November 2025. Checked 15 October 2026.
• MeitY circular F. No. 2(1)/2026-Pers.I, 6 May 2026, inviting applications for the Board. Checked 15 October 2026.
• Reserve Bank of India circular DPSS.CO.OD.No 2785/06.08.005/2017-18, 6 April 2018, on storage of payment system data. Checked 15 October 2026.
• CERT-In directions under section 70B(6) of the Information Technology Act 2000, 28 April 2022. Checked 15 October 2026.

This article is general information, not legal advice. Classification and obligations depend on facts specific to your organisation. Take advice before acting on anything here.