Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  / ,

  / SOC 2 Penetration Testing Cost: 2026 Price Ranges

SOC 2 Penetration Testing Cost: 2026 Price Ranges

A SOC 2 penetration test costs between $1,000 and $30,000 for most companies. A typical SaaS scope, meaning one web application, its API layer, and the cloud infrastructure behind it, usually lands between $2,000 and $20,000. Early-stage startups with a narrow scope can get an auditor-accepted test for $1,000 to $8,000, while enterprises with multiple products and hybrid infrastructure regularly spend $20,000 to $50,000 or more.

The spread is wide because “penetration test” covers everything from an automated scan with a cover page to weeks of manual testing by senior engineers. Auditors know the difference, and so do the enterprise customers who asked for your SOC 2 report in the first place. This guide breaks down what drives the price, where the hidden costs sit, and how to buy a test that holds up in fieldwork without overpaying for it.

What Is SOC 2 Penetration Testing?​

A SOC 2 penetration test is a simulated attack on your systems, performed by a qualified security professional, scoped to the environment covered by your SOC 2 report. The tester tries to exploit real weaknesses the way an attacker would: broken access controls, injection flaws, misconfigured cloud services, exposed credentials. The output is a report your auditor reads as evidence that your security controls work in practice, not only on paper.

That last part matters. A pentest bought for SOC 2 has a second audience beyond your security team. If the report doesn’t map findings to your audit scope, document its methodology, and show remediation, it fails the job you bought it for. We cover the full deliverable in our guide to what a SOC 2-ready VAPT report includes.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

How Penetration Testing Fits Into SOC 2 Compliance​

SOC 2 is built on the AICPA’s Trust Services Criteria, and the Security category (the Common Criteria) applies to every report. Penetration testing is the standard way to satisfy CC7.1, which expects you to detect and monitor for new vulnerabilities, and it supports CC4.1, which covers ongoing evaluations of whether controls actually function. The AICPA’s points of focus explicitly mention vulnerability scanning and penetration testing as examples of how companies meet these criteria.

In practice, the test slots into your audit timeline as an evidence item. Your auditor will ask for the report, check the test date against the audit period, and review how you handled the findings. Remediation is often scrutinized harder than the test itself, because it shows whether your vulnerability management process runs or merely exists.

Is Penetration Testing Required for SOC 2?​

Strictly speaking, no. The Trust Services Criteria never use the word “mandatory” about penetration testing. You could theoretically satisfy CC7.1 with vulnerability scanning and strong monitoring alone.

In reality, almost every auditor expects one, and skipping it invites two problems. First, your auditor may push back during fieldwork or add exceptions to the report. Second, the enterprise buyers reviewing your SOC 2 report increasingly look for pentest evidence specifically, and a report without it raises questions during procurement. Treat the test as effectively required and budget for it from the start of your SOC 2 compliance checklist.

How Much Does SOC 2 Penetration Testing Cost?

Typical Price Range for SOC 2 Pen Testing

Most companies pay $4,000 to $30,000, with the median engagement for a SaaS business sitting around $12,000 to $15,000. Compliance-focused tests at the bottom of the market start around $4,000 to $5,000. Deep manual testing from established firms runs $15,000 to $30,000. Anything quoted below roughly $3,000 is almost certainly automated scanning packaged as a pentest, which auditors are getting better at spotting.

Cost by Company Size (Startup, SMB, Enterprise)​

Company size is a proxy, not the driver. A 15-person company with three products and a legacy on-prem component will pay more than a 200-person company with one tightly scoped SaaS platform. Testers price effort, and effort follows scope.

Cost by Test Type (Network, Web App, API, Cloud, Internal/External)

Most SOC 2 engagements bundle two or three of these. The common package for a cloud-native SaaS company is web app plus API plus cloud configuration, which is why the $2,000 to $20,000 band comes up so often. Companies with office networks and internal systems in their audit scope add internal network testing, and the price climbs accordingly.

