What Access to Employee Data Can an External Interim HR Manager Have?

The role question comes before the access question

Before anyone grants a permission, it has to be clear in which role the external processes the data. The General Data Protection Regulation provides the terms. A controller is the body that alone or jointly with others determines the purposes and means of processing. That remains your company. A processor is a body that processes personal data on behalf of the controller.

Alongside these sits a third category that fits most often in practice and is named least often. The Regulation expressly excludes from the definition of a third party those persons who, under the direct authority of the controller, are authorised to process personal data. And it obliges any person acting under the authority of the controller who has access to personal data to process those data only on instructions from the controller. The security provisions repeat the same binding rule.

For your engagement this means: an interim HR manager who is embedded in your organisation, uses your systems, runs your processes and pursues no purposes of their own typically processes the data as a person under your authority. A provider delivering a self-contained HR service on their own infrastructure, payroll being the classic example, is typically a processor and needs the contract that goes with it.

The distinction is not a formality and cuts both ways. A processor who, in breach of the Regulation, determines the purposes and means of processing is considered a controller in respect of that processing, with every obligation attached. And a missing or wrong classification surfaces at the worst moment: when a data subject requests access, or a supervisory authority asks who was working here on what legal basis.

One more thing worth separating: the data protection role does not settle the employment law question. An engagement can be perfectly clean as processing under your instructions and still carry a status risk, because work performed under instruction, determined by others and in personal dependency, constitutes an employment relationship regardless of what the contract is called. Both questions belong on the table together, not one after the other.

Evidence12345

What that means for the contract

Once the role is settled, it determines which document you need. Where processing on behalf applies, the Regulation requires a contract or other legal act in writing that binds the processor in relation to the controller. The minimum content is prescribed and cannot be negotiated away.

It covers processing only on documented instructions, confidentiality of the people involved, security measures, assistance with data subject rights, deletion or return of all data after the end of the service, and evidence of compliance. There is also an obligation on you: you may only use processors providing sufficient guarantees to implement appropriate technical and organisational measures. That is a selection duty, not a box to tick.

If instead the interim manager acts as a person under your authority, you do not need a processing agreement, but you need the same substance somewhere else: a written commitment to confidentiality and to processing only on your instructions, a documented briefing on your data protection rules, and a clear description of the task from which the necessity of each access follows.

In both cases the same standard applies to the data itself. Under German law, employee data may be processed for employment purposes where necessary for entering into, carrying out or ending the employment relationship, and applicants as well as people whose employment has ended expressly count as employees. Necessary is the word against which every single permission has to be measured.

A practical note from a head-of-people perspective: write the task down so that an outsider could derive the access from it. An engagement supporting a restructuring needs different data from one building an applicant tracking process. Describe the task only as a role, and you end up at full access by default, because nobody can argue what should be missing.

Evidence467

What access the task actually requires

The principle of data minimisation requires personal data to be adequate, relevant and limited to what is necessary in relation to the purposes of processing. Translated into permissions: access is granted per task, never per person and certainly not per job title. Full access to the personnel file is not necessary for the vast majority of interim engagements.

That is easy to demonstrate. Preparing a pay round needs compensation data and role mappings, but not written warnings and not sickness records. Building an applicant tracking process needs process data and role profiles, but not existing personnel files. Supporting a restructuring needs the social criteria for selection, but not five years of meeting notes.

A second point that permission concepts often miss: access is not one thing. Reading, editing, exporting and forwarding are separate rights, and export is the dangerous one, because it moves data out of your protected environment. When an engagement needs analysis, the better answer is almost always a pseudonymised extract rather than a full export.

And a third, regularly underestimated: specially protected data rarely sits where you expect it. Health data appears not only in medical records but in return-to-work plans, in applications for equal status and in notes on fitness for work. Release a folder wholesale and you release those too, without noticing.

So record the grant in writing, with task, systems, depth of rights and an end date. That list later becomes your evidence, because the controller has to be able to demonstrate compliance with the principles. Without it, it is one recollection against another, and the burden sits with you.

Evidence7

The technical side, short and concrete

The Regulation requires appropriate technical and organisational measures proportionate to the risk, and expressly names the pseudonymisation and encryption of personal data, the ability to ensure confidentiality, integrity, availability and resilience of systems, the ability to restore access swiftly after an incident, and a process for regularly testing the effectiveness of those measures.

For an interim engagement that translates into a handful of points you can settle in an hour. The external works with their own named account in your systems, not a shared account and not the account of the manager they are covering. They use your devices, or a device whose security posture you know. Data stays in your environment; private cloud storage and private mail accounts are out.

