The DPDP Act for Companies Outside India: What Section 3(b) Requires

If your company sits outside India and you have Indian users, the question is not whether India’s Digital Personal Data Protection Act 2023 reaches you. It does. The threshold is far lower than most global privacy teams assume: a sign-up form that takes a name and an email address from someone in Mumbai is enough to bring your processing inside the Act. This guide covers what Section 3(b) actually triggers, what is genuinely different from the GDPR programme you already run, and what to do about the vendors and servers scattered across your other regions.

What Actually Triggers the Act

Section 3(b) of the DPDP Act extends it to:

“processing of digital personal data outside the territory of India, if such processing is in connection with any activity related to offering of goods or services to Data Principals within the territory of India.”

Read that carefully, because the scoping instincts you built for the GDPR will mislead you here in two directions at once.

It is broader than you expect on volume. There is no materiality threshold, no user-count floor, and no turnover test — and, importantly, no requirement that anyone pay you. A free tier, a free trial, a freemium account and an ad-supported product are all services being offered, so their Indian users are in scope exactly as paying customers are. “Digital personal data” is any data about an identifiable individual, in digital form. A name and an email captured at signup qualifies. So does a support ticket, a newsletter subscription, or an account created and then abandoned. If you were waiting for a threshold to cross before starting compliance work, there isn’t one.

It is narrower than you expect on activity. The trigger is offering goods or services to people in India — and that is the whole trigger. The DPDP Act has no equivalent of the GDPR’s second limb at Article 3(2)(b), which also catches the monitoring of behaviour. Under DPDP, tracking Indian visitors’ behaviour without offering them anything is not, by itself, the statutory hook. In practice this rarely helps a commercial business — if people in India can sign up, subscribe, or buy, you are offering a service — but it matters for scoping, and importing the GDPR’s monitoring limb by reflex will make you over-scope.

Where your company is incorporated, where your servers sit, and which currency you bill in are all irrelevant to this test. A Delaware company running on European infrastructure with an engineering team in Poland is covered the moment it serves users in India.

Mobile apps are not a separate case

Nothing in the Act or the Rules treats an app differently from a website — the drafting is deliberately technology-neutral, and Rule 14(1) speaks of publishing on "its website or app, or both, as the case may be." So an iOS or Android app distributed to Indian users through the App Store or Play Store is in scope on exactly the same terms as a website. If your app has a login, a "continue with Google" button, or an email field anywhere in onboarding, you are collecting digital personal data from Indian users and Section 3(b) attaches.

Two things follow that app teams commonly miss. First, the store is a distribution channel, not a shield — Apple and Google are not your Data Fiduciary, and their own privacy terms do not discharge your obligations for the data your app collects. Second, the SDKs in your build are Data Processors: analytics, crash reporting, attribution, push notifications and ad mediation all typically ship personal data off-device. Each one belongs in the vendor review described below, and an SDK you cannot switch off for a given user is a consent problem waiting to happen.

The Question Almost Every Global Team Asks First

Two questions come up before any others, and both have reassuring answers.

Do we need to set up an entity or appoint a representative in India? No. The DPDP Act has no analogue to GDPR Article 27, which forces non-EU controllers to designate an EU representative. Nothing in the Act or the DPDP Rules 2025 requires a foreign Data Fiduciary to establish an Indian entity, appoint a local representative, or register with any authority. The single India-presence requirement anywhere in the framework is the Data Protection Officer who must “be based in India” under Section 10(2)(a)(ii) — and that duty attaches only to organisations the Central Government notifies as Significant Data Fiduciaries. No such notifications have been issued to date.

Do we have to move Indian users’ data to India? Also no, for ordinary businesses. This is the most persistent myth about the DPDP Act, and it is worth being precise about why it is wrong. Section 16 works as a negative list: the Central Government may, by notification, restrict transfers to a particular country or territory. Until it names one, transfers are permitted. No country has been notified. Rule 15 of the DPDP Rules 2025 adds one standing condition — a Data Fiduciary must meet whatever requirements the government may specify about making personal data available to a foreign State or its agencies — but no such order has been issued either.

Two caveats keep this honest. First, Rule 13(4) does contain a real localisation power, but it reaches only Significant Data Fiduciaries, and only for categories of data the government specifies on a committee’s recommendation; nothing has been specified. Second, Section 16(2) expressly preserves any Indian law imposing stricter transfer rules — which is where the genuine localisation mandates live. If you are in payments, RBI’s 2018 payment-systems data-storage directive applies to you and DPDP does not soften it. Insurance and telecom have their own regimes. DPDP itself does not localise; India’s sector regulators do.