Factors That Influence SOC 2 Penetration Testing Cost

Scope and Number of Assets Tested

Scope is the single biggest cost driver. Every additional application, API endpoint group, cloud account, or network segment adds testing hours. A pentest priced without a scoping call is a pentest priced on guesswork, and the guess usually favors the vendor.

Complexity of Application or Infrastructure​

A simple CRUD app with two user roles tests quickly. A multi-tenant platform with role hierarchies, workflow engines, file processing, and third-party integrations takes far longer, because each of those features creates attack surface a tester has to work through manually. Authentication tiers matter especially: every distinct role needs testing for privilege escalation and cross-tenant data access.

Testing Methodology (Black Box, Grey Box, White Box)

Black box testing gives the tester nothing but a URL, grey box adds credentials and documentation, and white box adds source code and architecture diagrams. Grey box is the default for SOC 2 and usually the best value, since the tester spends time exploiting rather than discovering. White box costs more upfront but finds deeper issues. Black box sounds rigorous but often wastes paid hours on reconnaissance an attacker would run for free.

Depth of Testing and Manual vs. Automated Approaches

Automated scanning finds known vulnerability patterns. Manual testing finds business logic flaws, chained exploits, and authorization gaps that no scanner catches, and it’s the part auditors and security-literate customers actually value. The ratio of manual work to automation is the honest explanation for most price differences between two quotes covering the same scope.

Tester Credentials and Firm Reputation

Senior testers holding OSCP, GPEN, or CREST credentials bill higher rates, and firms with recognized methodologies charge a premium for the credibility their letterhead carries in an audit. That premium is sometimes worth paying. When your SOC 2 report goes to a bank or a Fortune 500 procurement team, the testing firm’s name gets read too.

Remediation Testing and Retesting Fees​

After you fix the findings, someone has to verify the fixes. Some firms include one retest round in the base price, others charge $1,500 to $5,000 for it. Always ask before signing, because a Type 2 audit without retest evidence for critical findings is an awkward conversation with your auditor.

Location and Compliance Requirements

Testing firms in the US and UK typically charge more than firms in other regions for equivalent work, though rates have converged as remote testing became the norm. Stacked compliance requirements also raise price: a test that must satisfy SOC 2 and PCI DSS simultaneously carries extra documentation and methodology constraints.

SOC 2 Type 1 vs. Type 2 Penetration Testing Costs

Pen Testing for Type 1 Reports

A Type 1 report assesses control design at a single point in time, so one pentest completed before the audit date is sufficient. Companies pursuing Type 1 first often buy a smaller, tightly scoped test to keep first-year costs down, then expand scope for Type 2. The per-test price doesn’t differ from Type 2 pricing; you simply buy fewer of them.

Pen Testing for Type 2 Reports

A Type 2 report covers control operation over an observation window, usually 3 to 12 months, and your pentest needs to fall inside that window. The test itself costs the same, but the timing discipline is stricter and the remediation evidence matters more, because the auditor evaluates your process over time rather than a snapshot.

Insider Note: The most common pentest problem we see in SOC 2 engagements isn’t quality, it’s timing. Companies run their test three or four months before the Type 2 observation window opens, assume it counts, and only discover during fieldwork that the auditor wants a test dated inside the period. Booking the pentest for the early-middle portion of the window solves this and still leaves room to remediate before the audit closes.

Frequency Requirements for Type 2​

Annual testing is the accepted baseline, and since Type 2 reports are renewed annually, the practical effect is one pentest per audit cycle. Companies with fast release cadences or contractual obligations sometimes move to semi-annual testing, doubling the budget line. Significant architecture changes mid-cycle, like a new product launch or cloud migration, also justify an out-of-cycle test.

What’s Included in a SOC 2 Penetration Test Quote

Pre-Engagement Scoping

