GDPR and employee data, for HR teams

If any of your people are in the EU or the UK, the data you hold to employ them falls under the General Data Protection Regulation, and you, the employer, are the one accountable for it. This guide is the EU counterpart to the note on India’s DPDP Act: it works through what GDPR actually asks of an HR team handling employee records, and, just as importantly, where the common misreadings send people wrong.

It is a conceptual map, not legal advice. It states no article number, no fine figure, and no deadline, because a compliance position taken from a marketing page is not a compliance position. Confirm the specifics with counsel who knows your jurisdictions. What this guide gives you is the shape of the obligations and a short list of things that are either done or scheduled.

Lawful basis: consent is the wrong default

The most common mistake is to treat GDPR as a consent regime and start collecting tick boxes from employees. For most HR processing that is both unnecessary and unwise.

Consent has to be freely given, and inside an employment relationship the power imbalance means it rarely is. An employee asked to consent to being paid is not consenting in any meaningful sense, and consent can be withdrawn, which would leave you unable to run basic HR. So consent is the wrong basis for the ordinary run of the work.

The bases you actually rely on are others. Paying people and administering their contract rest on the performance of the employment contract. Tax withholding, statutory filings, and mandated record-keeping rest on your legal obligations. Parts of running the business rest on legitimate interests, which you weigh against the employee’s rights and document. Special categories of data, health information for sick leave or accommodations being the usual one, need an additional condition on top of the basis, and deserve particular care. Consent comes back only at the genuine edges, where processing is truly optional and refusing it costs the employee nothing. Draw that boundary deliberately, and take advice on where your specific activities fall.

Controller and processor: the split that decides accountability

GDPR splits the world into controllers and processors, and getting your own position straight is the foundation for everything else.

As the employer you are the controller. You decide what employee data is collected, why, and what happens to it. That makes you the one primarily accountable for meeting GDPR, for having a basis, for honouring rights, for security, for retention.

An HR software vendor that holds and processes that data on your instructions is a processor. It acts on your documented instructions and does not decide the purposes of the processing for itself. A processor has real duties of its own, but it does not take your accountability off your shoulders.

This is the split people most want to escape, so it is worth saying plainly: choosing a vendor that is based in the EU, or that holds a security certificate, does not make you GDPR compliant. Those things can make a processor easier to justify. They do not move the controller’s duty. You remain accountable for your own processing whoever you run it on.

Employee rights, including the last-day problem

Employees are data subjects, and the rights GDPR gives data subjects apply to them at work. In practice you need to be able to handle:

• Access. An employee can ask what personal data you hold about them and get a copy.
• Rectification. They can have inaccurate data corrected.
• Erasure, restriction, portability, and objection. These apply depending on the lawful basis and the circumstances, and are not absolute, retained records you are legally required to keep are the obvious limit.

Two practical points matter more than the list. First, you need a named route for these requests and a person who owns it, and you need to know in advance where the data would have to be gathered from, which is why a data inventory is the first thing to build. Second, the right of access does not end when someone’s work email is switched off. A former employee asking for a copy of their own payslip in three years is exercising a live right, and the usual answer, a colleague digging through an archive, is slow and means a second person sees the data. The pillar guide on HR data security covers the better shape: a surface built for a former employee to reach their own records.

Retention: the rule people get backwards

There is a strong instinct that deleting data quickly is good practice under GDPR. For employee data that instinct is often wrong.

GDPR asks you to keep personal data no longer than is necessary for the purpose. But employment, pay, and tax law commonly require you to keep certain records for years after someone leaves. Those two pull in the same direction more than it first appears: the retention period is set by the obligation, and holding the record for exactly that long is what “necessary” means here. Deleting a leaver’s record early is not clean hygiene, it can be a breach of a different law.

What good looks like is a written retention schedule: each category of employee record, the period you keep it, and the source of the obligation for that period. Then you apply it, so deletion becomes a scheduled act rather than a response to a request or an oversight. Put reviewing the schedule in your HR compliance calendar.

