System in use

Introducing an HR management system

In data protection terms an HR management system is only as good as its access model. What decides lawfulness is who can see which data and which analyses are possible, and both sit in the system rather than in the contract.

Access is granted, its extent unexamined

The new system is set up, the data has been migrated, access has been granted. Managers see the master data of their department, together with absences and their reason. The report on absence figures sits in the reporting menu and can be drilled down to the individual.

The access model is the real assessment

Who may see which data in the system is the question a data protection review of an HR system turns on. Section 26(1) BDSG permits processing only in so far as it is necessary for the employment relationship, and that necessity has to be determined per role and per data field.

Necessary for whom, and for what

Merkmal	HR department	Line manager	Parent company
Master data	Necessary	In partName, function, contact details. Not marital status, religion, bank details.	RarelyReporting works with an identifier and without a name.
Absences	With the reasonFor continued pay and for social security reporting.	Without the reasonStaffing plans need the fact of absence, nothing more.	Not personal
Health data	Narrowly limitedOnly the named access group, section 22(2) sentence 2 no. 5 BDSG.	No	No
Performance data	On a triggerFor a live matter, not as a standing right.	As agreedWithout a framework there is no basis for the access.	AggregatedAnd only where the aggregation rules out tracing back.

The row on absences is the most common finding. Staffing plans need the fact and not the reason, and a system showing both in the same view breaches the data minimisation principle in Art. 5(1)(c) GDPR.

Four recurring findings in access models

The reason for an absence is generally visible

The most common finding. The system shows absence and reason in the same view, because the vendor’s default provides for it.

The role follows the hierarchy and not the task

Whoever sits higher up sees more. Necessity under section 26(1) BDSG, however, follows the task, and a division head needs no more fields for planning than a team lead.

Deputy rights survive the period of deputising

A right is granted for a holiday stand-in and not withdrawn afterwards. After two years a substantial share of managers can see data they never needed.

Export rights are not governed

Whoever can export a view holds the data set. An access model that governs only views is therefore incomplete.

Art. 25(2) GDPR requires data protection by default and names accessibility expressly. A vendor’s default is designed for functionality and not for data minimisation, so adjusting it is part of the roll-out.

A metric turns into monitoring once it can be resolved

When a metric turns into behavioural monitoring is decided not by its presentation but by whether it can be resolved. For section 87(1) no. 6 BetrVG the Federal Labour Court has held that monitoring generally presupposes that the data can be attributed to individual employees.

Three levels of reporting

Personal
The report names people or identifiers. It is processing of employee data and needs a legal basis and a framework.
Aggregated with drill-down
The view shows group figures and allows the step to the individual. In law that is the same as the first level, because attribution remains possible.
Aggregated without tracing back
Only here does the personal reference end, and only where the group is large enough. Under the case law, pressure on a small group reaches its members.

3 von 3

For co-determination, intention is beside the point. A system that technically masters the second level is objectively suitable for monitoring, even where nobody uses the function.

In a group, every company is an entity of its own

What a group-wide roll-out requires in addition follows from Art. 4(7) GDPR. The controller is the individual entity. A group is not one, and a single system therefore breaks down into several processing activities each with its own role.

Four points to settle before a group-wide roll-out

Which company is controller for which processing in the system, per processing activity and not per company
In what role the operating company acts, usually as a processor under Art. 28 GDPR
What the transfer to the parent rests on, and where the balancing is documented
Which level of aggregation the parent’s reporting reaches, and whether it rules out tracing back

There is no group privilege. Recital 48 GDPR merely acknowledges that a legitimate interest in transmitting data for internal administrative purposes may exist, and that is a possible legal basis under Art. 6(1)(f) GDPR and not a merger of roles.

How we support you with your project

A roll-out needs three documents, and all three come before access is granted. An access model naming the data fields per role. An impact assessment wherever performance data is evaluated. And a works agreement setting the framework for reporting.

The employment law side lies outside data protection law. Negotiating the agreement, involvement under section 90 BetrVG at the planning stage and the admissibility of a report in an individual case run through the affiliated law firm.

Frequently asked questions

May managers see all data about their staff?

Only in so far as it is necessary for their task, section 26(1) BDSG. Holiday planning needs absences and not their reason, and an annual review needs no sickness records. Necessity has to be determined per data field and per role, not per person.

Are aggregated metrics unproblematic?

Only as long as they cannot be traced back to individual employees. A metric covering a group of three is not aggregation, and a report with a drill-down function is personal from the outset.

Does a group-wide system need its own legal basis?

For every transfer between two companies, yes. There is no group privilege. Recital 48 GDPR acknowledges that a legitimate interest in transmitting data for internal administrative purposes may exist, and the balancing has to be documented.

Is an impact assessment required?

Regularly yes, as soon as the system evaluates performance data or produces ratings. Art. 35(3)(a) GDPR names systematic and extensive evaluation of personal aspects as a standard case. Even without that feature, the number of data subjects speaks for an assessment.

Get in touch!

Have we sparked your interest? Do you have questions? Would you like a quote without obligation? We look forward to hearing from you!

Alternatively you can request a call back.