DPDP for SaaS startups: what your enterprise customers will ask you to prove

If you sell software to Indian companies, the DPDP Act will reach you through your customers' contracts long before it reaches you through the Board. For data your customers load into your product you are usually their processor, and they will ask you to prove your security, your breach response, and your ability to stop and erase on their instruction. For your own users, leads, analytics and any AI training, you carry the fiduciary duties yourself, from 13 May 2027, and no startup exemption has been notified.

Like the Act (s. 2(y)), we say "she" and "her" for every person.

Jump to what you need:

• Founders and sales leads: Questionnaire asks, Model answers, Liability and caps, 90-day plan.
• CTOs and engineers: Consent ledger, Erasure, backups and logs, Analytics.
• Legal and DPOs: Roles by feature, AI training, Where the law is unclear.
• Consumer apps (fintech, health, edtech, D2C): Consumer-facing startups.

What applies now, and what starts in May 2027

Under the commencement notification (G.S.R. 843(E)), the fiduciary duties and section 44(2), which deletes section 43A of the IT Act, start on 13 May 2027; most of the Rules start the same day (Rule 1(4)). Until then, the SPDI Rules under section 43A bind body corporates, and the CERT-In Directions already require service providers, intermediaries, data centres and body corporates to report specified cyber incidents within six hours and keep ICT logs for 180 days within India (CERT-In's FAQs of May 2022 suggest a copy may be held abroad if it can be produced in reasonable time, but commentators read this differently, so keep a copy in India). We expect DPAs signed before May 2027 to reference DPDP already. As of 25 October 2026 MeitY's reported January 2026 proposal to shorten the transition, at least for Significant Data Fiduciaries, has not been notified (Business Standard). The calendar is in DPDP deadlines.

Processor or fiduciary, decided feature by feature

A fiduciary decides "the purpose and means of processing", alone or with others (s. 2(i)). A processor processes "on behalf of" a fiduciary (s. 2(k)). The customer stays responsible for what you do (s. 8(1)) and may use you only under a valid contract (s. 8(2)). The question is asked per purpose, so one product usually holds both roles.

The duties are written for fiduciaries, so as a processor you will rarely face the Board directly for a customer's data. A processor that starts deciding its own purposes becomes a fiduciary for them. We recommend separate data paths for "on behalf of the customer" and "for us" processing, so you can show which is which.

What DPAs and questionnaires will ask, mapped to the law

Your customers carry the duty, so procurement will turn it into clauses and questionnaire rows. The asks below are our forecast; the provisions are the law. The last column shows where an existing ISO/IEC 27001:2022 Annex A control or SOC 2 criterion usually covers the ground, as a starting point for your mapping.

A Significant Data Fiduciary must run a Data Protection Impact Assessment and an audit every twelve months and check that its algorithmic software does not put rights at risk (Rule 13(1), (3)). As of 25 October 2026 none has been notified. In our view large banks, insurers, telecoms and platforms are the likely candidates, and their vendors should expect audit rights to harden. The buyer's side is in DPDP for corporates.

Model answers, with the numbers we recommend

These answers are illustrative, for a B2B SaaS processor. The figures in them are our recommendations, chosen to leave your customer room inside its own clocks; the law sets none of them for processors. Change any number you cannot meet and evidence.

Breach notice. "We will notify your designated security contact by phone and email within 24 hours of becoming aware of a personal data breach affecting your data, and within 6 hours where the incident may be reportable to CERT-In. The first notice will give what we know of the nature, extent, timing and location of the breach and its likely impact. Within 48 hours we will send a report covering causes, mitigation, any findings about who caused it and steps to prevent recurrence, so you can meet Rule 7(2)(b) of the DPDP Rules, 2025."

Withdrawal. "When you record a withdrawal in the product or call our withdrawal API, processing for that purpose stops in our systems within one hour. We relay it to the sub-processors that receive that data within 48 hours and confirm by event log."

Erasure at contract end. "Within 30 days of termination we will return your data in [format], erase it from production, and issue a certificate of erasure. Backups expire within 35 days and are never restored into live use. Security and access logs, which hold limited personal data, are kept for one year in a separate restricted store, in line with Rule 8(3) and Rule 6(1)(e), and then deleted."

Sub-processors. "Our sub-processors, the data each receives, its location and purpose are published at [URL]. We give 30 days' notice of a new sub-processor, and you may object."

AI. "Your data is used only to provide the service to you. AI features process it through [provider], a listed sub-processor, under terms flowed down from our contract with you (Rule 6(1)(f)) that prohibit training on your data. We do not train or fine-tune models shared with other customers on your data."

Hosting. "Primary storage and backups are in [region]. Support staff in [locations] access tenant data only on a ticket you raise, with access logged. We will comply with any restriction notified under section 16 of the DPDP Act and with sector rules that apply to you."

Liability, indemnity and caps: a negotiating position

Enterprise DPAs often ask for uncapped data-protection indemnities. The Act explains why buyers push: the fiduciary carries the penalty whatever the contract says (s. 8(1)), and the ceilings run to ₹250 crore for security failures and ₹200 crore for breach-notice failures (Schedule, items 1 and 2). The contract decides only who pays whose losses.

Our position for a startup negotiating as processor, which is opinion and no substitute for your lawyer:

• Offer a separate, higher sub-cap for data-protection claims instead of uncapped liability. We recommend a general cap of twelve months' fees and a data-protection sub-cap of two to three times annual fees, set no higher than you can insure.
• Tie the indemnity to your fault. Cover losses caused by your breach of the DPA or of the Rule 6 safeguards you committed to. Exclude losses from the customer's own choices of purpose, notice or basis.
• Carve out the customer's fiduciary duties. Notices, consent, legal basis and responses to the Board are theirs; your duty is to support them on time.
• Match the cap to cyber insurance and tell the buyer what the policy covers.
• Trade evidence for risk. A buyer who can see your control matrix, drill notes and sub-processor list has less reason to demand unlimited cover.

An illustrative clause, to adapt with your lawyer:

"Each party's total liability under this Agreement is limited to the fees paid or payable in the twelve months before the claim. For claims arising from Processor's breach of the Data Processing Addendum, including the security measures in Schedule 2, Processor's total liability is limited to [two] times that amount. Processor is not liable for losses arising from Customer's decisions as Data Fiduciary, including the purposes of processing, the notices given and the legal basis relied on."

Build a consent ledger and propagate withdrawal

Where consent is the basis and a question arises in a proceeding, the fiduciary must prove both the notice and the consent (s. 6(10)). If you capture consent for your own app or for customers, the ledger is that proof. A recommended event model:

The build rules that follow from the Act:

• Withdrawal as easy as consent (s. 6(4)), and the notice must say how (Rule 3(c)(i)).
• Check purpose at read time. After withdrawal you and your processors must stop within a reasonable time, unless a law requires or authorises continued processing (s. 6(6)). Gate jobs, exports and syncs on the current consent state per purpose.
• Propagate and record. Emit a withdrawal event to every downstream system and vendor that received the data for that purpose, and log each acknowledgement.

Earlier processing stays lawful, and the consequences of withdrawal fall on her (s. 6(5)), so you may stop a feature that genuinely needs the data. Notice text is covered in How to write a DPDP notice.

Consent Managers will not be usable before 13 May 2027: registration opens on 13 November 2026 (s. 6(9), Rule 4), but people can act through one only once section 6(7) starts, and with no Board Members to decide applications as of 25 October 2026 (LiveLaw), none is registered. Design the ledger so an event can later arrive from one; Consent Managers under DPDP has the detail.

Erase across tenants without breaking the log rules

Erasure duties come from withdrawal or the end of the purpose (s. 8(7)(a)), an erasure request (s. 12(3)), and the fiduciary's duty to make processors erase (s. 8(7)(b)). As a processor you receive all of them as customer instructions.

Backups. Rule 6(1)(d) asks for continuity measures, with backups as the example, and says nothing about erasing from them. We recommend short documented expiry, a deletion journal replayed after any restore so erased records never return to live use, and per-tenant keys so destroying a key makes remaining backup copies unreadable.

Logs and the one-year floor. Three rules pull against fast erasure. Rule 8(3) requires the fiduciary to keep personal data, associated traffic data and processing logs for at least one year from the processing, including processing done by its processors, for the Seventh Schedule purposes. Rule 6(1)(e) asks for a year of logs and personal data to investigate unauthorised access. CERT-In asks for 180 days of ICT logs kept in India.

Read literally, Rule 8(3) defers erasure of personal data by up to a year after the last processing, through the "compliance with any law" exceptions in sections 8(7) and 12(3). The text allows either of these designs:

• Lower-risk design. On erasure, remove the record from live systems and move it to a restricted store usable only for Seventh Schedule requests, then destroy it one year after the last processing. This follows the literal text.
• Erase-now design. Erase the record at once and keep only pseudonymised logs for a year. We think this is a defensible reading of the rule's purpose. Its risk is that a government request under Rule 23 finds the data gone, and a finding that Rule 8(3) was breached (Schedule, item 7).

Either way, keep logs pseudonymised, in a separate store in India, with narrow access and automatic expiry, and record the design you chose in your retention schedule.

Cookies and product analytics: what needs consent

The Act has no cookie provision. Cookies, device identifiers, session replays and event streams are personal data when they relate to an identifiable person (s. 2(t)), and then they need a basis.

A banner with "Accept all" and a buried "Manage" link is unlikely to show free, specific and unambiguous consent (s. 6(1)). Use equal-weight accept and reject buttons, list purposes separately, and fire nothing non-essential before the choice. Audit the scripts that load in production as well as the tag-manager list.

Children and section 9(3): who carries the duty

A child is anyone under 18 (s. 2(f)). A fiduciary needs verifiable parental consent (s. 9(1), Rule 10), must not process in ways likely to harm her well-being (s. 9(2)), and must not track, behaviourally monitor or target advertising at her (s. 9(3)). The government can lower the age only for a specific fiduciary whose processing it finds verifiably safe (s. 9(5)); as of 25 October 2026 none has been notified.

• You sell to schools. For the school's processing you are its processor. The school's Fourth Schedule exemption covers only tracking and behavioural monitoring for its educational activities or enrolled children's safety (Part A, item 3). It does not cover your own analytics on the same children.
• You sell to parents or children directly. You are the fiduciary: verify the parent against reliable identity and age details, including a DigiLocker token (Rule 10(1)), and switch off personalised advertising for under-18s.
• You do not intend to serve children. You may process data to confirm a user is not a child (Fourth Schedule Part B, item 6). Use the lightest check that works.

AI features: inference is processing, training is your purpose

Running a model on a customer's data to deliver a feature the customer turned on is processing on its behalf. The model provider you call is your sub-processor: it belongs on your list (s. 11(1)(b)) and under terms flowed down from your customer contract (Rule 6(1)(f)).

Training or fine-tuning a model that serves other customers is a purpose you decide, so our view is that you become a fiduciary for it (s. 2(i)), needing a basis for every person in the data that you will rarely have. Customer contracts will usually forbid it, and government departments have started writing it down for their partners, as a reported Uttarakhand affidavit for NGOs shows (MediaNama). Data that no longer relates to an identifiable individual is outside the Act (s. 2(t)), which sets no anonymisation standard; test re-identification before treating a training set as anonymous, and record the test.

Staff use of AI tools is the quieter risk. An example policy, illustrative:

• Use only the AI tools on the approved list, through company accounts, with training on our inputs switched off.
• Never paste customer data, end-user data, credentials or source code containing secrets into any other AI tool.
• Customer data may go into an approved tool only for that customer's ticket, and only the minimum needed.
• New tools go through security review and, if they will see customer data, onto the sub-processor list first.
• Report a mistaken paste to security the same day; it may be a breach.

Hosting outside India: keep a transfer register

Section 16 and Rule 15 start on 13 May 2027. From then, transfers abroad are allowed unless the government restricts the destination by notification (s. 16(1)), subject to any requirements on making data available to a foreign State (Rule 15); as of 25 October 2026 we have found no restriction notified. Until then, SPDI Rule 7 governs body corporates transferring sensitive personal data abroad: the recipient must ensure the same level of protection, and the transfer must be necessary for a contract or consented to. Stricter sector laws survive in both periods (s. 16(2)).

Keep a transfer register: each region and sub-processor, the data it holds, the support locations that can reach it, and the customers whose sector rules restrict it. Check these sector rules with each regulated customer:

Keep CERT-In logs in India regardless.

If you sell to consumers instead

A consumer app has no customer between you and the user, so you are the fiduciary for nearly everything, and the processor questions above become questions you ask your own vendors.

• Fintech. Sector rules sit on top of DPDP (s. 16(2), s. 38(1)), so map RBI, SEBI or IRDAI requirements beside the Act. KYC records are kept because a law requires it (s. 8(7)). Our view: marketing on the back of KYC data needs separate consent. Expect Significant Data Fiduciary scrutiny as you grow, given the volume and sensitivity test in s. 10(1).
• Health. No sensitive-data category exists, but the type of data is a penalty factor (s. 33(2)(b)). The Fourth Schedule lifts parental consent and the tracking ban for clinical and mental health establishments, healthcare professionals and allied healthcare professionals, only as needed for the child's health (Part A, items 1–2). If you connect to the Ayushman Bharat Digital Mission, its own consent and data policies apply as well. Keep consent for health records separate from consent for wellness marketing.
• Edtech. Parental consent and the tracking ban apply in full to your own processing of under-18 users. Verify parents at signup, switch off ad SDKs for child accounts, and decide in writing where personalisation stops short of behavioural monitoring.
• D2C and marketplaces. Marketing consent by channel (SMS, WhatsApp, email) is the main build, with withdrawal one tap away. Order data a user gave for delivery sits under s. 7(a) for that purpose. An e-commerce entity with at least two crore registered users in India must erase data three years after her last approach or the Rules' commencement, whichever is later, except data for account access and stored-value tokens, and unless a law requires retention, with 48 hours' warning (Rule 8(1)–(2), Third Schedule).

The obligation-by-obligation explanation is in the DPDP Act and Rules guide.

The startup exemption has not arrived

Section 17(3) lets the government exempt notified fiduciaries, "including startups", from a short list of duties (notice, accuracy, erasure, the SDF duties and the access right). Section 17(5) allows wider, time-limited exemptions. As of 25 October 2026 neither has been used. Even a 17(3) exemption would leave consent, security, breach notice and children's duties in place, and it would not change your customers' contracts. The full list is in the DPDP Act and Rules guide.

Where the law is unclear

These are our positions until the Board or the courts decide otherwise.

When does the 72-hour clock start if you, the processor, find the breach? Treat your awareness as starting the customer's clock. Why: Rule 7(2)(b) runs from the fiduciary becoming aware, whether a processor's knowledge counts is unsettled, and the fiduciary answers for its processors (s. 8(1)). Would change if: the Board says the clock starts only when the fiduciary is told. Confidence: medium.

Can the Board penalise a processor directly? Mostly no, for the customer's data. Why: the duties are written for fiduciaries, though the Schedule's residual item covers "any other provision". Would change if: an early order penalises a processor. Confidence: medium.

What is the basis for fraud and abuse detection? There is no legitimate-interests ground. For data a user gave you to use the service, state fraud prevention in the notice and rely on section 7(a), limited to what is necessary; for genuine detection of offences such as cheating, section 17(1)(c) may lift most duties, leaving responsibility for processors (s. 8(1)) and security (s. 8(5)). Why: consent would be bundled and refusable, which defeats the purpose. Would change if: the Board reads 7(a) or 17(1)(c) narrowly. Confidence: low.

Must data be erased from backups at once? No, if backups expire on a short cycle and are never restored into live use. Why: the Rules require continuity measures (Rule 6(1)(d)) and are silent on erasing from backups. Would change if: the Board treats retained backups as failing section 8(7). Confidence: medium.

Is adaptive learning "behavioural monitoring" of children? Personalising content from a child's answers in one session probably is not; a long-run behavioural profile used to drive engagement probably is. Why: neither term is defined, and the education exemption implies some tracking for learning is otherwise caught. Would change if: rules define the terms. Confidence: low.

A 90-day plan for a 20 to 200 person startup

From 2 November 2026 to the end of January 2027, leaving time to fix what the plan finds before May. The weeks are planning assumptions.

Legacy users and leads in your CRM need their own triage; The data you already hold covers it. If you would rather call an API than build consent capture and rights requests, see the consent management platform guide.

How we wrote this guide. We worked from the Digital Personal Data Protection Act, 2023, the commencement notification G.S.R. 843(E), the Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), as corrected by G.S.R. 892(E)), the CERT-In Directions of 28 April 2022 and the linked reports, last checked 25 October 2026. ISO and SOC 2 mappings are a starting point, to be checked against your own statement of applicability. The questionnaire asks, model-answer figures and negotiating position are our forecast and recommendations. This guide explains the law; it is not legal advice.