SDKs, Pixels and Trackers: Who Is Responsible Under the DPDP Act?

Introduction

Consumer apps routinely carry code written by other companies. Software development kits (SDKs) for analytics, crash reporting, advertising, install attribution, payments and chat run inside the app and send data to their makers' servers. On the web, pixels and tags do the same. The user sees one brand.

The Digital Personal Data Protection Act, 2023 (the DPDP Act) asks who answers for that data. A data fiduciary decides why and how personal data is processed; a data processor processes it on a fiduciary's behalf; the data principal is the person it concerns. For an SDK the answer can be the app, the vendor or both. Trayambic's website checklist gives the short version and our ad-tech study covers web pixels; this article works through apps before the main duties commence on 13 May 2027.

The legal position

• Roles. A fiduciary is anyone who "alone or in conjunction with other persons determines the purpose and means" of processing (s.2(i)); a processor acts "on behalf of" a fiduciary (s.2(k)).
• Responsibility. The fiduciary answers for processing by or on its behalf "irrespective of any agreement to the contrary" (s.8(1)) and may use a processor only under a valid contract (s.8(2)), which Rule 6(1) of the DPDP Rules, 2025 requires to carry security provisions.
• Grounds and consent. Processing needs consent or a listed legitimate use (ss.4, 6, 7). Consent must be specific and limited to necessary data (s.6(1)), as easy to withdraw as to give (s.6(4)), and on withdrawal processors must stop (s.6(6)). The fiduciary must prove notice was given "by her" and consent given "to the Data Fiduciary" (s.6(10)).
• Transparency. A person may learn "the identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared" (s.11(1)(b)).
• Children. Verifiable parental consent for under-18s (s.9(1)), and no "tracking or behavioural monitoring of children or targeted advertising directed at children" (s.9(3)).
• Transfers. Data may go abroad unless the Centre restricts a country (s.16(1)); none is restricted. Stricter sector rules survive (s.16(2)).
• Penalties. The Board penalises "a person" whose breach is significant (s.33(1)), up to the Schedule maximum for the obligation breached.

The Act never uses "joint" or "jointly": no joint-fiduciary category, no rule for dividing duties, no joint and several liability.

Analysis

Processor or fiduciary: follow the purpose

The vendor's own use of the data, not the label in its contract, decides the role. In our view, consistent with Trayambic's checklist, a vendor that uses app data for its own ends is a fiduciary for that use. The signs are terms letting it improve its products for all clients, build cross-app profiles, train models or serve advertising elsewhere, and a privacy policy it addresses to your users.

Device identifiers are personal data

Advertising IDs, installation IDs, IP addresses and device fingerprints exist to recognise one device over time. On a personal phone that means one person, and the IDs are joined to events, purchases and accounts. In our view they make that person "identifiable ... in relation to" the data under s.2(t), name or no name. "Anonymous ID" in SDK documentation is a description, not a legal conclusion; Trayambic's article on anonymisation sets out the test. On iOS an app needs permission through App Tracking Transparency to track or read the advertising identifier; Android users can delete theirs, after which apps read zeros.

Joint responsibility without a joint-fiduciary concept

Because s.2(i) says "in conjunction with", two businesses deciding a purpose together are each a fiduciary, as Trayambic's HR tech and ad-tech studies concluded. The Act then stops. It does not say who gives notice, answers rights requests or reports a breach, and an agreement between the two cannot bind the Board (s.8(1)).

European case law offers a model. In Fashion ID (Case C-40/17, 29 July 2019), the Court of Justice held that a website embedding a social plug-in was a joint controller for collecting visitors' data and disclosing it by transmission, not for the platform's later processing (paras 76 and 84), and had to obtain consent for those operations (para 102). That is persuasive only, but it fits s.2(x), which lists "disclosure by transmission" as processing.

In our view responsibility divides by operation:

1. 1.The app is a fiduciary for choosing the SDK, the collection inside its app and the disclosure to the vendor. It needs the notice, the ground and the safeguards for those steps.
2. 2.A vendor using data for itself is a fiduciary for that later processing. It needs its own ground, handles its own rights requests and reports its own breaches.
3. 3.A processor vendor has few if any penalty-backed duties of its own, as Trayambic's article on processors explains; the app answers for it under s.8(1).

Consent is where chains break. Because s.6(10) makes each fiduciary prove consent was given to it, a vendor relying on your consent screen needs your notice to name it, or a precise category of recipient, with its purpose, and needs your app to pass the user's choice to its SDK.

Consent before the SDK starts

Many SDKs begin collecting as the app launches unless configured otherwise. A consent screen shown after that is too late: the data has left. The fix is sequencing.

