Employee Data Privacy Under DPDP: An HR Guide

Employee data privacy is now a board-level topic in Indian companies, and HR is holding the file cabinet. India's Digital Personal Data Protection framework treats the salary slip, the Aadhaar copy in the onboarding folder, and the medical claim form in the insurer's portal as regulated personal data with real obligations attached. Most HR teams have never mapped what they hold, who can see it, how long it stays, or which vendor is quietly storing a copy. This guide walks through what DPDP compliance for HR actually looks like in practice, from data mapping to breach response, with templates you can adapt this quarter.

A quick note: This article is general guidance written for HR and payroll practitioners, not legal advice. Rules, notified provisions, timelines, and thresholds change, and the specifics of your situation matter. Verify every requirement against the current official text of the law and its rules, and take advice from your own legal counsel before finalising policies, notices, or contracts.

Why Employee Data Is the Riskiest Data Set You Own

Think about what customer data usually contains for a mid-sized Indian business: name, phone number, email, maybe a delivery address and an order history. Now think about what HR holds for a single employee.

Full legal name, date of birth, permanent and current address, a government identity number or two, a bank account number, a photograph, family members' names and ages, marital status, exact monthly compensation, tax declarations that reveal rent paid and loans taken, health insurance claims that reveal medical conditions, a background verification report that comments on past employment and possibly criminal record checks, performance ratings, and in some cases a grievance file describing an incident in painful detail.

That is a far richer, far more sensitive profile than almost anything else the company processes. It is also permanent in a way transactional data is not. A customer's order history ages into irrelevance; an employee's identity documents and salary history stay sensitive for decades.

Why HR is usually the least prepared function

Security and IT teams have spent years hardening customer-facing systems. HR sits outside that perimeter for a few structural reasons.

• HR runs on documents, not databases. Offer letters, scanned PAN cards, investment proofs, and F&F statements live as files, and files get emailed, downloaded, and copied.
• HR's tooling is fragmented. An ATS here, a payroll bureau there, a biometric device from a local vendor, an insurer portal, and a shared drive holding everything that does not fit elsewhere.
• Spreadsheets are the universal solvent. The single most common HR data incident in India is not a hack. It is a CTC master exported to Excel and mailed to the wrong person.
• HR teams are small and busy. A two-person HR function running payroll for 300 people does not have spare capacity for a data governance programme unless someone makes it a priority.
• Nobody has told HR that it owns this. Data protection is often assumed to be IT's problem. It is not. IT owns the controls; HR owns the data and the decisions about it.

The result is a predictable gap. Employee data protection in India is now a legal obligation with consequences, and the function that holds the most sensitive data set is frequently the one with the least formal governance around it.

What actually goes wrong

The realistic failure modes are mundane and that is exactly why they keep happening.

• A payroll executive emails the full salary register to an external consultant instead of the internal finance lead, because both are saved as "Ramesh" in the address book.
• A recruiter leaves and their personal cloud drive still contains 4,000 candidate CVs downloaded over three years.
• A manager is granted "reports access" in the HRMS and discovers they can see the compensation of peers in other departments.
• A biometric attendance vendor's cloud console uses a shared password that four site supervisors know.
• A laptop with a locally saved Form 16 archive is stolen from a car in a parking lot.

None of these require a sophisticated attacker. All of them are HR data breaches.

What Personal Data HR Actually Processes

Before you can protect anything, you need an honest inventory. Most HR teams underestimate their footprint by half because they only count what sits in the HRMS. Here is the realistic lifecycle view.

Recruitment

• CVs and application forms, including data candidates volunteer that you never asked for (photographs, date of birth, marital status, caste or community in some formats, salary history)
• Interview notes and scorecards, which can contain subjective and sometimes legally sensitive observations
• Background verification packs: education verification, employment verification, address checks, criminal record checks, and sometimes credit checks
• Reference contact details, which are third-party personal data you collected without that person applying to anything
• Assessment and psychometric results
• Rejected candidate records, which often sit forever in the ATS and in recruiter inboxes

Onboarding

• Identity and tax identifiers, bank account and IFSC details, UAN and PF nomination information, ESIC details where applicable
• Family and dependant details for insurance, gratuity nomination, and emergency contact
• Educational certificates, relieving letters, and previous salary slips
• Signed offer letter, appointment letter, NDAs, and policy acknowledgements
• Address proof documents, frequently scanned and stored as images

Payroll and finance

• Compensation structure, revisions, bonuses, incentives, ESOP allocations
• Tax declarations and investment proofs, which reveal rent, landlord PAN, home loan details, insurance premiums, and donations
• Loan and advance records, salary attachment or garnishment orders
• Reimbursement claims, which reveal travel patterns and sometimes medical spend
• Bank transfer files and statutory return filings

Attendance and workforce management

• Biometric templates or images from fingerprint and face-recognition devices
• Geolocation and geo-fencing data from mobile attendance apps, especially for field teams
• Access card swipe logs, which are a de facto movement record inside the premises
• Shift rosters, overtime records, and leave data, where leave reasons can disclose health or family circumstances

Benefits and wellbeing

• Group health insurance enrolment for the employee and dependants, including dates of birth and relationships
• Claims data, pre-authorisation requests, and hospital discharge summaries flowing through a TPA
• Occupational health check reports where the company runs them
• Employee assistance programme usage, counselling records, and wellness app data

Performance and employee relations

• Goals, ratings, calibration notes, promotion and increment decisions
• Performance improvement plan documentation
• Disciplinary files, show-cause notices, and inquiry records
• Grievance and POSH complaint files, including complainant and respondent statements and witness testimony
• Whistleblower and ethics hotline reports

Exit