A serious quote starts with a scoping call: what’s in your SOC 2 system boundary, how many applications and roles, which cloud accounts, what’s explicitly excluded. This produces the rules of engagement, a practice NIST SP 800-115 formalizes, covering what may be tested, when, and who gets called if something breaks.

Testing Execution

The testing window itself typically runs one to three weeks. Good firms test against a documented methodology, commonly built on the OWASP Top 10 and OWASP’s testing guides for application work, with NIST SP 800-115 or PTES structuring the overall engagement. Expect a mid-engagement heads-up if a critical finding shows up, rather than a surprise in the final report.

Reporting and Attestation Letter​

The report should contain an executive summary, the methodology, findings rated by severity (usually CVSS-based) with reproduction evidence, and remediation guidance. Most firms also issue a short attestation letter you can hand to customers without exposing technical detail. Confirm the letter is included, since a few vendors sell it separately.

Remediation Support and Retesting​

Quotes differ most here. Some include remediation consultation hours and one retest; others hand you the report and charge for everything after. For SOC 2 specifically, retest documentation for high and critical findings is worth having inside the audit window, so treat included retesting as a genuine pricing factor rather than a nice-to-have.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Hidden Costs to Watch For

The invoice from the testing firm is rarely the whole spend. Your engineers will spend real hours on the engagement: scoping calls, provisioning test accounts, monitoring during testing, and triaging findings, which for a small team often adds up to one to two weeks of a senior engineer’s time. Then comes remediation itself, which can range from a day of configuration changes to a quarter of refactoring if the test surfaces architectural problems.

Rush fees are the other trap. Firms charge 25 to 50 percent premiums for tests booked inside two or three weeks of the start date, and companies discover this exactly when an auditor or enterprise deal imposes a deadline. Finally, remember this is an annual cost. SOC 2 Type 2 renews yearly, and your pentest budget line renews with it.

Pro Tip: When to get a Pentest Quote

Get a pentest quote at the same time you budget your SOC 2 audit, not after. Bundling the conversation forces the scope question early, gives you a real total compliance number, and removes the rush-fee scenario entirely. If you're pricing the full stack, our breakdown of what Vanta actually costs covers the automation platform side of the budget.

How to Reduce SOC 2 Penetration Testing Costs

Scope the Engagement Strategically

Align the pentest scope with your SOC 2 system boundary, not your entire infrastructure. If the marketing website and the internal wiki sit outside the audit scope, they don’t need paid testing hours. A tight, well-documented boundary is the single most effective cost control without reducing quality.

Combine Pen Testing With Other Compliance Work

One properly scoped test can serve SOC 2, ISO 27001, and customer security questionnaires simultaneously if the scoping and reporting anticipate all three. Buying separate tests per framework is a common and entirely avoidable double-spend. Firms that do both compliance and testing can also bundle the pentest into a certification engagement at a better rate.

Choose the Right Testing Partner

Big-name firms carry enterprise overhead in their pricing. Specialist boutiques with credentialed testers frequently deliver equivalent technical work at 30 to 50 percent less, and their reports are just as audit-acceptable if the methodology and documentation are sound. The evaluation criteria in the next section matter more than the size of the vendor’s office.

Perform Internal Vulnerability Scans First

Run scans and fix the obvious findings before the pentest starts. Every hour a paid tester spends documenting an unpatched library or a default credential is an hour not spent on the deep manual work you’re actually paying for. Clean scan hygiene going in raises the value of every finding coming out.

How to Choose a SOC 2 Penetration Testing Provider

Questions to Ask Before Hiring

Ask five things:

  • What percentage of the testing is manual, and who exactly performs it?
  • Can you share a sanitized sample report?
  • Is a retest included, and at what cost if not?
  • Have your reports been through SOC 2 audits before, and with which audit firms?
  • What happens if you find something critical mid-engagement?

The sample report answers most of what you need. A strong one shows reproduction steps, business impact per finding, and severity reasoning. A weak one lists scanner output grouped by CVSS score.

Certifications to Look For (OSCP, CREST, CEH)