Logging deserves its own line. It makes sense for data protection and is delicate under employment law at the same time: technical devices designed to monitor the behaviour or performance of employees are subject to works council co-determination in Germany. So if you log access to personnel data, settle in advance how the log is evaluated and who sees it.

Finally, the record of processing activities. It has to contain the purposes, categories of data subjects and recipients, the envisaged time limits for erasure and a general description of the security measures. The exemption for organisations with fewer than 250 employees is practically never available in HR, because it falls away where processing is more than occasional or involves special categories of data. An interim engagement is a good moment to update the entry rather than forget it.

Evidence389

When the works council has a say

With external HR personnel there are two points of attachment, and they are regularly confused. The first concerns the person: if they are integrated into the establishment, this is an engagement in the sense of the Works Constitution Act, and the Betriebsrat, the elected works council, must be informed beforehand and given the required application documents. It can refuse consent on six statutory grounds, in writing and within one week, otherwise consent is deemed given.

Whether integration exists does not depend on the contract. The Federal Labour Court held on 23 September 2025 that it requires at least a partial right of instruction typical of an employment contract, covering content, place and time of the work. Merely working on the premises under a service or works contract is not enough.

The second point concerns the systems. As soon as a technical device is introduced or used differently for the engagement, and that device is designed to monitor behaviour or performance, co-determination applies. That rarely concerns the HR system itself and more often the new reporting created during the engagement, for instance on absence or processing times.

Here the two threads connect, and this is the part many engagements miss: the more clearly you shape the mandate as a self-contained service without instruction, the less likely a co-determined engagement exists, but the more likely you need a processing agreement. The more you embed the person, the simpler the data protection role and the greater the employment law duty to check.

And one construction to assess separately: if a provider supplies you with their own employees whom you deploy like your own staff, that is temporary agency work. It requires a licence in Germany, and the same agency worker may not be supplied to the same hirer for longer than 18 consecutive months, unless collective or works agreements provide otherwise.

Evidence1011129

When something goes wrong

A data breach does not respect contractual constructions. If the external loses a device, sends a list to the wrong distribution group or files an analysis in the open by mistake, the same clock runs as for any internal incident: notification to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals.

Where processing on behalf applies, the processor must notify the controller without undue delay. That is why the reporting path belongs in the contract, with a contact point and its availability. Settle who to call only once it happens, and you burn half of the 72 hours on that question alone.

On liability: a processor is liable for the damage caused by processing only where it has not complied with obligations specifically directed to processors, or where it has acted outside or contrary to lawful instructions of the controller. Towards the data subject, each party involved is liable for the entire damage so that effective compensation is ensured. Settling between the parties comes afterwards.

And the order of magnitude that tends to end internal debates quickly: infringements of the obligations of controllers and processors can draw up to 10 million euro or 2 per cent of total worldwide annual turnover, infringements of the processing principles and of data subject rights up to 20 million euro or 4 per cent, whichever is higher in each case.

None of that is an argument against external support. It is an argument for actually investing the half hour of preparation, because that half hour is what later separates a documented incident from an unexplained one.

Evidence131415

The first ten working days, in the right order

When an engagement starts at short notice, and most of them do, a fixed order helps more than a complete concept. The sequence below works because it puts each decision where it belongs and still makes the external productive from day one.

The core is that the task exists in writing first. Everything else follows from it almost by itself: the data required, the depth of rights, the co-determination question, the duration of the permission. Start with the permission and you are working backwards, justifying afterwards.

One detail from practice that fails surprisingly often: the removal date belongs on the same line as the grant. Permissions that do not expire automatically at the end of the engagement routinely outlive it by months, because nobody owns the task. It is the most common finding in internal audits and one of the easiest to avoid.

Evidence47

The three most common mistakes

The first mistake is full access out of convenience. It comes from time pressure rather than intent: the task is vague, so the person gets everything to avoid daily requests. The result is a permission nobody can justify and documentation that works against you in an audit.

The second mistake is a construction built on feel. A service contract gets signed, the collaboration then runs like an employment relationship, and the data protection role stays unsettled because formally an external provider is at work. In case of doubt what counts is lived practice, not the heading on the paper, and that holds in both areas of law.

The third mistake is the missing end. The engagement finishes, the handover happens, and the access stays. Sometimes because an extension is in the air, usually because nobody scheduled the removal. This is the case supervisory authorities and internal audit find fastest, because it shows up in every permissions report.

All three share a cause: the access question gets treated as a technical task rather than as part of the engagement. Move it back where it belongs, into the agreement about the mandate, and you solve it once instead of renegotiating it weekly.