GDPR-Compliant ATS Evaluation Guide for EU Hiring Teams

Executive summary

If you are buying or renewing recruiting software in the EU, do not start with features. A GDPR compliant ATS is not one that simply has a privacy page or a checkbox. It is one that lets your team execute the decisions you already need to make: why candidate data is collected, who can see it, how long it stays, when it is deleted, and what happens when a candidate asks for access or erasure.

That is the core of ATS GDPR procurement. The vendor should make your policies operational, traceable, and testable. If it cannot, you do not have a compliance tool. You have a database with a privacy label.

For mid-market hiring teams, the buying decision usually comes down to six checks:

1. Can the system support your lawful basis and candidate notices for each recruiting activity?
2. Can it handle retention, deletion, and rights requests across all linked records?
3. Does the contract clearly define controller and processor responsibilities?
4. Are access controls, logs, and security controls strong enough for your actual risk?
5. Can the ATS explain and govern AI screening, ranking, or recommendation features?
6. Do integrations, subprocessors, backups, and transfers behave the way your policies require?

That is the real test of recruiting software compliance. Not the marketing label.

Who this guide is for

This guide is for talent acquisition leaders at mid-market companies, usually around 100 to 500 employees, hiring roughly 20 to 300 people a year with lean recruiting teams.

It is especially relevant if you are:

• replacing spreadsheets, shared drives, and email inboxes
• renewing a first-generation ATS that feels more like a filing cabinet than a system of record
• trying to reduce agency dependence
• adding AI screening or ranking
• hiring across EU or EEA jurisdictions
• reviewing an ATS with procurement, IT, security, privacy, and legal together

If your team is small and your hiring volume is climbing, centralization helps. But centralization also concentrates candidate data. That makes vendor controls more important, not less.

Definitions you need before comparing vendors

What is an applicant tracking system?

An applicant tracking system is software that helps collect, organize, search, evaluate, communicate with, and report on candidates across recruiting. Modern systems may also include job distribution, resume parsing, talent-pool search, scheduling, workflow automation, analytics, communication tools, and AI screening.

What is a lawful basis?

A lawful basis is the legal justification for a specific processing activity. Recruiting may use consent, contractual necessity, legal obligation, legitimate interests, public interest, or vital interests depending on the activity and the rules that apply.

The key point is simple: one vague statement does not cover everything. Sourcing, application intake, talent-pool retention, future outreach, and assessments may need different justification.

What is consent?

Consent is one possible lawful basis, not a universal recruiting requirement. Where it is used, it must be freely given, informed, specific, clear, demonstrable, and easy to withdraw.

What is a data controller?

A controller decides why and how personal data is processed. In most hiring setups, the employer determines the purpose and essential means of candidate processing.

What is a data processor?

A processor processes personal data on behalf of a controller and under documented instructions. An ATS vendor commonly fills that role for customer-controlled recruiting data.

What is data portability?

Portability is not the same as a normal export. It applies where the legal conditions are met and concerns personal data the individual provided in a structured, commonly used, machine-readable format.

What is role-based access control?

Role-based access control, or RBAC, gives permissions based on job role instead of giving everyone the same access. Good RBAC may also restrict access by requisition, geography, team, client, candidate stage, or sensitive field.

Why this buying decision matters

The easy mistake is to think GDPR compliance lives in legal docs. It does not. It lives in day-to-day recruiting workflows.

If recruiters cannot find a candidate record quickly, rights requests get delayed. If hiring managers can see too much, access control fails. If deletion only removes the visible profile, the data still exists in attachments, notes, exports, indexes, or integrations. If AI ranking is a black box, human review is not really human review.

That is why ATS GDPR evaluation needs to be operational. You are not buying a privacy promise. You are buying a system that has to behave correctly under real recruiting pressure.

What data flows should you map first?

Before you compare vendors, map candidate data from end to end. That means sourcing, application, screening, interviews, talent-pool storage, collaboration, integrations, archival, export, and deletion.

