Aadhaar & PAN under DPDP Act 2023: what HR teams must change in 2026

It's the second Wednesday of the month. The payroll team is preparing salary advice for 240 employees. Someone needs the Aadhaar number for an employee whose UAN is failing validation. The HR coordinator opens a Google Sheet titled Master Employee Data 2026, scrolls down, and reads the full 12-digit number out loud over a Slack call.

If this is a familiar scene at your company, you have a DPDP Act problem. It was already a problem under the Aadhaar Act, 2016 and the IT Rules, 2011. But the Digital Personal Data Protection Act, 2023 has made it a much more expensive one — with penalties of up to ₹250 crore for serious violations under Section 33.

The DPDP Act was passed by Parliament in August 2023 and notified for phased implementation through 2026. The draft Digital Personal Data Protection Rules, 2025 fill in operational detail — consent notices, breach reporting timelines, the constitution of the Data Protection Board. Most Indian HR teams have read the headlines. Far fewer have changed how they actually handle two pieces of data they touch every day: Aadhaar and PAN.

This piece is about six specific things to change. Not a survey of the Act, not a "DPDP overview" — those exist everywhere. The premise here is that you already know DPDP applies to you. The question is what your HR and payroll teams need to do differently this quarter.

Why Aadhaar and PAN, specifically

Most personal data your HR team handles is risky in some way. Bank accounts can enable fraud. Health insurance details can reveal sensitive medical history. Photos can be used to impersonate. But Aadhaar and PAN are uniquely problematic for three reasons.

First, they're universal identifiers. Aadhaar uniquely identifies a person across every Indian system — banking, telecom, gas, ration, tax. A leaked Aadhaar number is leaked everywhere. PAN is similar within the financial system.

Second, they're governed by overlapping laws. Aadhaar is regulated by the Aadhaar (Targeted Delivery of Financial and Other Subsidies, Benefits and Services) Act, 2016 in addition to DPDP. PAN sits under the Income Tax Act, 1961 alongside DPDP. Compliance with one doesn't automatically mean compliance with the others.

Third, and most importantly: most HR teams store them in places they would never store a password. Yet a leaked Aadhaar number combined with a leaked phone number is functionally a credential — it can be used to clone SIM cards, open bank accounts, and apply for credit. The Reserve Bank of India and the UIDAI have both repeatedly warned about this.

So when the DPDP Act introduced specific obligations around storage, access, retention, and breach notification, the standard the law expects for Aadhaar and PAN is high. Higher than what most Indian HR teams currently meet.

1. Stop storing Aadhaar in spreadsheets

This is the most common, most fixable problem. Walk through almost any Indian HR team and you'll find at least one of these:

• A Google Sheet titled Master Employee Data with full Aadhaar in column F
• An Excel file on someone's laptop with new joiner Aadhaar copies
• A WhatsApp group where Aadhaar photos are shared during onboarding
• An email thread with "Pls find attached" Aadhaar PDFs

All four are violations under DPDP Section 8(5), which requires "reasonable security safeguards." Spreadsheets and email do not constitute reasonable safeguards because they have no access control beyond file-level permissions, no audit logging of who viewed what when, and no encryption at rest that's specific to the sensitive field.

Under the Aadhaar Act, this is even more explicit. Section 8 read with UIDAI's regulations requires Aadhaar numbers to be stored in encrypted form, accessible only on a need-to-know basis, and only by personnel authorised in writing.

The fix is straightforward in principle: store Aadhaar in a system that encrypts it at the field level, controls access by role, and logs every read. In practice that means moving it from spreadsheets to a proper HRMS, or building an in-house tokenisation layer if you have the engineering capacity. Both are real work.

2. Mask Aadhaar everywhere except where the full number is genuinely required

The "default masked" rule is the single highest-leverage change a HR team can make. Most places where Aadhaar appears in your systems — employee profile screens, payslips, MIS reports, exit documents — do not actually need the full 12 digits. The last 4 are enough to confirm identity.

Specifically, mask Aadhaar in:

• Employee profile screens in your HRMS and ESS portal. Show XXXX XXXX 4567. Reveal the full number only via an audit-logged action with a stated reason.
• Payslips and Form 16. UIDAI explicitly recommends masking in these documents. Compliant Form 16 templates from TRACES already do this.
• Internal HR reports. Exports, dashboards, headcount sheets — none need the full Aadhaar.
• Vendor handoffs. When sending data to BGV agencies, insurance providers, or payroll vendors, ask whether they actually need the full Aadhaar. Often they don't.

The places where the full number genuinely is required — PF UAN linking, ESI enrolment, bank account verification under PMRPY, KYC for company-provided insurance — are narrower than most HR teams assume. For each of those, the access should be logged with the reason, the accessor, and a timestamp under DPDP Section 11(1)(c).

3. Treat PAN with the same care

PAN gets less attention than Aadhaar in compliance conversations because there's no separate PAN Act. But the Income Tax Act, 1961 — Section 139A and Rule 114B — restricts who can collect PAN and for what purposes, and DPDP applies to PAN as personal data identical to any other.

The practical consequence: the same masking, encryption, and access-logging rules apply. A common mistake is to encrypt Aadhaar but leave PAN in plain text on the basis that "PAN is a tax thing, everyone has it." This is not a defensible position under DPDP.

