GDPR, CPRA, and the new compliance floor for HR tech

For most of the last decade, "privacy compliance" for hiring tools meant a paragraph in the master services agreement, an annual SOC 2 audit, and a checkbox in the security questionnaire that said "GDPR-ready." That floor has risen. Multiple converging regimes now impose specific, enforceable obligations on the vendors who handle candidate data — and on the employers who contract with them. This is a non-lawyer walkthrough of what the law actually says in 2026, what it requires of HR tech vendors, and the questions every employer should be asking before they sign a contract.

GDPR Article 22: automated hiring decisions

Article 22 of the General Data Protection Regulation is the provision most relevant to modern hiring tools and the one most vendors handle worst. The text is short. A data subject — the candidate — has the right not to be subject to a decision based solely on automated processing that produces legal effects concerning them or similarly significantly affects them. A rejection from a job is exactly such a decision. If an algorithm is the sole decider, Article 22 is implicated, and the candidate gets specific rights: human review, the right to express their point of view, the right to contest the decision.

Article 22 does not ban automated hiring decisions. It conditions them. The conditions are demanding. The vendor and the employer must be able to show that there was a human in the loop, that the human had real authority to override the algorithm, that the candidate was informed about the automated processing in advance, and that the candidate could exercise their right to contest. Most current ATSes can show the first two. Few can show the third or fourth in a way that survives a real audit. The disclosure language buried in a privacy policy is not, in most regulators' view, sufficient notice.

GDPR Article 9: special category data

Article 9 prohibits processing special category personal data — including racial or ethnic origin, religious beliefs, health data, sexual orientation, and trade union membership — without one of a narrow set of legal bases. Explicit consent is one. So is processing necessary for compliance with employment law obligations. Neither of these is a free pass. Explicit consent means specific, informed, freely given, and revocable — and for special category data, the consent must specifically identify the special category being processed.

This is where ATS schema decisions become a legal exposure. If your vendor stores fields for ethnicity, religion, or disability in the candidate object — even as nullable fields, even with no current users populating them — you are processing special category data the moment any record uses them, and you need a documented Article 9 basis. The cleanest answer is to not collect the data at all. The second cleanest is to isolate it in a separate schema with separate access controls and a separate purpose limitation that is explicitly tied to a documented legal obligation. Most vendors' answer in 2026 is "the field exists but we never look at it," which is not a legal basis under any reading of Article 9.

CPRA § 1798.140(ah): the redefinition of "share"

When the California Consumer Privacy Act was amended into the California Privacy Rights Act in 2020, one definition expanded in a way that has taken HR tech vendors three years to catch up to. The amended statute defines "share" — which triggers the right to opt out — as the transfer of personal information to a third party for cross-context behavioral advertising, whether or not money changes hands. Many integrations that vendors previously characterized as data partnerships or syndication arrangements now meet the statutory definition of "share." The vendor owes the candidate an opt-out, and the opt-out has to be honored through the global privacy control browser signal as well as via an explicit page.

For employers, the practical implication is that vendor relationships you previously treated as ordinary subcontractor agreements may now require a separate disclosure to your candidates and a separate opt-out pathway. The data processing addendum your vendor signed in 2021 almost certainly does not cover the 2023 definition. Ask for an updated DPA. If the vendor cannot produce one, that is the answer.

US state laws: NYC and Colorado as harbingers

Two US state-and-local laws have shifted the landscape more than their geographic scope suggests. New York City Local Law 144, in effect since 2023, requires bias audits of any automated employment decision tool used to screen candidates for jobs in the city. The audit has to be conducted by an independent auditor, the results have to be published, and the candidate has to be notified at least ten business days before the tool is used on their application. The law has teeth — civil penalties — and has been followed closely by similar laws in Illinois and a draft proposal in Maryland.

The Colorado Artificial Intelligence Act, passed in 2024 and effective February 2026, goes further. It applies statewide to any high-risk AI system used in employment, defines high-risk broadly enough to cover most modern hiring tools, and imposes specific obligations on developers and deployers including risk assessment documentation, ongoing monitoring, and consumer notification. The compliance burden is real, but the more interesting development is the model it provides for other states — at least six other state legislatures have proposed similar laws using Colorado's language as a template.

What this means for vendor RFPs

The good news is that the questions an employer needs to ask are now reasonably standardized. The bad news is that most vendor RFP response decks are not yet written to answer them. The questions:

• For GDPR Article 22: when the platform makes an automated decision adverse to a candidate, what mechanism documents the human review, and can we produce that documentation in a discovery request?
• For GDPR Article 9: list every field in the schema that could plausibly contain special category data, and the legal basis for processing each one.
• For CPRA "share": list every third party that receives candidate-level data of any kind, the purpose of each transfer, and whether the candidate has a working opt-out for each.
• For NYC Local Law 144 and Colorado AI Act: provide the most recent bias audit report and the supporting documentation for high-risk AI risk assessments.
• For all of the above: provide a copy of the data processing addendum with the explicit changes from the 2020 version highlighted.

“The privacy compliance gap in HR tech is no longer a legal-team problem. It is a buying-team problem. The vendors that survive the next three years are the ones whose architectures answer these questions before they are asked.”

A note on the floor versus the ceiling

Everything above describes the floor. It is the minimum a serious vendor in 2026 should be able to demonstrate. Some vendors will exceed the floor — by, for example, refusing to collect special category data at all rather than documenting a legal basis to do so, or by honoring opt-outs cookie-free across browsers. Those choices are not legal requirements. They are signals of intent. Employers who treat privacy as a procurement risk to manage will get the floor. Employers who treat it as a candidate-experience commitment will end up on the right side of every future regulation, and they will not have to renegotiate every contract when the floor moves again. The floor will keep moving.