A practical inventory should identify:

• the data owner
• lawful basis
• candidate notice
• recipients
• retention period
• access group
• country of processing
• subprocessors
• deletion behavior

Candidate data flow checklist

This is the part many teams skip. It is also the part that tells you whether the vendor can actually support your compliance model.

How should an ATS support lawful basis and consent?

Consent is useful in some recruiting situations, but it should not be treated as the default for everything. Employment relationships can create a power imbalance, so consent is not automatically valid just because there is a checkbox.

What matters is whether the product can support the lawful basis you actually choose.

Must-have capabilities

• document the lawful basis for each recruiting activity
• present candidate-facing notices that explain purpose, data categories, retention, recipients, transfers, and relevant automated processing
• store separate consent records where consent is used
• capture timestamp, consent wording or version, source, status, and withdrawal history
• let candidates withdraw consent as easily as they gave it
• stop optional communications without automatically deleting the record

Questions to ask vendors

• Can the system record consent separately for applications, talent pools, campaigns, recordings, assessments, and other optional uses?
• Can you export consent evidence for audit or subject-access review?
• Does withdrawal stop the relevant workflow, campaign, recommendation, and notification process?
• Can the buyer continue limited processing under another lawful basis when that is legally appropriate?
• Does the product block bundled or pre-ticked consent?

The issue here is not whether the vendor has a consent field. The issue is whether the field actually supports real compliance.

What should you verify about transparency and sourcing?

A good ATS should help you tell candidates what is happening with their data, especially when data comes from public profiles, job boards, referrals, agencies, or imported databases.

You should verify that the product can:

• show or link the correct privacy notice on application forms and career pages
• record which notice version was presented
• identify the source and date of imported or sourced profiles
• track whether the candidate was contacted or notified
• explain screening, ranking, talent-pool retention, communications, and sharing
• disclose recipients, integrations, processing locations, and transfers
• explain whether automated processing or profiling is used

A vendor’s own privacy policy does not replace your candidate notice. Your team still needs configuration control over identity, purposes, jurisdictions, and workflow.

How do you evaluate retention and deletion?

This is where many systems fail in practice. Deletion is not the same as “make the candidate disappear from the list.”

There is no universal GDPR retention period for all ATS candidate data. Your schedule should depend on purpose, stage, local requirements, litigation or audit needs, and whether the candidate opted into a talent pool.

Retention categories to separate

• active candidates for open roles
• withdrawn applications
• unsuccessful candidates
• talent-pool candidates
• hired candidates moved to the HRIS
• agency or client records
• interview recordings and assessments
• communications and campaign history
• legal holds or documented exceptions

What a strong vendor should support

• configurable retention by candidate type, region, requisition, or data category
• automated review, expiration, anonymization, or deletion workflows
• warnings before destructive deletion
• legal-hold handling with an audit trail
• deletion propagation to resumes, attachments, notes, emails, assessments, recordings, exports, indexes, analytics, backups, and subprocessors
• reporting that shows what was deleted, when, by whom, and what could not be deleted
• a clear distinction between archive, inactive, suppress, stop processing, erase, and delete

Retention and deletion checklist

Must have

• a documented retention rule or operational workaround
• deletion across linked records, not just the visible profile
• a way to apply exceptions and legal holds
• completion evidence for routine deletion requests

Nice to have

• automated retention queues
• candidate self-service deletion links
• expiration reminders
• deletion reports for audits

If a vendor says, “We delete data when requested,” that is not enough. Ask what exactly gets deleted and where the leftovers go.

How should candidate rights and portability work?

An ATS should help the controller respond to access, rectification, erasure, restriction, objection, and portability requests.

Access

You should be able to retrieve the full candidate record, not just the resume. That means applications, tags, notes, scores, screening answers, messages, interview records, consent history, source data, and linked files.

Rectification

