India's data protection law has generated a great deal of guidance in a short time. Vendors, consultancies and training providers have all published explainers, and much of it is useful. Some of it, though, is wrong in ways that matter. A few errors come from carrying over the GDPR. Others come from reading the draft Rules of January 2025 as if they were final. Some are simply repeated from one website to the next.
An organisation that builds its programme on a wrong reading pays for it twice: once to build the wrong thing, and again to fix it before 13 May 2027. This article goes through ten of the most common claims, what the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 actually say, and what to do instead.
None of this is legal advice for a specific situation. Where a point is close, take advice on your own facts.

1. "Penalties are a percentage of global turnover"
This comes from the GDPR, where fines are calculated as a share of annual turnover. The DPDP Act works differently. Its Schedule sets fixed maximum amounts for each type of breach, and the Board decides the actual penalty after an inquiry.
| Breach | Maximum penalty |
|---|---|
| Failure to take reasonable security safeguards to prevent a personal data breach | ₹250 crore |
| Failure to notify the Board or affected Data Principals of a breach | ₹200 crore |
| Failure to meet the additional obligations for children's data | ₹200 crore |
| Failure to meet the additional obligations of a Significant Data Fiduciary | ₹150 crore |
| Breach of any other provision of the Act or Rules | ₹50 crore |
Section 33(2) sets out what the Board must consider when it decides the amount: the nature, gravity and duration of the breach, the type of data affected, whether it was repeated, whether the organisation gained or avoided a loss, what it did to mitigate the effects, and whether the penalty is proportionate.
What to do: stop modelling exposure as a percentage of revenue. Model it per type of breach, and keep evidence of mitigation, because the Board is required to weigh it.
2. "You must tell affected people within 72 hours of a breach"
The seventy-two hours in the DPDP Rules apply to a detailed report to the Board. The duty to inform affected people is different: the Rules require it without delay. The notice must explain what happened, the likely consequences, what the organisation is doing about it, what people can do to protect themselves, and who to contact.
In practice, an organisation that waits seventy-two hours to tell customers has already failed the "without delay" standard. And for any incident that also falls under CERT-In's 2022 directions, the report to CERT-In is due within six hours of noticing it.
| Clock | Who is told | When |
|---|---|---|
| CERT-In directions, 2022 | CERT-In | Within six hours of noticing the incident |
| DPDP Rules | Affected Data Principals | Without delay |
| DPDP Rules | The Data Protection Board, first intimation | Without delay |
| DPDP Rules | The Data Protection Board, detailed report | Within seventy-two hours, unless the Board allows longer |
The detailed report to the Board covers the facts of the breach, its causes, the mitigation taken, the findings about the person responsible where known, the remedial steps, and the notices sent to the people affected.
What to do: build one incident timeline with three clocks running from the same moment: CERT-In at six hours, people affected without delay, and the detailed report to the Board within seventy-two hours. Add your sector regulator's clock if it has one.
3. "You have 30 days to answer a rights request"
Thirty days appears in some guidance because it echoes the GDPR's one month. The DPDP Rules set an outer limit of ninety days for responding to rights requests and grievances. Within that limit, each Data Fiduciary must publish its own timeline, and once published, the organisation is held to it.
Two practical points follow. The clock should start when the request reaches you through any channel you have published, including email and branches, not only when it reaches the privacy team. And identity verification should be proportionate: asking for more documents than you need to confirm who someone is can itself become a grievance.
The ninety days is a ceiling, not a target. Customers judge an organisation by how quickly it responds, and a slow answer is the most common reason a grievance turns into a complaint.
What to do: publish a period you can reliably meet, track every request against it, and warn owners well before the clock runs out.
4. "Data Principals have a right to data portability"
Several explainers list portability among DPDP rights. It isn't there. The Act gives Data Principals the right to access information about their personal data under Section 11, the right to correction, completion, updating and erasure under Section 12, the right to grievance redressal under Section 13, and the right to nominate someone to act for them under Section 14.
Section 11 is broader than many people realise. An access request covers a summary of the personal data being processed and the processing activities, and the identities of every other Data Fiduciary and Data Processor with whom the data has been shared, along with a description of what was shared.
What to do: design rights handling around the four rights the Act contains, and make sure your systems can produce the list of recipients that Section 11 requires.
5. "Legitimate interests covers marketing and analytics"
There is no legitimate interests ground in the DPDP Act. Processing is lawful under Section 4 only with consent or for one of the legitimate uses listed in Section 7, subject to the exemptions in Section 17.
The Section 7 uses are specific. They include data a person has voluntarily provided for a specified purpose where they have not objected, certain State functions, compliance with law and court orders, medical emergencies, epidemics and disasters, and employment purposes. Marketing, profiling and most analytics aren't among them.
Registers built on GDPR templates often file these activities under legitimate interests. Under the DPDP Act, they need consent.
What to do: review every activity in your register that relies on legitimate interests. Move each one to consent or to a specific Section 7 use, and change notices and journeys to match.
6. "The Data Protection Board is up and running"
The Board was established in law when the Rules were notified on 13 November 2025, and the provisions setting it up are in force. As of September 2026, however, the public record shows no Chairperson or Members appointed. MeitY invited applications in May 2026, and the process is under way.
Some vendors have published claims that the Board is fully operational, or that its leadership was appointed months ago. Neither is supported by the public record.
This doesn't mean enforcement is a distant prospect. The substantive obligations apply from 13 May 2027 regardless. A Board that begins hearing complaints later can still examine conduct from that date onwards.
What to do: plan to the statutory date, not to the Board's staffing. Track appointments, but don't treat delay as a reason to wait.
7. "A Consent Manager is any consent management tool"
In the Act, a Consent Manager is a specific kind of entity: a person registered with the Board who acts on behalf of Data Principals, giving them a single place to give, manage, review and withdraw consent across many Data Fiduciaries. The Rules set the conditions for registration, and these provisions apply from 13 November 2026.
A consent management platform used by a company to collect and record its own customers' consent is a different thing. It works for the Data Fiduciary, not for the Data Principal. Describing such a tool as a "Consent Manager" confuses the two roles and suggests a registration that hasn't happened.
The difference matters in practice. A registered Consent Manager owes duties to Data Principals and is accountable to the Board for how it acts on their behalf. It must not have conflicts of interest with the Data Fiduciaries it deals with. A vendor's platform owes duties to the vendor's customer under contract. Mixing the two up can mislead customers about who is acting for them.
What to do: keep the terms separate in procurement and in your notices. Your consent platform should be able to work with registered Consent Managers when they exist, without claiming to be one.
8. "The Act is about customer data"
The Act protects every Data Principal, meaning every natural person to whom the personal data relates. That includes employees, contractors and job applicants, including the ones you rejected. It includes co-borrowers, guarantors and nominees, visitors captured on CCTV, and the individuals you deal with at business customers and suppliers.
Most early registers list customers and stop. The other populations are often where the gaps are: personal data about applicants kept indefinitely, guarantors who never received a notice, CCTV footage with no retention rule.
Employment processing does have a legitimate use under Section 7. That covers processing for employment purposes. It does not extend to every use of employee data, and it does not cover the other populations.
What to do: add a "whose data" field to every processing activity, and list every population it touches.
9. "Hashing personal data makes it anonymous"
Hashing a value turns it into a fixed-length string. For data with only a limited number of possible values, the hash can be reversed by trying every possibility. Indian mobile numbers are ten digits, and only certain starting digits are in use. Every possible hash can be calculated in a short time with ordinary hardware. The same is true of many other identifiers with predictable formats.
A hashed mobile number is therefore still personal data, and an unsalted hash isn't an adequate safeguard on its own. Rule 6 of the DPDP Rules expects reasonable security measures, including encryption, obfuscation or masking, and the use of virtual tokens mapped to personal data. Weak pseudonymisation that can be undone easily is unlikely to meet that standard.
What to do: treat hashed identifiers as personal data. Where you need a stable reference without the identifier itself, use keyed hashing or tokenisation, with the key held separately and access controlled.
10. "Compliance means having the right policies"
Policies matter, but the Act is written around what an organisation does and what it can show. Section 6(10) puts the burden of proving that a notice was given and consent obtained on the Data Fiduciary. Section 8(5) requires security safeguards to be in place, not described. The Rules require logs, retention for a minimum period, and evidence of what was done in response to a breach.
When a complaint arrives, the questions will be specific. What did this person see before they agreed? When did they withdraw, and when did processing stop? Which systems held their data, and what happened to it after they asked for erasure? A policy can't answer those questions. Records can.
There is a practical point here too. Records created at the moment something happens are far more convincing than records assembled afterwards. A consent record written when the person chose, holding the exact notice text they saw, is strong evidence. A spreadsheet compiled during an investigation is weak evidence, however carefully it is put together.
What to do: for each obligation, decide what record proves it, and make sure that record is created as a matter of routine, with the date, the version and the person responsible.
Four more worth knowing
"Paper records are outside the Act." Mostly true, with an important exception. The Act applies to personal data collected in digital form, and to personal data collected in non-digital form and digitised later. A paper form scanned into a document system, or keyed into a core platform, is within scope from that point.
"Cross-border transfers need approval." The DPDP Act doesn't require approval or a standard contract for transfers outside India. Section 16 allows the government to restrict transfers to specific countries by notification. No such list has been published. Sector rules still apply on top, such as RBI's requirement that payment system data be stored in India.
"Every company must appoint a Data Protection Officer." Only a Significant Data Fiduciary must appoint a Data Protection Officer, who must be based in India and responsible to the Board of Directors or similar governing body. Every other Data Fiduciary must publish the business contact details of a person who can answer questions about its processing, under Section 8(9). Many organisations will choose to appoint a DPO anyway, and that is often sensible. It just isn't a universal legal requirement.
"Children means under 13." Under the DPDP Act, a child is anyone who has not completed eighteen years of age. That is much older than the thresholds many global platforms use. Verifiable consent from a parent or lawful guardian is needed before processing a child's personal data, and tracking, behavioural monitoring and targeted advertising directed at children are prohibited. The Rules exempt certain classes of processing, for example by healthcare providers and educational institutions within defined limits. Any service that teenagers might use needs to take this seriously.
How to check what you read
DPDP guidance will keep multiplying as the date approaches. Five simple checks catch most errors.
- Does it cite a section or rule? A claim about an obligation should point to where it sits in the Act or the Rules. If it doesn't, treat it as opinion.
- Is it reading the final Rules? The draft Rules published in January 2025 differ in places from the Rules notified on 13 November 2025. Guidance written in early 2025 may describe provisions that changed.
- Is it describing the GDPR? Terms like "legitimate interests", "data portability", "controller" and "special category data" are signs that the writer is working from European law.
- Does the date of the claim matter? Statements about the Board, Consent Manager registrations or notified restrictions on transfers can go out of date quickly. Check when the source was written.
- Who benefits from the claim? Guidance that makes the law sound more demanding than it is often comes attached to a product that solves the exaggerated problem.
When in doubt, read the provision itself. The Act runs to forty-four sections, and most of them are short.
Why accuracy matters
Each of these errors leads somewhere expensive. A programme built on legitimate interests has to rebuild its consent journeys. A breach plan built around a seventy-two-hour customer notice fails the standard the Rules actually set. A rights process designed for thirty days wastes effort, while one that ignores the recipient list in Section 11 fails the first serious access request.
Before 13 May 2027, every organisation will make dozens of decisions based on its reading of the law. The cheapest time to check that reading is now.