What Is Genuinely Different From the GDPR

If you run a mature GDPR programme, most of your machinery transfers. Concentrate your effort on the five places where India diverges, because these are where GDPR-shaped compliance quietly fails.

The lawful-basis shift is the one that costs real engineering time. Processing you currently run on legitimate interests — product analytics, enrichment, most lifecycle marketing — generally has to be re-based on consent for Indian users, which means a consent state per purpose per user, and a withdrawal path that is as easy as giving consent was (Section 6(4)). If your consent model is a single boolean at signup, it will not survive contact with the Act.

Your Servers Are in Five Regions. Now What?

A global architecture does not create a DPDP problem by itself — as established above, the Act does not require Indian data to stay in India. What a distributed architecture does create is an evidence problem. Section 8(1) makes you responsible for compliance “irrespective of any agreement to the contrary,” including for processing carried out on your behalf. When the Data Protection Board asks a question, you have to answer it about the whole estate.

Three practical consequences:

• You must be able to find an Indian user across every region. An erasure request under Section 12 is not satisfied by deleting the primary record in your US region while copies persist in an EU replica, a Singapore analytics warehouse, and a data lake someone stood up two years ago. If you cannot enumerate every store holding personal data, you cannot honestly answer a rights request — and the burden of proving you did sits with you.
• Backups and logs are in scope. They hold personal data. Your retention policy under Section 8(7) has to say what happens to them, and your deletion process has to be honest about backup cycles rather than silent about them.
• Region does not change the duty. Data on an Indian user processed in Frankfurt carries exactly the obligations it would carry in Bengaluru. Where you process changes nothing about what you owe.

Your Email, SMS and Analytics Vendors

Under the Act your vendors are Data Processors, and the allocation of responsibility is blunt. Section 8(1) keeps the Data Fiduciary responsible for processing done on its behalf, whatever the contract says. Section 8(2) permits you to engage a processor “only under a valid contract.”

Two things surprise teams arriving from the GDPR. First, the Act prescribes no mandatory contractual content — there is no DPDP equivalent of the Article 28(3) clause list. “A valid contract” is the whole statutory requirement. Second, there is no requirement that your processors be Indian. Your existing email, SMS, CRM, analytics and support vendors can stay exactly where they are.

That freedom comes with a catch, though, and it is the reason vendor review matters here. Because the Act leaves the contract content to you, and because you remain answerable for your vendors’ failures, your obligations are only as achievable as your weakest processor’s capabilities. Work through the list — the transactional email service, the SMS gateway that sends OTPs to Indian numbers, the analytics SDK in your mobile app, the support desk, the CDP, every sub-processor underneath them — and for each one ask four questions:

1. Can it delete on request, for real? An erasure request you cannot execute at a vendor is an obligation you cannot meet.
2. Will it tell you about a breach fast enough? Your 72-hour Board filing clock starts when you become aware. A vendor contract permitting 30 days’ notice has already blown your deadline.
3. Does it respect purpose limits? A vendor mining your data for its own model training is processing beyond your instructions — and it is your consent record that is now inaccurate.
4. Can it produce evidence? When the Board asks what was sent to whom and on what consent, the answer has to come out of a system, not a memory.

SMS deserves specific attention for Indian users, because it sits at an awkward intersection: the gateway is usually a local Indian provider, and it is often wired directly to your marketing stack. Marketing messages need consent for the marketing purpose specifically — consent to create an account is not consent to be marketed to. India’s TRAI commercial-communication rules also apply independently of DPDP; meeting one does not discharge the other.

If Children Can Use Your Product

This is the section to read twice if you build a game, a consumer app, or anything with a mixed-age audience — because India's rules for children are stricter than the regime you are used to, and the strictest part cannot be bought off with consent.

A child under the Act is anyone who has not completed eighteen years (Section 2(f)). Not thirteen, not sixteen — eighteen, with no member-state variation of the kind the GDPR allows. The Central Government can lower that bar under Section 9(5), but read the provision closely: it is a bespoke, per-company notification for a specific Data Fiduciary that has satisfied the government its processing is "verifiably safe", not a general power to set a lower age for an industry. No such notification has been issued. The operative age is eighteen for everyone.

