HR modules in your ERP process some of the most sensitive data imaginable every single day: salaries, sick leave, performance reviews, biometric clock-ins, disciplinary records. And in many organisations, this data is also the least scrutinised from a GDPR perspective. The payroll system “works”, HR managers have their logins, and the Data Protection Officer rarely gets involved in that part of the estate.
That is precisely where the most serious compliance risks concentrate. HR data falls under Article 9 of the GDPR — special category data — for several sub-categories (health data, biometric data, trade union membership). Processing these carries strict obligations, and their presence in a centralised ERP adds several layers of risk.
This article examines five concrete risks specific to HR and payroll modules, covering for each: why it is a GDPR problem, a common real-world mistake, and the remediation to apply. It complements our general guide to ERP and GDPR compliance which covers the foundational regulatory requirements.
Risk 1: Biometrics for Attendance Tracking
Why this is a GDPR problem
A growing number of organisations connect their HR module to biometric clocking terminals: fingerprint readers, facial recognition, vein recognition. These devices integrate natively with ERPs such as SAP SuccessFactors, Sage Business Cloud, or Workday through third-party modules. The issue: biometric data is explicitly listed as a special category under Article 9 of the GDPR, on par with health data or trade union affiliations.
Supervisory authorities across Europe consistently rule that employee consent cannot serve as the legal basis here, since it cannot be freely given within an employment relationship. The organisation must therefore demonstrate an absolute necessity, backed by documentation — typically a collective agreement or other recognised legal basis.
The common mistake
An ERP configured to “sync clock-in data” from a biometric terminal without the DPO or legal team ever verifying that a valid legal basis exists. The device has been running for years; nobody questioned it.
The remediation
Audit every biometric device connected to your HR ERP:
- Is the legal basis documented and valid? (Not consent — absolute necessity or a collective agreement with an explicit derogation)
- Is the processing registered in the Records of Processing Activities (RPA) with a “special category” flag?
- Have employees been informed via a legal notice in the staff handbook or employment contract?
- Does a less intrusive alternative exist that achieves the same objective (NFC badge, PIN code)?
If you cannot answer yes to all four questions, your biometric device carries a high risk of regulatory enforcement.
Risk 2: Retention Periods for Payroll Data
Why this is a GDPR problem
The storage limitation principle in Article 5(1)(e) GDPR requires that personal data be kept in a form permitting identification for no longer than necessary for the purposes for which it is processed. In payroll and HR, several retention periods coexist:
| Data type | Typical legal retention period (employment law) |
|---|---|
| Payslips | 5 years after employment ends |
| Sick leave documentation | 5 years after employment ends |
| Annual performance reviews | 2–3 years (ICO/CNIL guidance) |
| Training records | 5 years |
| Closed disciplinary file | Maximum 3 years |
The common mistake
A former employee who left eight years ago whose payslips, absences (with reasons), performance reviews and expense claims are still active and searchable in the ERP. Nobody ever configured a purge rule. The ERP “keeps everything” by default — often by design from vendors who want full accounting traceability — but that conflicts directly with GDPR.
The remediation
A sound architecture separates HR data in the ERP into three states:
- Active data: employee in post, data accessible to authorised users
- Archived data: employee has left, read-only, access restricted to HR leadership and legal counsel for the legally required retention period
- Deleted data: effective purge once the retention period expires
Check whether your ERP supports configuring automatic purge rules per data type. If this is not native, require it from your vendor or implementation partner as a compliance configuration — not a custom development.
Risk 3: Automated Profiling of Employees
Why this is a GDPR problem
AI-powered HR modules are proliferating: turnover prediction, performance scoring, early absenteeism detection, training recommendations. These features constitute automated profiling under Article 22 GDPR. Where a decision producing “legal effects” or “similarly significantly affecting” an individual is based solely or substantially on automated processing, specific obligations apply: a strengthened legal basis, the right to object, and an obligation to inform.
A dismissal, non-renewal of contract, or even a bonus allocation based on an automatically computed score falls squarely within this framework.
The common mistake
An ERP automatically generates a “flight risk” score for each employee based on activity, absence, and performance data. This score is visible to HR business partners in a dashboard. An employee with a high score does not have their contract renewed. Nobody informed the employee that this scoring existed, or of their right to object.
The remediation
For every AI or analytics module in your HR ERP:
- Document the algorithm in the RPA, including the description of input variables
- Verify whether the processing triggers a mandatory Data Protection Impact Assessment (DPIA, Article 35 GDPR): employee profiling typically does
- Establish a documented human-in-the-loop: every significant HR decision must involve an explicit human validation step, not just a confirmation click
- Inform employees through the staff handbook or HR policy of the existence of scoring tools and their right to object
Risk 4: Excessive Manager Access to HR Data
Why this is a GDPR problem
In many ERP deployments, line managers have access to a far broader data scope than their role requires. The cause is usually technical: RBAC (Role-Based Access Control) configuration was done quickly, replicating habits from the previous system, without rethinking access granularity.
The result: a line manager can see in the ERP the individual salaries of their entire team (information they are not supposed to hold individually), the details of sick leave including sometimes coded medical reasons, and historical performance reviews going back several years. The medical reason for a sick leave is health data — a special category under Article 9 GDPR — and access must be strictly limited.
The common mistake
Workday or SAP SuccessFactors misconfigured: the “Manager” role includes read access to team payslips and coded sick leave reasons. In a team of thirty, the manager can reconstruct the medical context of multiple colleagues. In the event of a regulatory audit or employment tribunal, this access can be cited as a violation.
The remediation
Conduct a full access rights audit across your HR ERP. For each role (line manager, HR business partner, CFO, HR coordinator, employee), document:
- Which data is accessible in read and write modes
- The functional justification for each access right
- Whether special category data falls within the scope
Then apply the principle of least privilege: a manager sees their team’s absence dates (necessary for operational planning), not the medical reason (reserved for HR leadership). The separation must be configured in the ERP — not just stated in a policy.
Risk 5: Data Transfers to Sub-Processors and SaaS Vendors Outside the EU
Why this is a GDPR problem
The majority of leading SaaS HR ERP vendors are American or operate global infrastructure: SAP SuccessFactors, Workday, Oracle HCM, ADP. Even when a vendor offers an “EU data residency” option, support teams, development teams, or technical sub-processors may access data from countries outside the EU. Those accesses constitute international transfers under Chapter V GDPR, subject to specific safeguards.
Since the EU-US Privacy Shield was invalidated in 2020 and the EU-US Data Privacy Framework was adopted in 2023, the legal landscape has shifted — but documentation requirements have not diminished. Every transfer outside the EU (including to the US under the Data Privacy Framework) must be documented, and a Transfer Impact Assessment (TIA) is recommended for transfers to countries without an adequacy decision.
The common mistake
Payroll data for European employees stored on AWS servers in Virginia, accessed by the vendor’s support team based in another continent. The company signed the vendor’s standard terms and conditions but never verified whether a GDPR-compliant Data Processing Agreement (DPA) is in place, whether Standard Contractual Clauses (SCCs) cover the transfers, or whether a TIA was conducted.
The remediation
For each vendor or sub-processor hosting or accessing your HR data:
- Require and retain a signed DPA (mandatory, Article 28 GDPR)
- Verify that the European Commission’s 2021 SCCs are appended to the contract for transfers outside the EU
- Conduct or request a documented TIA for countries without an adequacy decision
- Check whether your vendor offers an “EU-only access” option for support: Workday and SAP offer these contractual restrictions on request
- Keep your list of HR sub-processors up to date in the RPA, with the country of processing and applicable legal safeguard noted for each
DPO Checklist: Auditing Your HR ERP
Fifteen quick checkpoints to run through with your team:
- RPA: Does the HR module appear with all its sub-processes, including special category data?
- Legal basis: Identified and documented for every processing activity (employment contract, legal obligation, legitimate interest)?
- Biometrics: Valid specific legal basis + employee information?
- Retention periods: Configured and automated in the ERP, with a clear active / archived / deleted distinction?
- Access rights: Audited on the least-privilege principle, with separation between operational and sensitive data?
- Health data: Access restricted to HR leadership only; medical reasons invisible to line managers?
- DPIA: Completed for high-risk processing (biometrics, AI profiling, employee scoring)?
- Employee information: Legal notices present in the staff handbook or HR charter?
- Sub-processor DPAs: Signed with the ERP vendor and every sub-processor with access to HR data?
- International transfers: SCCs or adequacy decision in place, plus documented TIA?
- Data subject rights: Process defined for access, rectification and erasure requests, including for former employees?
- Audit logging: Are accesses to sensitive data logged within the ERP?
- Incident response plan: 72-hour supervisory authority notification procedure (Article 33 GDPR) in place for HR data breaches?
- Annual review: Are the RPA and access rights reviewed at least once a year?
- Training: Have HR and payroll users received GDPR compliance training specific to their role?
If you answer “no” or “unsure” to more than five of these points, your HR ERP presents a serious compliance risk. Supervisory authorities regularly audit HR data perimeters — either following an employee complaint or a scheduled inspection — and the processing of employee personal data has been a priority enforcement area across Europe in recent years.
For the broader picture, read our complete guide to ERP and GDPR compliance covering the general obligations of the data controller and how to audit customer and supplier data in your ERP. If you are weighing an integrated HRMS within your ERP against a dedicated HR platform, our comparison ERP HR/payroll: integrated HRMS vs dedicated module walks through the trade-offs, including data sovereignty considerations.