PAN is also the most-emailed sensitive identifier in Indian HR. Vendors ask for it via email, finance teams send it to chartered accountants in attachments, IT helpdesks copy it into ticket descriptions for "verification." Each of these is a separate violation. The rule to communicate internally is simple: PAN does not travel by email.

4. Map your retention windows — and resolve the conflicts

DPDP Section 8(7) requires that personal data be erased when "the purpose for which such personal data was processed is no longer being served." On its face, that sounds like a clean rule. In practice it conflicts with multiple statutory retention obligations:

• Income Tax Act, 1961: payroll records must be retained for at least 8 years (typically the relevant assessment year plus 7).
• Employees' Provident Funds and Miscellaneous Provisions Act, 1952: PF records must be retained for at least 10 years.
• Payment of Wages Act, 1936: wage and overtime registers must be retained for 3 years.
• Factories Act, 1948: muster rolls, leave registers, and accident records for periods ranging from 3 to 5 years.
• Companies Act, 2013: certain employment records form part of "books of account" with 8-year retention.

Most of these statutes are older than DPDP and continue to apply. The way to handle this is to document the retention period for each data category, the statutory basis for it, and what happens at the end. The DPDP Act allows continued retention where required by law — but you have to be able to show that's the reason, not "we just kept everything."

5. Build a real Data Principal rights workflow

Under DPDP Sections 11, 12, and 13, employees (as "Data Principals") have specific rights they can exercise:

• Right to access: ask what personal data you hold about them and where (Sec 11).
• Right to correction and erasure: ask to fix wrong data or delete what's no longer needed (Sec 12).
• Right to grievance redressal: a complaint mechanism if rights are not honoured (Sec 13).
• Right to nominate: appoint a person to exercise these rights on their behalf — typically used in case of death or incapacitation (Sec 14).

These rights are not theoretical. They are exercisable today. Under the draft DPDP Rules, 2025, an employer has to respond within a defined timeline (currently proposed as up to 90 days, depending on the rights involved, though the operational expectation is faster).

The workflow you need:

• A published process: an email address or portal page where requests can be submitted.
• An owner — usually the Grievance Officer, mandatory under DPDP Section 8(10).
• A defined SLA — currently 90 days under the draft rules, but most companies should aim for 30.
• An audit trail — every request, every response, who handled it.

For HR specifically, the most common request will be from departing employees asking for a copy of their data or for parts of it to be deleted. Plan for this. It will happen in your first year of operations after DPDP enforcement.

6. Appoint your Grievance Officer and publish the contact

Section 8(10) of the DPDP Act requires every Data Fiduciary — which includes every employer that processes employee data digitally — to publish "the business contact information of a Data Protection Officer or a person who is able to answer on behalf of the Data Fiduciary the questions, if any, raised by the Data Principal about the processing of her personal data."

For "Significant Data Fiduciaries" under Section 10 — companies that process larger volumes of data, or sensitive data — a formal Data Protection Officer is required. The threshold for "significant" status will be set by the Data Protection Board (still being constituted as of 2026), but most mid-size and larger Indian employers should expect to be in scope eventually.

Even if you're not yet a Significant Data Fiduciary, the Grievance Officer requirement applies. The fix is simple:

• Name a person, in writing. Usually a senior HR or Legal person.
• Publish their email address on your website's Privacy Policy page.
• Provide an alternative — an internal HR ticket queue or address — for current employees.
• Document a response SLA internally and train the team to meet it.

This is one of the cheapest items on the list, and one of the most-skipped. If a regulator looks at your Privacy Policy in 2026 and finds no Grievance Officer named, that is a visible, easy violation to flag.

What this means for the next 12 months

If you do nothing else after reading this, do these three things. They are the highest-leverage compliance improvements an Indian HR team can make in 2026, in roughly two days of effort each.

One: stop putting Aadhaar and PAN in spreadsheets. Pick a system — your HRMS, a password manager configured for shared secrets, even a properly-permissioned cloud storage with encryption — and move them there in the next 30 days. Delete the spreadsheets.

Two: mask the full Aadhaar everywhere it appears in your internal systems. Show last 4 digits by default; require an audit-logged action to reveal. Most modern HRMS platforms (including hrPLANR) do this natively. If yours doesn't, this is a conversation to have with your vendor this quarter.

Three: name your Grievance Officer and publish the contact. This is genuinely a half-day task and it closes the most-visible gap in your DPDP posture.

Everything else on the longer compliance list — data flow mapping, vendor agreement updates, breach response plans, retention matrices — is real work that will take months. Start with what you can ship this week.

How hrPLANR handles this

hrPLANR was built with DPDP compliance as a first-class design constraint. Aadhaar is masked by default throughout the platform. Access to the full number is role-controlled and audit-logged automatically. Encryption is AES-256 at rest, TLS 1.3 in transit. The platform handles many of the 45 items in the checklist natively.

None of this is exotic. Any HRMS launched in 2024 or later should be doing the same things. The question to ask any HR tech vendor — whether it's us or anyone else — is: show me where my employees' Aadhaar lives, who can see it, and what gets logged. The good vendors have a clean answer. The bad ones change the subject.

---

This article references the Digital Personal Data Protection Act, 2023 and the draft Digital Personal Data Protection Rules, 2025 as in force in May 2026. Statutory text and interpretation may change as the Data Protection Board is constituted and enforcement begins. This article is not legal advice — for your specific situation, consult qualified counsel.

Last updated: 26 May 2026. We re-review this article quarterly.