Two duties, and only one of them involves consent

Section 9(1) — verifiable parental consent. Before processing a child's personal data you must obtain the verifiable consent of a parent or lawful guardian. The same sub-section also covers persons with disability who have a lawful guardian, so quote it whole if you quote it at all.

Section 9(3) — a flat prohibition. A Data Fiduciary "shall not undertake tracking or behavioural monitoring of children or targeted advertising directed at children." Note what is absent: any mention of consent. Unlike 9(1), which is expressly a consent obligation, 9(3) is drafted as an unconditional bar on the company. Parental consent does not unlock it.

If that reading seems aggressive, the Rules settle it. Rule 12 exempts certain entities and purposes from sub-sections (1) and (3) as separate carve-outs. If consent under 9(1) could cure a 9(3) problem, there would be no reason for the Rules to exempt 9(3) independently. The drafting only makes sense if 9(3) stands on its own.

For a game or app monetised through advertising, that is the commercially significant fact on this page: your exposure is in the ad and analytics stack, not the consent flow. Behavioural ad SDKs, engagement profiling, lookalike targeting and retargeting directed at under-18s are prohibited outright, however impeccable your parental-consent screen.

Section 9(2) adds a third duty — no processing "likely to cause any detrimental effect on the well-being of a child". "Well-being" is undefined in the Act, unelaborated in the Rules, and has no Board guidance behind it yet. Treat it as an open standard you should be able to argue you considered, not a test with a settled answer.

What "verifiable" parental consent actually requires

Rule 10 sets the mechanics, and it is less prescriptive than most vendors will tell you. You must adopt "appropriate technical and organisational measures" and do due diligence that the person claiming to be the parent is an adult who is identifiable — traceable if Indian law later requires it — by reference to one of three routes: reliable identity and age details you already hold; details the individual volunteers; or a virtual token mapped to such details, issued by an authorised entity.

Three corrections to common claims. No specific technology is mandated — the obligation is framed by outcome. DigiLocker is not required; it appears inside the definition of "authorised entity" as something that is included, not prescribed. And that token route is not yet fully operational, because the Digital Locker service provider it depends on is itself subject to a government notification that has not issued.

The practical shape of the problem depends on whether you already know the parent. Where the parent is an existing registered user whose identity and age you reliably hold, you can rely on your own records. Where they are a stranger — the normal case for a game — you are pushed toward government-issued details or a virtual token. Our guide to verifiable parental consent works through the mechanics in detail.

Does the law require age verification? No — and that is not the relief it sounds like

Here the market's compliance advice runs ahead of the statute, and it is worth being precise. Neither the Act nor the Rules impose a freestanding age-verification or "age assurance" obligation. The phrase does not appear. Section 9(1) bites before processing the data "of a child"; Section 9(3) bites on tracking "of children". The duties are triggered by the user being a child, not by a duty to check first. Rule 10's verification machinery, read carefully, is aimed at confirming that the self-identified parent is an adult — there is no child-age-verification rule anywhere in the framework. You will see it asserted that DPDP "requires age gates". It does not, on the text.

The relief is narrower than it appears, though, and the reason matters. Section 9 carries no knowledge qualifier. There is no "actual knowledge" standard of the kind COPPA uses, and no safe harbour anywhere for self-declared age. An unchecked "I am over 18" tick-box is not mentioned in the Act, not blessed by the Rules, and is not a defence on the face of either. If a child in fact used your service, 9(1) and 9(3) were engaged in fact — and you are exposed regardless of what the user told you.

So the honest statement is this: age assurance is risk mitigation, not a statutory requirement. The law does not order you to build an age gate; it holds you strictly to obligations you cannot discharge unless you have some idea who is a child. Most teams serving a mixed-age audience will conclude that some form of age signal is the only practical way to meet a duty that has no knowledge defence — which is a business decision made in the shadow of the law, not compliance with a rule. Be sceptical of anyone who tells you otherwise while selling you the gate.

The exemptions almost certainly do not cover you

Rule 12 and the Fourth Schedule do carve out Sections 9(1) and 9(3) — for healthcare providers, educational institutions, crèches and school transport operators, and for governmental, safety and child-protection purposes. A consumer app or game is in none of those classes and cannot opt into them.

