DPDP Act for HR: Employee Data Privacy Guide (2026)

DPDP Act for HR: Employee Data Privacy Guide (2026)

Human resources runs on personal data. Every job application, salary slip, bank account number, PAN, Aadhaar copy, medical claim, biometric punch, and performance note is personal data about a real human being. For years, most Indian employers treated this information as an ordinary operational resource — collected freely, stored indefinitely, shared with vendors on a handshake, and rarely deleted. India's Digital Personal Data Protection Act (DPDP Act), 2023, together with the Digital Personal Data Protection Rules, 2025, changes that default. For HR and payroll teams, DPDP compliance is no longer a legal-department problem happening somewhere else. It lands squarely on the systems, spreadsheets, and habits that HR uses every single day.

This guide explains, in practical terms, what the DPDP Act means for employee data privacy, what an HR team should actually do about it, and how to build a defensible data-protection posture without grinding recruitment and payroll to a halt. It is written for HR managers, founders, and payroll teams in India and similar markets who need to move from awareness to action. Statutory timelines and rules continue to evolve, so treat this as a working framework and verify the current position of the notified rules and transition periods before you finalise policy.

Why the DPDP Act matters to HR right now

The DPDP Act is India's first comprehensive, standalone law governing the processing of digital personal data. It replaces the narrow, dated framework that previously sat inside the Information Technology Act and its 2011 SPDI Rules, which only covered a small category of "sensitive personal data." The new law is far broader in scope and much more consequential in its penalties.

Three features make it a genuine HR concern. First, the definition of personal data is expansive: essentially any information about an identifiable individual counts, not just financial or health data. That sweeps in names, employee IDs, contact details, addresses, family information, and most of what sits in a typical HRMS. Second, the law creates real obligations for the organisation that decides why and how personal data is processed — the Data Fiduciary — and real rights for the individual the data is about, the Data Principal. In the employment context, the employer is the Data Fiduciary and the employee or candidate is the Data Principal. Third, the penalties are significant enough to command boardroom attention, running into hundreds of crores of rupees for serious breaches, particularly failures to implement reasonable security safeguards.

The practical reality is that HR holds some of the most sensitive, most concentrated personal data in the entire organisation. A single HR folder can contain identity documents, salary history, bank details, health-insurance dependents, disciplinary records, and background-check reports. If a company is going to be judged on how it handles personal data, HR is where much of that judgement will be earned or lost.

The key concepts, translated for HR

Legal terminology can feel abstract until you map it onto what HR actually does. Here is the vocabulary that matters, translated into everyday HR language.

A Data Principal is the person the data is about. For HR, that is your candidates, employees, ex-employees, interns, contractors whose data you hold, and sometimes their nominated family members (for insurance or PF nominations).

A Data Fiduciary is the entity that determines the purpose and means of processing. Your company is the Data Fiduciary for its workforce data. This is the role that carries the legal obligations.

A Data Processor is a third party that processes personal data on the Fiduciary's behalf. Your payroll-outsourcing vendor, your background-verification agency, your HRMS provider, your group-insurance broker, and your cloud storage provider are all Data Processors. Crucially, the Fiduciary remains accountable for what its processors do, which is why vendor contracts become a compliance battleground.

Processing means almost anything you do with data: collecting, storing, using, sharing, structuring, or erasing it. Running payroll is processing. Screening a CV is processing. Emailing a salary slip is processing.

Consent is one lawful basis for processing, and it must be free, specific, informed, unambiguous, and given through a clear affirmative action. It can also be withdrawn. A pre-ticked checkbox buried in an offer letter is exactly the kind of thing the law is designed to discourage.

Legitimate uses (sometimes discussed as "certain legitimate uses") are situations where processing is permitted without fresh consent because the context makes it necessary. Employment is specifically recognised here, which matters enormously for HR, as we discuss below.

Consent versus legitimate use: the single most important distinction for HR

If you take one concept away from this guide, make it this one. Many HR teams panic and assume they must chase written consent for every field they hold. That is neither practical nor what the law strictly requires in the employment context.

The DPDP Act recognises that certain processing is a legitimate use connected to employment. This covers processing necessary for purposes such as maintaining the employment relationship, safeguarding the employer from loss or liability, preventing corporate espionage, protecting trade secrets and intellectual property, and providing services or benefits that the employee has sought. In plain terms, you generally do not need to beg for consent to run payroll, calculate statutory deductions, maintain attendance records, or administer the benefits an employee has enrolled in. These are core to the employment relationship.