• Resignation letters, exit interview transcripts, full and final settlement computations
• Clearance checklists that reference asset returns and outstanding advances
• Rehire eligibility markers and internal notes about the exit
• Post-exit correspondence about PF withdrawal, gratuity, and Form 16

Every one of these categories has an owner, a system, a retention need, and a risk profile. The point of the inventory is not completeness for its own sake. It is that you cannot write an HR data privacy policy for data you have not acknowledged you hold.

DPDP In Plain Language for HR Teams

The Digital Personal Data Protection framework in India is written in fairly readable language, but it uses terms that do not map neatly onto HR vocabulary. Here is the translation.

The three roles

Data principal. The individual the data is about. In HR terms: your employees, your candidates, your contractors where you process their personal data, and the family members and references whose details sit in your systems.

Data fiduciary. The organisation that decides why and how personal data gets processed. That is your company. HR is not a separate fiduciary; the company is the fiduciary and HR acts on its behalf.

Data processor. Anyone who processes personal data on your instructions. Your HRMS provider, payroll bureau, BGV agency, TPA, biometric vendor, and cloud host are all processors in most arrangements. The critical point: you remain accountable for what they do with employee data. Outsourcing the processing does not outsource the responsibility.

Notice and consent

The default rule under the framework is that personal data is processed on the basis of consent, and consent must be preceded by a clear notice. A compliant notice tells the person what data is being collected, for what purpose, how they can withdraw consent, how they can exercise their rights, and how they can complain to the regulator.

Consent itself must be free, specific, informed, unconditional, and unambiguous, signalled by a clear affirmative action. It must be limited to the data necessary for the stated purpose. And it must be as easy to withdraw as it was to give.

Two implications for HR that catch people out:

1. A blanket "I consent to the company processing my data" line at the bottom of the appointment letter does not meet this bar. It is neither specific nor informed, and it is bundled into a document the employee cannot decline.
2. Consent obtained as a condition of employment is on shaky ground because the freedom element is questionable when the power imbalance is that stark. This is precisely why the law provides an alternative route for employment.

Legitimate uses and the employment carve-out

The framework recognises certain "legitimate uses" where processing can proceed without separate consent. One of these covers employment purposes: processing for purposes of employment, and to safeguard the employer from loss or liability, including things like prevention of corporate espionage, maintenance of confidentiality of trade secrets and intellectual property, and provision of services or benefits sought by the employee.

This is genuinely useful. It means you do not need to chase consent forms to run payroll, maintain attendance, administer statutory benefits, or keep a personnel file.

But here is the part HR teams routinely misread. The employment legitimate use is an alternative to consent. It is not an exemption from the rest of the law. Even when you rely on it, you still owe the employee:

• Purpose limitation. You can use the data for employment purposes. You cannot quietly repurpose the same data for something unrelated.
• Data minimisation. Collect what the purpose actually requires. A cheerful "just in case" field on the joining form is not defensible.
• Accuracy. Data used to make decisions about a person, or disclosed to another fiduciary, must be complete, accurate, and consistent.
• Storage limitation. Erase the data when the purpose is served, unless a law requires you to retain it.
• Reasonable security safeguards. Technical and organisational controls, applied to your systems and enforced through your processors.
• Breach notification. Report personal data breaches to the affected individuals and to the regulator in the manner and timelines prescribed. Confirm the current requirements against the notified rules.
• Grievance redressal. A published mechanism, with a responsive person behind it.
• Data principal rights. Access, correction, completion, updating, erasure, grievance redressal, and nomination.

So the honest framing is: the employment carve-out changes your lawful basis, not your duty of care.

Where consent still matters in HR

Even with the carve-out, some HR processing sits outside "employment purposes" and needs consent or a rethink.

• Using employee photographs and personal stories in external marketing
• Publishing personal details in a public directory or on the website
• Sharing employee data with a group company for purposes unrelated to their employment with you
• Optional wellness programmes that collect health data beyond what benefits administration requires
• Alumni communications and rehire marketing after exit
• Processing candidate data for future roles after the applied-for role is closed

For candidates specifically, the employment legitimate use is a weaker fit because there is no employment relationship yet. Most careful organisations run candidate processing on consent, with a clear notice at the point of application and a defined retention period for the talent pool.

Other concepts worth knowing

Consent manager. The framework contemplates registered intermediaries through which individuals can give, manage, review, and withdraw consent. Whether and how this becomes relevant to employment contexts depends on the notified rules; watch this space rather than assuming it applies to you today.

Children's data. Processing personal data of children requires verifiable parental consent, and tracking, behavioural monitoring, and targeted advertising directed at children are restricted. HR encounters this in two places: dependant details for insurance, and apprentice or intern programmes involving people below the age threshold. Handle both with care and check the current rules for exemptions relevant to your case.

Significant data fiduciary. The government can designate certain fiduciaries as "significant" based on volume and sensitivity of data, risk to rights, and other factors. Significant data fiduciaries carry extra obligations, typically including appointing a Data Protection Officer based in India, appointing an independent data auditor, and conducting periodic data protection impact assessments and audits. Most mid-sized employers will not be designated, but large employers and HR service providers handling data at scale should track the criteria.

Exemptions. There are carve-outs for certain state processing, legal proceedings, and other specified situations. Do not assume one applies to your HR use case without advice.

Building Your HR Record of Processing

The data mapping exercise is the single highest-value thing an HR team can do in its first month of privacy work. It converts vague anxiety into a finite list of decisions.

What a good HR data map contains

For each data element or logical group of elements, capture:

• Field or data group — what you actually hold
• Source — employee, candidate, manager, vendor, device, statutory authority
• Purpose — the specific business reason, written plainly
• Lawful basis — employment legitimate use, other legitimate use, or consent
• Primary system — where the authoritative copy lives
• Secondary copies — the shared drive folder, the email thread, the local spreadsheet
• Internal recipients — which roles can see it
• External recipients — processors and other fiduciaries
• Retention — how long, and why
• Cross-border — whether the data leaves India, and to where
• Risk rating — high, medium, low, based on sensitivity and exposure