OSCP demonstrates hands-on exploitation skill and is the most respected practitioner credential for this work. CREST accredits firms as well as individuals and carries particular weight in the UK and internationally. GPEN signals solid methodology training. CEH is knowledge-based rather than practical, fine as a floor but weak as the lead credential of your primary tester. On team composition, one senior credentialed tester leading the engagement matters more than a large team of juniors.

Red Flags in Low-Cost Providers

Be wary of fixed prices quoted without any scoping conversation, guaranteed turnaround under a week for a full application test, reluctance to share a sample report, and vagueness about who performs the testing.

“Compliant pentest” as a marketing phrase is itself a tell: it signals the product is a checkbox, and checkbox reports are precisely what auditors have learned to probe.

Sample SOC 2 Penetration Testing Cost Scenarios

Early-Stage SaaS Startup

A 12-person startup pursuing SOC 2 Type 1 with one web application, a REST API, and a single AWS account. Grey box test, one senior tester, one week of testing, retest included. Realistic cost: $1,000 to $9,000.

Mid-Market SaaS Company

A 120-person company on Type 2 with two applications, a public API, AWS and GCP accounts, and SSO integration. Grey box, two testers, two to three weeks, retest and attestation letter included. Realistic cost: $2,000 to $22,000.

Enterprise Multi-Product Environment

A 600-person company with four products, internal corporate network in audit scope, hybrid cloud and on-prem infrastructure, and a PCI DSS overlap. Mixed grey and white box, senior team, four to six weeks. Realistic cost: $15,000 to $60,000, often split across quarterly engagements.

A pentest for SOC 2 is a five-figure line item for most companies, and the range you land in comes down to scope, manual depth, and timing. Buy the scoping call, keep the test inside your audit window, confirm retesting upfront, and match the firm’s credentials to the audiences who’ll read the report. Done that way, the same spend covers your audit evidence, your customer questionnaires, and a genuine reduction in exploitable risk. If you want the test scoped against your actual audit boundary, Axipro delivers penetration testing built for SOC 2 and ISO 27001 audits across web, API, network, and cloud environments.

Frequently Asked Questions

Is a penetration test mandatory for SOC 2?

No, the Trust Services Criteria don’t explicitly require one. In practice nearly all auditors expect a pentest as evidence for CC7.1, and its absence commonly triggers pushback during fieldwork or questions from customers reviewing your report. Budget for it as if it were mandatory.

Annually is the accepted standard, aligned with your yearly Type 2 audit cycle. Test more often if you ship major architecture changes, launch new products, or carry contractual obligations that demand it.

Not for most audits. Scanning is automated pattern-matching against known issues, while a pentest involves a human attempting real exploitation, including business logic and authorization flaws scanners can’t find. Auditors treat them as complementary controls, and most expect both: continuous or periodic scanning plus an annual manual test.

Testing itself takes one to three weeks for typical SaaS scopes, with the report arriving one to two weeks after testing ends. Add scheduling lead time: reputable firms book two to six weeks out, which is exactly why rush fees exist.

No, and it shouldn’t. Your SOC 2 auditor is a CPA firm attesting to your controls; the pentest comes from an independent security firm and feeds into the audit as evidence. Some audit firms have testing arms, but independence between the two functions is the cleaner arrangement and the one enterprise customers prefer.

Scope tightly to your audit boundary, fix scanner-level findings before the engagement, book six or more weeks ahead, and use a specialist boutique rather than a big-name firm. That combination gets a legitimate manual test down to the $4,000 to $8,000 range for a simple SaaS scope. Going below that usually means buying a scan, which costs less now and more later.

Yes. Each annual Type 2 report covers a new observation period, and auditors expect pentest evidence dated within that period. Last year’s report demonstrates last year’s controls, and reusing it is one of the fastest ways to collect an exception.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

