Short answer: Under the DPDP Act the app, as Data Fiduciary, stays responsible for everything its vendors and SDKs do with personal data on its behalf, whatever the contract says (s.8(1)). From 13 May 2027 it may engage a Data Processor only under a valid contract (s.8(2)), must include security safeguards in it (Rule 6(1)(f)), and must make processors stop processing and erase data when the law requires.
What is a Data Processor under the DPDP Act?
A Data Processor is any person who processes personal data on behalf of a Data Fiduciary (s.2(k)). For a mobile app, that typically includes cloud hosting, analytics, attribution, crash reporting, messaging and customer support tools that handle user data on the app's instructions.
- Data Fiduciary: the person who, alone or in conjunction with others, determines the purpose and means of processing (s.2(i)).
- Valid contract: the Act allows a processor to be engaged only under one (s.8(2)), and Rule 6(1)(f) requires it to include provision for reasonable security safeguards.
Does the Act place duties directly on processors?
Largely no. Chapter II of the Act is addressed to Data Fiduciaries, and the Act imposes no direct statutory duties on Data Processors comparable to those on fiduciaries. DLA Piper's India summary reports the same reading. Duties reach processors through the app: its contract, its instructions and its responsibility under s.8(1).
What must an app make its processors do?
The app must use a valid contract with security provisions, and must cause its processors to stop processing on withdrawal of consent, erase data when erasure is due and retain processing logs for at least one year (s.8(2), Rule 6(1)(f), s.6(6), s.8(7), Rule 8(3)).
| Duty flowing to processors | Source |
|---|---|
| Engage only under a valid contract | s.8(2) |
| Contractual provision for reasonable security safeguards | Rule 6(1)(f) |
| Cease processing within a reasonable time after consent is withdrawn | s.6(6) |
| Erase personal data made available to the processor when erasure is due | s.8(7) |
| Retain processing logs for at least one year, as in the Rule 8(3) cloud processor illustration | Rule 8(3) |
| App stays responsible regardless of contract terms | s.8(1) |
| App can name each processor that received a user's data | s.11 |
Is an SDK vendor a processor or a fiduciary?
It depends on what the vendor does with the data. The Act does not address SDKs or the allocation of responsibility between joint fiduciaries expressly.
- Interpretation: an SDK vendor that processes only on the app's instructions fits the Data Processor definition (s.2(k)) and needs a s.8(2) contract.
- Interpretation: a vendor that also uses the data for its own purposes, such as building cross-app profiles or improving its own models, determines purpose and means and is likely a Data Fiduciary in its own right, or jointly with the app, since s.2(i) covers anyone who determines purpose and means alone or in conjunction with others.
- Law firm AMLEGALS reports that a s.8(2) contract is needed for every processor in the ad stack, but does not classify SDK vendors. Joint or independent fiduciary status of attribution, analytics and ad-network SDKs is an open question.
Which SDK categories handle personal data?
Most apps embed several categories of SDK, each of which may process device and event data on the app's behalf:
- Analytics and product analytics: in-app events, session data, device details.
- Attribution and measurement: attribution SDKs such as Linkrunner, AppsFlyer, Adjust or Branch process device and event data, such as install and in-app events, on the app's behalf. As one example of configuration options, Linkrunner offers PII hashing by default and a Bring Your Own Cloud option that keeps raw events, identifiers and PII inside the app's own cloud boundary. Whether any setup meets the Act depends on the app's own consent, contracts and controls.
- Advertising and monetisation: ad networks and mediation SDKs.
- Messaging and engagement: push, email, SMS and in-app messaging tools.
- Infrastructure: cloud hosting, crash reporting and customer support platforms.
Masking and obfuscation are security measures under Rule 6(1)(a), not a route out of the Act. Interpretation: law firm commentary reports the same for hashing where an identifier stays linkable. See personal data in attribution.
What this means for your app
These are practical steps teams commonly consider. They are not a guarantee of compliance.
- Consider an SDK and vendor register: who each vendor is, what data it receives, for which purpose, and whether it acts only on your instructions.
- A common approach is a data processing agreement with each processor covering instructions, security (Rule 6(1)(f)), deletion, cessation on withdrawal, log retention and breach notice.
- Review vendor terms for any right to use your users' data for the vendor's own purposes, which may point to fiduciary status.
- Plan how withdrawal and erasure signals reach each vendor, by API, configuration or manual process (s.6(6), s.8(7)).
- Make sure the register can answer an access request naming every recipient (s.11). See data principal rights.
- Link vendor breach notice terms to your breach notification runbook.