The secondary copies column is where the truth comes out. Almost every HR team discovers three to five shadow copies of their most sensitive data during this exercise.

Worked example

Take Meridian Consulting, a fictional 180-person services firm in Pune running an HRMS, an outsourced payroll bureau, group health insurance through a broker and TPA, and biometric attendance at reception. A slice of their map looks like this.

You do not need a fancy tool for this. A well-structured spreadsheet, reviewed quarterly, beats an expensive platform nobody updates. Just keep the map itself access-controlled, because it is a treasure map to your most sensitive data.

How to run the exercise without it stalling

1. Timebox it. Two weeks, three working sessions of two hours each. Perfection is the enemy here.
2. Go lifecycle by lifecycle, not system by system. Systems hide the shadow copies; lifecycles surface them.
3. Interview the doers, not the leads. The payroll executive who actually runs the monthly cycle knows about the reconciliation spreadsheet that the HR Head has never seen.
4. Ask "and where else does this live?" three times for every high-risk item.
5. Record the uncomfortable answers. The map is only useful if it is honest.
6. End each session with decisions, not just documentation: stop collecting this field, delete that folder, restrict this report.

Vendor and Processor Management

Your employee data protection posture is only as strong as your weakest processor. For a typical Indian mid-sized employer, that list is longer than expected.

The realistic vendor inventory

• HRMS or HRIS platform
• Payroll bureau or payroll processing partner
• Applicant tracking system and job board integrations
• Background verification agency
• Insurance broker, insurer, and third-party administrator
• Biometric or access control device vendor and their cloud console
• Learning management system
• Employee engagement, survey, and recognition tools
• Expense management platform
• Cloud hosting and storage providers underlying all of the above
• Contract staffing agencies and payroll-on-record partners
• Statutory compliance consultants who receive registers and returns
• Corporate travel and hotel booking partners

Each of these has a copy of some portion of your employee data. Each is a potential source of a breach you will have to report.

What belongs in a data processing agreement

Whether it sits as a standalone DPA or a schedule to the master services agreement, cover these points.

• Scope of processing: the categories of data, categories of data principals, nature and purpose of processing, and duration
• Processing only on documented instructions, with no independent use of the data for the vendor's own purposes, including model training or product analytics, unless separately and specifically agreed
• Security obligations: encryption in transit and at rest, access control, logging, secure development, vulnerability management, and periodic testing
• Personnel obligations: confidentiality undertakings, background checks on staff with access, and training
• Sub-processing: prior approval or a notified list, with the same obligations flowed down, and vendor liability for sub-processor failures
• Location and cross-border: where data is stored and processed, and notification before any change of region
• Breach notification: a defined short window to notify you, with a defined content set, and cooperation in your own regulatory notification
• Assistance with rights requests: the vendor must help you fulfil access, correction, and erasure requests within your response window
• Audit and assurance: the right to audit, or acceptance of an independent audit report or recognised certification, plus a completed security questionnaire annually
• Return and deletion on termination: a defined deadline, a defined format for return, and written certification of deletion including backups
• Retention limits during the term, so the vendor is not keeping historic payroll files indefinitely
• Liability and indemnity for data protection failures, negotiated to a level proportionate to the sensitivity of the data
• Cooperation with the regulator and with your grievance process

Vendor due-diligence question list

Send this before signing, and again at renewal. Written answers, not a sales call.

1. Where is our employee data stored and processed, at country and region level, including backups and disaster recovery?
2. Which sub-processors touch our data, and for what?
3. Is data encrypted at rest and in transit? What key management is in place?
4. How is access to our data by your staff controlled, logged, and reviewed?
5. Can your support team access our production data? Under what approval workflow, and is it logged?
6. Do you offer role-based access control granular enough to separate payroll, recruitment, and performance data?
7. Are admin actions and data exports logged, and can we see those logs?
8. What is your breach detection capability and your notification commitment to us, in hours?
9. Have you had a security incident affecting customer data in the last three years? What changed as a result?
10. What independent security certifications or audit reports can you share?
11. What is your data retention default, and can we configure retention and automated deletion per record type?
12. On termination, what is your data return format and deletion timeline, including backups?
13. Do you use customer data for product improvement, analytics, or model training? Can we opt out contractually?
14. Who is your data protection contact, and what is your escalation path?
15. Do you carry cyber liability insurance, and at what limit?
16. How do you handle data principal rights requests routed through us?
17. What happens to our data if you are acquired or cease operations?

Score the answers. A vendor who cannot answer questions 1, 8, and 12 in writing is a vendor you should be nervous about.

The uncomfortable vendors

Two categories deserve extra attention because they are frequently informal.

Biometric device vendors. Often small local firms, sometimes with a cloud console you did not know existed, sometimes with a technician who has admin access and no contract governing it. Ask where the biometric templates are stored, whether they leave the device, and who at the vendor can access them.

Compliance consultants and CA firms. They receive salary registers, PF and ESI data, and sometimes full employee masters, often over email, often to a personal-domain address. They are processors. They need agreements and secure transfer channels like everyone else.

Retention: Reconciling "Delete It" With "Keep It"

Privacy pressure says minimise and delete. Labour, tax, and corporate law say keep registers and records for defined periods. Both are right, and the resolution is a written retention schedule that assigns a period and a reason to every category.

Principles that make retention decisions easier

