DPDP Act and browser fingerprinting

What the DPDP Act says about fingerprinting

The Digital Personal Data Protection Act, 2023 (the DPDP Act) does not use the word 'fingerprinting'. What it does is define 'personal data' in Section 2(t) as 'any data about an individual who is identifiable by or in relation to such data'. A browser fingerprint (a hash or vector derived from a device's screen parameters, fonts, audio stack, GPU renderer, time zone, and similar characteristics) falls within that definition the moment it can be used to recognise the same user across sessions. The fingerprint need not carry a name, an Aadhaar number, or any directly identifying token; identifiability under Section 2(t) is sufficient.

The Act also defines 'Data Fiduciary' in Section 2(i) as any person who, alone or in conjunction with others, determines the purpose and means of processing. If you deploy a fingerprinting SDK on your platform, you are the Data Fiduciary for the fingerprint data you collect, and you bear the obligations that attach to that role. Section 2(k) defines 'Data Principal' as the individual to whom the personal data relates: the end user whose device is being fingerprinted.

Processing is defined in Section 2(x) as wholly or partly automated operations performed on digital personal data, including collection, use, analysis, and disclosure. Running a fingerprinting SDK that reads device signals and produces an identifier is unambiguously processing within that definition.

Grounds for processing: Sections 4, 6, and 7

Section 4 of the DPDP Act establishes the foundational rule: a Data Fiduciary may process digital personal data only for a lawful purpose, with consent of the Data Principal or for certain 'legitimate uses'. There is no free-form balancing test equivalent to GDPR's Article 6(1)(f); instead the Act carves out a defined list of situations that substitute for consent.

Section 6 governs consent in detail. It must be 'free, specific, informed, unconditional and unambiguous', signalled by a clear affirmative action. The provision maps to the GDPR standard in substance, though the drafting is tighter: 'unconditional' is a word the GDPR definition does not use, and it signals that bundled or coerced consent (for instance, making access to an app contingent on accepting non-essential fingerprinting) is non-compliant on the face of the statute.

Section 7 then lists the 'legitimate uses' that permit processing without separate consent. For a fingerprinting deployment, the relevant categories include processing by a Data Fiduciary for preventing or detecting unlawful activity (Section 7(g)), purposes specified by the State for public interest functions (Section 7(b)), and processing necessary for employment-related purposes where requiring consent would impede the purpose (Section 7(f)). Section 7 uses are not consent-free in all respects: Section 5 notice is still required, and the Data Principal retains erasure rights under Section 13.

Section 5: the notice requirement

Section 5 of the DPDP Act requires that, before or at the time of collecting personal data, the Data Fiduciary give the Data Principal a notice describing the personal data to be processed and the purpose of processing, with information about how the Data Principal may exercise rights under the Act. The notice must be itemised: a blanket reference to a privacy policy is not compliant if the fingerprinting purpose is not specifically surfaced.

The implementing Rules are expected to specify the exact format and delivery mechanism for the Section 5 notice. Until those Rules are notified, the Act's language remains the operative standard. A privacy notice that identifies 'device fingerprinting for fraud prevention' as a named processing activity, explains what signals are read, and links to the Data Principal's rights under Sections 11 and 13 is the safe approach.

The Section 6(7) consent manager framework

Section 6(7) of the DPDP Act introduces 'consent managers': entities registered with the Data Protection Board that can mediate consent on behalf of Data Principals across multiple Data Fiduciaries. A Data Principal can give, review, update, or withdraw consent through a consent manager, and a Data Fiduciary can rely on that consent record as satisfying Section 6.

This framework is significant for fingerprinting infrastructure. A consent manager that captures device-fingerprinting consent as a named purpose category would allow Benny-enabled platforms to draw on a portable consent signal rather than collecting one de novo on every site. The practical mechanics (registration, interoperability, API standards) will be specified in the implementing Rules. Until the Board is constituted and the Rules are notified, consent managers cannot formally operate under the Act.

Section 9: children's data and the profiling prohibition

Section 9 of the DPDP Act applies elevated restrictions to the personal data of children (defined as individuals under eighteen years of age). Before processing a child's data, the Data Fiduciary must obtain verifiable parental consent. Unlike GDPR, which permits member states to lower the age threshold to sixteen, the DPDP Act's default of eighteen is uniform across India.

More strikingly for fingerprinting deployments, Section 9(3) prohibits any Data Fiduciary from undertaking the tracking or behavioural monitoring of children, or targeted advertising directed at children. The prohibition is unconditional: consent from the parent does not unlock it. A fingerprinting SDK deployed on a platform that serves under-eighteens, and that uses the resulting device identifier for any tracking or behavioural purpose, is non-compliant with Section 9 regardless of the consent architecture in place.

The implementing Rules are expected to detail the mechanics of age verification and parental-consent collection. Until the Rules are notified, the Act's text is the operative standard, and the Data Fiduciary bears the responsibility for designing a compliant verification flow.

Section 10: Significant Data Fiduciary designation

Section 10 empowers the Central Government to designate certain Data Fiduciaries as 'Significant Data Fiduciaries' based on the volume and sensitivity of data processed, national security risk, public order, sovereignty, or the risk to the rights of Data Principals. A Significant Data Fiduciary faces additional obligations: appointment of a Data Protection Officer (based in India), retention of an independent data auditor, and periodic Data Protection Impact Assessments.

The criteria and threshold for designation will be specified in the implementing Rules. For fingerprinting platforms, the relevant concern is scale and sensitivity: a platform that collects device fingerprints from tens of millions of Indian users, or that operates in a sector touching public-order or sovereignty concerns, is a plausible candidate for Significant Data Fiduciary designation. The designation is made by Central Government notification; there is no self-reporting mechanism.

Section 11 and Section 13: Data Principal rights

Section 11 gives every Data Principal the right to obtain a summary of the personal data being processed by a Data Fiduciary, and the identity of all Data Fiduciaries and processors with whom data has been shared. For a fingerprinting deployment, this means your privacy notice and Data Subject Access Request (DSAR) workflow must be capable of surfacing the device identifier, the signals used to generate it, and any third parties to whom it has been disclosed.

Section 13 grants the right to correct inaccurate or misleading personal data, complete incomplete data, update outdated data, and request erasure. For a fingerprinting SDK the erasure obligation is operationally significant: when a Data Principal requests deletion, the device identifier and any associated signals must be removed from your systems within the period the Rules will specify. Until the Rules are notified, the prudent approach is to treat the erasure right as effective immediately on request.

Section 16: cross-border data transfers

Section 16 of the DPDP Act takes a structurally different approach to cross-border transfers than GDPR Chapter V. Under GDPR's positive-list model, transfers to third countries are restricted by default and require an adequacy decision, standard contractual clauses, or another approved mechanism. Under the DPDP Act's negative-list model, transfers to all countries are permitted unless the Central Government has issued a specific notification restricting a destination.

As of mid-2026, no country has been notified as a restricted destination. This means that, on the face of the current statute, a Data Fiduciary can transfer fingerprint data to processors in the EU, the United States, Singapore, or elsewhere without any transfer mechanism beyond their ordinary DPA obligations. This position may change once the Central Government exercises its power under Section 16: the negative list is an evolving instrument, not a permanent open door.

The practical consequence for Benny's architecture is that Indian-origin fingerprint data processed in Chennai by default does not raise a Section 16 cross-border issue. Customers with global infrastructure who route fingerprint calls through non-Indian endpoints should monitor the Central Government's Section 16 notifications as the Act moves toward full commencement.

Section 33: penalties

Section 33 of the DPDP Act sets out a tiered penalty schedule imposed by the Data Protection Board following an inquiry. The penalties are denominated in INR crore (one crore equals ten million rupees) and apply per breach category, not per data record.

Failure to take reasonable security safeguards under Section 8(5) carries a penalty of up to INR 250 crore. Failure to notify a personal data breach under Section 8(6) carries up to INR 200 crore. Breaches of the Section 9 children's-data obligations carry up to INR 200 crore. Breaches of duties by a Data Processor carry up to INR 50 crore. Non-compliance with other provisions of the Act or the Rules carries up to INR 50 crore. There is no global-turnover multiplier: penalties are capped in absolute terms rather than as a percentage of revenue, which makes the regime less punishing for large multinationals than GDPR but more severe for mid-sized Indian platforms.

How Benny the Doorman fits into a DPDP-aware deployment

Benny processes all identifications on Indian infrastructure in Chennai by default. No fingerprint data leaves the country in the standard configuration, which means Section 16 cross-border restrictions are not triggered for the default deployment. This is the home-market architecture, and it reflects a deliberate design choice to make the compliance story as clean as possible for Indian Data Fiduciaries.

For consent-based purposes (personalisation, analytics, A/B testing), the integration follows the same pattern as any consent-requiring deployment: the fingerprint call is gated behind your consent management layer, deferred until the Data Principal has given a clear affirmative signal for device-fingerprinting as a named purpose. Your Section 5 notice must surface fingerprinting explicitly.

For Section 7 legitimate-use purposes (anti-fraud, security-of-service, bot mitigation), the fingerprint call can fire without a prior consent prompt, but the Section 5 notice must still disclose the activity, the purpose, and the Data Principal's rights. The Section 7 basis collapses the moment the fingerprint data feeds a consent-required use such as behavioural advertising: purpose isolation is a precondition of the Section 7 carve-out.

Benny's Data Processing Agreement is available in a DPDP-shaped form that addresses the processor-fiduciary relationship under Section 8, the breach-notification timeline, and erasure obligations. GDPR and ePrivacy addenda are available as overlays for customers who also serve EU Data Subjects.