GDPR-Compliant Recruiting Software: The Nine Questions Every Vendor Should Answer

GDPR-compliant recruiting software is software you can prove is compliant: candidate data stored and processed in the EU/EEA, a signed data processing agreement in place before go-live, a named sub-processor list, a working erasure path, an enforced retention window, and a documented lawful basis on every record you hold. None of that is visible in a product demo. All of it is answerable in a single email to the vendor.

I ran a recruitment agency before I built Pickr, so I have been on both sides of this conversation: asking these questions as a buyer, answering them as a vendor. The questions are identical whether you run an agency or an in-house talent team. Only the volume of candidate records and the number of people who can see them changes. Vendors rarely say no outright. They say something adjacent to yes. So what follows is not a list of obligations but a list of questions, with the good answer and the bad answer written next to each other, so you can tell which one you just received.

I am not a lawyer and this is not legal advice. Send these before you sign and forward the answers to whoever carries your data protection responsibility. If you want the underlying obligations instead, the companion piece on what GDPR actually requires from a recruitment ATS covers that. One worked example of what good sounds like: Pickr's own free recruiting process audit connects to your ATS read-only, never stores the API key, keeps data in the EU, and can be deleted at any time. Four specifics, no adjectives.

The nine questions

1. Where is candidate data physically stored, and where is it processed?

A good answer names a country and usually a city, covers storage and processing separately, includes backups, and says whether support staff outside the EU can reach production data.

A bad answer is "we are GDPR compliant" or "we run on AWS" with no region. The worst version is "EU data residency is available on our Enterprise tier", which tells you what the default configuration looks like for everyone else.

2. Will you sign a data processing agreement, and is it included?

You are the controller. The vendor is the processor. Article 28 requires a contract between you, and without it the arrangement is unlawful no matter how good the vendor's security is.

A good answer is the AVV arriving as an attachment before you asked twice, with sub-processors annexed and standard contractual clauses where any transfer leaves the EEA. A bad answer is "our terms of service cover data protection", an AVV that exists only on the higher plan, or a vendor that will not accept a single redline.

3. Who are your sub-processors, and where are they?

A good answer is a current list with names, purpose, and location, plus a commitment to notify you of changes and a right to object. Hosting, email delivery, transcription, CV parsing, error monitoring, support desk and any AI provider belong on it.

A bad answer is "we do not share your data with third parties." That is never true. Every product of this kind has sub-processors, and a vendor who claims otherwise is hoping you have not thought about it.

4. What happens to candidate data that goes into an AI prompt?

This is the question most buyers skip. A CV going into a model is a transfer, and a transfer needs a basis, a destination and a record.

A good answer explains what is stripped before the data leaves, states contractually that your data is not used to train anyone's model, names where inference happens, and confirms an impact assessment exists. A bad answer is "the AI is secure" or "our provider does not train on customer data" without naming the provider or the region. If you are evaluating AI features at all, the EU AI Act obligations for recruiting sit on top of this and land on you as the deployer, not the vendor.

5. What is the retention period, and is deletion actually deletion?

A good answer is a configurable retention window per record type, expiring automatically, where deletion removes or irreversibly anonymises the candidate across notes, emails, attachments, transcripts and search indexes, with a stated window for backups.

A bad answer uses the word "archive". Archiving is not deleting, and neither is hiding a row from the interface. Ask whether a deleted candidate can still be found by a keyword search of interview notes six months later.

6. How are erasure and access requests handled, and how fast?

GDPR gives you one month to respond, extendable by two for complex requests. That clock is yours, so the software has to beat it.

A good answer is one action inside the product that produces both a portable export for an access request and a record that the erasure happened. A bad answer is "email support and we will take care of it" with no timeline, which converts your legal deadline into somebody else's ticket queue.

7. Can I see the lawful basis for every candidate record I hold?