• Retention is per category, not per employee. You do not delete "the employee"; you delete specific data groups as their purposes expire.
• A statutory retention requirement beats a privacy preference, but only for the specific records the statute covers, and only for the period it specifies.
• "We might need it someday" is not a retention basis. Neither is "storage is cheap."
• Anonymisation is a legitimate middle path for analytics needs. Aggregate attrition trends do not require named exit interview transcripts.
• Backups need a policy too. Deleting from production while retaining a full copy in a five-year backup archive is a partial deletion at best. Define backup rotation and document it.
• Litigation hold overrides deletion. If a dispute is live or reasonably anticipated, freeze the relevant records and document why.

Illustrative retention schedule

Treat the periods below as placeholders for a conversation with your counsel, not as legal advice. Applicable periods vary by statute, by state-specific shops and establishments rules, by industry, and by the nature of your workforce.

Turning the schedule into practice

A schedule nobody executes is a liability, because it documents that you knew and did not act. Make it operational.

1. Assign each category an owner in HR.
2. Configure automated deletion or archival in the HRMS wherever the platform supports it.
3. Put a recurring quarterly calendar entry for the manual categories: shared drives, ATS purges, local folders.
4. Log each purge with date, category, volume, and who ran it. That log is your evidence.
5. Add a deletion step to every vendor offboarding checklist, with a written certificate as the closure criterion.

Access Control and Internal Governance

Most HR data exposure is internal and accidental, not external and malicious. Access control is where you get the most risk reduction per unit of effort.

Design principles

Least privilege, by role. Start from zero and grant only what the role needs. The reverse approach, granting broad access and trimming later, never gets trimmed.

Managers do not need full payroll. A manager needs to approve leave, run performance conversations, and often see a compensation band or an increment budget. They rarely need to see the exact net pay, bank account, tax declarations, or insurance claims of their team members. Configure the HRMS accordingly.

Segregate recruitment from payroll. A recruiter needs candidate data. A payroll executive needs employee financial data. Very few people need both, and those who do should have it deliberately, not by default.

Restrict the sensitive vaults. POSH files, disciplinary records, whistleblower reports, and medical documents should sit behind a separate access wall, not in the general employee folder.

Separate viewing from exporting. Many roles need to see data on screen. Far fewer need to download it. Where your HRMS supports it, disable bulk export for roles that do not need it, and log every export that does happen.

The controls checklist

• Named individual accounts only; no shared HR or payroll logins under any circumstances
• Multi-factor authentication on the HRMS, payroll system, ATS, and email, without exception for admins
• A documented list of who holds admin rights in each HR system, reviewed quarterly
• At least two admins so there is no single point of failure, but not five
• Audit logging enabled for record views, edits, exports, and permission changes, with logs retained long enough to investigate an incident
• Quarterly access review: HR Head signs off the list of users and their permission levels in each system
• Same-day access revocation when an HR or payroll team member exits or changes role, covering the HRMS, payroll portal, ATS, insurer portal, biometric console, shared drives, and any vendor portals
• Device standards for anyone handling payroll data: full-disk encryption, screen lock, and no local storage of payroll extracts
• A rule against screen-sharing HR systems in meetings without first switching to a filtered or anonymised view
• Clear-desk practice for printed payroll registers and document scans

The spreadsheet leakage problem

This deserves its own treatment because it defeats every other control you put in place.

The pattern: someone needs an analysis the HRMS does not directly produce. They export a full employee master to Excel. They mail it to a colleague. The colleague saves it locally, adds columns, and mails a version to a consultant. Six months later, four uncontrolled copies of the complete salary and identity data of the whole company exist across three machines and two mailboxes, and nobody knows.

What actually reduces this:

• Build the reports people keep exporting for them, inside the HRMS, so the export stops being necessary
• Give analysts a masked or aggregated view rather than raw records
• Route all salary-related file sharing through a controlled link with expiry, never as an email attachment
• Ban salary and identity data from WhatsApp and personal email in policy, and give people a workable alternative so the ban is realistic
• Run a periodic amnesty: ask the team to find and delete old HR extracts, with no blame attached, and repeat it every six months
• Watermark or label exports with the recipient's name where the platform supports it, which changes behaviour more than any policy memo

Employee-Facing Obligations: Notice, Consent, and Rights

Compliance that employees never see is only half a programme. The visible half is your notice, your consent mechanics where consent applies, and your handling of rights requests.

What the employee privacy notice should say

Write it as a standalone document, not a clause buried in the handbook. Plain language, ideally available in the languages your workforce actually reads.

• What we collect, grouped by lifecycle stage, in categories an employee can recognise
• Why we collect it, stated as specific purposes rather than a generic "for business purposes"
• Our basis, distinguishing what we process for employment purposes from what we ask consent for
• Who we share it with, by category of recipient, with a note that a current vendor list is available on request
• Where it is stored, including whether any of it leaves India
• How long we keep it, by category, referencing the retention schedule
• How we protect it, briefly and honestly
• Your rights, and exactly how to exercise them, with a named channel
• How to complain, internally to the grievance officer, and externally to the regulator
• Special processing, covering biometric attendance, location tracking, monitoring, and CCTV, each with its own short paragraph
• When we last updated this, with a version number and a commitment to notify on material changes

Issue the notice at offer stage for candidates who convert, again at onboarding, and re-issue when it materially changes. Keep a record of issuance. That record is your evidence.

Running consent properly where you use it

For the narrow set of HR processing that genuinely runs on consent, the mechanics matter.

1. Unbundle it. Separate tick boxes for separate purposes. One box covering "marketing, alumni communications, and photo usage" is not specific consent.
2. No pre-ticked boxes. Affirmative action means the employee does something, not that they fail to undo something.
3. Make declining safe and real. If declining the optional wellness app has no employment consequence, say so explicitly in the request.
4. Log the consent artefact: what was shown, which version of the notice, when, and what was selected.
5. Build the withdrawal path before you launch the collection. A withdrawal option that requires emailing HR and hoping is not equivalent ease.
6. Handle withdrawal consequences. When consent is withdrawn, stop that processing, tell your processors to stop, and delete unless another basis or a legal retention requirement applies. Document what you did.

