Ask most security teams which function handles the most sensitive personal data in the organisation, and they will point to the product team, or perhaps finance. The honest answer is usually HR. Between recruitment files, salary and bank details, medical and insurance claims, performance reviews, and disciplinary records, HR routinely holds the most complete, most personal, and most consequential dataset in the company -on every single employee, not just the customers who chose to sign up. The DPDP Act applies to every bit of it, and HR teams are often the least prepared function to answer for it.
This article is part of our industry-specific DPDP series. If you have not yet built the foundational programme -data inventory, notice and consent mechanisms, a grievance process -start with our 90-day roadmap before layering on HR-specific obligations. What follows assumes that foundation and focuses on where HR data handling diverges from a typical customer-data compliance programme.
The Data HR Holds
HR data does not look like a single dataset -it looks like several, each collected at a different stage and often stored in a different system entirely.
- Recruitment -resumes, cover letters, interview notes, assessment scores, and, where used, background verification reports covering education, employment history, and criminal record checks.
- Payroll and statutory -bank account details, PAN, Aadhaar or other identity documents, salary structure, tax declarations, and provident fund or insurance nomination details.
- Health and insurance -medical certificates, insurance claims, maternity or paternity leave records, and details of dependents covered under group health policies.
- Performance and conduct -appraisal ratings, performance improvement plans, disciplinary proceedings, and internal complaint records.
- Background checks -reference checks, prior employer verification, and, in some sectors, credit or litigation history checks.
Every category above is personal data under the DPDP Act's broad definition -see our explainer on what counts as personal data for the full test. None of it needs to be "sensitive" in the way other data protection laws define the term to be in scope; the DPDP Act does not carve out a separate, lighter-touch category for employee records. If your data inventory does not have a row for every one of these HR systems, it is incomplete.
Consent, Power Imbalance & Section 7
Consent under the DPDP Act has to be free, specific, informed, unconditional, and given through a clear affirmative action -see our piece on consent under the DPDP Act for the full mechanics. In an employment relationship, "free" is the word that breaks down fastest. An employee asked to consent to HR processing as a condition of employment has not really been given a choice; declining is rarely a realistic option. Relying on consent as the sole legal basis for routine HR processing therefore sits on shaky ground.
This is exactly the gap Section 7 is designed to close. Section 7 lists certain legitimate uses that let a Data Fiduciary process personal data without seeking consent, for specified purposes -among them, processing for the purpose of employment, or for safeguarding the employer from loss or liability, such as prevention or detection of fraud, or provision of any subsidy, benefit, or service that the employee has sought.
It only covers processing that is reasonably necessary for the stated purpose. Payroll processing to pay salaries sits squarely inside it; using the same salary data to build a marketing profile does not. Map each HR processing activity to its actual legitimate use -don't assume the whole HR function falls under one umbrella justification.
For processing that clearly falls outside employment purposes -sending personal-account marketing, sharing data with unrelated third parties, or optional benefit programmes an employee could reasonably decline -consent remains the appropriate basis, and it must meet the same free, specific, informed bar as any other DPDP consent.
Recruitment to Exit
HR data problems rarely start with a policy gap; they start with data that outlives its stage. Walking the employee lifecycle end to end surfaces most of the risk.
Recruitment and onboarding
Candidate resumes and assessment data are collected for a role that often goes to someone else -how long is the unsuccessful candidate's data kept, and why. Bank, tax, and identity documents collected at onboarding are frequently duplicated across payroll, HRMS, and benefits vendors, each with its own retention clock.
Active employment
Performance and disciplinary records accumulate across appraisal cycles, expense claims get linked to travel and location data, and health or insurance claims move through a third-party administrator who now also holds a copy of that data.
Exit
Final settlement calculations, exit interview notes, and reference data are retained to answer future verification requests from other employers. Ask what genuinely needs to persist after the last working day, and for how long -rather than defaulting to "keep it all."
Treat each stage as a separate retention and access decision rather than one continuous "employee file." A resume from a rejected candidate does not need the same retention as a payroll record for a current employee, and a manager should not retain performance review access to a report who left the team eighteen months ago.
Workplace Monitoring Limits
Monitoring is where HR data handling collides hardest with employee expectations. CCTV in office premises, email and endpoint monitoring, geolocation tracking for field or delivery staff, and access-badge logs are all personal data processing, and all subject to the same DPDP principles as anything else HR touches.
Three things keep monitoring defensible:
- Proportionality -the monitoring should match a genuine, stated purpose, such as security or fraud prevention, rather than blanket surveillance because it is technically possible.
- Notice -employees should know, in advance and in plain language, what is monitored, why, and who can see the results. A monitoring clause buried in a policy nobody reads does not meet this bar in spirit.
- Purpose limitation -data collected for security monitoring should not quietly become an input into performance reviews, and vice versa, without a fresh look at whether that reuse is justified.
Keystroke logging, screen recording, or location tracking with no defined scope or retention period is the practice most likely to draw scrutiny -both through the employee grievance process and in a compliance audit. If a monitoring practice would be hard to explain to the employees subject to it, that is usually a sign it needs redesigning before it needs defending.
Retention vs Deletion
The DPDP Act expects Data Fiduciaries to stop processing and erase personal data once the purpose it was collected for is served -see our detailed piece on erasure and deletion requests. For HR data, that principle runs into a wall of statutory retention obligations that most other functions do not face at the same scale.
Labour law, provident fund and social security legislation, and tax law each impose their own minimum retention periods for payroll registers, attendance records, statutory returns, and related employment documentation -obligations that in several cases extend years beyond an employee's last working day. Where a specific statutory retention requirement applies to a record, it overrides a blanket erasure request for that record: you cannot delete what the law requires you to keep.
The nuance that trips teams up is scope. A statutory retention obligation typically covers a narrow, defined set of records -not the entire HR file. A performance review, an old interview assessment, or a health insurance claim from three employers ago rarely carries the same statutory hook as a payroll register. Build your HR retention schedule record-by-record against the actual statutory basis, rather than defaulting to "keep everything, indefinitely, just in case."
Employee Rights & Grievances
It is easy for HR to think of itself only as the administrator of DPDP compliance for the workforce, and to forget that employees are also Data Principals in their own right -see our overview of data principals, fiduciaries and processors for how the roles map. As Data Principals, employees can ask what personal data you hold about them, request correction of inaccurate records, and raise concerns about how their data is used.
Practically, this means HR needs a defined internal grievance redressal process: a known channel for an employee to raise a data-handling concern, a reasonable response timeline, and an escalation path if the employee is unsatisfied -before the matter reaches the Data Protection Board of India. Routing these requests through whichever manager happens to receive the email is not a process; it is a gap waiting to surface during an audit or, worse, a dispute. Publish the channel, train HR business partners to recognise a data-rights request when they see one, and log every request and its resolution.
Compliance Checklist
Pulling the above into something HR can act on before the next systems or vendor review:
Before your next HR systems review
- Map every HR data category against a documented legal basis -a Section 7 legitimate use or consent -not an assumed one.
- Confirm your privacy notice actually covers HR processing, including monitoring, and is given to employees, not just customers.
- Set a record-level retention schedule that separates statutory-hold data from discretionary HR data.
- Define and publish an internal grievance channel for employee data-rights requests.
- Inventory every HRMS, payroll, background-check, and benefits vendor and confirm each has a signed DPA.
Each of the vendors behind your HR stack is a Data Processor handling employee personal data on your instructions -the same DPA discipline that applies to your customer-facing SaaS stack applies here, and needs a place in your vendor register.
| Category | Typical Vendors | Data Handled |
|---|---|---|
| HRMS platforms | Darwinbox, Keka, Workday | Full employee record |
| Payroll processors | ADP, GreytHR | Bank, tax, salary data |
| Background verification | AuthBridge, First Advantage | ID, education, employment history |
| Benefits and insurance | TPAs, insurance brokers | Health, dependent data |
| Expense and travel | Concur, Zoho Expense | Location, spend data |
HR is not exempt from any DPDP obligation the rest of the business is building toward; it just has to apply that same discipline to data most functions never touch -health records, disciplinary history, salary details, and the family information behind insurance claims. Get the legal basis, the lifecycle discipline, the monitoring boundaries, and the vendor contracts right, and HR becomes one of the better-governed functions in the company rather than the one everyone hopes never gets audited.
Need to bring your HR data handling into DPDP shape?
SecComply audits HR data flows across recruitment, payroll, and benefits, drafts the DPAs your HRMS and payroll vendors need, and builds the grievance process your employees can actually use.
Book an HR data review call →FAQ
Not for everything. The DPDP Act treats consent as compromised in an employment relationship because employees rarely have a genuine ability to refuse. Section 7 sets out certain legitimate uses that let a Data Fiduciary process personal data without consent for specified purposes, including for employment -such as safeguarding the employer from loss or liability, or providing a subsidy, benefit, or service that the employee has sought. This is not a blanket exemption: it only covers what is reasonably necessary for that stated purpose. For processing outside those legitimate uses, consent is still the safer basis.
Generally yes, but not without limits. Monitoring falls under the same DPDP principles as any other processing: it needs a lawful basis (often a Section 7 legitimate use tied to safeguarding the employer), it must be proportionate to that purpose, and employees must be given clear notice of what is monitored and why -typically through a monitoring policy referenced in the privacy notice. Covert, disproportionate, or open-ended monitoring is the kind of practice regulators and courts are likely to scrutinise first.
Longer than the DPDP Act alone would suggest. The Act expects Data Fiduciaries to stop retaining personal data once its purpose is served, unless retention is required by law. Several labour, tax, and provident fund statutes impose their own minimum retention periods for payroll and employment records that extend well beyond the last working day. Where a statutory retention obligation applies, it overrides an employee's erasure request for that specific record -but only for the data and duration the law actually requires, not indefinitely.
Yes. Once you hold their personal data, employees are Data Principals like any customer or user, and you are their Data Fiduciary. They can request access to and correction of their records, ask how their data is processed, and raise a grievance through your internal grievance redressal mechanism before escalating to the Data Protection Board of India. HR teams should have a defined, documented process for handling these requests.
Yes, almost always. Any HRMS, payroll processor, background-verification vendor, or benefits administrator that handles employee personal data on your instructions is a Data Processor under the DPDP Act, and you remain the Data Fiduciary responsible for that data. Each of these vendors needs a Data Processing Agreement covering the data categories they handle, security measures, breach notification back to you, sub-processor approval, and data return or deletion obligations when the contract ends.