Consent still matters in situations that fall outside the necessary scope of employment. Common examples include using employee photographs in external marketing, sharing testimonials, enrolling employees in optional wellness apps run by third parties, processing data for purposes the employee did not reasonably expect, or continuing to use data after the relationship ends for something new.

The safest operating model is a hybrid one. Rely on the legitimate-use basis for the genuinely necessary machinery of employment, document clearly why each processing activity is necessary, and layer explicit consent on top for anything optional, secondary, or externally facing. Do not use consent as a fig leaf for processing you would do anyway — a consent that the employee cannot realistically refuse without losing their job is not a free consent, and building your entire programme on it is fragile.

The notice obligation: telling people what you do with their data

Whatever your lawful basis, transparency is non-negotiable. The DPDP framework expects Data Fiduciaries to give clear notice about what personal data is collected and the purposes for which it will be processed, and to make the mechanics of exercising rights and withdrawing consent accessible.

For HR, this translates into an employee privacy notice — a plain-language document, separate from the general customer privacy policy, that tells your workforce exactly what you do with their data. A good HR privacy notice covers the categories of data you collect, the purposes for each category, who you share it with, how long you keep it, how employees can exercise their rights, and who to contact with a grievance. It should be written for humans, not lawyers, and it should be given at the point of collection — ideally as part of onboarding, with a version also available to candidates during recruitment.

The notice is not a one-time formality. When you introduce a new tool that processes employee data — a new monitoring system, a new engagement-survey platform, an AI screening tool — you update the notice and communicate the change. Silent scope creep is precisely the behaviour the law targets.

Data Principal rights and the HR request desk

The DPDP Act gives individuals a set of rights over their data, and employees are among the most likely people to exercise them, particularly around exits and disputes. HR needs a defined process to receive and answer these requests, because ignoring them is not an option.

Employees have the right to access a summary of the personal data being processed and the processing activities. They have the right to correction and updating of inaccurate or incomplete data — think of an employee who changed their bank account or legal name. They have the right to erasure in defined circumstances, subject to the many legal retention obligations that apply to employment records. They have the right to grievance redressal, meaning a readily available way to complain and get a response. And they have the right to nominate another individual to exercise their rights in the event of death or incapacity, which intersects neatly with the nomination processes HR already runs for PF and gratuity.

Practically, you should build a lightweight data-subject request workflow: a single intake channel (an email alias or a form in your HRMS), a register that logs each request and its resolution, a service standard for responding within a reasonable and consistent timeframe, and an identity-verification step so you do not hand one employee's data to someone impersonating them. Assign a named owner. When an access request arrives, you must be able to say what you hold and why — which is only possible if you have done the mapping work described next.

Building an HR data inventory: you cannot protect what you have not mapped

Every serious DPDP programme starts with a data map. You cannot honour access requests, apply retention rules, or answer a regulator if you do not know what personal data you hold, where it lives, and who can touch it. For most HR teams, this is the single most valuable exercise they will do, because it usually surfaces uncomfortable surprises — the shared drive full of scanned Aadhaar cards, the WhatsApp group where salary details get discussed, the ex-employee records nobody ever deleted.

Work through the employee lifecycle and, for each stage, record what data is collected, why, where it is stored, who has access, which vendors receive it, and how long it is retained. A simple inventory table is enough to begin.

The mapping exercise almost always reveals two problems: data held in far more places than anyone realised, and data kept far longer than any purpose justifies. Fixing both is the substance of compliance.

Data minimisation and purpose limitation in everyday HR

Two principles quietly do most of the heavy lifting in a privacy programme: collect only what you need, and use it only for the purpose you collected it for.

Data minimisation asks a simple question of every field on every form: do we actually need this? A shocking number of onboarding forms collect religion, caste, marital status, spouse income, or full family details with no processing purpose behind them. If you cannot state a clear, lawful reason for a field, remove it. The less you hold, the smaller your breach surface and the lighter your compliance burden.

Purpose limitation means you do not quietly repurpose data. Attendance data collected to run payroll should not silently become the basis for a productivity-surveillance dashboard shared with managers. Health data collected for insurance should not feed into performance decisions. If you want to use data for a genuinely new purpose, go back and get a fresh basis — usually consent — and update your notice.

These principles are not just legal hygiene; they are good HR practice. They reduce the risk of discrimination claims, they build employee trust, and they make your systems simpler to run.

