Ensuring GDPR & CCPA Compliance When Migrating Candidate Data

You've done it. You've sat through the demos, negotiated the contracts, and finally picked your new Applicant Tracking System (ATS). Everyone's excited. This new platform is going to streamline everything!

Then you realize: What about the data?

What about the thousands, or hundreds of thousands, of candidate profiles, resumes, interview notes, and old applications sitting in your current system? You can't just move it without thinking carefully about the legal implications.

If you're in HR, IT, or legal, you know this isn't a simple "copy-paste" job. This is a compliance minefield.

We're talking about Personally Identifiable Information (PII) of the most sensitive kind. And when you move it, you trigger a whole host of legal obligations under regulations like the GDPR (General Data Protection Regulation) in Europe and the CCPA/CPRA (California Consumer Privacy Act and its 2023 amendment, the California Privacy Rights Act).

Get this wrong, and you're not just looking at a difficult project. You're looking at a data breach, a catastrophic loss of candidate trust, and fines that can climb as high as 4% of your company's global annual revenue or €20 million, whichever is greater.

This article is your step-by-step guide to a compliant ATS data migration. We'll walk you through a 7-step, compliance-first framework and flag the legal nuances that generic migration guides miss.

Section 1: GDPR vs. CCPA/CPRA: Why Your Candidate Data Carries Elevated Legal Risk

First, let's get on the same page. Why is candidate data treated differently from, say, migrating your product inventory or your sales pipeline?

Because of one simple fact: You don't own this data. The candidate does.

You are a custodian who has been granted a specific legal basis to process that data for a defined purpose (evaluating their application). The moment you move, analyze, or store that data beyond the original scope, you need to verify that your legal basis still holds.

Regulations like GDPR and CCPA/CPRA are the mechanisms that enforce that. While they have a lot in common, they differ in scope, rights, and the legal obligations they place on you.

🌍 The GDPR (General Data Protection Regulation)

• Who it Protects: Any "data subject" residing in the European Union (EU). If you have a single resume from a developer in Berlin or a sales rep in Paris, it applies to you.
• The Big Concept: "Lawful Basis for Processing" Under GDPR Article 6, you must have one of six lawful bases to process personal data. For candidate data, the most commonly applicable are:
  • Contractual necessity (Article 6(1)(b)): Processing needed to take steps at the request of the data subject prior to entering a contract — relevant during active recruitment.
  • Legitimate interests (Article 6(1)(f)): Often used to retain candidate data for future roles, but requires a balancing test against the data subject's rights.
  • Consent (Article 6(1)(a)): Freely given, specific, and withdrawable. Consent is often the weakest basis for candidate data because it must be as easy to withdraw as to give — and withdrawal does not retroactively affect processing already carried out. Over-relying on consent creates the risk that withdrawal triggers deletion obligations that are difficult to operationalize at scale.
  • Legal obligation (Article 6(1)(c)): Relevant where you are required by employment law to retain certain records.
• Special Category Data: If your ATS stores health information, diversity data (race, religion, disability status), or criminal record checks, these fall under GDPR Article 9 and require explicit consent or another Article 9(2) condition. Standard PII rules are insufficient — explicit consent or a specific legal exception is required, and the bar is materially higher.
• The Migration Problem: When you migrate to a new ATS managed by a new vendor, your lawful basis must still hold. For consent-based processing, you should verify whether the original consent covered transfer to a new data processor. For legitimate interest, you should re-run the balancing test in the new processing context.
• The "Right to be Forgotten" (Article 17): If a candidate asks you to delete their data, you must do it completely and permanently. If their data exists in your old system, your new system, and a staging environment used during the migration, all three locations must be addressed before the statutory deadline.
• Cross-Border Transfers: If your new ATS vendor stores data in the US or any country without an EU adequacy decision, you must have a valid transfer mechanism in place. The primary options are Standard Contractual Clauses (SCCs), the EU-US Data Privacy Framework (for qualifying US organizations), and Binding Corporate Rules. The Schrems II ruling (C-311/18) invalidated the previous Privacy Shield and tightened the conditions under which SCCs can be relied upon — you are expected to assess whether the destination country's laws undermine the protection SCCs provide. This is not a checkbox; it requires a documented Transfer Impact Assessment (TIA) for high-risk scenarios.
• Breach Notification: Under GDPR Article 33, you must notify your supervisory authority within 72 hours of becoming aware of a personal data breach that is likely to result in risk to individuals' rights and freedoms. If the breach is high-risk, affected individuals must also be notified without undue delay (Article 34).