Candidates should be able to correct inaccurate or incomplete information. Check whether fixes update the canonical profile, duplicates, parsed fields, exports, and connected systems.

Erasure

Confirm the workflow, exceptions, approval process, and propagation to linked records and subprocessors.

Restriction or stop processing

The system should be able to stop outreach, ranking, or other processing without deleting the record when you need to preserve it under a permitted exception.

Objection

The ATS should support suppression from relevant processing and campaigns, with a clear record of the objection and the resulting workflow.

Portability

Ask for a sample machine-readable export and a field-by-field data dictionary. Do not assume a normal report export equals portability. Test the fields, format, and scope.

Candidate rights checklist

• Can we complete access requests without opening a ticket for every case?
• Can we export all linked records?
• Can candidates correct their own data or trigger a correction workflow?
• Does suppression stop future contact without destroying the record?
• Is portability a true machine-readable export, not just a PDF or report?

This is one of the most important checks in recruiting software compliance. If the system cannot support the rights you owe candidates, the rest of the promise is weak.

What should the controller–processor contract cover?

Before production use, require a proper data processing agreement.

At minimum, it should cover:

• subject matter, duration, nature, and purpose of processing
• types of personal data and categories of data subjects
• documented customer instructions
• confidentiality obligations
• technical and organizational security measures
• assistance with rights requests
• assistance with security assessments, breach response, and DPIAs where needed
• subprocessor authorization and change notice
• flow-down obligations
• return or deletion at termination
• audit, inspection, evidence, and reporting rights
• responsibilities for notices, lawful basis, requests, imports, and integrations
• breach notification channel and service levels

Also review how the vendor uses data for its own purposes. Customer-controlled recruiting data is one thing. Product analytics, service improvement, AI model training, fraud prevention, billing, support, and marketing are separate questions.

Where should candidate data be processed and transferred?

“Hosted in the cloud” is not a transfer answer. You need a map.

Ask where the vendor stores or accesses:

• production data
• backups
• logs
• support systems
• AI services
• analytics
• subprocessors

Also ask:

• what are the primary hosting regions?
• where are backup and disaster-recovery regions?
• where does remote support access happen from?
• who are the subprocessors, in which countries, and what do they do?
• what transfer mechanism applies to each transfer outside the EEA?
• how do you get notified when locations or subprocessors change?

Modernized standard contractual clauses were issued on 4 June 2021, but an SCC reference is not the whole answer. You still need the transfer map, parties, module, supplementary measures, and current subprocessor list.

What security and access controls should you require?

Security for candidate data is not optional. It is part of ATS GDPR readiness.

Minimum security questions

• Is data encrypted in transit and at rest?
• Are multi-factor authentication, SSO, and automated deprovisioning available?
• Can access be limited by role, team, requisition, geography, or data type?
• Can interview notes, compensation, diversity data, assessments, and recordings be separately restricted?
• Are exports, permission changes, deletes, and rights requests logged?
• Are logs exportable and retained appropriately?
• How are backups protected and eventually deleted?
• How is tenant isolation tested?
• What vulnerability management, penetration testing, incident response, and disaster recovery evidence exists?
• How quickly will the vendor notify the customer after it becomes aware of a breach?
• Can a compromised user or integration be disabled immediately?

A certification or report can help, but it does not replace checking whether the actual configuration fits your risk.

Security and RBAC checklist

Must have

• least privilege
• MFA or equivalent strong authentication
• role-based access
• audit logs
• breach notification commitments
• tested deletion and recovery behavior

Enterprise or high-risk requirements

• SSO and SCIM
• privileged access controls
• field-level segregation
• centralized security logging
• contractual audit rights
• independent assurance reports
• dedicated residency or restricted-support commitments

How should you assess AI screening and ranking?

If your ATS ranks, filters, scores, or recommends candidates, you need more scrutiny than you would for a simple storage tool.

AI in recruiting can be useful, but only if you can explain it, govern it, and override it.