Vendors and data processors: your compliance is only as strong as your weakest contract

HR outsources heavily. Payroll bureaus, background-verification firms, insurance brokers, HRMS vendors, engagement-survey tools, and cloud storage providers all process your employees' data. Under the DPDP framework, the employer as Data Fiduciary stays accountable even when a processor mishandles data. That makes vendor governance a core HR responsibility, not an afterthought.

Every processor relationship should sit on a written contract that addresses data protection specifically. The contract should require the vendor to process data only on your documented instructions and only for the agreed purpose, to implement reasonable security safeguards, to assist you in responding to data-principal requests and breaches, to restrict onward sub-processing without your approval, to return or delete data at the end of the engagement, and to allow reasonable audit or assurance. Before onboarding a new vendor, do basic due diligence: where do they host data, who can access it, what certifications do they hold, and what is their breach history and notification commitment.

Pay special attention to cross-border transfers. The DPDP framework permits transfers to most countries by default but allows the government to restrict specified destinations. If your HRMS or payroll data sits on servers abroad, or your global parent accesses Indian employee data, keep a clear record of where data flows and be ready to adjust if the list of restricted countries changes. Global Capability Centres and multinationals with shared HR platforms should map these flows carefully, because employment data routinely crosses borders inside a group.

Security safeguards: the obligation most likely to bite

Of all the DPDP obligations, the requirement to implement reasonable security safeguards is the one most closely tied to the largest penalties, because it is the failure that produces breaches. HR data is a prime target precisely because it is rich and concentrated. Ransomware crews and fraudsters love HR systems.

Reasonable safeguards for HR data are not exotic. They include role-based access control so that only people who genuinely need a record can see it; encryption of sensitive data at rest and in transit; strong authentication, ideally multi-factor, on HR and payroll systems; secure disposal of physical and digital records rather than leaving scanned IDs on open shared drives; logging and monitoring so you can detect unusual access; and regular access reviews so that leavers and role-changers lose access promptly. The most common real-world failures are mundane: HR spreadsheets emailed as attachments, salary data shared over consumer messaging apps, generic shared logins to the payroll system, and no process to revoke access when someone leaves the team. Closing those gaps delivers more risk reduction than any amount of policy documentation.

Breach response: plan before you need it

If a breach occurs, the DPDP framework expects notification to the Data Protection Board and, in appropriate cases, to affected individuals. HR should not be improvising when this happens. Build a simple incident-response plan that covers detection and escalation, containment, assessment of what data and how many people are affected, notification decisions and timing, and remediation. Run a tabletop exercise once so the team has walked through it before a real event. A breach involving payroll bank details or identity documents is a high-severity event; treat it as one in your planning.

The special case of sensitive data: Aadhaar, health, and biometrics

While the DPDP Act does not carve out a separate "sensitive data" category the way some laws do, certain data types carry outsized risk and additional legal context, and HR handles all of them.

Aadhaar is governed by its own statute and rules on top of the DPDP framework. Collect it only where legally required, prefer masked versions, avoid storing full Aadhaar numbers where a verification token would do, and never treat an Aadhaar photocopy as a casual identity document to be filed in an open folder.

Health and disability data appears in insurance enrolment, medical claims, sick-leave certificates, and accommodation requests. It deserves the tightest access controls, strict purpose limitation, and clear separation from performance processes.

Biometric data from fingerprint or face-recognition attendance systems is both personal and hard to change if leaked. If you use biometric attendance, be transparent about it, secure the templates, prefer on-device matching where possible, and offer a non-biometric alternative where feasible. The convenience of a biometric punch does not override the obligation to handle the data responsibly.

AI in hiring and monitoring under DPDP

AI has entered HR through resume-screening tools, chatbots, sentiment analysis, and productivity monitoring. The DPDP framework does not ban these, but it makes the employer fully responsible for how any AI system handles personal data. That responsibility is not something you can outsource to a vendor's model.

If you deploy AI that processes employee or candidate data, insist on a lawful basis and transparency, keep a human in the loop for consequential decisions such as rejection or termination, watch for bias that could translate into discrimination, and be able to explain in plain terms what the tool does with data. Monitoring tools deserve particular care: covert or excessive surveillance corrodes trust and sits uncomfortably against purpose limitation and proportionality. Tell people what you monitor and why, and monitor no more than the legitimate purpose requires.

Retention and deletion: keeping data only as long as you should

