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.

How Kit approaches this

Kit is a combined hiring and security platform, and the Mercor failures map onto controls it already implements, which is why this is a posture argument rather than a marketing one. None of it makes any vendor breach-proof, supply-chain attacks can hit anyone, but the right defaults shrink both the blast radius and the regulatory exposure when something goes wrong.

• Column-level encryption of candidate PII. Kit encrypts the most sensitive candidate fields at rest using Active Record Encryption. Email is encrypted deterministically so it stays queryable for deduplication, while fields that need no lookups are encrypted non-deterministically. The “store PII encrypted, not in plaintext” lesson, made concrete.
• Retention as a first-class setting. Candidate consent carries a configurable retention window with a sensible default measured in months, and consent itself can be renewed, declined, and expired rather than stored indefinitely. Data you delete on schedule cannot be in the next dump.
• Disciplined handling of video and transcripts. Recorded interviews and AI transcripts are treated as the biometric-adjacent, retention-bound assets they are, with access to candidate CVs logged for an audit trail.
• Multi-tenant isolation and defensible deletion. Candidate data is scoped per account, and soft-delete plus access logging support the “right to delete” that GDPR and CCPA require.
• A built-in CSIRT vertical. Because Kit ships a full vulnerability-disclosure and incident-response module alongside hiring, the same response discipline applied to production can cover the ATS. The two worlds that Mercor kept separate are one surface here.

We covered standing up the response side of this in how to set up a vulnerability disclosure program, and the compliance pressure now bearing down on small teams in the EU Cyber Resilience Act’s disclosure deadline. This article is the candidate-data layer that sits underneath both.

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.