One entry is worth understanding precisely, because it is easy to over-read. Part B item 6 permits processing for "confirmation by the Data Fiduciary that the Data Principal is not a child" and for observing Rule 10 due diligence. That is a bootstrapping permission: it clears the legal path to collect the minimum data needed to work out whether you are dealing with a child and to run the parent check. It does not exempt your service from anything else. Part B item 3 similarly permits creating "a user account for communicating by email" — but the condition confines that account to email communication, so it is not a general onboarding exemption and a game account is not within it.

What this costs if you get it wrong

Breach of the Section 9 obligations sits in the Schedule at up to ₹200 crore — the second-highest tier in the Act, behind only the ₹250 crore security-safeguards entry. As always these are ceilings ("may extend to"), and the Board sets the actual figure using the Section 33(2) factors.

For a foreign developer, though, the fine may not be the operative risk. Section 37 lets the Central Government, on the Board's reference after penalties in two or more instances, direct the blocking of public access to the computer resource through which you offer goods or services to people in India. If you hold no Indian assets, losing access to the Indian market is the enforcement mechanism that actually reaches you.

The Page You Are Probably Missing

Here is the requirement most global companies have not built, because no other regime words it quite this way. Rule 14(1) of the DPDP Rules 2025 requires a Data Fiduciary to prominently publish on its website or app both:

• the means by which a Data Principal can make a request to exercise their rights; and
• the particulars — a username, customer ID, registered email or mobile, or similar — that you need in order to identify them.

Separately, Section 8(9) requires you to publish the business contact information of your Data Protection Officer, if you have one, or of a person able to answer questions about your processing. Ordinary Data Fiduciaries do not have to appoint a DPO — but you do have to publish a named point of contact.

A privacy policy paragraph saying “contact us for privacy requests” does not meet this. What Rule 14 asks for is a specific, findable, working channel — in practice, a data-request page carrying a form, the identifier you need, your published response period, and your contact point. Rule 14(3) sets an outer limit of ninety days for responding to grievances through your redressal system, and requires you to implement measures that actually make that period achievable.

Get one thing right if you build this yourself: verify identity before you act. A deletion endpoint that accepts an email address without proof of control is a data-destruction tool for anyone who knows your users’ addresses. Rule 14(5) contemplates exactly this by letting you specify the identifier you require.

When the Obligations Bite

The DPDP Rules 2025 were notified on 13 November 2025 with a staged commencement:

• 13 November 2025: Rules 1, 2 and 17–21 — definitions and the machinery for constituting the Data Protection Board.
• 13 November 2026: Rule 4 — Consent Manager registration.
• 13 May 2027: Rules 3, 5–16, 22 and 23 — the substance. Notice, security safeguards, breach reporting, retention, children’s data, Significant Data Fiduciary duties, Data Principal rights, and cross-border transfers.

As of September 2026, one caveat is worth tracking. In January 2026 MeitY consulted stakeholders on a proposal to compress the eighteen-month runway to twelve months and to bring the SDF cross-border provisions into force earlier. That is a proposal only — no amendment has been notified, and 13 May 2027 remains the operative date. But if your programme is planned to land in April 2027, it has no margin for a change that is actively under consideration. Confirm the current position before you finalise a timeline.

Where to Start

For a global company with an existing privacy programme, the sequence that wastes least effort is:

1. Scope it. Confirm Section 3(b) applies — for most companies with Indian users this takes minutes — and identify which of your products and data stores actually hold Indian users’ data.
2. Re-base your lawful bases. Work out which processing currently runs on legitimate interests and needs consent for Indian users. This is the long pole; start it first.
3. Publish the rights channel. The Rule 14 page and the Section 8(9) contact point are small builds with disproportionate visibility — they are the first thing anyone checking your compliance will look for.
4. Review your processors. Four questions per vendor, starting with the ones that touch Indian users most: email, SMS, analytics, support.
5. Fix the breach clock. Make sure your incident runbook produces a Board filing in 72 hours and user notification without delay, with no risk threshold gating it.

The DPDP guide for global companies sets this out as a readiness checklist you can work through with your team, with a printable version to circulate. If you want the obligation-by-obligation view first, our interactive DPDP compliance checklist covers the full duty set, and the free 2-minute checker tells you which obligations attach to your specific situation.

India is rarely the only regime a global product has to satisfy. To see where it sits against the others you already run — and where the consent defaults, breach clocks and transfer rules genuinely conflict — see our comparison of global data privacy laws, twelve regimes side by side.