A SOC 2 penetration test costs between $1,000 and $30,000 for most companies. A typical SaaS scope, meaning one web application, its API layer, and the cloud infrastructure behind it, usually lands between $2,000 and $20,000. Early-stage startups with a narrow scope can get an auditor-accepted test for $1,000 to $8,000, while enterprises with multiple products and hybrid infrastructure regularly spend $20,000 to $50,000 or more. The spread is wide because “penetration test” covers everything from an automated scan with a cover page to weeks of manual testing by senior engineers. Auditors know the difference, and so do the enterprise customers who asked for your SOC 2 report in the first place. This guide breaks down what drives the price, where the hidden costs sit, and how to buy a test that holds up in fieldwork without overpaying for it. What Is SOC 2 Penetration Testing?​ A SOC 2 penetration test is a simulated attack on your systems, performed by a qualified security professional, scoped to the environment covered by your SOC 2 report. The tester tries to exploit real weaknesses the way an attacker would: broken access controls, injection flaws, misconfigured cloud services, exposed credentials. The output is a report your auditor reads as evidence that your security controls work in practice, not only on paper. That last part matters. A pentest bought for SOC 2 has a second audience beyond your security team. If the report doesn’t map findings to your audit scope, document its methodology, and show remediation, it fails the job you bought it for. We cover the full deliverable in our guide to what a SOC 2-ready VAPT report includes. How Penetration Testing Fits Into SOC 2 Compliance​ SOC 2 is built on the AICPA’s Trust Services Criteria, and the Security category (the Common Criteria) applies to every report. Penetration testing is the standard way to satisfy CC7.1, which expects you to detect and monitor for new vulnerabilities, and it supports CC4.1, which covers ongoing evaluations of whether controls actually function. The AICPA’s points of focus explicitly mention vulnerability scanning and penetration testing as examples of how companies meet these criteria. In practice, the test slots into your audit timeline as an evidence item. Your auditor will ask for the report, check the test date against the audit period, and review how you handled the findings. Remediation is often scrutinized harder than the test itself, because it shows whether your vulnerability management process runs or merely exists. Is Penetration Testing Required for SOC 2?​ Strictly speaking, no. The Trust Services Criteria never use the word “mandatory” about penetration testing. You could theoretically satisfy CC7.1 with vulnerability scanning and strong monitoring alone. In reality, almost every auditor expects one, and skipping it invites two problems. First, your auditor may push back during fieldwork or add exceptions to the report. Second, the enterprise buyers reviewing your SOC 2 report increasingly look for pentest evidence specifically, and a report without it raises questions during procurement. Treat the test as effectively required and budget for it from the start of your SOC 2 compliance checklist. How Much Does SOC 2 Penetration Testing Cost? Typical Price Range for SOC 2 Pen Testing Most companies pay $4,000 to $30,000, with the median engagement for a SaaS business sitting around $12,000 to $15,000. Compliance-focused tests at the bottom of the market start around $4,000 to $5,000. Deep manual testing from established firms runs $15,000 to $30,000. Anything quoted below roughly $3,000 is almost certainly automated scanning packaged as a pentest, which auditors are getting better at spotting. Cost by Company Size (Startup, SMB, Enterprise)​ Company size is a proxy, not the driver. A 15-person company with three products and a legacy on-prem component will pay more than a 200-person company with one tightly scoped SaaS platform. Testers price effort, and effort follows scope. Cost by Test Type (Network, Web App, API, Cloud, Internal/External) Most SOC 2 engagements bundle two or three of these. The common package for a cloud-native SaaS company is web app plus API plus cloud configuration, which is why the $2,000 to $20,000 band comes up so often. Companies with office networks and internal systems in their audit scope add internal network testing, and the price climbs accordingly. Factors That Influence SOC 2 Penetration Testing Cost Scope and Number of Assets Tested Scope is the single biggest cost driver. Every additional application, API endpoint group, cloud account, or network segment adds testing hours. A pentest priced without a scoping call is a pentest priced on guesswork, and the guess usually favors the vendor. Complexity of Application or Infrastructure​ A simple CRUD app with two user roles tests quickly. A multi-tenant platform with role hierarchies, workflow engines, file processing, and third-party integrations takes far longer, because each of those features creates attack surface a tester has to work through manually. Authentication tiers matter especially: every distinct role needs testing for privilege escalation and cross-tenant data access. Testing Methodology (Black Box, Grey Box, White Box) Black box testing gives the tester nothing but a URL, grey box adds credentials and documentation, and white box adds source code and architecture diagrams. Grey box is the default for SOC 2 and usually the best value, since the tester spends time exploiting rather than discovering. White box costs more upfront but finds deeper issues. Black box sounds rigorous but often wastes paid hours on reconnaissance an attacker would run for free. Depth of Testing and Manual vs. Automated Approaches Automated scanning finds known vulnerability patterns. Manual testing finds business logic flaws, chained exploits, and authorization gaps that no scanner catches, and it’s the part auditors and security-literate customers actually value. The ratio of manual work to automation is the honest explanation for most price differences between two quotes covering the same scope. Tester Credentials and Firm Reputation Senior testers holding OSCP, GPEN, or CREST credentials bill higher rates, and firms with recognized methodologies charge a premium for the credibility their letterhead carries in

