DPDP Compliance on a Startup Budget: A Tiered Programme
The DPDP Act has no small-business threshold and no startup exemption yet, so founders need a short, evidenced programme they can run themselves, show investors and defend before the Board.
- TYPE
- White paper
- POSITION AS OF
- October 2026
- READING TIME
- 18 min read
- FILE
FULL TEXT
DPDP Compliance on a Startup Budget: A Tiered Programme
Selecting and copying text is turned off on this page. To keep a copy, download the PDF.
Executive summary
The Digital Personal Data Protection Act, 2023 (the DPDP Act) does not scale its duties to the size of a business. A five-person app that collects phone numbers is a data fiduciary (the person who decides why and how personal data is processed) on the same terms as a bank. The Act lets the Central Government exempt startups from a handful of provisions under section 17(3), but no such notification has been issued. Even if one were, it could not reach security, breach intimation, children's data or most of the rights that individuals hold.
What the Act does offer small businesses is proportionality when penalties are set. Section 33(2) obliges the Data Protection Board of India (the Board) to weigh seven factors, including the likely impact of the penalty on the business and whether it acted quickly to limit the harm. Those factors reward a business that can show a sensible, documented programme.
This whitepaper sets out five things: a twelve-action baseline that every startup and MSME should complete before the main obligations commence on 13 May 2027; two tiers, one for a consumer app with fewer than 50 people and one for a growing B2B SaaS company; low-cost ways to deliver each control; a split between what founders can do themselves and where they need help; and what investors now check. Three worked examples, an AI startup, a diagnostics startup and an ed-tech startup, show how the same twelve actions play out.
Our central recommendation: do not wait for an exemption. Build the twelve items, keep the evidence, and use the Board's proportionality factors as the design brief.
Background
Indian law has two common labels for a young or small business. The DPDP Act uses neither as a threshold.
Startups. The Department for Promotion of Industry and Internal Trade (DPIIT) recognises startups under a Gazette notification. On 4 February 2026 it replaced its 2019 criteria with G.S.R. 108(E). An entity is now a startup for up to ten years from incorporation or registration if its turnover has not exceeded ₹200 crore in any financial year, with longer and higher limits (twenty years and ₹300 crore) for deep tech startups. The 2026 notification also extends recognition to co-operative societies.
MSMEs. The Micro, Small and Medium Enterprises Development Act, 2006 classifies enterprises by investment in plant, machinery or equipment and by turnover. From 1 April 2025 (S.O. 1364(E)), a micro enterprise may have investment up to ₹2.5 crore and turnover up to ₹10 crore; a small enterprise up to ₹25 crore and ₹100 crore; and a medium enterprise up to ₹125 crore and ₹500 crore. A "medium" enterprise can be a substantial business.
Neither label switches any DPDP duty on or off. The only size-based numbers in the regime point upwards. The Third Schedule to the DPDP Rules, 2025 sets special erasure rules for e-commerce and social media platforms with at least 2 crore registered users in India and online gaming intermediaries with at least 50 lakh. Section 10 lets the Centre designate Significant Data Fiduciaries (SDFs) by reference to factors such as the volume and sensitivity of data. Below those levels, every fiduciary carries the full set of duties.
Timing matters. Most obligations, including notice, consent, security, breach intimation, children's data and individual rights, commence on 13 May 2027 under the commencement notification G.S.R. 843(E). Rule 4 on consent managers takes effect on 13 November 2026. MeitY consulted in January 2026 on shortening the timeline, but no amending notification has followed. The Board has been established on paper but, as of October 2026, has no members.
Legal framework
Scope and grounds. The Act applies to digital personal data processed in India, and to processing outside India connected with offering goods or services to people in India (s.3). Processing needs one of two grounds: consent (s.6) or one of the "certain legitimate uses" in the closed list in s.7. There is no general legitimate-interests ground.
Duties that bind every fiduciary. They are:
- notice before seeking consent (s.5; Rule 3);
- consent that is free, specific, informed, unconditional and unambiguous, limited to necessary data (s.6(1)), and withdrawable as easily as it was given (s.6(4));
- the burden, in any proceeding, of proving that notice was given and consent obtained (s.6(10));
- responsibility for processors "irrespective of any agreement to the contrary" (s.8(1)), and a valid contract with each (s.8(2));
- accuracy where data is used for decisions about a person (s.8(3)), and technical and organisational measures to observe the Act (s.8(4));
- reasonable security safeguards (s.8(5); Rule 6) and breach intimation to the Board and each affected person (s.8(6); Rule 7);
- erasure once the purpose is served (s.8(7)), a published contact (s.8(9); Rule 9) and grievance redressal (s.8(10), s.13; Rule 14);
- the children's data rules (s.9; Rule 10) and the rights of data principals, the individuals the data is about (ss.11 to 14).
The startup exemption that does not yet exist. Section 17(3) lets the Centre, "having regard to the volume and nature of personal data processed", notify fiduciaries or classes of fiduciaries, "including startups", to whom section 5, sections 8(3) and 8(7), section 10 and section 11 shall not apply. The Explanation defines a startup as "a private limited company or a partnership firm or a limited liability partnership incorporated in India" which "is eligible to be and is recognised as such" under the criteria and process notified by the department to which startup matters are allocated. The Act does not name DPIIT; it identifies the department by function, and DPIIT is the department that issues the startup criteria. No notification has been issued under s.17(3), and in December 2023 the Government told the Lok Sabha that no organisation had been exempted under section 17. Separately, s.17(5) lets the Centre, within five years of commencement, declare that any provision shall not apply to notified fiduciaries for a specified period. We have found no notification under that power either.
Penalties and proportionality. The Board may impose a penalty only if, after an inquiry, it finds a breach "significant" (s.33(1)). The Schedule sets maximums by obligation: up to ₹250 crore for failing to take reasonable security safeguards, ₹200 crore each for breach-intimation and children's data failures, ₹150 crore for SDF obligations and ₹50 crore for breaches of other provisions. Section 33(2) then requires the Board to have regard to:
- the nature, gravity and duration of the breach;
- the type and nature of the personal data affected;
- whether the breach is repetitive;
- any gain realised or loss avoided as a result;
- any action taken to mitigate the effects, and how timely and effective it was;
- whether the penalty is proportionate and effective, given the need to secure observance and deter breach; and
- the likely impact of the penalty on the person.
Under s.32 the Board may also accept a voluntary undertaking at any stage of a proceeding. Acceptance bars proceedings on the matters it covers, unless the undertaking is breached.
Analysis
What a section 17(3) notification could and could not change
On the most generous reading, a startup notification would remove five things: the stand-alone notice in s.5, the accuracy duty in s.8(3), the duty to erase when the purpose ends in s.8(7), exposure to the SDF regime in s.10, and the right of access in s.11. It could not touch consent, withdrawal, security, breach intimation, children's data, correction and erasure on request under s.12, grievance redressal or nomination.
Three consequences follow, in our view. First, an exempted startup would still need consent that is "informed" under s.6(1), so it would still have to tell people what it collects and why; only the Rule 3 format would fall away. Second, the s.8(7) relief would be partly hollow, because s.12(3) still requires erasure when a person asks. Third, the phrase "having regard to the volume and nature of personal data processed" invites a targeted notification. A startup that processes health or children's data should assume it would be left out.
Eligibility would also be narrower than DPIIT recognition. The Explanation covers only private limited companies, partnership firms and LLPs that are actually recognised. A sole proprietorship, a public company, a co-operative society recognised under the 2026 criteria, and a company that has outgrown the age or turnover limits would not qualify as a startup. Nor would an eligible company that has never applied, because the definition requires that it "is recognised". MSME registration has no bearing at all. Section 17(3) also lets the Centre notify other classes of fiduciary, so a non-startup could still be covered by a class defined some other way.
Proportionality is evidence, not a discount
Section 33(2) is the provision that helps small businesses today, but only those that can prove things. Read as a design brief, the factors point to four habits.
- Keep the data you hold small and ordinary (factor 2). The type of data affects the penalty. Health, financial and children's data raise the stakes; collecting less of it lowers them.
- Detect, contain and record (factors 1 and 5). Duration and mitigation are both weighed, so a breach found within hours and contained with a written timeline stands differently from one discovered months later.
- Fix root causes (factor 3). A repeat of the same failure loses the benefit of the doubt.
- Keep records that show impact (factor 7). The likely impact of a penalty is a mandatory consideration. A startup that can show its revenue and runway gives the Board the material to apply it.
The "significant" threshold in s.33(1) and the undertaking route in s.32 point the same way. A business with a documented programme has something to show the Board; one without has nothing.
Two tiers, one baseline
| Area | Tier 1: consumer app, under 50 people | Tier 2: growing B2B SaaS |
|---|---|---|
| Role | Fiduciary for its users, staff and leads | Mostly a processor for clients' data; a fiduciary for its own users, staff and leads |
| Notice and consent | In-app notice under Rule 3; consent split by purpose; a consent log | The same for its own website and trials; clients give notice to their users |
| Privacy contact | A founder or operations head, published under Rule 9 | A named lead and deputy, and a privacy section in the client trust pack |
| Contracts | A data addendum with each vendor | A client data processing agreement, a sub-processor list and matching terms with each sub-processor |
| Breach | Notify affected users and the Board; report to CERT-In within six hours | The same for its own data, plus notice to clients within hours so they can file their 72-hour report with the Board |
| Rights | Handled in-house within a published period of no more than 90 days | Clients' users routed to the client, with help to answer; own users handled in-house |
| Retention | Fixed periods and scheduled deletion | Return or delete client data at contract end; backups deleted on rotation |
| Hosting | Record the region used | Region set per client contract and sector rule |
Tier 1 is the default. A business moves to Tier 2 when most of the personal data it touches belongs to its clients' customers or staff. Many will be both: a SaaS company with a consumer app is Tier 2 for its client data and Tier 1 for its own users. Trayambic's SaaS and IT services impact study covers the processor side in more depth, and our vendor-contracts blog covers the contract terms.
Low-cost ways to deliver each control
Each control can run on infrastructure a young company already has. The entries below describe categories of tool, not products.
| Need | Low-cost choice |
|---|---|
| Data map | A shared sheet with locked columns: system, data, purpose, ground, retention, vendor, location |
| Consent records | An append-only table in your own database: user, purpose, notice version, time, channel, withdrawal |
| Notice versions | Notice text kept in version control, with each release tagged |
| Rights requests | An in-app form and a dedicated email alias feeding your existing helpdesk, with a due-date field |
| Identity checks | Requests raised from a logged-in session, or a one-time code sent to the registered mobile or email |
| Access control | Multi-factor authentication everywhere, single sign-on through the office suite you already pay for, a password manager and quarterly access reviews |
| Encryption and logs | Your cloud provider's built-in encryption, key management and logging, with logs kept for at least a year and 180 days of them in India |
| Deletion | Scheduled deletion jobs and storage lifecycle rules, each writing to a deletion log |
| Code hygiene | Open-source secret and dependency scanners in the build pipeline |
| Breach readiness | A one-page runbook, a contact sheet and a tabletop drill twice a year |
The one-year log period comes from Rule 6. The 180-day India requirement comes from CERT-In's Directions of 28 April 2022, which also require incidents to be reported to CERT-In within six hours.
What founders can do themselves, and where they need help
| Task | Founders can usually do it | Get help when |
|---|---|---|
| Data map and retention schedule | Yes, from the sheet above | Data flows to group companies, lenders or overseas affiliates |
| Notice and consent text | A first draft in plain language | Children's, health or financial data is involved, or several languages are needed (s.6(3)) |
| Choosing the ground | Simple flows such as orders and bookings under s.7(a) | You want to rely on any other s.7 ground or on a s.17 exemption |
| Vendor and client terms | A standard addendum | An enterprise client sends its own agreement, or sub-processors sit abroad |
| Security baseline | Configuring the controls above | Before launch and every year: independent security testing |
| Incidents | The runbook and the drills | On the day: legal, forensic and communications support |
| Rights requests | Routine access, correction and deletion | Nominee, deceased-user or disputed requests, which Trayambic's article on data principal rights and nomination covers |
What investors now check
Data protection has moved from a boilerplate warranty to a diligence workstream. A ready startup can answer these questions with documents rather than assurances:
- What personal data do you hold, on what ground, and where is it?
- Can you prove notice and consent for each user? Section 6(10) puts that burden on the fiduciary, so the consent log is evidence.
- Do you process children's data, and how do you verify parental consent?
- Which vendors and sub-processors handle personal data, and on what terms?
- Have you had incidents, and were the Board, users and CERT-In told in time?
- Where did your AI training data come from, and can you remove a person from it?
- Do you share data with lenders, advertisers or partners, and on what ground?
- Could you be designated a Significant Data Fiduciary as you scale?
Two transaction points are often missed. First, diligence is itself processing. In our view customer-level data should not go into a data room without a ground, so share aggregated or de-identified extracts. Second, s.17(1)(e) exempts processing necessary for a merger, demerger or similar scheme only where it is "approved by a court or tribunal or other authority competent to do so". In our view a share subscription or a secondary sale is not such a scheme. Warranties and indemnities move cost between investor and founder; they do not change whom the Board holds responsible.
Worked example: three startups, one checklist
All figures are illustrative.
An AI startup (Tier 2). A 30-person company in Bengaluru sells a call-summarisation tool to Indian mid-size businesses. It is a processor for its clients' call recordings. Its founders want to fine-tune their own model on those transcripts. That reuse would make the company a fiduciary in its own right, needing a ground for every caller it has never met. Its programme: client contracts that forbid training unless the client opts in and the data is de-identified first; a sub-processor list naming the model host and its region; a six-hour CERT-In path for its own incidents and same-day notice to clients; and a provenance record for every training set, which its lead investor asked to see in the Series A round. Trayambic's article on training AI on personal data covers the grounds in detail.
A diagnostics startup (Tier 1). A 45-person home sample-collection app in two cities books tests with partner laboratories. Bookings fit s.7(a), as our health studies explain. The partner labs are separate fiduciaries for testing and reports, so the app names them in its access responses (s.11(1)(b)) and signs data-sharing terms with each. Report links expire and open only with a one-time code. Employed phlebotomists' live location is processed under s.7(i) during shifts only and deleted after a short dispute window; gig collectors would need consent, as our employee-monitoring article explains. Because health data weighs under factor 2 of s.33(2), the startup spends most of its security budget on the report store. Tests on children need verifiable parental consent, because the Fourth Schedule exemption belongs, at most, to the labs as clinical establishments, not to the booking platform. Trayambic's article on hospitals and diagnostics covers record retention for the labs themselves.
An ed-tech startup (Tier 1). A 20-person AI-tutoring app serves students in Classes 6 to 10 through their parents' phones. Every learner is a child under s.2(f), so section 9 shapes the product: an age gate, parental consent verified under Rule 10, no advertising code and no engagement tracking. Screen-time scores and attention signals were dropped. The adaptive engine picks the next question from the child's answers within a topic; in our view that is closer to the service the parent asked for than to behavioural monitoring, though the point is untested. The app assumes it is not an "educational institution", so the Fourth Schedule exemption helps only where it works as a school's processor. Trayambic's ed-tech impact study and our article on children's data in schools and ed-tech set out the limits.
The twelve actions were the same for all three. What differed was where each spent its effort: contracts for the AI company, security for the diagnostics app, product design for the ed-tech app.
Compliance framework
The twelve-action checklist
| Action | Owner | Legal basis | By when |
|---|---|---|---|
| 1. Name a privacy lead, publish a contact and brief all staff | Founder | ss.8(4), 8(9); Rule 9 | Nov 2026 |
| 2. Map systems, data, purposes and vendors | CTO | ss.4, 8(1) | Dec 2026 |
| 3. Record a ground for each purpose and drop data you do not need | Founder, with counsel | ss.6(1), 7 | Jan 2027 |
| 4. Publish an itemised notice and split consent by purpose | Product lead | ss.5, 6; Rule 3 | Feb 2027 |
| 5. Log consents and make withdrawal reach every system and vendor | Engineering | ss.6(4), 6(6), 6(10) | Feb 2027 |
| 6. Gate by age and verify parental consent, or keep children out | Product lead | s.9; Rule 10 | Feb 2027 |
| 7. Apply the security baseline | CTO | s.8(5); Rule 6 | Mar 2027 |
| 8. Sign a data addendum with every processor | Founder | ss.8(1), 8(2), 8(7)(b) | Mar 2027 |
| 9. Adopt a breach runbook covering the Board, users and CERT-In | CTO | s.8(6); Rule 7; CERT-In Directions | Mar 2027 |
| 10. Set retention periods and automate deletion | Engineering | s.8(7); Rule 6 | Apr 2027 |
| 11. Open rights, grievance and nomination channels | Support lead | ss.11 to 14; Rule 14 | Apr 2027 |
| 12. Rehearse one breach and one rights request, and file the results | Founder | ss.8(6), 33(2)(e); Rule 7 | May 2027 |
Tier 2 businesses add three items: a client data processing agreement with a sub-processor list, an incident-notice clause for clients, and a map of hosting regions and sector rules for each client.
Roadmap to 13 May 2027
- To 13 November 2026, when Rule 4 takes effect. Name the lead and decide whether you will accept consent signals from registered consent managers once any exist. Start the data map.
- 14 November 2026 to 31 March 2027. Finish the map, record grounds and set the tier. Ship notices and consent logs, the children's flow if needed, the security baseline, vendor addenda and the breach runbook.
- 1 April to 13 May 2027. Switch on deletion jobs and the rights, grievance and nomination channels. Rehearse a breach and a rights request, and keep the results with the data map, consent log and vendor list.
- From 14 May 2027. Review the data map every quarter and before each funding round, and watch for any s.17(3) or s.17(5) notification and the Board's first orders.
Recommendations
- Plan for full compliance. Treat any s.17(3) notification as a bonus, and expect security, breach, children's data and most rights to remain even then.
- If you are an eligible company, partnership or LLP, obtain or keep DPIIT recognition; any s.17(3) startup exemption will require it.
- Use the twelve actions as your programme and the s.33(2) factors as your test of it.
- Collect less sensitive data. It lowers the stakes under factor 2 and shrinks every other task.
- Decide your tier honestly. If most of your data belongs to clients' customers, build the Tier 2 contracts first.
- Build the investor file now: data map, consent log, vendor list, incident log and training-data records.
- Pay for expert help at the hard edges, not the basics: children, health data, cross-border flows, AI training and live incidents.
Key takeaways
- The DPDP Act has no size threshold; a small startup carries the same duties as a large company from 13 May 2027.
- No exemption has been notified under s.17(3); any future one could lift only ss.5, 8(3), 8(7), 10 and 11, and a startup exemption would reach only recognised private limited companies, partnerships and LLPs.
- Section 33(2) obliges the Board to weigh proportionality factors, including the penalty's impact on the business, which rewards documented programmes.
- Twelve low-cost actions, delivered through tools most startups already pay for, form a defensible minimum programme.
- Investors now test DPDP readiness; a data map, consent log, vendor list and incident log answer most of their questions.
General information on the DPDP Act and Rules, as the law stood at the position date shown. It is not legal advice.
MORE WHITE PAPERS
ALL ARTICLES & WHITEPAPERSEmployee Data from Offer to Exit: A DPDP Lifecycle Framework
Employee data passes through nine stages, from the first CV to the last reference call, and the DPDP Act asks a different question at each: which ground, what notice, how long, and what can go wrong.
Privacy by Design for Product Teams: Building DPDP Into the Build
The DPDP Act never says 'privacy by design', but its duties on consent, accuracy, security, erasure and children can only be met by controls built into the product before launch.
Retention, Deletion and Logs: A Defensible DPDP Schedule
The DPDP Act says erase personal data when its purpose ends, but other laws, two one-year floors in the Rules and CERT-In's log directions decide what must stay, and this whitepaper shows how to reconcile them in one schedule.



