Short answer
People analytics is GDPR-ready only when a specific use can be justified and operated with evidence. Define the decision and controller, choose and document the lawful basis, minimise the data, explain the use to employees, control access and retention, test identification and automation risks, verify suppliers and transfers, and keep accountable human review. A vendor label or hosting location cannot complete that work for you.
Treat compliance as a use-case decision
“GDPR-compliant platform” is too broad to evaluate. The same tool may support a limited, transparent onboarding study and also enable an excessive monitoring design. The data controller remains responsible for why and how personal data is used; a processor must act within documented instructions and its contract.
Start with one sentence:
We use [defined data] from [defined population] to support [specific decision], for [named audience], for [retention period].
If the sentence cannot be completed, procurement is premature. The European Commission's GDPR principles overview puts purpose limitation, data minimisation, accuracy, storage limitation, security, transparency, and accountability at the centre of processing.
Complete this evaluation card
Use the card for each listening, reporting, or analytics purpose. Do not approve a product once and assume every future use inherits the decision.
| Field | Evidence to record |
|---|---|
| Decision and purpose | The organisational decision, why employee data is necessary, and uses that are outside scope |
| Controller and processor roles | Which entity determines purpose and means; which suppliers act on documented instructions |
| Population | Who is included, excluded, or likely to be indirectly affected |
| Data map | Source fields, free text, inferred fields, identifiers, destinations, subprocessors, and return flows |
| Lawful basis | Article 6 basis; any Article 9 condition for special-category data; local employment-law requirements |
| Necessity and proportionality | A less intrusive alternative considered and why each retained field changes the decision |
| Transparency | What employees are told about purpose, sources, recipients, retention, rights, and consequences |
| Access | Roles that can see source material, excerpts, themes, aggregates, and exports |
| Retention | Deletion or review point for each data layer, including backups and derived outputs |
| Identification risk | Small groups, rare attributes, linked records, repeated releases, free text, and external knowledge |
| Automated processing | What the system produces, its limits, the human review point, and how a person can challenge an error |
| Supplier evidence | Contract terms, security measures, subprocessor list, locations, transfer mechanism, audit material, and incident duties |
| DPIA decision | Screening outcome, risks, mitigations, owner, approval, and review trigger |
| Rights workflow | How access, correction, restriction, objection, and deletion requests reach every relevant system |
This is an evaluation aid, not a substitute for legal advice in the countries where employees work.
Test purpose, lawful basis, and necessity together
A broad purpose such as “improve employee experience” cannot show which data is necessary. “Identify where first-week access delays occur so the onboarding owner can test a revised handoff” is specific enough to challenge each input.
The GDPR text requires a lawful basis under Article 6 and additional conditions when Article 9 special-category data is processed. It also requires data protection by design and by default under Article 25 and a data protection impact assessment under Article 35 where processing is likely to create high risk.
Do not assume employee consent is the safest route. In employment, a power imbalance can make a refusal feel costly. The appropriate basis depends on purpose, jurisdiction, relationship, and safeguards. Record the analysis with the organisation's data protection or legal owner before collection; do not search for a basis after results arrive.
For every proposed field, ask:
- What part of the defined decision uses it?
- Would a less precise field work?
- Could the question be asked directly instead of inferred from behaviour?
- Could the analysis work without identifying the person?
- What harm could follow if the field, combination, or output reached the wrong audience?
Map source data and derived data
People analytics rarely ends with the fields imported. A conversation may produce a transcript, summary, theme, quotation, category, reviewer note, and aggregate. Each layer needs a purpose, audience, retention rule, and correction path.
Pseudonymisation can be a useful safeguard when identifying information is separated and controlled. GDPR Article 4(5) defines it by reference to additional information kept separately under technical and organisational measures. Recital 26 says data that could be attributed to a person through additional information should still be considered personal data, while identifiability must take account of means reasonably likely to be used by the controller or another person. Apply that assessment to each holder and disclosure context instead of assuming one status for every recipient.
Aggregation also needs testing. A team average based on five respondents may still be identifying when readers know who was present, can compare successive reports, or see a recognizable quotation. Use the HR reporting-threshold worksheet to assess the complete release rather than treating one minimum group size as an anonymity guarantee.
Worked example: minimise an onboarding analysis
This fictional organisation wants to decide whether to change its first-week equipment handoff. Sixty employees were eligible during the quarter.
The first draft asks the platform to combine:
- employee name and email;
- manager, site, team, role, and exact start date;
- device delivery timestamp;
- help-desk tickets;
- free-text conversation responses;
- absence history and performance rating; and
- a model-generated “flight risk” label.
The evaluation card exposes the mismatch. Absence, performance, and a departure label do not answer the handoff question. Exact dates and narrow role-team combinations increase identification risk. The analyst revises the design:
- define the outcome as handoff stage completed by the agreed checkpoint, rather than an employee score;
- retain delivery events and a coarser journey stage where sufficient;
- collect a short, explained conversation about the handoff experience;
- remove absence, performance, and inferred departure fields;
- restrict source responses to the authorised research team;
- give the decision owner reviewed themes and appropriately grouped process findings;
- review free text for identifiable events before quoting it;
- set separate retention rules for contact data, source responses, coded evidence, and final findings; and
- record missing groups and uncertainty instead of filling gaps with inference.
The revision may be easier to justify because every remaining field has a job. It is not automatically compliant: the organisation still needs the correct lawful basis, transparency, security, contracts, rights process, and jurisdiction-specific review.
Verify the supplier and the operating configuration
Ask for evidence, then connect it to the proposed data flow.
Roles and instructions. Identify controller, joint-controller, and processor roles for each stage. The ICO's processor-contract guidance covers documented instructions, confidentiality, security measures, subprocessors, assistance, deletion or return, and audit information.
Locations and transfers. “EU hosted” does not describe support access, subprocessors, backups, or onward transfers. Map where data is stored and remotely accessed, then verify the relevant mechanism. The ICO's international-transfer guide was updated in January 2026 and distinguishes adequacy, appropriate safeguards, and limited exceptions for UK restricted transfers.
Security and incidents. Request security controls that match the data and risk: authentication, role access, logging, encryption, resilience, testing, deletion, incident response, and notification duties. A certificate can support due diligence; it does not answer whether your configuration is necessary or fair.
Rights and correction. Walk through a realistic request. Can the organisation locate source material and derived records, explain the use, correct an error, apply a valid restriction or deletion decision, and propagate the outcome where required?
Give extra scrutiny to employment monitoring and AI
Employee analytics can affect people who have limited practical choice. The ICO's current worker-monitoring guidance advises employers to define purpose, assess necessity and fairness, inform workers, minimise information, set retention, secure it, and perform a DPIA before high-risk processing. The ICO notes that this guidance is under review after the UK Data (Use and Access) Act, so UK programmes should check its status at the time of implementation.
If AI helps organise or summarise evidence, record the permitted sources, tests, material error modes, reviewer authority, and stop rules. Keep source statements separate from generated interpretations. Do not turn conversational data into hidden individual performance, potential, or departure scores. The ethical AI in HR method provides a practical test and review record.
Evaluate Lontra in the same way
Lontra supports defined employee conversations, manager briefs, and aggregate reporting for HR. Managers do not receive raw employee responses. HR aggregate displays use a minimum group of five respondents; that display rule is not an anonymity guarantee.
Use the evaluation card to verify the exact planned configuration and contract: purposes, roles, notices, data fields, source access, retention, subprocessors, locations, transfer arrangements, security evidence, rights support, and the organisation's human decision process. Those facts determine whether a particular deployment fits the controller's obligations. This article does not assert that any deployment is GDPR compliant by default.
Explore Lontra's employee-conversation workflow and bring a completed use-case card to the product and privacy review.
Frequently asked questions
Can a people analytics vendor be GDPR compliant on its own?
A vendor can provide relevant safeguards and contractual commitments, but compliance depends on the specific purpose, data, roles, configuration, notices, lawful basis, retention, access, transfers and operating decisions of the organisations involved.
Is employee consent always the right lawful basis?
No. Employment power imbalances can make freely given consent difficult to establish. The controller should document the lawful basis appropriate to the purpose and jurisdiction, plus any special-category condition, with its legal or data protection adviser.
Does aggregating employee data take it outside GDPR?
Not automatically. Creating an aggregate is processing, and the output may remain personal data if people can be identified directly or indirectly. Assess small groups, linked data, successive releases, text and reader knowledge.