The Digital Personal Data Protection Act, 2023 changes the arithmetic on holding full Aadhaar numbers. Not because it mentions Aadhaar — it barely does — but because of what it says about collecting more than you need.
Most compliance conversations about Aadhaar in India still run on the Aadhaar Act and sectoral regulator circulars. The DPDP Act sits on top of both, and it applies a general principle that cuts across all of it: you may collect personal data for a specified lawful purpose, and only what is necessary for that purpose.
For a KYC team, that principle has a very concrete consequence. If the last four digits do what you need, the other eight are data you collected without needing it.
The four obligations that bite
1. Purpose limitation and data minimisation
You must specify the purpose for which personal data is collected, and collect only what that purpose requires. This is where full Aadhaar numbers become difficult to defend.
Ask what the full number is doing in your system. If you are a registered KYC User Agency performing authentication, it has a clear job. If you are not — and most organisations collecting Aadhaar are not — you cannot verify the number against UIDAI at all. It sits in your document store, matching nothing, serving a purpose the masked version serves identically.
That is the case you would have to make to a Data Protection Board: that eight digits you cannot use were necessary for a purpose you can name. It is not a comfortable position.
2. Security safeguards
Section 8(5) requires reasonable security safeguards to prevent personal data breaches. The Act does not enumerate them, which means the standard is what a reasonable organisation in your position would do.
Masking is unusually easy to argue here, because it is not a control that might have worked. A masked document cannot leak a full Aadhaar number, in the same way an encrypted disk cannot leak plaintext. It removes the data rather than guarding it.
3. Breach notification
A personal data breach must be notified to the Data Protection Board and to affected Data Principals. There is no materiality threshold in the Act — the obligation is not limited to large or serious breaches.
This is where masking pays for itself in a way that is easy to quantify. A bucket of masked KYC documents that becomes publicly readable is a bad day. The same bucket holding full Aadhaar numbers is a notification to every affected individual, a report to the Board, and a set of questions about why you held numbers you could not use.
4. Penalties
Schedule 1 sets financial penalties, with failure to take reasonable security safeguards attracting up to ₹250 crore. That figure is a ceiling rather than a tariff, and the Board weighs the nature and gravity of the breach and any mitigating action.
The mitigation argument is worth thinking about in advance. "We minimised what we held, and the exposed documents were masked" is a materially different conversation from "we held complete identity numbers for every customer since 2019."
None of this requires a legal opinion about Aadhaar specifically. The DPDP argument for masking is the general one: you collected more than you needed, and the excess is what leaked.
Where the DPDP Act and the Aadhaar Act stack
They are not alternatives. An organisation holding Aadhaar data sits under both, plus whatever its regulator requires.
| Aadhaar Act, 2016 | DPDP Act, 2023 | |
|---|---|---|
| Scope | Aadhaar numbers and identity information | All digital personal data |
| Core duty | Restricted disclosure; authentication confined to registered agencies | Purpose limitation, minimisation, security, notification |
| Consequence | Criminal provisions under Chapter VII | Financial penalties under Schedule 1 |
| Effect of masking | Removes the restricted identifier | Evidences minimisation and a security safeguard |
A bank also has RBI KYC directions; an insurer has IRDAI's; an NBFC has both RBI and its own sectoral guidance. Masking does not conflict with any of them, because none of them require you to retain a full Aadhaar number after whatever verification step called for it.
Retention: the part most teams get wrong
Section 8(7) requires erasure once the purpose is served and retention is no longer required by law. In practice this is where the gap between policy and system tends to be widest.
The specific failure looks like this. A team implements masking, correctly, at the point of collection. The masked copy goes into the document store. And the original — unmasked — stays exactly where it was: in the upload bucket, in the email attachment, in the processing directory, in a database blob column nobody has looked at since the migration.
Masking that leaves the original alongside it has not reduced exposure at all. It has added a file. The audit question is not "do you mask?" but "where is the unmasked copy?", and it is worth being able to answer that with a path rather than an assumption.
- Delete the original once the masked copy is durably stored, in the same operation.
- Where a regulator genuinely requires the original, hold it somewhere with stricter access than the masked copy — not the same bucket with the same permissions.
- Check the places a document passes through, not just where it lands: upload staging, message queues, temp directories, backup snapshots, and log aggregation.
That last one deserves emphasis. A debug log that records request bodies puts unmasked Aadhaar numbers into a system that typically has broader access and longer retention than the document store you were protecting. It is a common and almost invisible failure.
A practical sequence
If you are starting from a system that holds full numbers today:
- Find out what you actually hold. Not what the policy says — where the documents are. Most organisations find more locations than expected.
- Mask at the point of collection, so new documents arrive already redacted and the question stops growing.
- Work through the archive as a bulk exercise, with the documents that come back unreadable listed rather than assumed clean. See bulk Aadhaar masking for how to size and resume that.
- Close the retention loop: delete originals, and check the staging and log paths as well as the store.
- Write down why you hold whatever you still hold. If the answer names a regulation, you are fine. If it is "we always have", that is the item to fix.
None of this is difficult work. It is mostly a matter of doing it deliberately, once, rather than discovering the gaps during an incident.
This is a description of the compliance landscape, not legal advice. Obligations under the DPDP Act, the Aadhaar Act and sectoral regulations depend on your specific circumstances, and rules are still being operationalised through subordinate legislation. Take advice on your own position.
Questions
Does the DPDP Act require Aadhaar masking?
It does not name Aadhaar masking specifically. What it requires is that personal data be collected for a specified purpose and limited to what is necessary for it, together with reasonable security safeguards. For an organisation that is not a registered UIDAI authentication agency — and so cannot verify a number at all — holding the full twelve digits is difficult to justify against that standard when the last four serve the same record-matching purpose.
What are the penalties under the DPDP Act for a data breach?
Schedule 1 sets financial penalties, with failure to take reasonable security safeguards attracting up to ₹250 crore. That is a ceiling rather than a tariff; the Data Protection Board weighs the nature and gravity of the breach and any mitigating action taken. Being able to show that exposed documents were masked and that collection was minimised is a materially different position from having held complete identity numbers.
Do I have to report every data breach under the DPDP Act?
The Act requires notification of a personal data breach to the Data Protection Board and to affected Data Principals, without a materiality threshold limiting it to large or serious incidents. This is one of the strongest practical arguments for masking: a leak of masked KYC documents is a bad day, whereas the same leak carrying full Aadhaar numbers becomes a notification to every affected individual.
Can I keep the original unmasked document after masking?
Only where a law or your regulator requires it, and then it belongs somewhere with stricter access than the masked copy rather than in the same bucket under the same permissions. Section 8(7) requires erasure once the purpose is served. Masking that leaves the original beside it has not reduced exposure — it has added a file, and the audit question is where the unmasked copy is, not whether you mask.
Does masking conflict with RBI or IRDAI KYC rules?
No. Sectoral KYC directions require verification steps; none of them require retaining a full Aadhaar number afterwards. Banks, NBFCs and insurers sit under the DPDP Act and the Aadhaar Act as well as their own regulator's directions, and masking is compatible with all three.
Masking Aadhaar at volume?
One REST call takes a document and returns it redacted, for KYC and document pipelines. Free browser tools for everything smaller — those never upload the document at all.
Request API access