Named In The Act. Not Yet Exempt.
Section 17(3) singles out startups for potential relief from five obligations. It is an enabling power, not a live exemption - and the difference matters more than any other point on this page.
Covers: DPIIT-recognised startups, early stage companies, seed and Series A teams.
Why this sector is treated differently
Section 17(3) provides that the Central Government may, having regard to the volume and nature of personal data processed, notify certain Data Fiduciaries or classes of Data Fiduciaries - including startups - as Data Fiduciaries to whom section 5, sections 8(3) and 8(7), and sections 10 and 11 shall not apply. An Explanation defines startup as a private limited company, partnership firm or limited liability partnership incorporated in India that is recognised as such under the criteria notified by the department to which startup matters are allocated - in practice, DPIIT recognition.
Read the verb. The Government *may* notify. Until it notifies a class and you are inside it, nothing in your obligations changes. The most common and most expensive misreading of this Act is a founder concluding that DPIIT recognition is itself an exemption. It is a precondition for one that may be granted, and building on the assumption that it has been is a compliance debt that compounds with every user you add.
It is also worth noticing how modest the relief would be. Section 5 is notice. Section 8(3) is data accuracy where the data is used for a decision affecting the Data Principal or is disclosed to another Data Fiduciary. Section 8(7) is erasure. Section 10 is the Significant Data Fiduciary regime, which a startup would rarely be notified under anyway. Section 11 is the right to access information about processing.
What section 17(3) conspicuously does not touch: consent under section 6, purpose limitation, reasonable security safeguards under section 8(5), breach notification under section 8(6), the children's provisions in section 9, the right to correction and erasure under section 12, grievance redressal under section 13, and the entire penalty regime. The obligations most likely to generate a breach and a penalty are precisely the ones that would survive a section 17(3) notification intact.
What you actually process
One row per activity, not per data type. Lawful basis and erasure attach to a purpose, so the same phone number can sit in three rows below with three different answers.
| Activity | Lawful basis | When it must go |
|---|---|---|
| Sign up a userEmail, Name, Password hash, Device and referral data | § 6Consent must be free, specific, informed, unconditional and unambiguous, by clear affirmative action, limited to the data necessary for the stated purpose. Section 17(3) does not list section 6, so this applies whatever happens with the exemption. | § 8(7)Erase when the account closes or the purpose is served. Section 17(3) could disapply this, but only once a notification exists and you are inside the notified class. |
| Secure the dataEverything you hold | § 8(5)A Data Fiduciary shall protect personal data in its possession or under its control, including data processed on its behalf, by taking reasonable security safeguards. This is not on the section 17(3) list. | § 8(7)Less data held is less to secure. Erasure is a security control as much as a compliance one. |
| Report a breachWhat was exposed, and whose | § 8(6)In the event of a personal data breach, the Data Fiduciary shall give the Board and each affected Data Principal intimation in the prescribed form and manner. Also not on the section 17(3) list. | § 8(7)Incident records are their own processing; keep what evidences the response. |
| Delete a user completelyEvery copy of that user's data | § 12The right to erasure of personal data, alongside correction, completion and updating. Section 12 is not on the section 17(3) list either. | § 8(7)Erase on withdrawal or when the purpose is served, whichever is earlier, unless a law requires retention. |
The data flow, and where it breaks
Each lane follows one activity through the actors and systems that touch the data. The failure mode sits on the hop where it happens, rather than in a list somewhere else on the page.
Sign up a user
Create the account and start delivering the product
- Signup formCollects the details§ 5Fails when: Notice buried in terms of service, which section 5 is not satisfied by
- Auth serviceCreates the account§ 6Fails when: Marketing consent bundled into signup, so it is neither free nor specific
- AnalyticsRecords the funnelFails when: Third-party analytics loaded before any consent exists
Secure the data
Prevent a personal data breach
- ApplicationHandles the data§ 8(5)Fails when: Safeguards deferred as a later-stage concern
- InfrastructureStores it§ 8(5)Fails when: Shared credentials and no access separation while the team is small
- Third-party toolsAlso hold it§ 8(2)Fails when: Tools adopted on a free tier with no processing terms
Report a breach
Tell the Board and every affected Data Principal
- DetectionNotices the incident§ 8(6)Fails when: No detection at all, so the clock starts when someone external tells you
- AssessmentDetermines scope and who is affected§ 8(6)Fails when: Cannot enumerate affected Principals because there is no data map
- NotificationInforms the Board and each Data Principal§ 8(6)Fails when: Timelines missed because the process was invented during the incident
Delete a user completely
Honour withdrawal and erasure
- Delete requestArrives from the user§ 12Fails when: No route to request it at all
- Primary storeRemoves the records§ 8(7)Fails when: Deletion that is a status flag
- Downstream copiesAnalytics, warehouse, support tooling, backups§ 8(7)Fails when: Copies spread across services faster than the ability to delete them
The provisions that apply
What the power actually covers
The Central Government may notify Data Fiduciaries or classes of them, including startups, to whom sections 5, 8(3), 8(7), 10 and 11 shall not apply - having regard to the volume and nature of personal data processed. Five provisions, exercised by notification, at the Government's discretion.
Who counts as a startup
A private limited company, partnership firm or limited liability partnership incorporated in India, eligible to be and recognised as a startup under the criteria and process notified by the department to which startup matters are allocated in the Central Government. Recognition is the gateway to being inside a class that may be notified - it is not the exemption.
Security and breach reporting are not on the list
Reasonable security safeguards to prevent a personal data breach, and the duty to notify the Board and each affected Data Principal of a breach, sit outside section 17(3) entirely. These are also the obligations with the largest penalty exposure - up to ₹250 crore for a security safeguards failure. No notification would relieve them.
Consent applies from day one
Section 6 governs consent - free, specific, informed, unconditional and unambiguous, with a clear affirmative action, limited to the personal data necessary for the specified purpose, and withdrawable with comparable ease. It is not within the section 17(3) list, and it is the provision that shapes signup and onboarding, which is what a startup builds first.
What to do about it
Assume no exemption and build accordingly
Design for the full regime. If a notification later relieves five obligations, you will have over-built slightly. If you design for an exemption that never arrives, you will retrofit consent and erasure into a live product with real users, which is materially harder and usually happens under deadline pressure.
Spend the effort on consent and security
Neither is in section 17(3), both are load-bearing, and both are far cheaper to get right before scale. A consent record you can produce per user per purpose, and safeguards you can evidence, are the two artefacts that matter most if anything goes wrong.
Instrument erasure early even though it might be relieved
Section 8(7) is on the section 17(3) list, so it could be disapplied - but the ability to delete a user completely is an architectural property, not a feature. Systems that cannot delete become systems that cannot comply, and retrofitting it after the data model has spread across services is the expensive path.
Watch for notifications rather than assuming them
The relief in section 17(3) arrives, if it arrives, as a published notification specifying a class. Track it deliberately, and record the date you checked. "We believed we were exempt" is not a defence; "we monitored and were not yet within a notified class" is a defensible compliance position.
Sequence the work
The same controls as above, in the order they are worth doing. Each names the evidence you would put in front of an auditor, because a control you cannot evidence is a control you cannot prove you had.
Build the foundation
Get the lawful basis and the roles right. Everything else assumes these are settled.
- Sign up a userBuild per-purpose consent from day one and keep the record. Retrofitting it into a live product with real users is materially harder than starting with it.Evidence: Consent records showing purpose, timestamp and the wording shown at the time.
- Secure the dataTreat safeguards and breach readiness as founding work. They carry the largest penalty exposure in the Schedule and no notification would relieve them.Evidence: Access model, key management, and a dated record of what was decided and why.
Operationalise it
Turn the basis into systems that run without anyone remembering to run them.
- Delete a user completelyBuild the ability to delete a user completely while the data model is small. It is an architectural property, not a feature you can add later.Evidence: A deletion runbook naming every store, and logs proving it ran end to end.
Keep it honest
Prove it still works, and answer the people whose data it is.
- Report a breachWrite the runbook before you need it, and make sure you can answer whose data was affected from a data map rather than from memory.Evidence: The runbook, a dated tabletop exercise, and a data map good enough to enumerate affected Principals.
Section and Schedule references above point at the statute itself. Read them in context in the full text of the Act, or against the MeitY publication. This is an educational summary, not legal advice for your organisation.
Startups: common questions
Are startups exempt from the DPDP Act?
No. Section 17(3) gives the Central Government a power to notify classes of Data Fiduciary, including startups, as exempt from sections 5, 8(3), 8(7), 10 and 11. Until such a notification is made and you fall within the notified class, every obligation in the Act applies to you in full. The power existing is not the same as the power having been exercised.
Does DPIIT recognition make us exempt?
No. DPIIT recognition is how the Explanation to section 17(3) defines who counts as a startup, so it determines whether you could be inside a notified class. The exemption itself would still have to be conferred by a notification from the Central Government. Recognition is a qualification, not a grant.
If the exemption arrives, what would still apply?
Most of the Act. Consent under section 6, purpose limitation, reasonable security safeguards under section 8(5), breach notification under section 8(6), children's data under section 9, correction and erasure rights under section 12, grievance redressal under section 13, and the whole penalty regime in the Schedule. Section 17(3) removes five provisions, and not the ones that carry the largest exposure.
Know this well enough to prove it
The certification is a free, graded 15-question exam covering the Act end to end, not just this sector. Pass mark is 70%.
DPDP Academy Editorial: Legal education and implementation guidance. DPDP Academy Source Review: Primary-source verification against Gazette and MeitY publications; last checked 9 August 2026 against Startups implementation guide. Educational information, not legal advice.