Security: appropriate to the risk

GDPR requires security appropriate to the risk, and employee data sits at the high end of that risk, because a single record often carries salary, a national identity number, bank details, home address, and dependants. That is the full kit for identity theft and payroll fraud, about a person who had no choice but to hand it over.

The regulation does not prescribe specific controls, but the ones the pillar guide sets out are what “appropriate” tends to mean in practice: encryption at rest where the database cannot decrypt its own contents, tenant isolation enforced below the application, access that denies by default including for the vendor’s own staff, and export and deletion you can actually exercise. A breach of employee data is frequently a reportable event with a tight deadline, which is another reason the bar is higher here than for ordinary business data.

International transfers

GDPR restricts sending personal data outside the EU or UK unless the destination provides adequate protection or you put an approved safeguard in place. For an HR team this is mostly a question about your vendors and their sub-processors: where does the data physically rest, and does anything move it out of the region?

The cleanest answer is a system that keeps the data in the EU and is honest about anywhere it goes. Ask each vendor where employee data sits, whether that is a genuine deployment boundary or a setting on a shared global system, and which sub-processors touch the data and in which countries. A residency promise you cannot verify is not a transfer safeguard.

What to ask an HR vendor, and reading the answers honestly

Because your processors are usually the largest concentration of employee data you hold, vendor diligence is a real part of your own GDPR position. The pillar guide and the DPDP guide both carry the five-question version; the same questions apply under GDPR. Where does the data sit, and is that a boundary or a setting? Who at the vendor can read it, under what authorisation, and is it logged? Which sub-processors touch it, and how do you hear about changes? What is the deletion process, and how is it evidenced? Is any employee data used to train a model?

Read the answers the way the pillar guide describes: separate what a vendor holds today from what it has genuinely commissioned and what is only an intention, and be especially careful with the word “compliant”. A vendor cannot make you GDPR compliant, and a vendor that implies it can is overselling. A certificate is a signal about a specific scope, not a GDPR attestation, and you should ask what it actually covers.

Where Capstan fits, stated modestly

It would be dishonest to write this guide and imply Capstan solves GDPR for you, so here is the accurate version.

Capstan is not GDPR compliant, and has no near-term plan to claim it. GDPR compliance is the controller’s responsibility, which is to say yours, and no vendor discharges it. What Capstan can say about its own role is narrower and more useful than a compliance badge:

• It is a processor acting on your instructions. It does not decide the purposes of your employee data, and being a processor does not move your accountability as controller.
• It runs from one self-contained EU region, with data resident in Frankfurt (eu-central-1) and compute in Amsterdam (eu-west-1). That is a property of where the deployment is, and it can help you reason about transfers, but it is not by itself a compliance claim.
• Support access is consent-gated: staff have no standing access to your data, and helping you needs a consent you grant that is scoped, time-limited, revocable, and logged where you can see it.
• Sensitive fields use per-tenant envelope encryption (AES-256-GCM), so a raw database dump is ciphertext rather than readable records.
• The entity behind Capstan, N53 Techworks LLP, holds an ISO/IEC 27001:2022 certificate for its information-security management system, published with its number, dates, and scope on the security page. That is an information-security management-system certificate, not a GDPR attestation and not a test of the product, and its scope is published beside it so the limit is visible.

Assess Capstan as you would any processor, against your own obligations, and take your GDPR position from counsel rather than from any vendor’s page, this one included.

Where to start

Write the data inventory first: every system that holds employee personal data, what it holds, who can see it, and which vendor is behind it. From that, fix the employee privacy notice so it describes the systems you actually use, settle your lawful basis for each kind of processing, write the retention schedule, name the person who handles employee requests, and run the vendor questions above over anyone who touches the data. If your workforce spans India as well, the DPDP guide is the counterpart to this one, and how to answer an HR security questionnaire covers the method for saying all of this out loud to your own customers.

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