Your ATS already has SOC 2. The audit you fail in 2026 is a different one.

Walk into any procurement security review at a Series B tech company and the questionnaire is the same. Encryption at rest, AES-256. Encryption in transit, TLS 1.2 or higher. Single sign-on through SAML 2.0 or OIDC. SCIM 2.0 for user provisioning. Role-based access controls with a documented permission matrix. Audit logs of administrator actions, kept for at least one year. Independent third-party penetration testing on an annual cadence. A SOC 2 Type 2 report under AICPA SSAE 18, scoped to the security trust service criterion at minimum and ideally to availability and confidentiality too. ISO 27001 certification if the buyer has European customers. A signed data processing addendum that maps to GDPR Article 28. A documented retention policy with the ability to purge candidate records on request.

Every entry on that list is real. Every entry is also a solved problem. Greenhouse has been ISO 27001 and SOC 2 Type 2 audited for years. Ashby went through Vanta and shipped a SOC 2 attestation by 2021. Workday Recruiting has the entire enterprise security stack as a baseline. Lever has SOC 2 Type 2. Every credible ATS in the consideration set for a 40 to 250 person tech team has shipped this layer. The differentiator is not whether the vendor has it. The differentiator is what the vendor has on top of it.

Treat the perimeter stack as a gate. If the vendor cannot produce a current SOC 2 Type 2 report under NDA within five business days, fail them at the gate. If they produce the report and the controls are in scope, move to the part of the conversation that actually decides whether the product survives 2026.

Four anchors define the 2026 AI hiring law cluster, and they all judge the ATS on the same axis: what the system does on a per-decision basis, not what it does at the perimeter. New York City Local Law 144 went into effect for enforcement in July 2023 and has been the template the rest of the regulatory pile copies from. It requires an annual independent bias audit of any automated employment decision tool that substantially assists or replaces a hiring or promotion decision, a public posting of the audit summary, and candidate notice at least ten business days before the tool is used.

Illinois HB 3773 amended the Illinois Human Rights Act effective January 1, 2026 to make it a civil rights violation for an employer to use AI in hiring, promotion, discharge, training, or discipline in a way that produces a discriminatory effect, and to require notice when AI is used. Colorado SB 24-205, the Colorado AI Act, was originally scheduled for February 1, 2026 with deployer obligations on high-risk AI systems including hiring, was amended during the 2025 session, and lands in 2026 with documented impact assessments and consumer notice obligations. The EU AI Act lists hiring and worker management systems as high-risk under Annex III, with conformity assessment, transparency, and post-market monitoring obligations phasing in through 2026 and 2027.

Read those four together and the same shape falls out. The regulator does not ask whether the resume was encrypted at rest. The regulator asks why a particular candidate was rejected, which AI inferences contributed to the rejection, which spans of the candidate's record were the evidence, what the human reviewer changed, and whether the candidate received notice that an automated decision tool was in use. Every one of those questions is per-decision. None of them is answerable from a SOC 2 control catalog.

The phrase human in the loop has been doing too much work in vendor decks for two years. Three of the four 2026 laws care less about whether a human is anywhere in the workflow and more about whether the human's input is captured as data. Colorado CAIA's deployer obligations require documented human review of consequential decisions. The EU AI Act distinguishes human oversight from human approval and requires that the reviewer have the information and authority to override, in a form that is reconstructable after the fact. NYC Local Law 144 distinguishes between AI that makes a decision and AI that substantially assists a decision; the audit obligation tracks both, and the substantially-assists definition turns on whether the human meaningfully changed the AI's output.

The data shape that satisfies all three is identical. Every AI-produced claim and every AI-produced score is a row. The row carries a column for human override with a timestamp, a reviewer ID, a reviewer role, and an optional note. The override is not a soft delete or a field replacement; it is a separate logged entry tied back to the AI row. The row that ships into the next step of the hiring funnel is the override, not the AI's first answer. If you cannot point at a row in your ATS that proves the human override happened, the human is not in the loop in any way the law recognizes.

A second, quieter test: the reviewer has to have authority to disagree. If the override field exists but the workflow gates the next step on the AI score, the reviewer is advisory, not in the loop. The law looks at whether the override actually controls the outgoing decision. The approval queue pattern (every AI write is a draft, the draft becomes the action only after a recruiter tap) survives that test. A dashboard where the AI fires the action and the reviewer audits afterward does not.

A perimeter-only ATS at step three of that flow has two artifacts to hand over: a similarity score (often a floating-point number to three decimal places) and an administrator audit log showing that a recruiter logged in and marked the candidate rejected. That is not the answer to the regulator's question. The regulator asked which claims drove the rejection. The ATS handed over a score and a login time. A reasonable regulator infers that the AI substantially assisted the decision (because there is no other input visible) and routes the case under whichever AEDT statute applies. The employer is now defending the model, which the employer did not build, with no internal visibility into how the model arrived at the score.

A claim-ledger ATS at the same step hands over the eleven-row ledger, the two override entries (one weight adjustment, one classification flip), the notice receipt showing the candidate was informed an AEDT was in use, the bias audit summary for the AEDT version that scored the candidate, and the retention status for the resume itself. The conversation moves from the AI to the rubric and the reviewer, which is where the law expects it to be.

None of this argues against the perimeter stack. The perimeter stack stops the breach that ends up in TechCrunch. It stops the contractor exfiltrating the candidate database on their last day. It stops the GDPR Article 33 seventy-two hour notification clock from starting. Those are the failures that lose the customer base. The per-decision audit stack is what loses the customer to a regulator instead of a hacker; both losses count.

The honest counterargument to everything above is that Local Law 144 enforcement has been thin, Illinois HB 3773 only kicks in this year, the Colorado AI Act has been amended and partially delayed, and the EU AI Act has a phased timeline running through 2027. A reasonable procurement officer can argue that the per-decision audit stack is a leading indicator, not a 2026 failing-grade question. That argument is correct on enforcement volume today and wrong on procurement direction. Boards accountable for hiring data and customers running procurement security reviews are already asking the per-decision questions because the laws are public, the shape is set, and a vendor that cannot produce the artifact today is a vendor that has to ship a roadmap to do so by renewal.

The buy decision in 2026 is not whether to take the perimeter stack seriously. It is whether the vendor on the other side of the table can answer the per-candidate question when one candidate complains. If the answer is yes, you have a vendor who can defend their work. If the answer is a SOC 2 report and a confidence score, you do not.

10xats is in development. Waitlist members get the first invite and the first published price. The product was designed against the per-decision audit stack first. Match Rating produces a claim ledger of 5 to 15 rows per (candidate, job) pair, each row carrying a visible weight, a must-have / nice-to-have / red flag classification, the resume span the evidence came from, and a logged recruiter override. The recruiter approval queue is the override surface; every approve, edit, or reject on a candidate-facing draft is a logged row. The privacy policy commits, in writing, to no AI training on customer data. The terms commit to a Human Oversight Required posture as a contractual obligation, not a slogan.

None of that excuses the perimeter stack. The perimeter stack ships when the product ships, and the build is aligned to the same SOC 2 Type 2 controls every credible buyer will ask about at procurement. The argument is not that the perimeter stack is optional. The argument is that the per-decision audit stack is what should decide the buy, and the perimeter stack is what should decide whether the vendor is in the room at all.

If you are evaluating an ATS in 2026 and the per-decision audit stack is not on the questionnaire, add it. Ask the vendor for one candidate's audit trail. The quality of the answer is the buy decision.