Data principal rights in an HR context

A workable request-handling workflow

1. Single intake channel. One published email alias or an HRMS request form. Multiple channels mean missed requests and missed deadlines.
2. Log on arrival. Assign a reference number, timestamp, requester, and type. The clock starts here.
3. Verify identity. For current employees, authenticated HRMS submission is usually sufficient. For ex-employees, verify against known record details without demanding fresh identity documents you would then have to protect.
4. Acknowledge quickly, within a couple of working days, with the reference number and expected timeline.
5. Scope the request. What data, what period, what systems. Ask a clarifying question if genuinely ambiguous, but do not use clarification as a delaying tactic.
6. Collect across all systems, including processors. This is why your data map exists.
7. Review before release. Redact third-party personal data, protect confidential business information, and take a view on material like ongoing investigation files with legal input.
8. Respond in writing, stating what you provided, what you did not, and why.
9. Close and record. Keep the request, the response, and the decision rationale.
10. Review the register quarterly for patterns. Ten correction requests about the same field means your data quality has a root cause worth fixing.

Confirm applicable response timelines against the current rules. Whatever they are, set your internal target well inside them, because collection across systems and processors is what consumes the time.

A simple intake form

Keep it to what you need:

• Name and employee ID or last-held employee ID
• Contact email and phone for the response
• Current or former employee, or candidate
• Type of request: access, correction, erasure, grievance, nomination
• Description of the request, including specific data or period if known
• For correction requests: current value, corrected value, supporting document
• Declaration that the requester is the data principal or an authorised nominee
• Date of submission

Special Categories That Need Tighter Handling

India's framework does not create a formal "sensitive personal data" tier the way some other regimes do. That does not mean everything deserves the same handling. Some HR data causes disproportionate harm when it leaks, and your safeguards should be proportionate to that harm.

Health and insurance data

Enrolment data, claim documents, pre-authorisation forms, and medical certificates reveal conditions the employee may not have disclosed to their manager, and often involve family members.

• Route claims directly between the employee and the insurer or TPA wherever possible, so HR never holds the clinical detail
• Where HR must be in the loop, restrict to one or two named benefits administrators
• Store medical certificates in a restricted vault, never in the general personnel file
• Sick leave records should note the duration and the fact of medical certification, not the diagnosis
• Never discuss an employee's medical situation with their manager beyond what is operationally necessary, which is usually just availability

POSH and grievance case files

These files contain the most damaging possible content: allegations, witness statements, and findings about named individuals.

• Access limited to the Internal Committee, with a named custodian
• Stored in a separate restricted repository, not in the HRMS employee folder
• No forwarding of statements by email; use a controlled repository
• Confidentiality obligations documented for every person who touches the file, including external IC members
• Retain per the statutory register requirement; access remains restricted for the whole retention period
• The employee's general HR record should not carry a searchable flag that discloses the existence of a complaint to routine HRMS users

Disciplinary records

• Restricted to HR and the specific management chain involved
• Time-bounded: a warning that has expired under your own policy should not be visible to a future manager browsing the record
• Factual content only; the file should record what happened and what was decided, not editorial commentary

Background verification results

• Retain the verification outcome, not the full raw report, once the person has joined
• Never share BGV content with the hiring manager beyond a pass or fail signal and any specific discrepancy they need to address
• Where a check produces adverse information, document the decision process, because that is the record you will need if the decision is later challenged
• Delete declined candidates' BGV packs promptly

Whistleblower reports

• Protecting reporter identity is the primary control, above everything else
• Restrict access to the ethics or audit function, and keep HR out of it unless the report concerns HR matters
• Use case reference numbers rather than names in status communications
• Never store whistleblower content in general HR systems

A good test: for each of these categories, ask who in the company could pull the file today without anyone knowing. If the answer includes anyone whose job does not require it, you have a fix to make.

Biometric Attendance and Location Tracking

These are the two HR technologies most likely to generate employee complaints, and the two where a proportionality argument matters most.

The proportionality question

Before deploying, answer three questions in writing:

1. What problem are we solving? "Buddy punching" is a real problem. "We wanted modern attendance" is not a justification.
2. Is there a less intrusive way? Card-based systems, QR codes at fixed locations, network-based check-in, or supervisor attestation may achieve enough of the benefit with less sensitive data.
3. Is the data collection proportionate to the benefit? Continuous background location tracking of a field sales team to verify attendance is disproportionate. A location stamp at check-in and check-out is arguably not.

Write the answers down. If your approach is later questioned, the reasoning file is what you will rely on.

Doing biometrics responsibly

• Use template-based systems that store a mathematical representation rather than a raw fingerprint or face image, and confirm with the vendor which one they use
• Confirm in writing where templates are stored, whether they leave the device, and who at the vendor can access them
• Give clear notice at enrolment: what is captured, where it is stored, how long, and who can see it
• Offer a genuine alternative for employees who cannot or will not enrol, including those with worn fingerprints, medical conditions, or religious objections, and make sure using the alternative carries no penalty
• Delete templates promptly on exit, and verify with the vendor that deletion actually happened
• Never repurpose the biometric system for productivity monitoring without a fresh assessment and fresh notice

Doing location tracking responsibly

• Track during working hours only, and prove it: employees should be able to see when tracking is on
• Prefer discrete check-in and check-out stamps over continuous trails
• Set a short retention window for raw location data, and keep only aggregates thereafter
• Never use location data for a purpose you did not disclose, such as inferring personal activity outside work
• Be explicit that the app does not track outside working hours, and make that verifiable in the app's interface