Questions to ask

• What inputs influence the score or ranking?
• Does it use resume text, application answers, public-profile data, recruiter behavior, historical hiring outcomes, or inferred attributes?
• Does the vendor use customer data to train generalized models?
• Can AI features be disabled by jurisdiction, job family, or workflow?
• Can recruiters see the factors behind a recommendation?
• Can they override the result and record why?
• Is human review required before rejection or advancement?
• Are model versions, changes, confidence levels, and known limitations documented?
• How are false negatives and non-traditional career paths tested?
• Can the buyer reproduce the input and output used in a past decision?
• Is the candidate informed about relevant automated processing?

Human review has to be real. If the reviewer simply clicks through a recommendation without scrutiny, that is not meaningful oversight.

AI governance checklist

• explainability appropriate to the use
• meaningful human review
• Hiring bias and performance testing
• model-change information
• override controls
• decision logs
• disablement options

The EU AI Act separately treats recruitment and selection systems, including automated job matching and ranking, as potentially high-risk. So when you evaluate AI features, do not treat the ranking engine as a harmless add-on. It is a procurement issue.

How important are integrations and data minimization?

Every integration is another data flow, another access path, and another deletion dependency.

Review integrations with:

• job boards and sourcing platforms
• LinkedIn, GitHub, Stack Overflow, and browser-import tools
• email and calendar sync
• video interviewing and assessment tools
• HRIS, payroll, onboarding, and background-check providers
• analytics, reporting, support, and AI services

Ask whether integrations receive the full candidate record or only the minimum fields needed. Confirm whether revoking access stops future sync and removes copied data where required. Also test duplicate detection so one person does not create multiple uncoordinated records.

This matters for both privacy and recruiter sanity. A clean system is easier to govern.

What does CVViZ document, and what should you verify?

CVViZ provides documented GDPR workflow capabilities that are worth testing in a trial and contract review.

Documented capabilities

• a GDPR module that can be activated through a company-settings flag
• a candidate profile Data Privacy tab when the module is active
• consent status visibility and the ability to add, update, or withdraw consent
• consent states including pending, withdrawn, offered, and not offered
• five request categories: Access, Delete, Rectification, Erase, and Stop Processing
• request statuses such as received, in-progress, and completed
• aggregate counts in a compliance dashboard
• Delete Candidate described as destructive and permanently removing candidate data when executed
• Stop Processing halts further activity without deleting candidate data
• access requests supported through available export options

Documented product and access capabilities

CVViZ provides authorized-access controls that can give users all or limited access to the recruitment dashboard. It also supports candidate database search, Boolean search, filters, resume uploads, parsing, duplicate-resume identification, candidate-source capture, reporting exports, and integrations with recruiting and sourcing platforms.

CVViZ also supports AI resume screening, contextual matching, relative ranking, sourcing, workflow automation, analytics, communications, and API-related capabilities. Those should be tested against your own data flows and contractual terms rather than assumed to behave identically in every context.

What still needs verification

The public materials reviewed do not fully establish:

• a complete, current subprocessor list
• exact transfer mechanisms and supplementary measures for every non-EEA transfer
• a configurable retention schedule by candidate type, jurisdiction, or data category
• automated retention expiration and deletion reporting
• whether deletion propagates to backups, indexes, logs, exports, integrations, and every subprocessor
• whether the access export is a true portability export
• a full permission matrix
• comprehensive audit logs
• detailed breach-notification timing in the contract
• AI model documentation, bias testing, model-change notices, and guaranteed human review
• whether all modules and integrations are covered by the same GDPR controls

That is not proof those capabilities do not exist. It is a reminder to verify them before purchase.

What is the best evaluation framework for buyers?

Use a scorecard. It keeps the discussion grounded and prevents the loudest feature from winning by accident.

ATS GDPR evaluation scorecard

Scoring guidance