Two compromised versions of LiteLLM sat on PyPI for roughly 40 minutes on the morning of March 24, 2026. That window was enough to capture secrets from around 434,000 CI/CD pipeline runs across nearly 2,500 organizations, including AWS, Samsung, Cisco, Salesforce, Siemens, and Deloitte. In August, researchers at CloudSEK and Hudson Rock confirmed they had obtained the raw exfiltrated data: a 153GB archive containing 433,909 files of environment variables, cloud keys, Kubernetes secrets, and API tokens harvested live from running pipelines, as covered by Help Net Security’s reporting on the credential archive. If LiteLLM runs anywhere in your stack, or you touch any AI proxy infrastructure at all, you need answers to three things: whether you were exposed, what to rotate first, and whether the rotation you did back in March actually held. That last one matters more than it sounds, because “we rotated everything” has already burned at least one very large company. How the Breach Happened The attack didn’t start with LiteLLM. On March 19, 2026, a threat group called TeamPCP compromised the build pipeline of Trivy, a vulnerability scanner half the industry runs, and pushed a poisoned release. LiteLLM’s own CI pipeline ran Trivy, so the poisoned scanner had legitimate read access to the project’s runner environment. The attackers used that to steal LiteLLM’s PyPI publishing tokens and ship two malicious releases of their own: versions 1.82.7 and 1.82.8. KICS and the Telnyx Python SDK got hit in the same campaign. The payload design is the part worth studying. The malicious package dropped a .pth startup hook into site-packages, so the code ran the moment any Python interpreter started on the machine, whether or not anything imported LiteLLM. From there it harvested environment variables, read local credential files like .aws/credentials and .kube/config, tried to move laterally across Kubernetes clusters, and installed a systemd backdoor dressed up as a generic telemetry service. InfoQ’s coverage of the PyPI compromise put downloads of the compromised release above 40,000. For scale, LiteLLM normally gets downloaded around 3 million times a day. The exfiltration had a nasty fallback, too. According to CloudSEK, stolen data was encrypted and sent to a typosquatted domain, and when that failed, the malware created a public repository inside the victim’s own GitHub account and uploaded the loot as a release asset. Some companies were publishing their own secrets to the open internet and had no idea. Worth Knowing: The malicious code only existed in the PyPI artifacts. The GitHub source repository stayed clean the whole time, so a developer reviewing the code on GitHub saw nothing wrong. Source review isn’t artifact verification. If you don’t check that what the registry serves matches the upstream source, this class of attack is invisible to you. How to Check If You Were Exposed Three checks, from quickest to most involved. 1. Confirm whether the compromised versions ever ran The malicious versions went live on PyPI at 10:39 UTC on March 24, 2026 and got quarantined about 40 minutes later. The project’s advice: treat any install from that day before 16:00 UTC as suspect. Search your lockfiles, pip caches, SBOMs, and container image histories for 1.82.7 and 1.82.8. And check your internal artifact mirrors. An Artifactory or Nexus proxy that cached the bad release in March can keep serving it internally long after PyPI pulled it. Keep the .pth mechanism in mind when you scope this. The question isn’t “which applications import LiteLLM,” it’s “which machines had the package installed at all,” because every Python process on an infected machine triggered the payload. 2. Hunt for persistence Rotation is pointless if the attacker still has a foothold. Check developer machines, CI runners, and containers for unauthorized .pth files in site-packages and for suspicious systemd units, especially anything posing as a system telemetry service. And review activity from March 24 onward, not just the 40-minute window. Persistence is there so the access outlives the infection. Pro Tip: Don’t limit the persistence hunt to live machines. Base container images rebuilt in late March may have baked the payload into every image derived from them since. Scan your image registry for the affected LiteLLM versions and for unexpected .pth files, then trace which running workloads came from flagged images. 3. Check whether your secrets are in the dump Hudson Rock has published a domain lookup tool and is running ethical disclosures for affected organizations, and CloudSEK maintains a high-confidence victim list. Use them, but know their limits. Attribution in this dataset is genuinely hard. One dump with a siriusxm.com committer email actually traced, through its self-hosted GitLab endpoints, to AdsWizz, a SiriusXM subsidiary. And a large share of the dumps are generic pipeline configurations with no identifying domain, email, or server name at all. Absence from a victim list is not evidence of absence. If your pipelines ran the compromised versions, assume exposure no matter what a lookup tool tells you. What to Rotate, in What Order The guidance from both research teams is blunt: treat every secret the LiteLLM environment could reach as compromised. That covers secrets on disk, in memory, injected into CI jobs, and anything retrievable through instance metadata services. Work down by blast radius: Priority Credential type Why it comes first 1 Cloud IAM keys (AWS, GCP, Azure) Direct control of infrastructure, data stores, and billing. This is where attackers monetize fastest. 2 GitHub and GitLab PATs, package publishing tokens These let an attacker poison your releases and turn your company into the next link in the supply chain. 3 Kubernetes service account tokens and kubeconfigs Lateral movement across clusters was built into the payload, not a theoretical risk. 4 Database passwords and third-party API keys Dumped in plain text in the archive, often with no attribution, so nobody will warn you they leaked. 5 AI provider API keys Billing abuse, quota theft, and access to whatever data flows through your LLM routing layer. One word matters more than the rest of this article: revoke, don’t just rotate. That

