When Your ATS Becomes the Breach: Securing Candidate PII

A recruiting platform data breach is now one of the highest-value targets in your stack, because an applicant tracking system holds the densest concentration of regulated personal data your company touches: legal names, addresses, salary expectations, resumes, and increasingly government IDs, recorded video interviews, and AI-derived biometric data. When that system is breached, attackers do not get a marketing list. They get a turnkey identity-theft and deepfake kit. The fix is not “pick a vendor that promises security.” It is privacy-by-design: collect less, encrypt what you keep, delete on a schedule, and treat the ATS as a system your incident-response plan actually covers.

If you own the hiring stack and your CISO or board has started asking “could the Mercor thing happen to us?”, this is for you. Here is what actually happened, why recruiting platforms are suddenly in the crosshairs, the legal exposure that follows, and a concrete checklist of controls you can demand from any vendor.

What happened to Mercor (and why it should scare every hiring team)

In late March 2026, the AI-industry recruiting platform Mercor was breached and roughly 4TB of data was exfiltrated, including candidate Social Security numbers, passport and driver’s-license scans, facial biometric data, and HD video interviews. Mercor, reportedly used to source contractors who train models for major AI labs, did not get hit through its own front door. It got hit through a dependency.

The attack rode in on the LiteLLM supply-chain compromise. A threat actor tracked as TeamPCP compromised LiteLLM’s PyPI publishing credentials and pushed two trojanized package versions, v1.82.7 and v1.82.8. Per LiteLLM’s own security post, the malicious packages were live on PyPI for roughly 40 minutes on 24 March 2026 before being quarantined. Forty minutes was enough. The payload harvested environment variables, SSH keys, cloud credentials, Kubernetes tokens, and database passwords. The extortion group Lapsus$ then listed Mercor on its leak site around 31 March and put the data up for auction; Mercor disclosed impact in early April, describing itself as “one of thousands of companies” affected.

The data Lapsus$ claimed breaks down to roughly 939GB of source code, a 211GB candidate database, and around 3TB of stored files (Repello AI; SecurityWeek). The candidate database reportedly held resumes, verified contact information, and SSNs. The stored files were the truly alarming part: HD video of candidates, identity-document scans, and the facial biometric data used to match faces to IDs.

The lesson is not “LiteLLM was bad.” LiteLLM is widely used; Wiz found it present in 36% of analyzed cloud environments (Wiz). The lesson is that your candidate data’s blast radius includes your vendor’s vendors, and the most sensitive pile you own may be sitting in a system nobody on your security team thinks about.

Why recruiting platforms are now prime targets

Recruiting platforms are high-value targets because the hiring funnel collects more sensitive data than almost any other back-office system, yet is rarely scoped into a company’s security program. Think about what flows through an ATS on a single hire: legal name, home address, phone, email, full employment history, salary expectations, a resume, references, and for many modern stacks a recorded video interview, a government ID for right-to-work checks, and AI-generated transcripts or scores. That is a richer profile than most CRMs, billing systems, or internal wikis hold.

Two structural shifts made this worse in the last few years.

AI hiring tools collect biometric-adjacent data by default. Video interviews, voice analysis, and face-to-ID matching are now common features. Each one converts a hiring step into a permanent biometric record.

AI gateway and proxy services concentrate credentials. Tools like LiteLLM sit in front of model APIs and accumulate API keys and cloud credentials. Any platform that adopts one inherits its upstream supply-chain risk, which is exactly the path into Mercor.

Put those together and you get a system holding crown-jewel data, expanded by AI features, exposed through dependencies, and almost never included in the incident-response plan. Attackers noticed before most hiring teams did.

The data you can’t rotate

The reason a recruiting breach is worse than a typical PII leak is simple: biometric identifiers cannot be reset. As one analysis of the Mercor breach put it, “there is no ‘rotate’ button for your face” (IQ Source).

A stolen password is reissued in seconds. A leaked credit card is cancelled and reprinted. But a stolen face scan plus a voice recording is permanent, and it is precisely the raw material needed to generate convincing deepfakes. In Mercor’s case, that means impersonating contractors who have access to AI labs, a chain of consequences that outlives any password reset email. Recorded video interviews and AI voice transcripts belong in the same category. They are biometric-adjacent, they are functionally irreversible once leaked, and most companies store them with no retention or deletion policy at all.

This is the core argument for data minimization in hiring. The data you never collected cannot leak. The data you deleted on schedule cannot be in the next dump. Every video interview you keep “just in case” is a permanent liability sitting on someone else’s S3 bucket.

The legal blast radius

A candidate-data breach is not just a security incident; it is a regulatory and litigation event, and the bills land fast. Within the first week of April 2026, at least four class-action complaints were filed against Mercor, most in the U.S. District Court for the Northern District of California, with later reporting putting the count at five to six (HR Dive; ComplianceHub). One complaint proposes a nationwide class of more than 40,000 individuals, with claims spanning negligence, breach of implied contract, invasion of privacy, and California’s Unfair Competition Law. A separate Texas suit names downstream sub-vendors, turning a third-party problem into a fourth-party one.

