The main obligations under India's Digital Personal Data Protection Act switch on in roughly six months, and most of the work they create is engineering rather than legal drafting. A privacy policy update will not get you there. Your forms, your logs, your CRM's deletion behaviour and your contracts with vendors will.
This post sets out what the rules actually say, quoted from the government's own text rather than from summaries of summaries, and translates each obligation into what changes in a website, an app or an internal system. It is not legal advice, and where the text is ambiguous we say so instead of guessing.
When does any of this actually apply?
The DPDP Rules, 2025 were notified on 13 November 2025 (G.S.R. 846(E)), and the government's own explainer describes an eighteen-month phased rollout. Rule 1 sets three dates:
| What | Comes into force | Roughly |
|---|---|---|
| Definitions, the Data Protection Board, appeals (Rules 1, 2, 17–21) | On publication | November 2025 — already live |
| Consent Manager registration (Rule 4) | One year after publication | November 2026 |
| Notice, security, breach reporting, retention, children, user rights (Rules 3, 5–16, 22, 23) | Eighteen months after publication | May 2027 |
The third row is the one that matters for almost every business. If you are reading commentary that says the 72-hour breach clock is already running, check it against Rule 1(4): the breach rule is Rule 7, and Rule 7 sits in the eighteen-month group.
Six months sounds comfortable. It is not, if your CRM has no way to delete a contact cleanly or your server logs currently vanish after fourteen days. Those are build tasks with their own testing and migration, and they queue behind whatever else your developers are doing.
One caution on dates: there was talk earlier this year of shortening the window. As of writing we have not found an amending notification, so we are working from the published text. Check MeitY before you plan around the date.
Does it apply to a small business?
Almost certainly yes, if you collect personal data from people in India in digital form, or collect it offline and then digitise it. There is no turnover or headcount threshold in the Act for the core duties.
The Act does let the government exempt some data fiduciaries, "including startups", from a handful of sections under Section 17(3). We have not seen any such exemption notified. Do not build your plan around one arriving.
The heavier duties are scoped to size. The three-year deletion rule in the Third Schedule applies to e-commerce entities and social media intermediaries with at least two crore registered users in India, and online gaming intermediaries with at least fifty lakh. Data Protection Impact Assessments and annual audits apply only to entities the government notifies as Significant Data Fiduciaries. Most of our readers will be neither.
What has to change on your forms?
Two things: the notice, and the consent itself.
The notice. Rule 3 requires a notice that can be understood "independently of any other information" — so a link to a 4,000-word privacy policy does not do the job on its own. At the minimum it must give an itemised description of the personal data you collect, the specific purpose, and a description of the goods or services that the processing enables. It must also tell people how to withdraw consent, how to exercise their rights and how to complain to the Board.
Section 5(3) of the Act adds that people must be able to read the notice in English or any of the 22 languages in the Eighth Schedule of the Constitution. That is a content and translation task as well as a front-end one.
The consent. Section 6(1) says consent must be "free, specific, informed, unconditional and unambiguous with a clear affirmative action", and limited to the data necessary for the purpose. In interface terms:
- No pre-ticked boxes. A clear affirmative action means the person does something.
- No bundling. The Act's own illustration is a telemedicine app that also asks for the contact list; consent to the second is not valid because it is not necessary for the first. If your signup form gates the product behind marketing consent, that is the same pattern.
- Withdrawal "comparable to the ease with which such consent was given" (Section 6(4)). If consent was one tap, withdrawal cannot be an email to a support inbox that nobody answers.
Not everything needs consent. Section 7(a) lets you process data someone has voluntarily given you for a specified purpose, unless they have told you they object. The Act's example is a person messaging a property broker for help finding a flat. A visitor who fills in your enquiry form so you can call them back is in similar territory. Adding that same person to a monthly newsletter is not.
Existing records. For data collected before the Act, Section 5(2) requires a notice "as soon as it is reasonably practicable", by email, in-app notification or similar. If you have fifty thousand contacts in a CRM, that is a campaign you will need to plan, send and record.
What does Rule 6 mean for how a system is built?
Rule 6 lists the minimum "reasonable security safeguards". Read as an engineering spec, it asks for:
| Rule 6 requirement | What it usually means in practice |
|---|---|
| Encryption, obfuscation, masking or tokens | Encryption at rest and in transit; masking phone numbers and IDs in admin screens and exports |
| Access control over computer resources | Role-based permissions, no shared admin logins, offboarding that actually revokes access |
| Visibility through logs, monitoring and review | Logs of who accessed which personal data, and someone who looks at them |
| Continued processing if data is compromised | Tested backups, not just configured ones |
| Retain logs and personal data for one year | Log retention long enough to investigate a breach found months later |
| Security terms in contracts with Data Processors | Your agreements with hosting, CRM, email and payment vendors |
The access-log requirement is the one we expect most small systems to fail. Plenty of web applications log requests. Far fewer record that a particular staff member opened a particular customer's record and exported it. If your admin panel was built quickly, this is retrofit work.
The penalty that maps to this rule is the largest in the Act's Schedule: failing to take reasonable security safeguards "may extend to two hundred and fifty crore rupees". That is a ceiling, not a tariff, and the Board is required to weigh factors such as the nature and gravity of the breach. We are not aware of the Board having imposed any penalty yet, so nobody knows how it will set them in practice for a small firm. We would not quote a likely figure.
What happens when there is a breach?
Rule 7 has two parts, and engineers should notice that neither contains a materiality threshold. It applies "on becoming aware of any personal data breach".
- Each affected person, without delay: what happened, the likely consequences for them, what you are doing about it, what they can do, and a contact person.
- The Board, without delay, followed by a detailed report within 72 hours covering the facts, the cause, mitigation, any findings about who caused it, and a report on the notifications sent to individuals.
Seventy-two hours is very little time to reconstruct what happened if your logs do not exist. This is why Rule 6 and Rule 7 belong together: the logging work is what makes the breach report possible. It also means you need to know, today, which of your systems hold personal data, so that "which customers were affected" is a query rather than a forensic project.
Do you now have to keep data, or delete it?
Both, which is the part that confuses people.
Rule 8(3) requires every data fiduciary to retain personal data, traffic data and processing logs for a minimum of one year from the date of processing, and to cause them to be erased after that unless another law requires longer. The rule's own illustration is an e-book purchase: the platform must keep the order, payment and delivery records for a year even if the buyer deletes their account. Section 8(7) of the Act separately requires erasure once the purpose is served or consent is withdrawn.
So "delete my account" cannot mean DELETE FROM users. It needs a design: suspend the account, retain what the one-year rule and other laws (GST and accounting rules, for a start) require, then erase on a schedule. And because Section 8(7)(b) requires you to make your Data Processors erase the data too, deletion has to propagate to your email platform, your CRM and your analytics, not just your own database.
For the large platforms in the Third Schedule there is an additional rule: erase data after three years of inactivity, and warn the person at least 48 hours before you do.
Which other duties need building?
- A published contact. Rule 9 requires the business contact of a Data Protection Officer, or someone who can answer questions about processing, to be published prominently on the website or app.
- A rights request route. Rule 14 requires you to publish how people can request access, correction or erasure, what identifier you need from them, and your response period for grievances, which cannot exceed ninety days. This is a form, a queue and an owner.
- Children. Section 9 of the Act requires verifiable parental consent before processing the data of anyone under eighteen, and bans "tracking or behavioural monitoring of children or targeted advertising directed at children". Rule 10 describes how to verify that the parent is an identifiable adult, including through DigiLocker. If your audience includes students — as education businesses' audiences usually do — this is the single most expensive part of compliance, and it needs designing early.
What nobody can tell you yet
There are real gaps, and confident vendor checklists tend to paper over them.
Cookies and analytics. Neither the Act nor the Rules mention cookies by name. Whether a standard analytics tag needs prior consent under the "clear affirmative action" test is not settled, and we have found no guidance from the Board on it. A consent banner that genuinely blocks non-essential tags until accepted is the cautious choice; anyone telling you it is definitely required, or definitely not, is ahead of the law.
What "reasonable" means. Rule 6 lists categories of safeguard, not standards. There is no named certification that proves compliance.
Enforcement posture. The provisions setting up the Board are in force, but until it decides cases nobody knows how it will treat a mid-sized business that did most things right.
What not to do
Do not buy a consent tool and call it done. A consent management platform handles one row of the obligations above. It does nothing for access logs, deletion that propagates to vendors, or the 72-hour report.
Do not rewrite the privacy policy first. The policy should describe what your systems actually do. Change the systems, then write it.
Do not delete everything to be safe. Rule 8(3) requires a year of retention. Purging logs to reduce exposure can itself be a breach of the rules.
Do not assume your vendors have it covered. You remain the data fiduciary when your data sits in a third-party CRM. Rule 6(1)(f) puts the contract terms on you.
Where to start this month
Make a list of every system that holds personal data — website forms, CRM, email platform, payment gateway, spreadsheets, WhatsApp exports — and for each one answer three questions: can we find a specific person's data, can we delete it everywhere, and can we see who accessed it. The gaps in that list are your build plan. For most small businesses it is a few weeks of focused work, not a platform rebuild.
If the gaps sit in a system we can fix — a site's forms and consent flow, a web application's permissions and logs, or a CRM that cannot delete anyone cleanly — tell us what you are running and we will tell you which items are real work and which are a configuration change. For the legal reading of your specific situation, you also need a lawyer; we will say so rather than pretend otherwise.
Bharat Vasireddy
Founder & Digital Marketing Strategist8+ years of experience in performance marketing and web development. I help businesses scale through data-driven SEO, Google Ads, and high-performance websites.