Controller or processor? GDPR roles for agencies

Under the GDPR, a recruitment agency is almost always an independent controller of the candidate data in its own database, because it decides the purposes and the means of processing under Article 4(7), so it rarely qualifies as a mere processor working on a client’s instructions. Getting this role wrong puts you on the wrong contract and the wrong side of liability.

This article is practitioner guidance, not legal advice. National implementations differ; confirm specifics for your market with counsel.

Is a recruitment agency a controller or a processor?

A recruitment agency is normally a controller, not a processor, for the candidate data it sources and holds. The test in Article 4(7) of the GDPR is who determines the purposes and the means of processing. When an agency decides which candidates to attract, how to store and rank them, which roles to pitch them for, and how long to keep them, it is making those decisions, so it is the controller.

A processor, by contrast, acts only on a controller’s documented instructions and has no independent purpose of its own. The European Data Protection Board’s Guidelines 07/2020 on the concepts of controller and processor (final version 2.0, adopted 7 July 2021) is explicit that the role follows the factual reality of who decides, not the label in a contract. The ICO’s recruitment guidance lands in the same place: an agency that builds and runs its own talent pool is a controller for that data.

There are narrow exceptions. If a client hands you its own applicant inbox to triage strictly under its instructions, with no freedom to reuse those candidates for other roles, you may genuinely be processing on the client’s behalf. That is processor work. It is the unusual case, not the default. For how long you can lawfully hold a candidate’s data once you are the controller, see our guide on candidate data retention.

What is the difference between a controller, a processor, and joint controllers?

The three roles map to three different relationships, three different contracts, and three different liability profiles.

Role	Who decides purposes and means	Typical recruitment example	Required instrument
Independent (separate) controller	Each party decides for its own processing	Agency sources candidates from its pool and submits a shortlist to a client	Controller-to-controller arrangement (good practice, not always mandatory)
Joint controllers	Two parties decide jointly for the same processing	Agency and client co-run an assessment centre or share a candidate platform they jointly configure	Article 26 arrangement, essence made available to candidates
Processor	One party acts only on the other’s documented instructions	Agency triages a client’s own applicant inbox with no reuse rights	Article 28 data processing agreement (mandatory)

The trap is signing a processor agreement out of habit when you are actually a separate controller. The EDPB warns that you might believe you have a processor relationship while the facts make you a controller, and the contract cannot rewrite reality.

Does an agency need a data processing agreement (Article 28) with its client?

For ordinary candidate submissions, usually no. An Article 28 data processing agreement is mandatory only when one party is genuinely processing on behalf of the other. Article 28(3) of the GDPR lists what that contract must contain, including the duty to act only on documented instructions, confidentiality of staff, assistance with data subject rights, deletion or return of data at the end, and submitting to audits.

When an agency sources candidates from its own database and presents them to a client, neither party is taking instructions from the other in the processor sense. The agency processes to run its business and maintain its pool; the client processes to assess and hire. Their purposes are linked but not identical, which makes them separate controllers. Forcing a DPA onto that relationship misdescribes both parties and creates obligations (such as the agency promising to act only on the client’s instructions) that neither side actually honours.

The right instrument for separate controllers is a controller-to-controller data sharing arrangement. It is not strictly mandated by the GDPR the way an Article 28 contract is, but it is strongly advisable: it sets out lawful basis on each side, who answers candidate requests, retention, security, and breach notification. Getting these roles right is one part of the wider GDPR picture, which we map in the GDPR guide for recruiters.

When are an agency and its client joint controllers under Article 26?

Joint control under Article 26 of the GDPR applies only when the agency and the client jointly determine the purposes and means of the same processing operation. That is a higher bar than simply sharing data. Most CV submissions do not meet it: the agency decides its sourcing, the client decides its selection, and they exchange data across that line as two controllers.

Joint control does arise in specific moments. If an agency and a client co-design and jointly run an assessment day, or operate a shared candidate platform whose configuration they decide together, they may be joint controllers for that activity. Where Article 26 applies, three things follow:

1. You must agree, in a transparent arrangement, who is responsible for each obligation, in particular candidate rights requests and the transparency notices under Articles 13 and 14.
2. The essence of that arrangement must be made available to the candidate, so they know how responsibilities are split.
3. Candidates can exercise their rights against either controller regardless of what the arrangement says between you.

Joint control is not a tidier default. It is a specific finding for a specific shared operation, and it should be diagnosed activity by activity rather than declared across the whole relationship.

What happens at the candidate submission and handover moment?

The submission is where the roles are most often confused, and where the data actually changes hands. Before submission, the agency is a controller of a candidate in its pool. At submission, it discloses that candidate to the client, who becomes a controller of the same data for its own hiring purpose. This is a controller-to-controller disclosure, not a processor handing data back to its controller.

Two practical duties attach to that moment:

1. Lawful basis on each side. Sharing a candidate’s CV for a live, relevant vacancy is commonly justified on legitimate interests under Article 6(1)(f), as the ICO recognises for candidates who have made a CV available, but the legitimate interests assessment is each controller’s own to make and document.
2. Transparency. The candidate should be able to understand that their data has been shared with a named client, on what basis, and how to exercise their rights against that client. A controller who hides the handover behind a processor label cannot make that disclosure honestly.

This is also where pay transparency intersects with data roles. From 7 June 2026, agencies must handle pay information correctly in the vacancies they place under Directive (EU) 2023/970, which interacts with the candidate data they hold; we cover that in the pay transparency directive for recruitment agencies.

Why does getting the role wrong matter?

Because the role determines your liability, not just your paperwork. Under Article 82 of the GDPR, where more than one controller is involved in the same processing and is responsible for damage, each can be held liable for the entire damage to ensure the data subject is compensated, then claim contribution from the others. An agency that mislabels itself as a processor does not escape controller liability; it simply signs a contract that misallocates risk and may breach its own transparency duties along the way.

There is a commercial cost too. A client that audits its vendors will spot a processor agreement covering what is plainly controller activity, and that undermines trust in your whole data posture. Choosing the wrong instrument is the kind of gap a buyer notices, which is why it features in our checklist for what to look for in a GDPR-compliant ATS.

How Recruitifly supports agency and client data roles

Recruitifly’s Agency Hub models the relationship the way the law sees it. Instead of treating an agency as a separate tenant or a generic processor, an agency user is a restricted member of the client’s workspace, with access scoped to the jobs assigned to them. That keeps each party’s processing visible and bounded: the agency controls its own sourcing, the client controls its own selection, and submissions cross a clear, logged boundary rather than a fuzzy one. Candidate-data controls, retention settings, and access scoping are configurable so you can reflect a separate-controller or, where it genuinely applies, a joint-controller arrangement, and posting compliance checks keep pay and inclusive-language rules attached to every vacancy that goes out.

Recruitifly is in private beta. If you want your agency and client data roles to match the GDPR rather than fight it, talk to us and join the beta.