When employees object

Objections are useful signals, not obstacles. Handle them properly.

1. Acknowledge the objection formally and log it in your grievance register
2. Explain the purpose and the safeguards in specific terms, not in policy language
3. Offer the alternative mechanism where one exists
4. Where no alternative exists, document the business necessity and be prepared to justify it
5. Never let an objection about data collection influence a performance or employment decision, and be able to show it did not

A 300-person logistics firm in Coimbatore that offered a supervisor-attested alternative to face-recognition attendance found that fewer than ten people took it up. The alternative cost almost nothing, and it converted a contentious rollout into an uneventful one. That is usually how it goes.

Cross-Border Transfers

If your HR data stays entirely on Indian infrastructure, this section is short: confirm it, document it, and move on.

Most organisations discover it does not. The global HRIS is hosted abroad. The parent company's compensation team accesses the Indian employee master. The ATS runs on a US cloud region. The engagement survey tool processes responses in Europe.

Practical steps

1. Find the flows. Your data map has a cross-border column for exactly this reason. Ask each vendor, in writing, for storage and processing locations including backups and support access.
2. Do not forget remote support access. A vendor whose data sits in Mumbai but whose support engineers in another country can log into production is transferring data, functionally.
3. Classify by sensitivity. Payroll and identity data crossing borders carries more risk than an anonymised engagement survey.
4. Check for restrictions. The framework allows the government to restrict transfers to specified countries, and sector regulators may impose their own localisation requirements. Confirm the current position and any sector rules that apply to you.
5. Paper the intra-group flows. Group companies are separate legal entities. An intra-group data transfer agreement is not bureaucratic overhead; it is the document that establishes who is responsible for what.
6. Restrict global access to what the global role needs. A regional HR director may need headcount and band data across countries. They rarely need Indian bank account numbers or PAN details, and those fields can usually be masked in a global HRIS view.
7. Disclose it in the notice. Employees should be able to read your privacy notice and understand that their data is accessible from outside India, and why.
8. Re-check on vendor changes. Cloud region migrations happen quietly. Put a clause in the DPA requiring notice before any change of processing location.

The realistic risk

The practical risk with cross-border HR data is rarely a regulator objecting to the transfer. It is that data crosses into an environment where your access controls, your retention schedule, and your deletion capability do not apply. A global HRIS administered by a team in another country, on a retention policy you did not set, is a governance gap regardless of the legal position on the transfer itself.

Breach Readiness

Assume you will have an incident. The organisations that come through them well are the ones that prepared while nothing was on fire.

What an HR data breach actually looks like

• The payroll register emailed to the wrong external recipient
• A full CTC export saved to a personal cloud drive and shared with a link set to "anyone with the link"
• A stolen or lost laptop with locally cached payroll files and no disk encryption
• An HRMS account compromised through a reused password, with no MFA
• A departed HR executive who retained access to a vendor portal for three months
• A vendor incident: the BGV agency, the TPA, or the biometric vendor is breached and your employee data is in scope
• A misconfigured shared drive folder that made scanned ID proofs readable company-wide
• Salary data pasted into a group chat with the wrong participants

Note how many are internal and unintentional. Your incident response plan must handle these, not just the dramatic external intrusion.

Incident response runbook

Step 1 — Detect and report (immediately). Every HR and payroll team member should know exactly who to tell and how, within minutes. Publish a single incident contact. Make it explicit that reporting a mistake promptly is the expected behaviour and will not be punished; the alternative is silence, which is far worse.

Step 2 — Contain (first hour). Recall the email if the platform allows. Revoke the sharing link. Disable the compromised account. Suspend the vendor integration. Lock the affected folder. Containment beats investigation in the first hour.

Step 3 — Assess (first day). Establish what data, whose data, how many people, what exposure window, and whether the data was accessed or merely exposed. Write down what you know and what you do not.

Step 4 — Notify. Determine your notification obligations to affected individuals and to the regulator, and the applicable content and timelines under the current rules. Do this with legal counsel; do not improvise. Also check contractual notification obligations to clients whose data may be implicated, and your cyber insurance notification requirements.

Step 5 — Communicate to affected employees. Plain language, no defensiveness. What happened, what data was involved, what you have done, what they should do, and who they can contact. Employees forgive incidents handled openly. They do not forgive discovering it from someone else.

Step 6 — Remediate. Fix the specific cause and the class of cause. If it was a misdirected email, look at whether external-recipient warnings are enabled and whether that report needed to be an attachment at all.

Step 7 — Record and review. Complete the breach register entry. Run a blameless review within two weeks. Update the runbook with what you learned.

The breach register

Maintain it whether or not an incident is reportable. It is your evidence of a functioning programme.

Run a tabletop exercise once a year. Pick a scenario, put the HR, IT, legal, and communications leads in a room for ninety minutes, and walk it through. You will find gaps in your contact list, your vendor escalation paths, and your assumptions about who decides what. Finding them on a Tuesday afternoon is much cheaper than finding them at 11pm during a live incident.

A 90-Day HR Privacy Programme

You cannot fix everything at once. This sequence front-loads the work that reduces the most risk.

Days 1 to 30: See clearly

Days 31 to 60: Decide and document

Days 61 to 90: Operate and prove

Ninety days will not make you perfect. It will move you from "we have no idea" to "we know what we hold, who can see it, how long we keep it, and what we do when something goes wrong." That is the difference that matters.

Readiness Self-Assessment

Score each item: 2 for fully in place, 1 for partial, 0 for absent. Twenty-five items, fifty points available.

Governance 1. A named person owns HR data privacy, with time allocated for it 2. A published grievance contact exists and responds within a defined timeline 3. An internal HR data privacy policy exists and HR staff have read it 4. Leadership receives a periodic report on HR privacy status