🌴 The CCPA and CPRA (California Consumer Privacy Act & California Privacy Rights Act)

• Who it Protects: Residents of California. The CCPA originally applied to for-profit businesses that meet one or more thresholds: annual gross revenue above $25 million; buying, selling, or sharing the personal information of 100,000 or more consumers or households per year; or deriving 50% or more of annual revenues from selling personal information.
• The CPRA Amendment (Effective January 1, 2023): The California Privacy Rights Act materially expanded CCPA. Key changes relevant to ATS migrations include:
  • The employee and applicant exemption that limited CCPA's scope was removed. California employees, job applicants, and contractors now have the full suite of consumer rights under the law.
  • A new category of "Sensitive Personal Information" was introduced, covering Social Security numbers, driver's license numbers, financial account details, precise geolocation, racial or ethnic origin, religious beliefs, union membership, health data, and biometric data. Candidates have the right to limit the use of sensitive personal information.
  • The California Privacy Protection Agency (CPPA) was established with independent enforcement authority.
• The "Right to Know" and "Right to Delete": A candidate can ask you exactly what information you hold on them. You are legally obligated to provide a full response within 45 days (with one possible 45-day extension). The Right to Delete applies across all systems where their data exists — old ATS, new ATS, staging environments, and any intermediate exports.
• The Migration Problem: Can you instantly locate, package, and export all data associated with a specific candidate from both your old and new systems, including custom fields and interview notes? If a Right to Delete request arrives during your migration window, you must be able to execute deletion across all active and transitional environments.

So, What's the Real Challenge?

Your database isn't neatly sorted into "GDPR people" and "CCPA people." It's one pool of data, subject to overlapping legal regimes, with different rights, timelines, and deletion obligations. And the migration itself — the act of moving data between systems — is a processing activity in its own right, one that must be justified, documented, and secured.

Section 2: The 7-Step Compliance-First Migration Plan

A compliant migration isn't just about security. It's a strategic project that blends legal, IT, and HR expertise. Here is the 7-step plan that addresses the core compliance obligations at each phase.

Step 1. Conduct a Data Audit, Establish Lawful Basis, and Classify Your Data

Before you move a single byte, you need to understand what you have and why you have it. A data audit means answering:

• What do we have? Resumes, interview notes, salary expectations, diversity data, health accommodations, background check results?
• Where is it? Is it only in the ATS, or also in email inboxes, shared drives, and spreadsheets?
• What is the lawful basis for each data type? This is not a single answer — different categories of data may rest on different bases.
• Does any of it qualify as special category data under GDPR Article 9 or sensitive personal information under CPRA? If so, the requirements are stricter and must be handled separately.

A useful starting point is a simple data classification table:

Data Type	Example	GDPR Category	Lawful Basis	Retention Trigger
Standard PII	Name, email, phone	Personal data (Art. 6)	Legitimate interest / Contract	End of recruitment process
Special Category	Disability, health notes	Special category (Art. 9)	Explicit consent / Art. 9(2)	Explicit review required
Sensitive PI (CPRA)	SSN, biometric data	Sensitive PI	Defined use limitation applies	Explicit review required
Financial data	Salary history	Personal data (Art. 6)	Legitimate interest / Contract	Jurisdiction-specific

This classification determines which profiles can be migrated as-is, which require re-consent or re-assessment, and which must be deleted before the migration begins.

This is where automated tools fail at the first hurdle. An automated tool sees a field. It cannot tell you what lawful basis justifies that field's existence, whether it qualifies as special category data, or whether the original consent still covers transfer to a new processor.

Step 2. Define Your Data Retention Policy (and Enforce It Before You Migrate)

This is the single most important step for reducing your legal exposure. Keeping a candidate's resume from eight years ago "just in case" isn't just poor data hygiene; under GDPR's data minimization principle (Article 5(1)(c)), it may be a violation.

