Indian Data Protection Law (DPDP) Explained for Companies and Startups
Most Indian founders think DPDP is a privacy-policy problem. Rewrite the policy page, add a cookie banner, done. Then we sit down with them, open their signup flow, and ask one question: show me where the user gave consent for the WhatsApp marketing you are already doing. The room goes quiet. That silence is the real DPDP gap, and it is not on your website.
The Digital Personal Data Protection Act, 2023 (DPDP Act) is India's first standalone data protection law. It received Presidential assent in August 2023. The Draft DPDP Rules, 2025 were published for public consultation in January 2025 and set out the operational detail. As a CERT-In empanelled auditor, I read this law the way an examiner does: not as principles to admire, but as artefacts to produce on demand. This guide is about those artefacts.
What DPDP actually regulates, in one page
The Act governs digital personal data of individuals in India. It applies to you if you process such data in India, and also if you sit outside India but offer goods or services to people in India. So a Singapore SaaS company selling to Indian customers is caught. There is no revenue threshold and no small-business carve-out from the core obligations. If you handle a name, a phone number, a UPI ID, an Aadhaar-linked field, or a health record tied to an identifiable person, you are in scope.
The law gives everyone a role. Learn these four words because every clause hangs off them.
| Term | Who it is | Your likely role |
|---|---|---|
| Data Principal | The individual whose data it is | Your customer, employee, lead |
| Data Fiduciary | Whoever decides why and how data is processed | Your company |
| Data Processor | Whoever processes on the Fiduciary's behalf | Your AWS, your CRM vendor, your BPO |
| Significant Data Fiduciary (SDF) | A Fiduciary notified by Government based on volume and sensitivity | Large platforms, some fintech and healthtech |
You are almost certainly a Data Fiduciary. That single classification pulls in consent, notice, security, breach reporting, grievance handling and deletion duties. If the Government later notifies you as a Significant Data Fiduciary, you inherit a heavier set: a Data Protection Officer based in India, an independent data auditor, and periodic Data Protection Impact Assessments.
The consent trap that catches nearly everyone
Consent under DPDP is not a tick you collect once and forget. Section 6 says consent must be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action, and limited to the purpose stated. Two words there are quiet killers: specific and unconditional.
Specific means one broad consent for everything is invalid. You cannot bundle account creation, marketing emails, WhatsApp promotions and data sharing with partners under a single checkbox. Each purpose needs its own consent. Unconditional means you cannot refuse the core service because someone declined the marketing consent. If your signup breaks when a user says no to promotional messages, that flow is non-compliant.
Here is what actually happens in a review. We open your registration API and trace the consent flag. In eight cases out of ten, there is a single boolean called terms_accepted set to true, covering the terms of service and privacy policy together. No timestamp of which policy version was shown. No separate purpose records. No way to reconstruct what the user actually agreed to on the day they signed up. That record cannot survive a Data Protection Board inquiry, because you cannot prove informed consent for any specific purpose.
The fix is a consent ledger. Not a flag, a ledger. Every consent event should capture the following.
- The specific purpose consented to, worded in plain language
- The notice version and text shown at that moment
- Timestamp, and the channel where consent was captured
- An immutable record of withdrawal, because withdrawal must be as easy as giving consent
- The identity of the Consent Manager, if you route through one of the Board-registered Consent Managers introduced by the Act
The notice you owe before you take a byte
Section 5 requires a notice at or before the point of collection. The Draft Rules add specificity. The notice must be a standalone, clear document, not buried in a twelve-page privacy policy. It must tell the Data Principal the personal data being collected, the purpose, how to exercise their rights, how to withdraw consent, and how to complain to the Data Protection Board of India.
Practitioners get two things wrong here. First, they write the notice for lawyers, not humans, so it fails the informed test. Second, they show it once at signup and never again, even when they later start processing the same data for a brand-new purpose. New purpose, new notice, fresh consent. There is no grandfathering old data into new uses.
Rights of the Data Principal, and the 90-day clock nobody planned for
The Act gives individuals real rights, and each one is an operational commitment with a deadline. The number that surprises teams is the grievance redressal timeline in the Draft Rules: you must respond to grievances within the period the Fiduciary publishes, and the Rules contemplate a maximum of ninety days. Miss it repeatedly and you have a documented pattern of non-compliance.
| Right | What you must build | Common failure |
|---|---|---|
| Access to information | A way to return what data you hold and who you shared it with | No lineage of downstream processors |
| Correction and erasure | A workflow to fix or delete on request | Deletion in the app but not in backups or logs |
| Grievance redressal | A published contact and a tracked queue with SLAs | support@ inbox with no ownership |
| Nominate | Let a user nominate someone to exercise rights on death or incapacity | Feature simply does not exist |
Erasure is the one that exposes bad architecture. When a user asks to be deleted and consent is withdrawn, you must erase the data unless a law requires retention. That means deleting from the primary database, the analytics warehouse, the search index, the email tool, the CRM, the backups on their next rotation, and the log lines that carried the PII. If you cannot answer where does this person's data physically live, you cannot honour erasure, and you cannot pass an audit.
Breach reporting: two clocks, and CERT-In is not the same as the Board
This trips up even mature security teams, so be precise. India now has two overlapping breach obligations, and they run on different clocks.
| Obligation | Trigger | Deadline |
|---|---|---|
| CERT-In Directions (April 2022) | Any reportable cyber incident, including data breaches | Within 6 hours of noticing or being notified |
| DPDP Act, Section 8(6) | Personal data breach | Notify the Board and each affected Data Principal, per the Rules |
The CERT-In six-hour window is brutal and already in force. It also requires you to keep logs for 180 days within Indian jurisdiction and to sync clocks to NPL or NIC time servers. The DPDP breach duty is broader on the who-you-tell axis: you must inform the individuals themselves, not just the regulator, describing the breach, its likely consequences, and what you are doing about it. In practice you need one incident runbook that satisfies both, because the moment you notice a personal data breach, both clocks start.
What actually happens in an incident tells the story. A mid-size lending app had an exposed S3 bucket flagged by a researcher at 2 a.m. The on-call engineer patched it by 4 a.m. and went back to sleep. Nobody filed with CERT-In. Nobody informed a single customer. Six weeks later the researcher went public. Now the company faced not just the original exposure but a documented failure to report within six hours and a failure to notify affected principals. The penalty exposure multiplied, and the story became the breach of process, not the bucket.
The penalties are structured to hurt at the board level
DPDP penalties are financial, not criminal, and they are large enough that they belong on a risk register, not in legal's drawer. The Board can impose penalties up to the following caps per instance of non-compliance.
| Failure | Maximum penalty (INR) |
|---|---|
| Failure to take reasonable security safeguards to prevent a breach | Up to 250 crore |
| Failure to notify the Board and affected persons of a breach | Up to 200 crore |
| Breach of obligations relating to children's data | Up to 200 crore |
| Breach of additional Significant Data Fiduciary obligations | Up to 150 crore |
| Breach of any other provision or the Rules | Up to 50 crore |
| Breach of a Data Principal's own duties (false or frivolous complaints) | Up to 10,000 |
Read the top line again. The single largest penalty is not for the breach itself. It is for failing to take reasonable security safeguards. That is a direct instruction: your defensibility comes from what you did before the breach. If you can show encryption, access controls, logging, vendor contracts and a tested incident plan, you have a case. If you cannot, the 250 crore cap is the ceiling on the conversation.
Children's data: the clause that reshapes your product
Section 9 treats anyone under eighteen as a child and demands verifiable parental consent before processing their data. It also prohibits behavioural tracking or targeted advertising directed at children, and any processing likely to cause harm. If your product is even accessible to minors, edtech and gaming especially, this is not a footnote. Verifiable parental consent is genuinely hard to implement, and the Draft Rules point toward reliable age-verification and consent mechanisms. Design for it early, because retrofitting age gates onto a live product is painful and expensive.
Cross-border transfer is now a blacklist, not a whitelist
Earlier drafts of Indian data law proposed a permitted-countries list. The final Act flipped the logic. Section 16 allows transfer of personal data outside India to any country, except those the Central Government specifically restricts by notification. This is a lighter regime than many feared, but do not relax entirely. Sectoral regulators still bind you. The RBI's storage directive requires payment system data to be stored only in India. So a fintech can transfer under DPDP yet still breach RBI localisation. Map your data flows against both DPDP and your sector regulator, because the stricter rule wins.
Reasonable security safeguards, made concrete
The Act says take reasonable security safeguards and leaves reasonable undefined, which frustrates engineers. As an auditor I treat the Draft Rules and established Indian security baselines as the working definition. Here is what I expect to see evidenced, not just claimed.
- Encryption of personal data at rest and in transit, with documented key management
- Role-based access control and the principle of least privilege, reviewed quarterly
- Logging and monitoring retained for at least 180 days to satisfy CERT-In, in Indian jurisdiction
- Data Processor contracts that flow down security and breach-notification duties to every vendor
- A tested incident response plan mapped to both the CERT-In six-hour and DPDP breach clocks
- Backups and their deletion pathways documented, so erasure requests can actually complete
- Reasonable measures to ensure completeness and accuracy of data used for decisions affecting people
Your DPDP readiness checklist
If you do nothing else this quarter, work through this list in order. It is the same sequence I use when scoping a readiness assessment.
- Build a data inventory: what personal data you hold, where it lives, why, and who you share it with
- Map every processing purpose and attach a specific, unbundled consent to each one
- Replace the single consent flag with a consent ledger that records purpose, notice version, timestamp and withdrawal
- Rewrite the collection notice as a standalone, plain-language document, and version it
- Stand up a rights-request workflow for access, correction, erasure and grievance, with a published SLA under 90 days
- Trace erasure end to end, including analytics, search, CRM, logs and backups
- Write one incident runbook that satisfies CERT-In 6-hour reporting and DPDP breach notification to individuals
- Put Data Processor agreements in place with every vendor, flowing down security and breach duties
- If you touch children's data, design verifiable parental consent and kill behavioural tracking of minors
- Map cross-border flows against DPDP and any sectoral localisation rule such as RBI payment-data storage
- Assess whether you are likely to be notified a Significant Data Fiduciary, and pre-plan the DPO, auditor and DPIA duties
The point most people miss
DPDP compliance is not a document you sign off once. It is a set of living systems: a consent ledger that updates, an erasure pipeline that reaches every store, an incident runbook that two different regulators can accept. The company that treats it as a website update will fail the first inquiry. The company that treats it as engineering will barely notice the Board when it comes calling. Go back to that silent room from the opening. The founders who can answer show me the consent are the ones who built the ledger, not the policy page.
If you want a second set of eyes before the Rules are finalised, CyberSigma's CERT-In empanelled auditors run DPDP readiness assessments hands-on, tracing your actual data flows rather than reviewing your paperwork. We would rather help you find the gap than watch a regulator find it for you.
FAQs
Is the DPDP Act in force yet, and do I need to comply now?
The DPDP Act, 2023 has Presidential assent but its operative provisions come into force on dates the Government notifies, and the Draft DPDP Rules, 2025 are being finalised after public consultation. Enforcement is imminent rather than active on every clause, but a phased commencement is expected. Given that readiness takes months to build, and that the CERT-In six-hour breach rule is already in force, you should start now rather than wait for the final notification.
Does DPDP apply to a startup with no funding and few users?
Yes. There is no revenue or user-count exemption from the core Data Fiduciary duties around consent, notice, security and breach reporting. The heavier Significant Data Fiduciary obligations, such as appointing a Data Protection Officer and running impact assessments, apply only if the Government specifically notifies you, which is volume and risk based. But the baseline applies to everyone processing digital personal data of people in India.
What is the difference between a Data Fiduciary and a Data Processor?
A Data Fiduciary decides why and how personal data is processed and carries the legal accountability. That is your company. A Data Processor only processes on the Fiduciary's instructions, for example your cloud host or CRM vendor. You must bind every Processor by a valid contract that flows down security and breach-notification duties, and you remain accountable to the Data Principal even for your Processor's failures.
How much can DPDP non-compliance actually cost?
Penalties are financial and set per instance of non-compliance. The largest cap is up to 250 crore rupees for failing to take reasonable security safeguards to prevent a breach, and up to 200 crore for failing to notify a breach or for mishandling children's data. Other breaches carry up to 50 crore. There is no imprisonment under DPDP, but the financial exposure is board-level, so it belongs on your enterprise risk register.
How does DPDP interact with the CERT-In breach reporting rules?
They are separate obligations that often trigger together. The CERT-In Directions of April 2022 require reporting a cyber incident within six hours of becoming aware, plus 180-day log retention in Indian jurisdiction. DPDP requires notifying both the Data Protection Board and every affected individual of a personal data breach. Build one incident runbook that satisfies both, because a personal data breach usually starts both clocks at once.
Can I still store data outside India under DPDP?
Yes, in general. The Act permits transfer to any country except those the Central Government specifically restricts by notification, which is a lighter regime than a permitted-list model. However, sectoral rules still apply and can be stricter. For example, the RBI requires payment system data to be stored only in India, so a fintech may satisfy DPDP yet still breach RBI localisation. Always check both the general law and your sector regulator, and follow the stricter one.
Liked the post? Share on:
Leave A Comment