The standing regulatory regimes raise the stakes further:

Sources: National Law Review; evidenced.app.

The pattern across all of these is the same: regulators reward minimization, documented retention, consent, and the ability to delete on request. Those are not just compliance checkboxes. They are the same controls that shrink a breach.

How to protect candidate data in an ATS: the checklist

To protect candidate data in an ATS, apply privacy-by-design: collect the minimum, encrypt it at the column level, set retention defaults that delete data on a schedule, log access, vet your vendor’s sub-vendors, honor deletion requests, and put the ATS inside your incident-response plan. Here is the short version you can hand to a vendor or your own team:

1. Minimize collection. Do not gather SSNs, full government IDs, or recorded video unless a specific stage genuinely requires them. The cheapest data to protect is the data you never took.
2. Encrypt PII at the column level. Sensitive fields should be encrypted at rest in the application layer, not just “encrypted disk” hand-waving.
3. Set retention defaults. Every candidate record, video, and transcript needs a default deletion clock measured in months, not “forever.”
4. Log access. Who viewed which resume or CV, and when, should be an auditable record.
5. Vet vendors and their vendors. Ask what dependencies and AI gateways sit behind your ATS. Mercor’s blast radius ran through a package most of its team never chose directly.
6. Honor deletion on request. GDPR and CCPA give candidates the right to be forgotten; your stack must execute it cleanly across video, transcripts, and derived data.
7. Put the ATS in your IR plan. A system holding SSNs, passports, and biometric video is a crown-jewel asset and belongs in scope, not in a blind spot.

Your ATS belongs in your incident-response plan

The single most common gap is structural: incident-response plans cover “production” infrastructure and quietly exclude the hiring system, even though the ATS often holds the most sensitive data in the company. A modern CSIRT scope explicitly includes the systems holding the most sensitive data and the legal and HR functions needed to handle breach notification (FIRST CSIRT Services Framework). An ATS holding SSNs, passports, and biometric video is exactly that kind of system.

Treating the ATS as a security surface means three concrete things. First, it appears in your asset inventory and data-flow maps with its data classification labeled. Second, its vendor and sub-vendor risk is reviewed on the same cadence as the rest of your supply chain. Third, when an incident hits, the people who can answer “what candidate data was in there and who do we have to notify” are already on the response roster, not scrambling. Most companies run hiring and security as two disconnected worlds. The Mercor lawsuits are what happens when the seam between them is where the data lives.

Data Protection in Kit

Kit encrypts candidate email and phone fields at the application layer. Email uses deterministic encryption for lookup and deduplication. This does not mean every CV field, name, and attachment uses that same mechanism.

Retention settings govern specific anonymisation workflows. Application retention starts from rejection, withdrawal, or import according to the applicable rules. Anonymisation removes specified data and attachments, not every possible recording, transcript, backup, and export on an identical timer.

Kit records views and downloads through shared CV flows. This is not a complete audit of every data read in the application. Tenant separation and permissions restrict access, while soft deletion alone is not erasure under privacy law.

The CSIRT module supports vulnerability-report handling; it does not automatically detect ATS breaches or supply the employer’s incident response plan. See the VDP setup guide and CRA disclosure article.

FAQ

Is my applicant tracking system a data breach risk?

Yes, by default it is one of your highest-risk systems, because it concentrates regulated PII (names, addresses, SSNs, government IDs, salary data) and increasingly biometric data from video interviews, while rarely being included in security programs. The risk is reducible: minimize what you collect, encrypt it, set retention limits, and bring the ATS into your incident-response scope. The Mercor breach showed the data is there whether or not you are protecting it.

What candidate data is most dangerous in a breach?

Biometric and identity data: facial scans, voice recordings, video interviews, and government-ID images. Unlike a password or credit card, these cannot be rotated or reissued, and they are the raw material for deepfakes and identity theft. SSNs are also acutely dangerous. The safest posture is to avoid collecting these at all unless a specific stage requires them, and to delete them on a fixed schedule when it does.

How long should an ATS keep candidate data?

Long enough to serve the hiring purpose and meet legal obligations, then delete it. Under GDPR you need a defined, documented retention period rather than indefinite storage, and many teams default to roughly two years for unsuccessful applicants with a clear deletion clock. Video interviews and transcripts deserve the tightest window, since they are the hardest data to defend keeping. Retention should be a configured default, not a manual cleanup nobody runs.

The bottom line

The Mercor breach is the textbook case of the ATS becoming the breach: 4TB out the door through a dependency, including the one category of data, your face and voice, that no one can ever reset. The defensible response is not buying a vendor that promises safety. It is privacy-by-design as a posture you can verify: collect less, encrypt at the column level, set retention defaults that delete on schedule, log access, vet your vendor’s vendors, and pull the hiring system inside the incident-response plan where it always belonged.

If you are auditing your hiring stack and want minimization, encryption, retention, and incident-response discipline built in from the start, start a free Kit trial and configure a privacy-by-design hiring process today.