Before your migration, define and enforce a retention policy. The appropriate retention period will depend on your jurisdiction, the type of role, and any applicable employment law. A defensible policy documents:

• The retention period for active candidates (e.g., 12–24 months post-process)
• The retention period for unsuccessful applicants
• The trigger for deletion (last activity date, end of recruitment process, withdrawal of application)
• Special rules for special category data, which should generally be retained for the shortest defensible period
• Jurisdiction-specific carve-outs where employment law mandates a minimum retention period

Note that CPRA-covered businesses must also disclose retention periods in their privacy notices — if your policy is not already documented there, this migration is an opportunity to align them.

The compliance benefit is also operational: migrating only the data you are legally entitled to retain reduces scope, cost, and risk in a single step.

Step 3. Review Your Vendor Contracts (The DPA Deep-Dive)

Migrating to a new ATS means introducing a new data processor. Under GDPR Article 28, you are required to have a Data Processing Agreement (DPA) in place with every processor that handles personal data on your behalf. A compliant DPA must include:

• The subject matter, duration, nature, and purpose of the processing
• The type of personal data and categories of data subjects involved
• The controller's obligations and rights
• A requirement that the processor only processes data on documented instructions from the controller
• Obligations on the processor to ensure confidentiality, implement appropriate security measures, delete or return data at the end of the contract, and assist with DSARs and breach notifications
• A requirement that sub-processors (e.g., the cloud infrastructure provider the ATS runs on) are subject to equivalent obligations
• Audit rights for the controller

A DPA that doesn't address these elements is not Article 28-compliant. Review your new ATS vendor's DPA against this list before signing. If the vendor is US-based and will store EU data in the US, confirm which cross-border transfer mechanism they rely on (SCCs, EU-US Data Privacy Framework) and request their Transfer Impact Assessment if SCCs are used.

The same applies to your migration partner. They are a processor for the duration of the migration and must sign a DPA with you that covers the transitional processing period.

Step 4. Build a DSAR Response Plan for the Migration Window

A complex ATS migration can take several weeks from planning to final cutover. During that window, candidate data may exist simultaneously in the old system, a staging environment, and the new system. A Data Subject Access Request (DSAR) or deletion request received during this period requires a coordinated response across all three.

Your DSAR plan for the migration window should define:

• A single internal owner responsible for coordinating responses during the migration
• A system inventory documenting where data exists at each phase (old live system, staging, new system, any intermediate exports or backups)
• A deletion workflow that covers all active environments, not just the production system
• Response timelines: GDPR requires compliance within one month (extendable by two months for complex cases, with notice to the requester); CCPA/CPRA requires a response within 45 days (extendable by a further 45 days with notice)
• A process for confirming deletion was completed in all environments before the case is closed

Without this plan, a deletion request received mid-migration may be partially executed — data removed from the old system but not from staging — which constitutes a compliance failure.

Step 5. Anonymize or Pseudonymize All Test Data (and Know the Difference)

Never use live candidate data in test or staging environments. This should be a non-negotiable rule, but it is frequently the most common shortcut taken during ATS migrations.

Before using any data in a test environment, understand the legal distinction:

• Anonymization produces data that cannot be re-linked to the original individual by any reasonably available means. Truly anonymized data falls outside the scope of GDPR entirely. However, genuine anonymization is technically difficult — removing a name and email is not sufficient if other fields (job title, location, application date, unique skills) create a re-identifiable combination.
• Pseudonymization replaces identifying fields with artificial identifiers (e.g., replacing "Jane Smith" with "Candidate_4821") while preserving data structure. Pseudonymized data is still personal data under GDPR Article 4(5) because re-identification is possible if the mapping key exists. It reduces risk but does not remove GDPR obligations.

For test environments, the goal is either genuine anonymization or pseudonymization with the mapping key held separately and securely. Engineers should generate synthetic data that replicates the structure and volume of real data — realistic field values, representative pipeline distributions, correctly formatted custom fields — without containing any actual PII.

This lets you validate that custom fields mapped correctly, pipelines behave as expected, and reports produce accurate output, without exposing candidate data to an environment that may have different access controls than production.

Step 6. Secure the Transfer

