Aadhaar eSign and the DPDP Act: Your Complete Compliance Guide

If your organisation uses Aadhaar eSign to execute contracts, onboard customers, or authenticate employees, India's Digital Personal Data Protection (DPDP) Act 2023 and the DPDP Rules 2025 have reshaped your legal obligations in concrete, enforceable ways. Aadhaar eSign DPDP Act compliance is no longer optional — every Application Service Provider (ASP) and Data Fiduciary routing an Aadhaar-based signing transaction now carries duties around consent, data minimisation, breach notification, and the rights of data principals.

This guide explains exactly what changed, what you must do, and how to audit your current eSign workflow against the new framework — section by section.

What Is Aadhaar eSign?

What is Aadhaar eSign? Aadhaar eSign is an electronically signed certificate service through which an Indian resident can sign a document digitally using their Aadhaar number and OTP (or biometric) for authentication, producing a legally valid electronic signature under the Information Technology Act 2000.

The legal backbone is Section 3A read with Schedule 2 of the IT Act 2000, which formally recognises Aadhaar-based e-signatures as a valid class of electronic signature on par with a physical signature in a court of law. The mechanism runs through UIDAI's eSign API, with a licensed Certifying Authority (CA) countersigning the document once the resident authenticates successfully.

The workflow involves three parties:

• Application Service Provider (ASP): the business or platform collecting the signature
• eSign Service Provider (ESP): the UIDAI-licensed intermediary that handles authentication
• Certifying Authority (CA): the entity that issues the cryptographic signing certificate

Each party carries independent compliance obligations under the DPDP Act — and the ASP, typically the platform your customers interact with, shoulders the heaviest load.

The DPDP Act 2023 and Aadhaar eSign Workflows

India's Digital Personal Data Protection Act was notified in August 2023. The DPDP Rules 2025 — published in November 2025 — operationalise it with binding technical and organisational requirements. For Aadhaar eSign workflows, three changes are material.

Aadhaar numbers require heightened protection

The Aadhaar Act 2016 classifies the Aadhaar number as biometric/demographic data requiring heightened protection. Under the converged DPDP framework, any ASP that collects or processes an Aadhaar number — even transiently, during an OTP flow — is processing personal data subject to DPDP obligations. Masking the first eight digits of the twelve-digit Aadhaar number before any processing or storage is a mandatory technical control.

The ASP becomes a Data Fiduciary

Under the DPDP Act, the entity that determines the purpose and means of processing is the Data Fiduciary. When your platform initiates an Aadhaar eSign request, you determine that an individual's Aadhaar credentials will be used to sign a specific document — making you the Data Fiduciary for that transaction. That designation brings the full set of obligations: lawful basis, consent notice, purpose limitation, security safeguards, and Data Principal rights.

Data Principal rights are now enforceable

A signer can now exercise their rights as a Data Principal: access information about what personal data you hold, correct inaccuracies, and request erasure. If a customer asks you to delete the record of their Aadhaar-authenticated signature transaction, you must have a documented mechanism to respond — and a retention policy that explains what you keep and why.

Consent and Notice Obligations for ASPs

Consent under the DPDP Act must be free, specific, informed, unconditional, and unambiguous. For Aadhaar eSign DPDP Act compliance, this translates into a three-layer requirement that the ASP owns.

The pre-signing notice

Before your platform initiates an eSign request, it must present a privacy notice that explains:

• What personal data will be collected (Aadhaar number, OTP, phone number used for OTP delivery)
• The specific purpose for which it is being processed (authenticating a signature on a named document)
• The Data Principal's rights (access, correction, erasure, grievance redressal)
• The process for submitting a complaint to the Data Protection Board

The notice must be in clear, plain language — not buried in a general terms-of-service page — and must be available in English or any of the 22 languages listed in the Eighth Schedule of the Constitution. Bundling eSign consent into a general "I agree to terms" checkbox is non-compliant.

Separate, granular consent

Consent for Aadhaar eSign must be obtained independently of any other consent. A user agreeing to your platform's marketing emails cannot simultaneously be deemed to have consented to Aadhaar authentication. The Act treats bundled or conditional consent as invalid.

The right to withdraw consent

Every consent must be as easy to withdraw as it is to give. If a user has initiated an eSign flow and abandons it mid-way, your platform must treat that as a withdrawal and not proceed with authentication. Your audit trail should capture that withdrawal explicitly.