Strictly this is your question, not the vendor's, but the software decides whether you can answer it. A good answer is lawful basis as a real field on the record, visible and filterable, so you can list everyone held under consent, or under legitimate interest, in one query.

A bad answer is that no such field exists, which means your basis lives in a spreadsheet or in nothing at all. That applies hardest to everyone you keep after a role closes, which is where most talent pools quietly turn into a liability.

8. How is consent captured, and how is it renewed?

A good answer records the timestamp, the exact wording version the candidate agreed to, and the channel it came through, then prompts before that consent expires. Withdrawal has to be one action for the candidate and has to propagate everywhere, including to any outreach sequence already running.

A bad answer is a checkbox on the application form and silence afterwards. Consent captured once in 2023 is not consent today, and a screenshot of today's form is not evidence of what the candidate saw then.

9. Can you show me who opened a candidate record, and when?

A good answer is an access and change log per record, retained, exportable, and covering vendor support staff as well as your own team. A bad answer is "only your team can see the data", which is about permissions, not accountability. Article 5 requires you to demonstrate compliance, and demonstrating it means logs.

The checklist, condensed

Question	Green flag	Red flag
Where data sits	Named country, processing and backups included	"GDPR compliant", or EU residency as a paid upgrade
Processing agreement	AVV sent unprompted, sub-processors annexed	Terms of service offered instead
Sub-processors	Current named list, change notification	"No third parties involved"
AI prompts	PII stripped, no training on your data, region named	"The AI is secure"
Retention	Configurable, auto-expiring, per record type	Archive presented as deletion
Erasure and access	One action, export plus proof	Support ticket, no timeline
Lawful basis	A field on the record, filterable	Not modelled at all
Consent	Timestamp, wording version, renewal prompt	One checkbox, never revisited
Audit trail	Per-record access log, vendor staff included	Role permissions offered instead

The four gaps I see most often

The gaps that surface in an audit are rarely exotic. In my experience they are these four, in agencies and in-house teams alike.

• Rejected candidates kept forever with no basis. Almost every agency, and every in-house talent pool that has been running for a few years, holds people who applied once in 2019 and were never contacted again. No lawful basis, no consent, and no retention rule that stopped it.
• No AVV with the ATS vendor. Terms of service were accepted at signup, an Article 28 contract was never signed, and nobody noticed because nobody asked.
• Candidate PII sent to a US AI provider with no assessment. A recruiter pastes a CV into a general-purpose chatbot to summarise it, or the ATS does the equivalent invisibly.
• No working erasure path. The request arrives, someone deletes the profile, and the interview notes, email thread and transcript survive under a different record type.

Article 83 sets the ceiling at EUR 20 million or 4% of global annual turnover, whichever is higher, but the likelier cost is smaller and far more frequent: a client's procurement team, or your own security review before a renewal, asks for the sub-processor list and nobody can produce one.

Where Pickr stands on these questions

I built Pickr, so discount this section and check the answers yourself. Pickr is the AI-native recruiting platform that hosts candidate data in Germany, includes the data processing agreement as standard, and redacts personally identifying information from AI prompts by default. Storage and processing both sit in Frankfurt, Germany, and the answer is the same whether you are an agency running twelve client pipelines or a company hiring for your own roles. The AVV and the sub-processor list go out before you sign, not after you ask. Where Pickr reads from an ATS you already run, that connection is read-only and the key is never stored. Pickr is built in Austria for the EU market, which is why these answers were designed in rather than retrofitted.

What Pickr does not do: decide your lawful basis, write your retention policy, or absorb your controller obligations. No vendor can. The most a good one does is make the compliant path the default one, so the reasoning behind a hire or a rejection is captured when the decision is made rather than reconstructed for an auditor a year later.

Send these nine questions to every vendor on your shortlist, in writing, before the contract. The ones who answer in specifics within a day have already done the work. The ones who answer with adjectives are telling you what your compliance file will look like in two years, and that signal is worth just as much when you are deciding between recruiting platforms on everything else.