The EU AI Act names recruitment AI as high-risk. Annex III explicitly lists AI systems used for recruitment, candidate selection, and employment decisions, which pulls CV screeners, video interview platforms, and assessment tools into the most demanding compliance regime the Act contains. The original compliance date for these systems was August 2, 2026. In June 2026, the EU’s Digital Omnibus moved the deadline to December 2, 2027, a 16-month extension that has led many HR and talent teams to shelve the topic entirely. That’s a mistake, for two reasons. First, one rule that directly affects recruitment technology is already in force: the ban on emotion recognition in the workplace has applied since February 2, 2025, and it catches features still shipping in some video interview products today. Second, the deferred obligations didn’t shrink. Conformity assessments, human oversight design, bias monitoring, and documentation all still arrive in full, and the practical work of auditing a recruitment stack, renegotiating vendor contracts, and training hiring teams routinely takes a year or more. Here’s what the EU AI Act actually requires of employers and vendors using recruitment tools, on the timeline that now applies. Why Recruitment Tools Are Classified as High-Risk Under the EU AI Act​ Definition of High-Risk AI Systems in Hiring​ The Act takes a list-based approach. Annex III, point 4, designates as high-risk any AI system intended for the recruitment or selection of natural persons, including placing targeted job advertisements, analyzing and filtering applications, and evaluating candidates. The same point covers AI used for decisions on promotion, termination, task allocation, and monitoring of workers, so the classification follows the tool through the entire employment lifecycle, not just the hiring funnel. The reasoning is straightforward: hiring decisions shape access to livelihoods, and algorithmic discrimination in hiring is well documented. The European Commission’s regulatory framework for AI treats employment as one of the areas where an AI error or bias causes serious harm to fundamental rights. That’s the test for the high-risk tier. Types of Recruitment Tools Affected In practice, the high-risk classification captures most of the modern recruitment stack: CV and resume screeners that rank or filter applicants, video interview platforms that score responses or delivery, psychometric and skills assessment tools that produce scores feeding a hiring decision, sourcing and matching algorithms that decide which candidates a recruiter sees, and programmatic job ad targeting systems that determine who sees a vacancy at all. If the system’s output materially influences who advances and who does not, assume high-risk until proven otherwise. Important: Emotion recognition is not high-risk in the workplace. It is prohibited. Article 5 bans AI systems that infer emotions of people in the workplace (outside narrow medical and safety cases), and that ban has applied since February 2025 with the Act’s top penalty tier attached. If your video interview vendor markets “engagement scoring” or “sentiment analysis” of candidates, that feature needs to be switched off for EU hiring now, not in 2027. Recruitment Tools That May Fall Outside High-Risk Classification Not everything in the HR stack qualifies. The Act carves out systems performing narrow procedural tasks that do not materially influence decision outcomes. An applicant tracking system that stores applications, schedules interviews, and sends templated emails is a database with a workflow, not a high-risk AI system. The same goes for tools that transcribe interviews without scoring them, deduplicate candidate records, or generate first drafts of job descriptions for a human to edit. The line is decision influence: the moment a tool ranks, scores, filters, or recommends candidates, it crosses into Annex III territory. Deployers who rely on an exemption must be able to document that assessment, so “we decided it doesn’t count” needs to exist on paper. Extraterritorial Scope: Which Employers Are Covered The Act applies to providers placing AI systems on the EU market and to deployers established in the EU, but it also reaches further: it covers providers and deployers located outside the EU where the output of the system is used in the EU. For recruitment, the consequence is blunt. A US or UK company with no EU entity that uses an AI screener to filter applicants for roles based in Berlin or Dublin, or that screens candidates located in the EU, is using the system’s output in the Union. Brexit doesn’t move UK employers out of scope when they hire into or from the EU. Providers vs. Deployers of Recruitment AI Tools The Act splits obligations between the provider (the vendor that develops the tool and places it on the market) and the deployer (the employer using it). Most employers are deployers, and deployer obligations are lighter but real. One common trap: an employer that substantially modifies a high-risk system, or puts its own name on it, can be reclassified as a provider and inherit the full provider stack. Heavy customization of a screening model, or fine-tuning it on your own hiring data, can be enough to trigger this. Key Obligations for Employers Using AI Recruitment Tools Human Oversight in Automated Hiring Decisions Deployers must assign oversight of the system to people with the competence, training, and authority to intervene. That last word matters. A recruiter who rubber-stamps whatever the ranking algorithm produces, because nobody has time to review 800 rejected CVs, doesn’t count as oversight. Regulators and courts will look at whether the human could genuinely override the system and whether they ever did. Designing review checkpoints where a person can meaningfully change the outcome, and logging when they do, is the core of compliant deployment. Transparency Requirements Toward Candidates Employers must inform workers and their representatives before putting a high-risk AI system into use at work, and candidates subjected to such a system must be told it is being used. In countries with works councils, such as Germany, this obligation lands on top of existing co-determination rights, so employee representatives may need to be consulted before the tool goes live rather than just told afterward. Burying an AI disclosure in a privacy policy paragraph is unlikely to survive scrutiny.