Employee Data Under DPDP: The Overlooked Obligation That BFSI HR Teams Are Getting Wrong
Every DPDP conversation in BFSI focuses on customer data. But the Act does not distinguish between customer and employee personal data — it applies to both. Most BFSI HR teams have no compliance programme in place for employee data, and the risks are more significant than most realise.
Employee data obligations HR teams are missing
HR departments in BFSI organisations process some of the most sensitive personal data in the enterprise — biometrics, health records, financial details, background check results — yet most have not been included in the DPDP compliance programme at all. The following processing activities carry specific regulatory obligations that HR teams are consistently overlooking:
- Biometric attendance: Fingerprint and facial recognition systems require a DPIA and documented consent where no statutory obligation basis applies. Most BFSI organisations implemented biometric attendance as an operational convenience, not a legal requirement — which means the legal basis cannot be "compliance with law" and must be explicit consent with a genuine opt-out alternative.
- Performance management and HR analytics: Automated scoring of employee performance, attrition risk modelling, and promotion likelihood algorithms constitute profiling under DPDP. Profiling triggers a mandatory DPIA. Most HR analytics platforms were procured without privacy impact assessment, and the profiling logic is often opaque even to the HR team operating it.
- Health data for insurance: Group health insurance enrolment requires employees to share medical history, pre-existing conditions, and family health information. This is sensitive personal data requiring explicit, informed consent — not the blanket consent buried in the insurance enrolment form.
- Background verification: Pre-employment and periodic background checks are conducted by third-party agencies acting as data processors. Each agency requires a Data Processing Agreement with DPDP-compliant terms covering data retention, deletion after purpose fulfilment, and breach notification obligations back to the fiduciary.
The notice obligation
Section 7 of the DPDP Act requires that data principals receive a notice before their personal data is processed. For employees, this means an employee privacy notice — not a clause in the employment contract, not a reference in the employee handbook, but a specific, plain-language notice that describes what data is collected, why it is collected, how long it is retained, and who it is shared with.
The clause buried in most employment contracts — "your data may be used for HR purposes" — does not meet the §7 notice standard. The notice must be specific enough that an employee can understand exactly what processing will occur. "HR purposes" is not a purpose — it is a category. The notice must list each processing activity: payroll computation, tax filing, performance evaluation, biometric attendance, background verification, insurance enrolment, and any other activity involving employee personal data.
The notice must also be provided before processing begins. For existing employees, this means issuing the notice retrospectively and documenting acknowledgement. For new joiners, the notice should be part of the onboarding process, separate from the employment contract, and signed independently.
The employment contract clause "your data may be used for HR purposes" has never met the specificity requirement — under DPDP Rules 2025, this is no longer a grey area. The notice must enumerate each processing activity, its purpose, the legal basis relied upon, retention periods, and any third-party sharing. A single sentence in a contract does not constitute informed notice regardless of whether the employee signed it.
Legal basis mapping for HR data
One of the most common mistakes HR teams make is treating all employee data processing as consent-based. This leads to over-collection of consent — asking employees to consent to processing that the organisation is legally obligated to perform anyway — which creates its own compliance risk. If an employee withdraws consent for payroll processing, the organisation still has a legal obligation to pay them. The correct approach is to map each processing activity to its appropriate legal basis:
- Payroll processing: Legal obligation — compliance with employment law, tax regulations, and provident fund requirements. Consent is not required and should not be sought, because the processing would continue regardless of consent status.
- Time and attendance (non-biometric): Legitimate interest of the employer in managing workforce scheduling and compliance with labour regulations. Standard swipe card or login-based attendance does not require explicit consent.
- Biometric attendance: Likely requires explicit consent, because biometric data is sensitive and most organisations cannot demonstrate that biometric collection is a legal obligation or that no less intrusive alternative exists. A genuine opt-out mechanism (such as manual register or card-based attendance) must be available.
- Health data for group insurance: Explicit consent — health data is sensitive personal data, and insurance enrolment is typically voluntary. The consent must be specific to health data sharing with the insurer, separate from general employment consent.
Mapping legal basis correctly avoids two problems: collecting unnecessary consent (which creates withdrawal risk for mandatory processing) and failing to collect required consent (which creates a compliance gap for sensitive data processing).
What HR needs to do now
The action plan for HR teams is straightforward, but it requires coordination with the compliance and legal functions. HR cannot do this alone, and compliance cannot do it without HR's detailed knowledge of what data is actually collected and why.
Step 1: Map all HR processing activities into ROPA. Every system that touches employee personal data needs a ROPA entry — payroll, HRMS, attendance, performance management, learning management, background verification portals, insurance platforms, and internal communication tools. Most HR teams undercount by 40–60% on their first attempt.
Step 2: Complete PIAs for biometric and profiling activities. Any processing involving biometric data, automated decision-making, or systematic monitoring of employees requires a Privacy Impact Assessment. If the PIA identifies high risk, a full DPIA must follow before processing continues.
Step 3: Update employee privacy notices. Replace the employment contract clause with a standalone employee privacy notice that meets §7 requirements. Issue to all existing employees with documented acknowledgement. Integrate into the onboarding process for new joiners.
Step 4: Establish DPAs with all HR vendors. Every third-party service provider processing employee data — payroll outsourcer, background verification agency, insurance broker, HRMS cloud provider — requires a Data Processing Agreement with DPDP-compliant terms. Audit existing agreements and identify gaps.
The ROPA register includes pre-seeded HR activity templates — payroll, attendance, performance management, background verification, health data processing — making it straightforward for HR and compliance teams to document obligations jointly. Each template includes suggested legal basis, retention periods, and data categories specific to BFSI HR operations.
See ROPA templates →Get DPDP compliance insights in your inbox
Practical guides for CISOs, DPOs, and compliance teams — no spam, unsubscribe anytime.
Ready to implement what you've read?
The CreativeCyber DPDP Assurance Platform puts every framework, workflow, and control referenced in this article into a single audit-ready platform — built specifically for BFSI.
Book a Live Demo →