Indian employment law requires you to keep many records for defined periods — tax records, statutory registers, PF and ESI documentation, and so on. DPDP does not override those obligations; you keep what the law requires you to keep. But DPDP does push against the opposite failure, which is keeping everything forever "just in case."

Build a retention schedule that pairs each category of HR data with its retention driver and disposal timeline. Recruitment data for rejected candidates should be deleted or anonymised after a short, defined window unless the candidate agrees to be kept in a talent pool. Employee records are retained through employment and for the statutory period afterwards, then securely disposed of. Health and claims data follows the insurer's and auditor's requirements and no longer. Once you have a schedule, automate the deletion where your systems allow, and log disposals so you can show the schedule is real and not just aspirational.

A practical DPDP roadmap for HR teams

Turning all of this into action is less daunting than it looks if you sequence it sensibly. The following roadmap works for most SMBs and mid-market employers.

Begin by appointing a clear owner for HR data protection and securing leadership backing, because the exercise touches budgets, vendor contracts, and system settings. Next, run the data-mapping exercise across the employee lifecycle so you know what you hold and where. With the map in hand, write or refresh the employee privacy notice and give it to candidates and new joiners. In parallel, decide your lawful basis for each processing activity, leaning on legitimate use for the core machinery of employment and consent for the optional extras, and record those decisions.

From there, move to the operational controls. Stand up a data-principal request workflow with a single intake channel and a register. Review vendor contracts and add data-protection terms where they are missing, starting with your payroll, verification, insurance, and HRMS providers. Tighten security safeguards with the unglamorous basics: access reviews, MFA, encryption, and an end to salary spreadsheets flying around over email and chat. Draft a retention schedule and start deleting what you no longer need a reason to keep. Finally, write a short breach-response plan and run one tabletop exercise. Refresh training so hiring managers and HR staff understand the new expectations, and revisit the whole programme annually.

None of these steps requires a large team or an enormous budget. They require a decision to take employee data seriously, a bit of structure, and follow-through.

Where DPDP meets existing labour-law recordkeeping

HR teams sometimes worry that DPDP conflicts with the mountain of records that Indian labour and tax law obliges them to keep. In practice the two coexist neatly once you understand the relationship. Statutory recordkeeping is a purpose, and where the law requires you to maintain a register, a wage record, a PF challan trail, or a TDS record, that requirement supplies both the reason to hold the data and the reason to retain it for the mandated period. DPDP does not ask you to delete records you are legally obliged to keep; it asks you to be deliberate about everything else.

The friction, when it appears, is almost always about the surplus — the copies, the convenience exports, the ad-hoc spreadsheets that duplicate what the system of record already holds. A statutory wage register is a legitimate, retained record. Seventeen versions of a payroll working file sitting in various inboxes and shared drives are not; they are risk with no offsetting purpose. The discipline DPDP encourages is to keep the authoritative record in a controlled system, apply the statutory retention period to it, and stop the uncontrolled proliferation of shadow copies. Done well, this makes your labour-law compliance stronger, because a single well-governed record is easier to produce in an inspection than a scatter of half-matching spreadsheets.

The same logic applies to statutory sharing. When you file PF and ESI returns, deposit TDS, or respond to a lawful authority, you are processing and sharing personal data for a legally mandated purpose, which is squarely legitimate. What DPDP adds is the expectation that these flows are documented in your data map, secured in transit, and limited to what the filing actually requires — not that they stop.

A one-page HR data-protection checklist

When the framework feels overwhelming, come back to a short operational checklist that captures the essentials. Have you appointed a named owner for HR data protection with leadership backing? Have you mapped what personal data you hold across the employee lifecycle, and where it lives? Do candidates and new joiners receive a plain-language privacy notice at the point of collection? Have you decided and recorded a lawful basis for each processing activity, leaning on legitimate use for the core of employment and consent for the optional extras?

On the operational side: is there a single intake channel and register for data-principal requests, with an identity-verification step? Do your payroll, verification, insurance, and HRMS contracts contain data-protection terms? Have you enforced the security basics — role-based access, multi-factor authentication, encryption, prompt access revocation for leavers, and an end to salary data travelling over email and consumer chat? Does a retention schedule pair each data category with its retention driver and a disposal timeline, and is deletion actually happening? Is there a written breach-response plan that the team has rehearsed at least once? And have hiring managers and HR staff been trained on the new expectations?

If you can answer yes to most of these, you have a defensible, practical posture — one that protects employees, satisfies the spirit and substance of the law, and does not strangle recruitment or payroll in red tape.