• 0 = not offered or vendor cannot answer
• 1 = marketing claim only
• 2 = exists but requires heavy manual work
• 3 = available and documented, with limits
• 4 = demonstrated, configurable, logged, and contractually supported
• 5 = demonstrated end to end, automated where appropriate, exportable, monitored, and backed by strong evidence

Procurement hold rules

Do not proceed if there is any unresolved failure in:

• DPA
• transfer mechanism
• deletion
• breach response
• access control

And do not award full AI-governance points unless the ranking or screening feature can be explained, overridden, and audited.

What questions should you ask every ATS vendor?

Lawful basis and consent

1. Which recruiting activities do you support with consent records?
2. Can we configure separate purposes and consent wording by country or workflow?
3. What exactly is stored as evidence of consent?
4. How is withdrawal propagated to campaigns, workflows, ranking, and integrations?
5. Can we suppress future contact without deleting the candidate record?

Retention and rights

6. Can we set different retention rules for active applicants, rejected applicants, talent-pool candidates, hires, and recordings?
7. What does deletion remove, including attachments, notes, indexes, logs, backups, and subprocessors?
8. How do you handle legal holds or records that cannot immediately be deleted?
9. Can we complete an access request within one month and export all linked records?
10. Is the export structured, commonly used, and machine-readable for portability purposes?
11. Can candidates correct their own information, and does correction update duplicates and integrations?
12. What is the difference between archive, inactive, suppress, stop processing, erase, and delete in your product?

Processor governance and transfers

13. Will you sign our data processing agreement?
14. What are your documented purposes and instructions for customer data?
15. Do you use customer or candidate data to train generalized AI models?
16. Who are all subprocessors, where are they located, and what do they do?
17. What happens when a subprocessor changes?
18. Where are production data, backups, support systems, and logs stored?
19. Which transfer mechanism applies to each transfer outside the EEA?
20. What data is deleted at termination, and when are backups and replicas removed?

Security and access

21. Which encryption applies at rest, in transit, and in backups?
22. Do you support SSO, MFA, SCIM, and automatic deprovisioning?
23. Can we restrict hiring-manager access to only assigned requisitions?
24. Can sensitive fields, notes, assessments, recordings, and exports have separate permissions?
25. Are viewing, downloading, exporting, deletion, and permission changes logged?
26. Can we export logs for our own audit process?
27. How often are penetration tests and vulnerability assessments performed?
28. What is the incident-notification target after the vendor becomes aware of a breach?

AI and profiling

29. What data features influence ranking or screening?
30. Can we inspect the factors or evidence behind a recommendation?
31. Can a human override the result, and is the override recorded?
32. Can we disable automated rejection and require human review?
33. How are false negatives, disparate outcomes, and non-traditional candidates tested?
34. How are model changes communicated and evaluated?
35. What candidate-facing explanation is available?
36. Which AI Act classification and role does the vendor assign to the feature?

What common buying mistakes should you avoid?

1. Treating a vendor’s “GDPR compliant” label as proof of compliance.
2. Assuming consent is always the correct lawful basis.
3. Using one generic consent checkbox for applications, talent pools, recordings, and assessments.
4. Keeping unsuccessful applicants indefinitely because storage is cheap.
5. Defining deletion as removing a candidate from the visible list only.
6. Forgetting resumes, notes, emails, interview recordings, backups, exports, and indexes.
7. Ignoring candidates sourced from public websites.
8. Giving every hiring manager broad access to the whole database.
9. Treating a CSV or PDF report as portability.
10. Assuming a processor contract resolves undisclosed subprocessors or international transfers.
11. Buying AI ranking without testing non-traditional profiles and false negatives.
12. Calling human review meaningful when reviewers cannot see, challenge, or override the recommendation.
13. Migrating historical candidate data before deciding whether the buyer still has a purpose and lawful basis.
14. Failing to test rights requests before launch.
15. Relying on a security certificate without reviewing actual roles, logs, exports, integrations, and deletion behavior.

