The most dangerous sentence in an Indian startup is not "we'll fix it after the round." It is "we're too small for that to apply to us."
Picture a fourteen-person B2B SaaS company in Bengaluru, three weeks from closing a seed round. The investor's counsel sends over the diligence list. Item 31 reads: "Confirm compliance status under the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025." The founder replies in four minutes: "We're pre-Series A and have under 5,000 users. It doesn't apply to us yet."
Counsel's response arrives the next morning, politely and in two lines: please share your data map and your breach response plan.
There was no data map. There was a production database, a Notion workspace full of customer call notes, a Google Sheet of demo requests, and a staging server that nobody had cleaned since the last hackathon.
If any of that feels familiar, this article is for you. We will answer the question directly, show where the law draws its lines, name the real operational problems lean teams hit, and give you a plan that fits a startup's calendar and budget.
The short answer: yes, almost certainly
The Act does not ask how big you are. It asks what you do with data.
Section 3 applies the law to the processing of digital personal data within India, and to processing outside India when it is connected to offering goods or services to people in India. Two things sit outside: personal data an individual processes for purely personal or domestic purposes, and personal data that the individual themselves has made publicly available (or that someone has made public under a legal obligation).
Notice what is missing from that list. There is no turnover floor, no headcount floor, no funding-stage floor, and no minimum user count. A two-founder company with 800 users and a six-person company with 800,000 users both become a Data Fiduciary the moment they decide why and how personal data is processed. Your users are Data Principals. Your vendors who process on your behalf are Data Processors.
One nuance worth keeping. The Act covers personal data in digital form, including paper records that are later digitised. A paper visitor register is out of scope until someone scans it.
Seven beliefs founders hold, and what the Act actually says
We hear the same objections in almost the same words. Here they sit beside the text.
| What founders say | What the Act says |
|---|---|
| "We're too small." | Section 3 has no size test. Applicability turns on digital personal data and its connection to India. |
| "We're B2B, so there's no personal data." | Names, work emails, phone numbers and call recordings of your customers' staff are personal data. |
| "Payments run through a gateway, so it's their problem." | The gateway handles the card. You still hold name, email, billing address and order history. |
| "Our servers and company are outside India." | If you offer goods or services to people in India, Section 3 reaches you wherever you are incorporated. |
| "We only have employees' data." | Employees, applicants and contractors are Data Principals too. Section 7 allows processing for employment purposes, but only for those purposes. |
| "A privacy policy page is enough." | Notice, consent, security, breach reporting and rights are separate duties, each of which needs evidence. |
| "The startup exemption covers us." | Section 17(3) is a power to notify an exemption, not an exemption. More on this next. |
The startup carve-out: what Section 17(3) really says
This is the part that causes the most wishful thinking, so it deserves care.
Section 17(3) lets the Central Government, "having regard to the volume and nature of personal data processed", notify certain Data Fiduciaries or classes of them, including startups, to whom a short list of provisions will not apply. The Act defines a startup for this purpose as a private limited company, partnership firm or LLP incorporated in India that is recognised as a startup under criteria notified by the department handling startups.
The list of provisions is short. If a notification is issued for your class, these could be relaxed: Section 5 (notice), Section 8(3) (completeness, accuracy and consistency of data), Section 8(7) (erasure once the purpose is served), Section 10 (Significant Data Fiduciary duties) and Section 11 (the right to information about processing).
Read the right-hand column twice. Consent or a legitimate use, security safeguards, breach intimation, processor contracts, children's protections, correction and erasure rights and grievance redressal are all untouched. Even in the best case, a notified startup gets relief on a handful of provisions and keeps the core.
Two further points. First, this is a power, not a protection: at the time of writing we have not seen a notification under Section 17(3) for any class of startups, so check MeitY and the Gazette before relying on one. Second, Section 17(5) separately lets the Government, within five years of commencement, declare that any provision will not apply to a class of Data Fiduciaries for a specified period. That too has to be notified first.
The sensible planning assumption is the full Act applies to you, and any exemption that arrives is a bonus.
Are you a Fiduciary or a Processor? Usually both
Startups often assume the role question lets them off the hook. It rarely does, because most companies wear both hats on different data.
| Your startup type | Role for your end users' data | Role for your own staff, leads and website visitors |
|---|---|---|
| B2C app (fintech, edtech, health, commerce) | Data Fiduciary | Data Fiduciary |
| B2B SaaS that hosts your customers' end-user data | Usually Data Processor, bound by your customer's contract | Data Fiduciary |
| Agency, consultancy or dev shop | Often Processor for client data | Data Fiduciary |
| Marketplace connecting buyers and sellers | Fiduciary for both sides' account data | Data Fiduciary |
The processor label does not make compliance disappear. Under Section 8(1), your customer remains responsible for processing done on its behalf and under Section 8(2) it may engage you only under a valid contract. In practice that contract flows obligations down to you: security controls, breach notice timelines, deletion on exit, sub-processor disclosure. So the processor startup meets the DPDP Act through its customers' procurement teams, long before any regulator arrives.
The calendar: three dates, one faster clock
The Rules were notified on 13 November 2025 and the Act commences in phases.
The Data Protection Board is already constituted. The Consent Manager provisions begin on 13 November 2026. The core obligations in Rules 3 and 5 to 16 become enforceable on 13 May 2027. MeitY discussed compressing the 18-month window for larger entities in January 2026, but nothing has been gazetted at the time of writing, so treat 13 May 2027 as the operative date and an earlier one as a risk.
For a startup, though, the statutory calendar is the slower clock. The faster one is commercial: enterprise buyers, banks and investors already put DPDP language in contracts and diligence lists, so the question reaches you in 2026 regardless of 2027.
The real challenges nobody puts in the compliance deck
Legal summaries make DPDP sound like a paperwork problem. For a startup it is an operations problem. These are the patterns we see most often.
Nobody owns it. In a fifteen-person company, privacy is "someone's side job" until it becomes nobody's job. The CTO assumes legal has it; the founder assumes the CTO has it. Name one accountable person. The Rules expect you to publish contact details for someone who can answer a Data Principal's questions.
Data multiplies faster than documentation. Startups ship weekly. A growth experiment adds a tracker, a sales hire exports leads into a spreadsheet, an engineer copies production into staging "just for a day." Each is a new home for personal data, and none appear in a document written in March.
Every SaaS tool is a processor. Analytics, CRM, support desk, email automation, session replay, payroll. Most of these vendors offer click-through terms, and a seed-stage buyer has little negotiating power. The practical work is knowing which vendors touch personal data, where it is hosted, and whether their terms cover security, sub-processors, breach notice and deletion at exit.
Consent retrofits collide with growth. Rewriting a sign-up flow to meet Section 6 (free, specific, informed, unconditional, unambiguous, with a clear affirmative action) hurts if the funnel was built on pre-ticked boxes and bundled permissions. The Rules also expect a standalone, itemised, plain-language notice. And for people who already consented before commencement, Section 5(2) expects a notice as soon as reasonably practicable. Your legacy user base is not grandfathered into silence.
Security safeguards cost real money. Rule 6 expects encryption, obfuscation or masking or virtual tokens, access control, logging and monitoring, tested backups, and retention of logs and relevant personal data for one year. Storing a year of logs is an infrastructure bill. And logs are themselves personal data, which creates a quiet tension with deletion requests that your team needs to resolve on paper first.
Seventy-two hours is shorter than it sounds. Under Rule 7, you tell affected people without delay, tell the Board without delay, and follow up with detailed information within 72 hours. A four-person engineering team with no on-call rota and a weekend incident does not make that clock by improvisation.
Children's data catches edtech and gaming teams by surprise. Section 9 treats anyone under 18 as a child, requires verifiable parental consent, and bars tracking, behavioural monitoring and targeted advertising directed at children. Section 17(3) does not touch Section 9, and a startup serving teenagers needs an age-assurance answer on day one.
| Challenge | Why startups hit it | The pragmatic move |
|---|---|---|
| No owner | Founders wear nine hats; privacy is nobody's quarterly goal | Appoint one accountable lead, publish a grievance contact, and report to a named sponsor |
| Shadow data | Speed beats documentation; copies and exports spread | Inventory systems first, then go looking for spreadsheets, staging copies and chat groups |
| Vendor sprawl | Click-through terms, no legal team | Rank vendors by personal data touched; fix the top ten contracts first |
| Consent debt | Funnel built before the law existed | Rewrite collection points, then re-notify legacy users in waves |
| Thin security bench | No dedicated security hire | Cover Rule 6 basics, keep logs, test one restore, and revoke access on exit day |
| Slow breach response | No on-call, no playbook | Run one tabletop exercise this quarter and write down who calls whom |
What the law puts at stake
Scale is useful context for a board conversation. The Schedule to the Act sets penalty ceilings.
These are ceilings, not price tags. Under Section 33(2) the Board weighs the gravity and duration of the breach, the data involved, repetition, your mitigation and proportionality, and a voluntary undertaking under Section 32 can close a proceeding. But look at the shape of the chart. The largest ceiling attaches to failing to take reasonable security safeguards, the most fixable item for a lean team and one your engineers are already half-way through.
A lean 90-day plan for a startup
You will not be finished in ninety days. You will be defensible, which is the thing diligence teams and enterprise buyers actually test.
| Window | Focus | What you can hand to a buyer or investor |
|---|---|---|
| Days 1 to 30 | Name an owner. Inventory every system and tool holding personal data. Start the Record of Processing Activities (RoPA) with the three highest-volume flows | Appointment note, system inventory, first RoPA |
| Days 31 to 60 | Rewrite notice and consent at every collection point. Build one intake channel for rights requests and grievances (the Rules allow up to 90 days for a grievance response, but aim for days). Rank vendors and chase the top ten | Notice templates, consent logs, request register, vendor list |
| Days 61 to 90 | Set retention periods and delete what has no purpose. Harden access controls and log retention. Run a breach tabletop. Assemble the evidence file | Retention schedule, access review, tabletop report, dated evidence folder |
Two cautions. The Third Schedule's erasure-after-inactivity clocks apply to large e-commerce, online gaming and social media platforms above specified user thresholds. Most early-stage startups sit below them, but confirm where you stand. And keep evidence as you go, because auditors and customers sample your records. They do not grade your intentions.
Where VaultDef fits
Every item in the plan above is a data problem before it is a legal problem. You cannot write a RoPA for systems you have not found, prove consent you did not record, or meet a breach clock without knowing which records were exposed. A spreadsheet will carry you through the first quarter. By the fourth, it will be wrong, and nobody will have noticed.
VaultDef is built for that gap between a good intention and a defensible record. It gives a small team:
- Automated data discovery and classification across databases and stores, so the inventory starts from what is actually there rather than from memory.
- RoPA and data mapping that updates as systems change, which solves the March-to-September drift that kills static documents.
- Consent and notice management, with cookie consent and timestamped records, so you can show what a person agreed to and when.
- Data principal rights workflows that ticket every access, correction, erasure and grievance request and track turnaround.
- Vendor and cross-border tracking so your processor register is a live view, not an annual exercise.
- Breach workflow and DPIA tooling that turns the 72-hour clock into a rehearsed process.
- A tamper-evident evidence trail, so that when a customer or investor says "prove it," you open a folder instead of a war room.
You do not need all of it on day one. Process comes first, tooling second: start with discovery and the RoPA, and add modules as the business scales.
If you would rather see it than read about it, VaultDef runs a forty-five minute working demo on a sample of your own schema, or ours, and leaves you with the gap assessment generated during the call. Request a walkthrough at vaultdef.com.
The honest closing thought
Small does not mean exempt, and the exemption startups keep pointing to is not in force. But small is also an advantage. A company of twenty can map its data in a fortnight and build privacy into the product before the codebase hardens around bad habits. A company of two thousand cannot.
The startups that struggle in 2027 will not be the ones with small budgets. They will be the ones that waited for certainty before taking a first step. Clarity arrives through the work.
Start this week with one question: where does personal data live in our company? Everything else follows from the answer.
Frequently asked questions
Does the DPDP Act apply to a startup with only a few hundred users?
Yes. The Act sets no minimum user count, turnover or headcount. If you process digital personal data in India, or offer goods or services to people in India, you are a Data Fiduciary.
Is there a startup exemption under the DPDP Act?
Not automatically. Section 17(3) allows the Government to notify startups or classes of Data Fiduciaries for relief from Sections 5, 8(3), 8(7), 10 and 11. We have not seen such a notification at the time of writing, and even if one arrives, the core duties remain.
Do we need a Data Protection Officer?
A DPO based in India is required for Significant Data Fiduciaries. Everyone else should still appoint an accountable privacy lead and publish contact details for questions from Data Principals.
When must we be compliant?
Consent Manager provisions commence on 13 November 2026 and the core obligations on 13 May 2027. A proposal to shorten the window for larger entities has been discussed but not gazetted.
This article is for general information and is not legal advice. Check the Act, the Rules and current MeitY notifications, and consult counsel for your own situation.