Knowing your data 5. A current HR data map covers the full employee lifecycle 6. The map records lawful basis for each processing activity 7. Shadow copies in shared drives, mailboxes, and local machines have been identified 8. Cross-border flows are documented, including vendor support access

Notice and consent 9. A standalone employee privacy notice is published and issued at joining 10. The notice covers biometrics, location tracking, and monitoring specifically 11. Consent, where used, is unbundled, specific, and logged 12. A working consent withdrawal mechanism exists and has been tested

Access control 13. Role-based access is configured; managers cannot see full payroll data 14. No shared logins exist in any HR system 15. MFA is enforced on all HR systems and admin accounts 16. Access rights are formally reviewed at least quarterly 17. HR and admin access is revoked same-day on exit or role change, across all systems and vendor portals 18. Audit logs capture views, edits, exports, and permission changes

Vendors 19. A complete processor inventory exists 20. Data processing terms are in place with every processor handling employee data 21. Vendor due diligence is completed at onboarding and refreshed at renewal 22. Deletion certification is obtained when a vendor relationship ends

Retention and rights 23. A written retention schedule exists, validated against applicable statutes 24. Retention is actually executed, with a purge log as evidence 25. A rights request workflow exists with a single intake channel and a request register

Interpreting your score. Below 20: you are exposed and should treat this as urgent. 20 to 34: the basics are forming but execution is patchy. 35 to 44: a functioning programme with specific gaps to close. 45 and above: you are in good shape; focus on evidence, testing, and keeping it current.

Common Mistakes and How to Fix Them

The blanket consent clause

The mistake: A line in the appointment letter reading "I consent to the Company collecting, storing, using, and sharing my personal data for all business purposes."

Why it fails: Not specific, not informed, not freely given because it is bundled into a document nobody can decline, and it covers no defined purpose.

The fix: Rely on the employment legitimate use for genuine employment processing, backed by a proper notice. Use separate, specific, unbundled consent for the narrow set of things outside employment purposes.

Keeping every CV forever

The mistake: An ATS with 40,000 candidate records going back eight years, plus recruiter mailboxes and personal drives holding thousands more.

Why it fails: No purpose survives that long, no consent covers it, and the volume makes it a serious breach exposure with zero business value.

The fix: Set a talent-pool retention period. Purge beyond it. If you want to keep candidates longer, ask them, with an end date and an easy opt-out.

Salary data in WhatsApp groups

The mistake: Increment lists, CTC comparisons, and payroll queries flowing through chat groups on personal devices, sometimes including people who left the team months ago.

Why it fails: Uncontrolled, unlogged, unrecoverable, and often on personal devices with cloud backups you do not manage.

The fix: Prohibit it clearly, and give people a workable alternative in the HRMS. A ban without an alternative just moves the behaviour somewhere you cannot see.

Unrestricted HRMS admin rights

The mistake: Six people with full admin, including two who left the HR function last year, plus the implementation consultant's account still active.

Why it fails: Full admin usually means seeing everything, changing anything, and exporting without limit, often without logging.

The fix: Reduce to two named admins. Move everyone else to functional roles. Review quarterly. Remove implementation and support accounts at go-live.

No DPA with the payroll vendor

The mistake: A payroll bureau processing the complete salary and identity data of every employee under a services agreement that says nothing about data protection, security, breach notification, or deletion.

Why it fails: You are accountable for their processing and you have no contractual control over it, and no notification commitment if they are breached.

The fix: Issue an addendum. Most established vendors have a standard DPA ready. If yours resists entirely, that is information about the vendor.

Scanned ID proofs in shared drives

The mistake: A folder called "Employee Documents" on the company drive, containing thousands of scanned identity documents, readable by everyone in HR and often by IT and finance too.

Why it fails: Identity documents are the highest-value target in your entire estate, and shared drive permissions drift over time.

The fix: Move them into a document vault inside the HRMS with per-employee access rules. Delete the shared drive copies. Verify permissions after migration, not just before.

Collecting data you do not need

The mistake: A joining form asking for marital status, religion, mother's maiden name, blood group, and previous salary, mostly because the form was inherited from a decade ago.

Why it fails: Data minimisation. Every field you collect is a field you must protect, justify, retain, and eventually delete.

The fix: Review every form field and ask what decision depends on it. Delete the ones with no answer. This takes an afternoon and permanently reduces your risk surface.

Treating privacy as a one-time project

The mistake: A privacy programme completed in a quarter, documented in a deck, and never revisited.

Why it fails: New vendors, new modules, new headcount, and staff turnover all erode the controls quietly.

The fix: A quarterly cadence with named owners: access review, retention purge, vendor check, register review. Thirty minutes a quarter beats a rebuild every two years.

How an HRMS Changes the Equation

A lot of HR privacy difficulty is architectural. Data scattered across spreadsheets, drives, mailboxes, and disconnected portals cannot be governed, no matter how good the policy. Consolidation is not just an efficiency argument; it is a privacy control in itself.

A single system of record. When compensation, attendance, documents, and performance data live in one place, you have one access model to manage, one audit trail to review, and one retention configuration to set. Every additional copy is a governance problem.

Role-based permissions that actually work. A capable HRMS lets you separate what a manager sees from what a payroll executive sees from what an HR business partner sees, and to restrict fields rather than entire records. That is the difference between a policy and a control.

Audit trails by default. Who viewed a salary record, who exported a report, who changed a bank account, and when. Without this, a breach investigation is guesswork, and you cannot demonstrate the safeguards you claim to have.

A document vault instead of a shared drive. Identity documents, investment proofs, and certificates stored against the employee record, with per-document access rules and no loose copies to lose track of.

Retention automation. Configure the period once and let the system flag or purge on schedule, rather than depending on someone remembering in March.