Implementation sequence for a mid-market buyer

Phase 1: Inventory and risk classification

List all candidate sources, data fields, users, integrations, countries, AI features, and retention categories. Identify sensitive content, high-volume roles, agency access, and imported public-source data.

Phase 2: Configure governance before migration

Define lawful basis, notices, consent purposes, retention schedule, access roles, rights-request ownership, incident contacts, and deletion rules. Do not migrate historical data until you know whether each record still has a purpose.

Phase 3: Configure permissions

Create least-privilege roles for recruiters, hiring managers, interviewers, agency users, administrators, privacy staff, and executives. Test both what each role can see and what it can export or delete.

Phase 4: Test candidate rights

Use synthetic records to test access, correction, restriction, stop processing, objection, portability, and deletion. Include duplicate resumes, email history, interview files, ranking scores, attachments, integrations, and a legal-hold record.

Phase 5: Test AI workflows

Run representative profiles, including career gaps, non-traditional backgrounds, multilingual resumes, equivalent skills, and incomplete resumes. Compare ranking outputs, document overrides, and verify that recommendations do not silently trigger rejection.

Phase 6: Contract and evidence review

Obtain the DPA, security schedule, subprocessor list, transfer documentation, retention and deletion description, incident terms, assurance reports, and AI documentation. Assign an owner and a test date for every “customer configurable” item.

Phase 7: Migration and launch

Migrate only approved data. Preserve consent and notice history where needed. Validate duplicates, access permissions, deletion queues, integrations, and audit logging. Train recruiters on the difference between stopping processing and deleting data.

Phase 8: Ongoing governance

Review access quarterly or after organizational changes. Test rights workflows periodically. Review subprocessors and data locations. Monitor retention exceptions. Reassess AI performance after material model or process changes.

What does a practical decision matrix look like?

Frequently asked questions

Does GDPR require an ATS to collect candidate consent?

No. Consent is only one lawful basis. The employer or agency must determine the correct basis for each activity.

Is an ATS automatically compliant if the vendor says it is GDPR compliant?

No. Compliance depends on your purposes, lawful basis, notices, configuration, users, integrations, retention, and operating procedures, plus the vendor’s controls and contract.

Who is responsible for candidate rights requests?

The controller normally manages the relationship with the candidate. The processor should provide tools and assistance. The contract should state who receives the request, who verifies identity, who approves deletion, and how the vendor supports the deadline.

Is “stop processing” the same as deletion?

No. Stop processing halts further activity while the record remains. Deletion is destructive and removes the record within the defined scope.

Is a resume export enough for portability?

Not necessarily. Portability has legal conditions and concerns personal data provided by the individual in a structured, commonly used, machine-readable format.

Can an employer use legitimate interests for recruiting?

Potentially, depending on the activity and applicable law. The employer still needs an impact assessment, transparency, and an objection workflow.

Does human review eliminate automated-decision risk?

No. Human review has to be meaningful and capable of changing the outcome.

What should a buyer verify about CVViZ specifically?

Verify the GDPR module configuration, consent and request workflows, the exact scope of exports and deletion, retention automation, role permissions, audit logs, subprocessors, transfer mechanisms, backup deletion, breach terms, and AI governance.

Bottom line

Choose the ATS that can demonstrate, not merely claim, that candidate data is collected for defined purposes, accessed by the right people, retained only as long as justified, exportable when required, deleted across its actual data estate, protected through enforceable processor controls, and evaluated transparently when AI influences recruiting decisions.

That is the real standard for a GDPR compliant ATS. It is also the standard for solid recruiting software compliance.

Update log

Reviewed: 21 September 2026

Coverage reviewed: lawful bases and consent; candidate transparency and rights; retention and deletion; processor governance; breach response; international transfers and standard contractual clauses; RBAC and security evidence; AI recruitment and ranking; CVViZ GDPR workflows, privacy policy, product capabilities, and publicly documented gaps.