Common mistakes to avoid

A handful of predictable errors trip up HR teams new to data protection. The first is treating consent as a universal solvent and demanding it for processing that employees cannot realistically refuse — a legitimate-use basis is both more honest and more robust for the core of employment. The second is collecting data reflexively on forms without a purpose, which quietly inflates risk for no benefit. The third is ignoring vendors, forgetting that a payroll bureau's breach becomes the employer's problem. The fourth is hoarding data forever with no retention discipline. The fifth is confusing policy with practice: a beautifully written privacy notice means nothing if HR staff still email unencrypted salary sheets. And the sixth is treating DPDP as a one-time project rather than an ongoing operating standard that must be maintained as tools, teams, and rules change.

Frequently asked questions

Does the DPDP Act require written consent from every employee for payroll? Generally no. Running payroll, calculating statutory deductions, and administering the benefits an employee has enrolled in are typically covered by the legitimate uses connected to employment, so you do not need separate consent for the core machinery of the employment relationship. You still owe employees clear notice about what you do with their data, and you should rely on explicit consent for optional or externally facing uses such as marketing photographs or third-party wellness apps.

Who is responsible if our payroll vendor suffers a data breach? As the Data Fiduciary, the employer remains accountable for personal data even when a processor handles it. That is why written contracts with data-protection terms, due diligence before onboarding a vendor, and a clear breach-notification commitment from the vendor are so important. You can and should require your processors to assist you, but you cannot fully transfer your accountability to them.

Can we still use biometric attendance systems? Yes, but handle biometric data with extra care because it is sensitive and effectively permanent if leaked. Be transparent that you use it and why, secure the biometric templates, prefer on-device matching where the technology allows, and consider offering a non-biometric alternative. The convenience of a fingerprint punch does not reduce your obligation to protect the underlying data.

How long should we keep employee records? Keep records for as long as the law requires — tax, PF, ESI, and statutory registers all carry their own retention periods — and no longer than you have a genuine purpose for the rest. Build a retention schedule that pairs each data category with its retention driver, delete or anonymise recruitment data for rejected candidates after a short defined window, and securely dispose of records once their retention period ends.

Do we need to appoint a Data Protection Officer? Formal DPO requirements apply most directly to entities classified as Significant Data Fiduciaries, a category based on volume and sensitivity of data and other factors. Even if your organisation is not in that category, appointing a clear internal owner for HR data protection is strongly advisable, because someone needs to own the privacy notice, the request workflow, vendor governance, and breach response.

What about data of employees who have left the company? Ex-employee data does not disappear from your obligations. You retain what statutory rules require for the mandated period, apply the same security safeguards, honour access and correction requests where applicable, and delete the rest once retention periods lapse. Continuing to use ex-employee data for a new purpose generally needs a fresh basis.

Does the DPDP Act apply to candidates who were never hired? Yes. Candidate data is personal data, and rejected applicants are Data Principals with rights. This is why recruitment data deserves a short retention window and why building candidates into your privacy notice and request workflow matters, not just current employees.

Are small companies exempt from the DPDP Act? The law applies broadly to the processing of digital personal data, and small size does not grant a blanket exemption from core obligations, though some procedural expectations scale with the nature and volume of processing. Every employer holds concentrated, sensitive HR data, so the practical answer for SMBs is to implement the fundamentals — notice, lawful basis, security, retention, and a request process — regardless of headcount.

Conclusion

The DPDP Act reframes employee data from a free operational resource into something the employer holds in trust and must protect. For HR, that means a shift in defaults: collect less, be transparent about what you do, rely on the legitimate uses of employment for the core machinery while using consent honestly for the extras, tighten the unglamorous security basics, govern your vendors, and delete what you no longer need. None of it requires a heroic budget. It requires ownership, a data map, and steady follow-through — and it delivers a real payoff in employee trust and reduced risk.

Getting there is far easier when your employee data lives in one well-controlled system rather than scattered across spreadsheets, inboxes, and shared drives. A modern HRMS with role-based access, audit logs, secure document storage, and clean retention controls turns many of these obligations into configuration rather than heroics. If you would like to see how a single, secure system of record can make employee data privacy manageable for your team, take CozyHR for a spin and build your DPDP readiness on solid foundations.

This article is general guidance for HR and payroll teams and is not legal advice. Data-protection rules and their implementation timelines continue to evolve; verify the current notified position and consult a qualified professional before finalising your compliance approach.