1. 1.At first launch, start only what runs the service the user asked for. Fraud checks can rest on s.17(1)(c). For crash reporting limited to technical fields, s.7(a) is arguable in our view, as data generated in delivering the requested service, but consent is safer.
2. 2.Show the notice and consent request for analytics, attribution and advertising, and initialise those SDKs only on "yes".
3. 3.On withdrawal, stop each SDK, instruct processors to cease (s.6(6)), signal fiduciary vendors, and erase under s.8(7).

Vendors document this; Google's Firebase guidance, for example, shows how to keep Analytics collection off and re-enable it "such as after an end-user provides consent". No SDK should request device permissions beyond your purpose.

Children

Parental consent does not lift the s.9(3) bar. If any users may be under 18, build a child mode in which advertising, attribution and cross-app analytics SDKs never initialise. Google Play's Families Policies add platform rules: only self-certified ads SDKs for ads shown to children, and no transmission of the advertising ID and similar identifiers from children or users of unknown age.

Store labels are platform policy, not law

Google Play requires every app to complete a Data safety form covering data handled "through any third-party libraries or SDKs", and makes the developer "alone" responsible for its accuracy. Apple's App Privacy details, which its documentation calls Privacy Nutrition Labels, must cover "third-party partners whose code you integrate", and listed common SDKs need privacy manifests. Apple's FAQ is blunt: "Developers are responsible for all code included in their apps."

These are store terms, not law. A label is not a Rule 3 notice and proves no consent, but a label that contradicts your notice or your traffic is evidence of a gap.

Transfers and contracts

Most SDK vendors process data outside India. That is lawful while no country is restricted, and Trayambic's cross-border article explains why no transfer clauses are needed. Sector rules are stricter: digital lending data must be stored "only in servers located within India", and data processed abroad returned within 24 hours (RBI Digital Lending Directions, 2025, para 13(iv)).

Contracts should match the role. Processor terms: use only on instructions, no reuse for the vendor's products or models, Rule 6 security, prompt breach notice, ceasing on withdrawal, deletion, processing locations and a sub-processor list, which you need to answer s.11(1)(b). Fiduciary vendors: permitted and barred uses, who gives notice and handles rights, how consent signals pass, and mutual breach notice. Indemnities move cost, not responsibility.

Practical implications

Worked example: a lending app with 15 SDKs

All figures are illustrative. An NBFC's personal-loan app with 1.8 million users carries 15 SDKs. The two-week audit used build files, both store declarations and Apple's Xcode privacy report for the inventory; a test phone behind an intercepting proxy to record traffic before consent, after consent and after withdrawal; and a reading of each vendor's terms for own-use, location and training clauses.

• Crash, performance, push and chat (4). Processors. Contracts updated; the chat vendor's training default switched off.
• Device-risk (1). It requested contact-list and call-log access, which para 12(i) of the Digital Lending Directions bars. Permissions removed; fraud scoring kept under s.17(1)(c).
• Video KYC and document scanning (2). Processors for the NBFC's KYC, data kept in India.
• Account aggregator and payments (2). Regulated entities, fiduciaries for their own regulated duties such as consent records, KYC and fraud checks; named in the notice.
• Product analytics and session replay (2). Session replay captured loan amounts and PAN fields and was removed. Analytics moved behind consent and to an Indian region.
• Attribution and a social media app-events SDK (2). Fiduciaries for their own use, kept behind consent and named in the notice. The app-events SDK now receives installs only, not "loan approved".
• Two ad networks (2). Removed. They sent the advertising ID and location abroad, and para 12(iv) requires explicit consent before sharing with any third party.

Twelve SDKs remain, four of them named fiduciaries, and the notice, consent screen and store labels now match.

Key takeaways

An SDK is your collection and your disclosure, whatever its maker says. A vendor that uses the data for itself becomes a second answerable party; it does not replace you. Treat device identifiers as personal data, start nothing optional before consent, keep tracking away from children, and test traffic rather than trusting documentation or labels.

• The app is a fiduciary for collecting data through an SDK and disclosing it to the vendor; s.8(1) makes it answer for processor vendors whatever the contract says.
• A vendor that uses app data for its own purposes is, in our view, a fiduciary for that use, needing its own ground and consent it can prove (s.6(10)).
• The Act has no joint-fiduciary concept; divide duties by operation, as the CJEU did in Fashion ID, and allocate the rest by contract.
• Device and advertising identifiers are personal data; optional SDKs must not initialise before consent, and tracking SDKs must never start for children (s.9(3)).
• Google Play and Apple labels are platform policy, not law, but a mismatch with your notice or traffic is evidence of a compliance gap.