Employee self-service. When employees update their own address, bank details, and dependants, three things improve simultaneously: accuracy improves, correction requests drop, and fewer HR staff need write access to sensitive fields.

Structured rights request handling. A request form that routes to the right owner, with a timer and a record, so nothing sits unnoticed in someone's inbox.

Fewer vendors, fewer flows. Every module you consolidate is one less processor to assess, one less DPA to negotiate, and one less place your employee data can be breached.

CozyHR was built around this way of working: a single system of record for Indian HR and payroll, with granular role-based access, audit logging, a secure document vault, configurable retention, and self-service that keeps employees in control of their own information. If your current setup is a mix of spreadsheets and disconnected tools and you are trying to build a defensible privacy posture on top of it, it is worth seeing what consolidation looks like. Try CozyHR when you are ready, or start with the data mapping exercise above regardless of what tools you use, because that step pays for itself either way.

Frequently Asked Questions

Do we need employee consent to run payroll under DPDP?

Generally no. The framework provides for legitimate uses including processing for purposes of employment, which covers core activities like salary disbursement, statutory filings, attendance, and benefits administration. What you do still owe is a clear privacy notice, purpose limitation, data minimisation, reasonable security safeguards, defined retention, and responsiveness to data principal rights. The carve-out changes your lawful basis, not your obligations. Confirm the precise scope of the legitimate use with your counsel, particularly for processing that sits at the edges of "employment purposes."

Can we keep candidate CVs in our talent pool indefinitely?

Not safely. There is no employment relationship with a candidate, so the employment legitimate use is a weak fit, and no purpose justifies indefinite retention. The practical approach is a defined retention period from the last meaningful interaction, disclosed in your candidate privacy notice, with a purge process that actually runs. If you want to keep someone longer, ask them explicitly, tell them how long, and make opting out easy.

Is biometric attendance allowed?

The framework does not prohibit it, but proportionality matters and you should be able to justify your choice. Document the problem you are solving, why less intrusive alternatives are insufficient, and what safeguards you have applied. Give clear notice at enrolment, offer a genuine alternative for employees who cannot or will not enrol, confirm with the vendor where templates are stored and who can access them, and delete templates promptly on exit. Also check whether any sector-specific or state-specific rules apply to your operations.

Who should be responsible for employee data privacy: HR, IT, or legal?

All three, with clear division. HR owns the data, the decisions about what is collected and why, retention, and employee communication. IT owns the technical controls: access, encryption, logging, and monitoring. Legal owns interpretation of obligations, contract terms with processors, and breach notification decisions. Someone needs to be the named coordinator, and in practice that works best in HR because HR understands the data. Organisations designated as significant data fiduciaries have specific requirements around appointing a Data Protection Officer; check whether the designation criteria apply to you.

What do we do if an ex-employee asks us to delete all their data?

Assess the request against your retention schedule rather than answering yes or no reflexively. Some data must be retained under tax, provident fund, and labour record obligations, and the right to erasure does not override a legal retention requirement. Delete what is genuinely spent, such as raw background verification packs, exit interview free text, and biometric templates. Then respond in writing explaining exactly what you deleted, what you retained, and the legal basis for retaining it. A clear explanation usually resolves the request; silence or a blanket refusal escalates it.

How long do we have to respond to a data principal rights request or report a breach?

Timelines for rights responses and breach notification are set out in the framework and its rules, and the operative details can change as provisions are notified. Rather than working from a number you read somewhere, confirm the current requirements against the official text or with your counsel, and then set your internal service level comfortably inside them. The practical constraint is usually not the legal deadline but the time it takes to collect data across systems and processors, which is exactly why the data map and vendor cooperation clauses matter.

Do we need a data processing agreement with our HRMS provider?

Yes. Your HRMS provider is processing employee personal data on your instructions, which makes them a processor and keeps you accountable for what they do with it. The agreement should cover processing scope, security measures, sub-processor controls, storage location, breach notification timelines, assistance with rights requests, audit rights, and return and deletion on termination. Established providers usually have a standard agreement ready. A vendor who cannot produce one, or who resists the conversation entirely, is telling you something useful about their maturity.

We are a 60-person company. Is this really proportionate for us?

The obligations do not scale down with headcount, but the effort does. A 60-person company has a smaller data map, fewer vendors, and a simpler access model, so the whole exercise might take a few days rather than a quarter. Focus on the highest-value items: know what you hold, restrict who can see payroll and identity data, get agreements in place with your payroll and HRMS vendors, publish a real privacy notice, set retention periods, and know what you would do in the first hour of a breach. That covers most of the practical risk, and it is entirely achievable for a small team.

Closing Thoughts

Employee data privacy work has a reputation for being abstract and legalistic. In practice, the things that matter most are concrete and unglamorous: knowing what you hold, restricting who can see it, writing down how long you keep it, getting proper agreements with the vendors who touch it, telling employees the truth about it, and having a plan for the day something goes wrong.

Start with the data map. Everything else in this guide depends on it, and most HR teams find that the exercise alone surfaces two or three fixes they can make the same week. Then work through access controls and vendor agreements, because those are where the largest risks concentrate. The notice, the retention schedule, and the rights workflow follow naturally once you know what you are describing.

The organisations that handle this well are not the ones with the biggest legal budgets. They are the ones where HR decided to own the problem and worked through it steadily, quarter by quarter. If your data currently lives across spreadsheets, shared drives, and disconnected portals, consolidating onto a single HRMS with proper role-based access, audit trails, a document vault, and retention controls will make every other step easier. CozyHR is built for exactly that, and it is there when you want to take a look.

Whatever tooling you choose, treat this as an ongoing operating discipline rather than a project with an end date. And check the specifics with your legal counsel, because the details are where compliance is actually won or lost.