A single non-compliant consent notice can invalidate every signature collected through that workflow — retroactively. Getting the consent architecture right before you scale is not optional.

Data Minimisation, Retention, and the Right to Erasure

The DPDP Act's data minimisation principle prohibits collecting personal data beyond what is strictly necessary for the stated purpose. For Aadhaar eSign, the UIDAI framework already imposes minimisation at the protocol level — the ASP never receives the Aadhaar number itself in plaintext after authentication, only a token. But the DPDP Act extends this to everything adjacent to the transaction.

What you must not retain

UIDAI guidelines prohibit the ASP from storing the Aadhaar number after the transaction completes. The ESP must not retain biometric data or OTP values beyond the immediate authentication window. Under DPDP, these prohibitions become statutory: retaining Aadhaar-linked data beyond transactional necessity violates the purpose limitation principle and exposes the ASP to penalties of up to ₹250 crore for failure to implement reasonable security safeguards.

Your retention policy must be documented

What you can retain — the signed document, the audit trail, the certificate metadata — must be governed by a documented retention policy with defined maximum periods. That policy must be disclosed in your consent notice. When the retention period expires, the data must be deleted automatically, not manually.

Organisations that have been accumulating signed-document archives without a retention schedule face a significant remediation exercise. If you have not done a data inventory against your eSign volume, now is the right time. SupaDoc's eSign platform includes a document retention dashboard where retention periods are set per-folder or per-document type, with automated flagging of documents approaching their expiry date — removing the manual step that creates compliance gaps.

Aadhaar eSign DPDP Act Compliance Checklist

Use this checklist to audit your current eSign workflow. Every row maps to a concrete obligation under the DPDP Act 2023 or the Aadhaar Act 2016.

Obligation	Requirement	Common gap	Maximum penalty
Consent notice	Plain-language notice covering purpose, data collected, rights, and grievance mechanism — shown before eSign initiation	Bundled into general T&C checkbox	₹10,000 per instance
Aadhaar masking	First 8 digits of Aadhaar number masked before any processing or display	Logs capturing full Aadhaar strings	₹250 crore (security failure)
Post-transaction deletion	ASP must not store Aadhaar number after signing transaction completes	Aadhaar cached in application session data	₹250 crore
Retention policy	Documented maximum retention period for signed documents and audit logs	No policy; archives grow unbounded	₹250 crore
Right to erasure	Mechanism for data principals to request deletion of their personal data	No erasure workflow; only manual support tickets	₹250 crore
Breach notification	Notify Data Protection Board and affected individuals of a personal data breach	No incident response plan covering eSign data	₹200 crore
Security safeguards	Technical and organisational measures commensurate with risk — including VAPT for eSign infrastructure	eSign infrastructure excluded from VAPT scope	₹250 crore
Multilingual notice	Consent notice available in the user's preferred Scheduled language	English-only notice on a multilingual platform	Invalid consent (signatures challengeable)

How SupaDoc Keeps Your eSign Workflow Compliant

Building DPDP compliance into an eSign workflow from scratch is a significant engineering effort — consent capture, multilingual notices, immutable audit trails, retention automation, erasure workflows, and VAPT-verified infrastructure. SupaDoc's eSign product was designed with this compliance layer built in, not bolted on.

• Consent-first signing flow: Every Aadhaar eSign request surfaces a structured consent notice before authentication begins. The notice is automatically linked to the document being signed, creating a verifiable consent record tied to the specific transaction.
• Immutable audit trail: Every step — consent given, OTP triggered, signature applied — is written to a tamper-evident audit log. If a signatory ever disputes the validity of their signature, you have a complete evidentiary record to produce.
• Retention policies: Set retention periods at the workspace, folder, or document level. SupaDoc flags documents approaching their expiry date and supports scheduled deletion workflows, making it straightforward to demonstrate compliance to an auditor.
• VAPT-certified infrastructure: SupaDoc undergoes regular Vulnerability Assessment and Penetration Testing (VAPT), ensuring the technical controls protecting your signing data meet the DPDP Act's "reasonable security safeguards" standard.
• Data Principal rights: The platform provides mechanisms for data principals to request access to their data or raise erasure requests, reducing the manual overhead on your compliance team.

