DPDP Act Compliance for Indian Startups (2026) — What Founders Must Do Before 13 May 2027

Q: Is a privacy policy enough to be compliant?

No. A privacy policy is a disclosure document. Compliance under the Act requires an operational posture — valid consent, accurate records, security safeguards, breach-response capability, and the documented ability to show the Data Protection Board how each is implemented. A policy document alone satisfies none of this.

Q: We only sell to businesses. Does the DPDP Act apply?

Yes. Your employees are data principals. The individual users within your business customers are data principals whose personal data you process. Both routes bring B2B SaaS and services into scope.

Q: Are cross-border transfers of personal data allowed?

The DPDP Act follows a negative-list model. Transfers to a country outside India are permitted by default, unless the Central Government has specifically restricted transfers to that country by notification. As of October 2026 no such notification has been issued.

The Digital Personal Data Protection Act, 2023 does not care about the size of your company. There is no small-business exemption, no revenue threshold, no user-count carve-out. If your startup collects personal data of a data principal in India, the Act applies. From 13 May 2027 the substantive obligations and the Section 33 penalties become fully enforceable. The Data Protection Board of India has already been constituted. Complaints can already be filed.

This page is written for founders who want a working picture of what to do between now and that date, with specific references to the Act and the Rules notified on 13 November 2025. It is informational, and does not replace specific legal advice on a startup's actual data footprint.

The three enforcement phases

The implementation framework is staggered. Each phase brings a different set of obligations into force. Treating the Act as a single May 2027 event misses the fact that the Board is already live and can already take cognisance of complaints.

Phase 1 — 13 November 2025. Rules 1, 2 and 17 to 21 came into force. The Data Protection Board of India was constituted. Definitions, the procedural framework and the complaint mechanism are live. A data principal who feels their rights have been breached can file a complaint today.
Phase 2 — 13 November 2026. Rule 4 applies. Any entity operating as a Consent Manager must register with the Board. This is the Phase relevant to startups whose own product is a consent management tool, and to any startup that intends to rely on a registered Consent Manager.
Phase 3 — 13 May 2027. The substantive obligations of the Act come into full force. Grounds for lawful processing (Section 4), notice (Section 5), consent (Section 6), reasonable security safeguards (Section 8(5)), breach intimation (Section 8(6)) and the Section 33 schedule of penalties.

Does the Act apply to you?

Three questions settle this.

Do you process personal data of a data principal? Personal data is defined broadly in Section 2(t). If a user signs up, if an employee is onboarded, if a customer's email is collected, personal data is being processed.
Is the processing in digital form? Section 3(a) limits the Act to digital or digitised personal data. Paper records that are never scanned, in principle, fall outside. In practice, almost every startup is in scope.
Is the data principal in India, or is the processing in connection with offering goods or services to data principals in India? Section 3(b) brings in extraterritorial scope. A Delaware C-corp running a SaaS product used by Indian customers is a Data Fiduciary under the Act.

If the answer to all three is yes, and for almost every Indian startup it is, the Act applies. The size of the company, whether revenues exist, whether the company is yet incorporated — none of these change the answer.

Core obligations under the Act

Section 8 is the operative provision for Data Fiduciaries. In practical terms it means the following work must be done.

Give a plain-language notice before (or at the time of) collecting personal data. The notice must list the personal data being collected, the purpose of processing, how the data principal may exercise their rights, and how a complaint may be made to the Board. Section 5 governs the content.
Obtain free, specific, informed, unconditional and unambiguous consent for processing that falls under Section 6. Consent must be as easy to withdraw as it was to give.
Process only for the stated purpose. Scope creep is not permitted. New purposes require fresh notice and fresh consent.
Maintain accuracy and completeness of the data. Section 8(3). If a user says their name is misspelt, correcting it is a statutory obligation, not a courtesy.
Erase personal data once the purpose for which it was collected is no longer served, unless retention is required by law. Section 8(7). Indefinite retention because "we might need it" is not a lawful ground.
Implement reasonable security safeguards to prevent personal data breach. Section 8(5). This is the obligation that attracts the highest penalty — up to ₹250 crore per contravention under the Section 33 schedule.
Intimate every personal data breach to the Board, and to each affected data principal. Section 8(6). The Rules set out the manner and timeline.

Consent architecture — the operational core

For most startups this is the single largest piece of work.

Consent under the Act is a specific technical act. Consent given in response to a dense wall of text is not valid consent. Consent that is bundled with service terms is not valid. Consent that cannot be withdrawn with equal ease is not valid.

A compliant consent flow has, at minimum:

A notice presented before data collection, in a form the user can read and act upon.
A separate, affirmative action by the user — a tick, a click, a confirmation.
A record of what was consented to, when, and in what form, retained for as long as the data is retained.
A withdrawal mechanism inside the product that is as prominent and accessible as the original consent prompt.
A separate consent for each distinct purpose. One consent cannot cover marketing emails and credit assessment and third-party sharing.

The Rules permit a registered Consent Manager to intermediate this process. For a startup that is not itself in the consent-management business, the choice between building in-house and integrating with a registered Consent Manager becomes a cost and roadmap decision rather than a compliance choice. Either route works. Both must produce a record of consent that will survive scrutiny.

Security safeguards — Section 8(5)

