Lenskart's Privacy Policy vs the DPDP Act: Someone Read the Act. Someone Else Wrote the Consent Clause.

Lenskart has the best Data Principal rights section of any policy in this teardown series. It names the right to access, correction, erasure, grievance redressal, withdrawal of consent, and the right to nominate someone to exercise your rights if you die or become incapacitated. That last one is §14 of the DPDP Act, and almost nobody includes it.

It also lists your duties as a Data Principal, which is §15. It tells you that you can complain to the Data Protection Board of India. It has a section on children and persons with disability with a lawful guardian, which tracks Rule 10 and Rule 11 almost exactly. Someone at Lenskart clearly read the Act.

And then the second paragraph of the policy says this:

Visiting a website is not consent under §6. Consent must be free, specific, informed, unconditional, and unambiguous, given through a clear affirmative action, and taken separately for each purpose. This single sentence covers collection, use, processing, disclosure, and transfer, all at once, triggered by arriving at the page.

The facial scan question (§8, Rule 6)

Lenskart's "3D Try On" collects a photo, facial scan, or other image, and stores pupillary distance and face width measurements captured through the iPhone TrueDepth camera. The policy is explicit that this data is not shared with third parties, which is genuinely good and worth crediting.

It also gives a retention period with an actual number, which is rarer than it should be:

A number is better than a vibe. But five years is a long time to hold facial geometry for someone who bought a pair of glasses once. Under §8(3), collection and retention must be limited to what is necessary for the stated purpose. The stated purpose is measuring pupillary distance to fit frames. That purpose is served when the order ships. Rule 6 then requires safeguards proportionate to the harm exposure could cause, and facial biometrics sit at the top of that scale, because unlike a password, you cannot reset your face.

Gap 2: The NDNC clause overrides your own DND registration (§6)

This is the sharpest problem in the policy, and it sits right at the bottom where most people stop reading:

A user who registered on the national Do Not Disturb registry made an active, deliberate choice not to receive marketing calls. This clause treats buying a pair of glasses as overriding that choice for a full year.

Under §6, consent must be free, and it must be specific to a purpose. Marketing consent bundled into the act of registration is not specific, and consent that overrides a standing opt-out the user separately exercised is not free. This clause also sits in direct tension with the policy's own stated right to withdraw consent, published a few sections earlier in the same document.

Gap 3: Deemed consent for cross-border transfer and business transfers

Two more places where the policy converts an action into consent for a distinct purpose:

• •Cross-border: "Your personal data may be transferred, stored and processed outside India. By using our services, you consent to such storage and processing." Using a service is not consent to international transfer.
• •Business transfers: "You hereby specifically consent and grant permission to the disclosure, and transferring, of information to such third parties" in the event of an acquisition or merger. Describing pre-emptive blanket consent as "specific" does not make it specific.
• •Lead generation: the policy states Lenskart may share "your name, phone number, prescription details, and addresses" with third parties you are redirected to. Prescription data is health-adjacent, and sharing it is a separate purpose needing its own consent under §6.

Gap 4: Health data from connected platforms

If you connect HealthKit, Health Connect, or a similar platform, Lenskart collects step count and activity timestamps, used "to provide you services, discounts, and/or rewards". The policy correctly notes this needs explicit consent and can be revoked through device settings, which is the right architecture.

The open question is proportionality. Health and activity data being processed to determine commercial discounts is a meaningful purpose expansion for an eyewear retailer, and Rule 6 asks whether the safeguards match the sensitivity of what is being held.

What Lenskart genuinely gets right

• •A named Data Protection Officer with a working email, and the same address used for consent withdrawal and rights requests.
• •A full Data Principal rights list, including the right to nominate under §14, which almost no Indian consumer policy includes.
• •A Data Principal duties section, tracking §15.
• •Explicit reference to the Data Protection Board of India as an escalation path.
• •Verifiable parental and guardian consent for children and persons with disability, tracking Rule 10 and Rule 11.
• •A stated lawful basis section using DPDP vocabulary, including "legitimate uses" from §7.
• •A real retention number for facial data, and a commitment not to share it.

That is more DPDP-specific engagement than most of the brands we have torn down combined.

The pattern: new rights, old consent

Lenskart is the clearest example in this series of a policy where the rights layer was updated for the DPDP Act and the consent layer was not. The document tells you about nomination and the Board, then asks for permission the way policies did under the IT Act in 2011: by treating your presence as agreement.

This is a common and fixable failure mode. Rights language is a drafting exercise. Consent architecture is an engineering one, because itemised consent per purpose has to be captured in the product, logged with a timestamp, and made withdrawable. That is the harder half, and it is where most policies stop.

If your policy lists Data Principal rights but still opens with "by using this site you agree", you have the same gap. Our DPDP compliance checklist covers what itemised consent actually requires, and the free Compliance Score below checks your consent capture in 60 seconds.