Frequently Asked Questions

Does the DPDP Act apply to Aadhaar eSign workflows?

Yes. Any organisation that processes personal data — including Aadhaar authentication credentials used to initiate an eSign — is subject to the DPDP Act 2023 as a Data Fiduciary. The ASP that collects the signer's data and initiates the authentication request carries the primary compliance obligation, regardless of whether the actual Aadhaar authentication is handled by a licensed ESP.

Can an ASP store the signer's Aadhaar number after the transaction?

No. UIDAI guidelines prohibit ASPs from storing the Aadhaar number after a signing transaction completes, and the DPDP Act's purpose limitation and data minimisation principles reinforce this prohibition. ASPs may retain the signed document, the digital certificate, and the audit log — but not the Aadhaar number itself or any biometric data used in the authentication.

Is an Aadhaar eSign legally valid if DPDP consent was not obtained?

The signature itself may remain technically valid under the IT Act 2000, but the ASP's failure to obtain a compliant DPDP consent notice creates independent regulatory liability — including potential penalties from the Data Protection Board. In contested cases, defective consent can also be raised by the signatory as grounds to challenge the enforceability of the underlying document.

Does a signer have the right to request deletion of their signing data?

Yes. Under the DPDP Act, a Data Principal can request erasure of their personal data once the purpose for which it was collected is fulfilled. For a completed signing transaction, this means the ASP must delete Aadhaar-linked personal data that is no longer required, subject to any overriding legal retention obligation such as a court-ordered hold or a statutory minimum retention period for the document type.

What are the penalties for Aadhaar eSign DPDP non-compliance?

The DPDP Act's Schedule sets maximum penalties of ₹250 crore for failure to implement reasonable security safeguards, ₹200 crore for failure to notify the Data Protection Board or data principals of a breach, and up to ₹10,000 per individual instance of failure to provide an adequate consent notice. These are maximum caps — the Data Protection Board determines actual penalties based on severity, intent, and remediation steps taken.

Does Aadhaar eSign DPDP compliance apply to B2B contracts?

Yes. The DPDP Act protects individuals (natural persons) as Data Principals, regardless of the commercial context. When a B2B contract is signed by an individual employee or authorised signatory using their Aadhaar credentials, their personal data is being processed and DPDP obligations apply to the ASP — even if both contracting parties are companies.

Is an English-only consent notice sufficient?

Not necessarily. The DPDP Act requires consent notices to be available in English or any of the 22 languages listed in the Eighth Schedule of the Indian Constitution. For platforms with users across linguistic regions — particularly in states where the local language is predominant — an English-only notice may be challenged as failing the "informed consent" standard if the signer does not read English fluently.

How long must an eSign audit trail be retained?

The DPDP Act does not specify a fixed retention period — it requires data to be retained only as long as necessary for the stated purpose. However, other laws set minimums: the Companies Act 2013 requires certain executed agreements to be retained for eight years; labour law documents have varying periods. Your retention policy must map to the longest applicable statutory hold for each document type, and documents should be deleted automatically once that period expires.

Is VAPT mandatory for eSign platforms under the DPDP Act?

The DPDP Act does not mandate VAPT by name, but requires Data Fiduciaries to implement "reasonable security safeguards" commensurate with the sensitivity of the data processed. For platforms handling Aadhaar authentication credentials and signed legal documents, periodic VAPT is widely regarded as part of the reasonable security standard. Platforms that have not undergone VAPT should treat this as a priority gap in their DPDP compliance programme.

Could an eSign-heavy platform be designated a Significant Data Fiduciary?

Potentially. The DPDP Rules 2025 empower the central government to designate organisations as Significant Data Fiduciaries based on the volume and sensitivity of personal data processed. A platform that processes Aadhaar-linked signing transactions at scale could meet this threshold. Significant Data Fiduciary status brings additional obligations: appointing a Data Protection Officer based in India, conducting periodic independent data audits, and completing a Data Protection Impact Assessment for high-risk processing activities.

Staying ahead of DPDP compliance is significantly easier when your eSign infrastructure is already designed for it. SupaDoc eSign combines a compliant consent flow, tamper-evident audit trails, automated retention controls, and VAPT-verified infrastructure — so your legal team spends time on strategy, not chasing compliance gaps.