This provision does the most work and carries the heaviest penalty. "Reasonable security safeguards" is not defined with granularity in the Act, but the Rules and the general drift of practice suggest the Board will look at:

Encryption of personal data at rest and in transit.
Access control appropriate to the sensitivity of the data.
Logging of access and processing activities.
A written, reviewed and tested breach-response plan.
Vendor-level safeguards flowed through contractual commitments in Data Processing Agreements.
Periodic review and audit.

For an early-stage startup, "reasonable" is proportionate to the risk the data presents and the resources of the organisation. A seed-stage SaaS does not need SOC 2 Type II on day one. It does need encryption at rest, documented access controls, basic logging, and a written breach plan. The Board's enquiry, if it ever comes, will begin with the question: can you show me what you did, and when.

Data breach notification

When a personal data breach occurs, two notifications are required: to the Board, and to each affected data principal. The Rules set the manner. The practical implications for a startup:

The breach-response plan must contain contact details and templated notifications. Deciding how to notify after a breach has happened is too late.
Logs that identify the affected data principals must exist. Without logs, individual notifications are not possible, and that is itself likely to be read as a Section 8(5) failure.
The notification to data principals must be in plain language. Legal boilerplate sent to a user whose password was stolen is not compliant.

The Board can impose a penalty of up to ₹200 crore specifically for failure to notify a breach. That is separate from the up-to-₹250-crore penalty for the security failure itself.

Children's data

If the product has, or is likely to have, users under 18, Chapter III of the Act applies. The specific obligations:

Verifiable parental consent is required before any processing. Verification is not an unchecked tick-box. Rule 10 contemplates verification through DigiLocker or an equivalent Central Government-designated identity service, among other means.
Targeted advertising to children is prohibited.
Tracking and behavioural monitoring of children is prohibited.

For EdTech, children's content platforms, gaming apps aimed at under-18 audiences and children's health tech, this is non-negotiable work. For general-purpose products that may incidentally pick up under-18 users, age-gating with meaningful friction is the practical minimum.

Cross-border transfers

The Act adopts a negative-list model. Transfers of personal data to a country outside India are permitted by default, unless the Central Government has specifically restricted transfers to that country by notification. As of October 2026 no such notification has been issued.

The practical implication for a SaaS startup running on AWS Mumbai with a disaster-recovery region in Singapore: continue as before. The practical implication for a startup contemplating a jurisdiction-specific business reason to move data into or out of India: watch the notifications.

Significant Data Fiduciary — the step-up tier

The Central Government may designate certain Data Fiduciaries as Significant Data Fiduciaries, based on the volume and sensitivity of personal data processed, the risk to data principals and the risk to national security or public order. Significant Data Fiduciaries bear a heavier compliance load. They must appoint a dedicated Data Protection Officer in India, conduct annual data protection impact assessments, undergo annual audits, perform algorithmic risk assessments where automated decisions are made, and may face tighter cross-border controls.

Most early-stage startups will not be designated Significant Data Fiduciaries. Those processing large volumes of financial, health or children's data should still model the possibility and keep the operational posture close to Significant-Data-Fiduciary-ready. Climbing to that grade of compliance after designation, under a Board-imposed deadline, is substantially harder than planning for it in advance.

What to do between now and 13 May 2027

A workable sequence for a startup with limited bandwidth:

Data inventory. List every category of personal data the product and the operations collect. Where it lives, who has access, how long it is retained. Nothing meaningful can happen without this map.
Notice and consent flows. Review each place personal data is collected. Rewrite notices in plain language. Rebuild consent flows to be unbundled, specific and withdrawal-friendly.
Vendor DPAs. For every vendor that touches personal data — cloud, email, analytics, customer support, HR — review and update the data processing agreement. Flow down the Act's requirements.
Security baseline. Encryption at rest, encryption in transit, documented access controls, access logs. Document what you have done and when.
Breach-response plan. Written, dated, tested at least once. Include the templates for Board and user notifications.
Policy stack. Internal data retention policy, access-control policy, breach-response policy, acceptable-use policy. Published, dated, reviewable.
Children's data decision. Age-gate or verifiable parental consent, depending on the product.
Training. Everyone who touches personal data should understand the basics. One hour per year is a reasonable minimum.

Frequently asked questions

Yes. The Act is agnostic to revenue, funding stage, headcount or incorporation form. If personal data in digital form is being processed and a data principal in India is involved, the obligations apply.

A privacy policy is a disclosure document. Compliance with the Act requires an operational posture — valid consent, accurate records, security safeguards, breach-response capability, and the documented ability to show the Board how each is implemented. A policy document on its own satisfies none of this.

Yes, in two ways. First, your employees are data principals and their personal data is protected. Second, the individual users and contacts within your business customers are data principals whose personal data you process alongside or on behalf of your customer. Both routes bring B2B SaaS and services into scope.

Where you act as a Data Processor on behalf of a Data Fiduciary customer, you must have a written agreement under which the customer is responsible for consent, and you process strictly on the customer's instructions. Where you act as a Data Fiduciary in your own right, you must have your own consent.

In order of priority: a valid consent flow, a written and tested breach-response plan, encryption at rest and in transit, logged access control, updated vendor DPAs, and a privacy notice that matches your actual processing. Nothing on this list is optional. Everything on it takes time to do well.

DPDP Act compliance for Indian startups — what founders must do before 13 May 2027.