Your company is outside India. Your users are not.

Yes, if you offer goods or services to people in India. Section 3(b) extends the Act to processing of digital personal data outside India where that processing is connected to offering goods or services to Data Principals in India. Where you are incorporated, where your servers run, and which currency you bill in do not affect the test. There is no user-count or revenue threshold — a signup form collecting a name and email from someone in India is enough.

Yes, on exactly the same terms as a website — the Act is technology-neutral, and Rule 14(1) speaks of publishing on "its website or app, or both, as the case may be." If your app has a login, a social sign-in button, or an email field in onboarding, you are collecting digital personal data from Indian users and Section 3(b) attaches. Two points app teams miss: the store is a distribution channel, not a shield, so Apple’s and Google’s own privacy terms do not discharge your obligations; and the SDKs in your build — analytics, crash reporting, attribution, push, ad mediation — are Data Processors that typically ship personal data off-device, so each belongs in your vendor review.

Yes. Section 3(b) turns on whether the processing is connected to offering goods or services to people in India — not on whether anyone pays you. A free tier, a free trial, a freemium account and an ad-supported product are all services being offered, so the personal data of their Indian users is in scope. The practical test is not revenue but data: if someone in India can create an account and you end up holding their name, email or phone number, the Act applies to that processing. Monetising later does not change when the obligations started.

No. The DPDP Act has no equivalent of GDPR Article 27, which requires non-EU controllers to designate an EU representative. Nothing in the Act or the DPDP Rules 2025 requires a foreign company to establish an Indian entity, appoint a local representative, or register with an authority. The only India-presence requirement is the India-based Data Protection Officer under Section 10(2)(a)(ii), which binds only entities notified as Significant Data Fiduciaries — none have been notified so far.

Not under the DPDP Act itself. Section 16 works as a negative list: transfers abroad are permitted unless the Central Government notifies a restricted country, and no country has been notified. The only localisation hook is Rule 13(4), which reaches Significant Data Fiduciaries only, for data categories the government may specify — none specified so far. Genuine localisation mandates come from sector regulators, such as RBI’s payment-data directive, and Section 16(2) expressly leaves those intact.

Most of your machinery transfers. The gaps are concentrated in five places: consent replaces legitimate interests as the primary lawful basis; notices must be available in any of the 22 Eighth Schedule languages at the user’s option; breach reporting has no risk threshold and adds a 72-hour Board filing; anyone under 18 is a child and behavioural tracking or targeted advertising at them is prohibited outright; and you must prominently publish a rights-request channel with the identifier you require.

No. Section 9(3) prohibits behavioural tracking, behavioural monitoring and targeted advertising directed at children outright, and it contains no consent proviso — unlike Section 9(1), which is expressly a consent obligation. Rule 12 confirms the reading by exempting Sections 9(1) and 9(3) as separate carve-outs: if parental consent could cure a 9(3) breach, there would be no need to exempt 9(3) independently. So for an ad-monetised app the exposure sits in the ad and analytics stack rather than the consent screen. Behavioural ad SDKs, engagement profiling and retargeting aimed at under-18s are barred however good your parental-consent flow. Non-personalised contextual advertising is widely argued to sit outside 9(3), but the text does not say so and there is no Board guidance yet.

Not as such. Neither the Act nor the Rules impose a freestanding age-verification or age-assurance obligation — the phrase appears nowhere, and Rule 10’s verification machinery is aimed at confirming the self-identified parent is an adult, not at checking the child’s age. What the Act requires is verifiable parental consent before processing a child’s data. The relief is narrower than it sounds, though: Section 9 has no knowledge qualifier, no COPPA-style actual-knowledge standard, and no safe harbour for self-declared age, so an unchecked "I am over 18" box is not a defence. Age assurance is therefore risk mitigation rather than a statutory requirement — most teams with a mixed-age audience conclude they need some age signal to meet a duty that has no knowledge defence.

Neither. The Act does not require processors to be Indian, and there is no certification scheme. What it requires is that you engage them only under a valid contract (Section 8(2)) — and it prescribes no mandatory clause list, unlike GDPR Article 28(3). The practical constraint is that Section 8(1) keeps you responsible for what they do on your behalf, so your obligations are only as achievable as your weakest vendor: if it cannot delete on request or report a breach quickly, you cannot meet yours.

The substantive obligations — notice, security, breach reporting, retention, children’s data, Data Principal rights and cross-border transfers — commence on 13 May 2027 under Rule 1(4) of the DPDP Rules 2025. Consent Manager registration starts 13 November 2026. One caveat as of September 2026: MeitY consulted in January 2026 on compressing the eighteen-month runway to twelve months. No amendment has been notified and 13 May 2027 remains operative, but a programme planned to land in April 2027 has no margin if that changes.