The data transfer itself must be protected at every stage. Acceptable minimum standards for regulated data migrations:

• Encryption at rest: AES-256 for data stored in the source system, any intermediate exports, and the destination system.
• Encryption in transit: TLS 1.2 at minimum; TLS 1.3 preferred. File-based transfers should use SFTP (SSH File Transfer Protocol) or equivalent. Plain FTP and unencrypted email are not acceptable for PII transfers.
• Key management: Encryption keys should be managed separately from the data they protect. If the same party holds both the encrypted data and the decryption key, encryption provides limited protection against insider risk or account compromise.
• Access control: Access to data during the migration should be limited to named individuals with a documented need. Access logs should be retained for audit purposes.
• No ad-hoc exports: Exporting data to a local CSV and transferring it via email or consumer cloud storage (personal Dropbox, Google Drive not covered by a DPA) is not compliant for regulated data.

Document your transfer method and security controls. If a regulator or auditor asks how the data was secured during transit, you need a written answer, not a recollection.

Step 7. Execute Secure Deletion and Obtain a Deletion Certificate

Once the migration is complete and the new system is verified, the data in the old system must be provably deleted. Letting the old ATS instance sit dormant "just in case" violates the data minimization and storage limitation principles under GDPR Article 5.

Secure deletion means:

• Deletion from the live database
• Deletion from any backups that contain the migrated data, or a documented policy for when those backups will be overwritten
• Deletion from any intermediate exports, staging environments, or migration logs that contain PII
• Confirmation from the old vendor that their copies have been deleted, per the terms of your DPA with them

At the end of this process, you should hold a Secure Deletion Certificate: a formal document recording what was deleted, from which systems, by whom, on what date, and by what method. This is your evidence for regulators, auditors, or internal governance purposes that the legacy data was handled correctly.

What Generic Automated Tools Cannot Do

Automated migration tools are built to move fields from one schema to another. They are not built for the compliance requirements described above. Specifically:

1. They cannot classify data. A tool cannot distinguish standard PII from special category data under Article 9 or sensitive personal information under CPRA. It moves everything, undifferentiated.
2. They cannot enforce retention policy. Automated tools are designed to migrate complete datasets. Selectively migrating only the profiles that pass your retention and lawful basis review requires custom logic applied before the migration runs.
3. They cannot produce an audit trail. When a regulator asks how the data was validated, secured, and handled during transfer, you need documented evidence. A tool's log file is not a compliance record.
4. They cannot handle DSAR mid-flight. If a deletion request arrives while the tool is running, there is no mechanism to intercept and act on it across the old system, staging, and new system simultaneously.
5. They cannot manage cross-border transfer compliance. If your source and destination systems are in different jurisdictions, the transfer mechanism — SCCs, adequacy decision, or other — must be validated before data moves. A generic tool has no awareness of this requirement.

A migration of regulated candidate data requires engineers who can write custom scripts tailored to your data structure and compliance requirements, combined with legal and compliance review at each phase.

Conclusion: Compliance Is Not an Add-On

You cannot bolt compliance onto the end of a migration. It has to be part of the project from the discovery phase.

The legal obligations are real: lawful basis under GDPR Article 6, special category protections under Article 9, DPA requirements under Article 28, cross-border transfer mechanisms under Chapter V, CPRA's expanded applicant rights, breach notification timelines, and deletion obligations that span every environment where data touched during the migration.

A successful, compliant migration requires knowing which obligations apply to your specific data, your specific vendor geography, and your specific retention history — and then executing against each one with documented evidence.

At ClonePartner, we handle the technical execution: custom scripts, data classification, anonymization for test environments, secure transfer, and deletion certification. The compliance decisions — lawful basis, retention periods, DPA review — belong with your legal team. We work alongside them.

Ready to Build Your Compliant Migration Plan?

Worried about your upcoming ATS migration? Don't be.

Let's talk. Book a free, no-obligation consultation with our migration experts today. We'll review your systems, identify your compliance risks, and design a custom migration plan that is secure, accurate, and built to the legal requirements that apply to your data.

P.S. Worried about more than just compliance? Check out our complete guide on the 5 "Gotchas" in ATS Migration: Tackling Custom Fields, Integrations, and Compliance.