The DPDP Act and employee data, for HR teams

India now has a general data protection law, and employee data sits squarely inside it. For most HR teams the practical question is not whether the law applies, which it does, but what actually changes about how you run HR, and which of the changes are things you fix in a document versus things you fix in a system.

This guide covers the shape of the obligations as they touch employee data, what a small company should do about them, and what to ask an HR vendor. It states no penalty figure, no deadline and no section number, because the rules have moved and will move again, and a compliance position taken from a marketing page is not a compliance position. Confirm the specifics with Indian counsel.

The one thing to get right first: notice is not consent

The most common misreading is to treat this as a consent regime and start collecting tick boxes from employees. That is both unnecessary and unwise.

The law provides a legitimate use for processing connected to employment. The ordinary run of HR work sits inside it: paying people, administering leave and benefits, keeping the records the employment relationship requires, and protecting the employer against loss. Asking an employee to consent to being paid is not meaningful consent, and consent obtained inside a relationship with a power imbalance is weak ground to build on. Where the employment ground applies, use it.

What does not go away is notice. Employees have to be told, in language they can actually read, what data is collected about them, why, who it goes to, how long it is kept, and how they raise a request or a complaint. This obligation is separate from consent and it applies regardless.

Consent comes back at the edges, where processing is not for an employment purpose. Marketing to your staff, sharing employee data with a third party for that party’s own purposes, or optional programmes that are genuinely optional. Draw that boundary deliberately, and take advice on where your specific activities fall.

What actually changes in a small HR team

Five things, in rough order of how much work they are.

1. The employee privacy notice. Most companies have one, and most are stale. The test is not whether the document exists but whether it describes the systems you actually use today. If the notice was written when HR ran on a spreadsheet, and there are now four tools holding employee data, the notice is inaccurate rather than incomplete. Rewrite it, date it, version it, and put reviewing it in your HR compliance calendar.

2. A data inventory for people data. Not a formal exercise, a list. Every system that holds employee personal data, what it holds, who at your company can see it, and who the vendor is. Most small companies are surprised by the length of this list: the HR system, payroll, the payroll partner, the identity provider, the chat tool, the shared drive, the recruiting inbox, the background check supplier. You cannot write an accurate notice or answer a subject request without it.

3. A retention schedule. This is the one people get backwards. There is a strong instinct that deleting a leaver’s record quickly is good practice. It is not, because employment, pay and tax law commonly requires those records to be kept for years afterwards. What good looks like is a written schedule naming each category of record, the retention period, and the obligation the period comes from, followed by actually applying it. Deletion is then a scheduled act rather than a favour.

4. A route for employee requests. Access, correction, and the other rights the law provides. Name a person, publish the route, and know in advance where the data would have to be gathered from, which is why the inventory comes first.

5. Vendor diligence on anyone who touches employee data. Your obligations do not stop at your own systems, and the vendors holding HR data are usually the largest concentration of it. That is the rest of this guide.

Contractors, candidates and former employees

Three groups get missed, and all three are within scope.

Contractors. If you engage individuals directly, you hold their personal data, and the fact that they are not employees does not put them outside the law. It may, however, put them outside the employment ground, which is a reason to think about the basis rather than assume it. Holding contractors in the same directory as employees at least means you know who they are; the Contractor Management module adds the engagement, document and invoice side, and hiring global contractors covers the wider relationship.

Candidates. Recruiting data is personal data, it accumulates fast, and almost nobody has a retention rule for it. A CV inbox that has never been cleared is a growing liability with no operational value. Decide how long you keep unsuccessful applications and apply it.

Former employees. Retention applies, so their records stay. The question is who can still see them and what happens when the person themselves asks for a copy of their own payslip in three years. Handling that by having a colleague dig through an archive is slow and involves a second person seeing the data. Alumni Access is the self-serve version: the former employee fetches their own documents on their personal email, scoped to what was already theirs, which is a better privacy answer as well as a cheaper one.

What to ask an HR vendor

Five questions. Ask them of every vendor, including this one.

Where does the data sit, and is that a boundary or a setting? There is a large difference between a residency dropdown on a shared global system and a genuine deployment boundary with its own database, its own identity and its own keys. One is a promise about configuration and the other is a property of the architecture. What a data region actually is sets out the difference and the four follow-up questions that separate them. India is the first live Capstan region, and an Indian workspace runs in the Indian deployment rather than in a global system with a country column; the region model, including that there is no cross-region key, is described on the security page.

Who at the vendor can read our data? Every vendor has support and administration staff. The question is whether their access is standing or requested, whether it is scoped and time limited, whether the customer authorises it, and whether it is logged where the customer can see it. “Only authorised personnel” is not an answer to this question.

Which sub-processors touch employee data, and how do we hear about changes? Ask for the register and ask what notice you get before it changes. Capstan publishes its sub-processor register and its data processing agreement as pages rather than as documents you request.

What is the deletion process, and how is it evidenced? Deletion is easy to promise and hard to prove. Ask what happens to backups, how long a deletion takes to propagate, and what you receive as confirmation.

Is any employee data used to train a model? This is now a standard diligence question and it should be. Capstan’s position is that nothing scores, ranks or screens a person, and employee data does not go to an outside model or train one. That is a design position rather than a policy, and the reasoning is in HR software that keeps AI out of judging people and what should never be a model’s guess.

Evidence, and the honest gaps

Two closing points that are worth more than any checklist.

The first is that compliance is evidence. Not what your policy says, but what you can produce later: the version of the notice that was live in March, the acknowledgement with a date on it, the access log showing who opened a record, the deletion confirmation. A system where changes are effective-dated and every action lands in an append-only log the admin can export themselves turns most of these from a search into a lookup. That is why the activity log in Capstan is on every plan rather than sold as an enterprise feature, an argument made at length in the audit log is not an enterprise feature.

The second is that naming your gaps is stronger than papering over them. Capstan publishes the ISO 27001 certificate it holds with its scope and dates attached, and says plainly on the security page that there is no SOC 2 report and that certifying a management system is not a test of the product, rather than letting a badge imply more than it covers. When you answer your own customers about employee data, the same technique applies: name the control you have, name the gap, and say what you are doing about it. How to answer an HR security questionnaire covers the method, and the security questionnaire at twelve people covers the version where you have no certificates at all.

Where to start

Write the inventory. It takes an afternoon and it is the input to everything else. Then fix the notice so it describes reality, write the retention schedule, name the person who handles requests, and ask your HR vendor the five questions above.

That is a week of work, and it converts a vague sense of exposure into a short list of things that are either done or scheduled.