Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  /

  / CMMC Readiness Assessment: Find Gaps Before Your C3PAO

CMMC Readiness Assessment: Find Gaps Before Your C3PAO

CMMC requirements started appearing in Department of Defense contracts on November 10, 2025, when the final DFARS rule took effect. By November 10, 2028, the clause at DFARS 252.204-7021 must appear in every solicitation and contract where contractor systems process, store, or transmit Controlled Unclassified Information (CUI). For most of the Defense Industrial Base (DIB), the math is blunt: pass a CMMC assessment or lose eligibility for DoD work.

A CMMC readiness assessment is how you find out whether you’d pass before the stakes are real. It’s a structured review of your environment, documentation, and evidence against the requirements of the Cybersecurity Maturity Model Certification, done before you sit for a self-assessment or a Certified Third-Party Assessment Organization (C3PAO) audit. A good one tells you exactly where you stand and what to fix first.

This guide covers what a readiness assessment includes, how the process works at each CMMC level, what it costs, how long it takes, and how to pick someone to run one.

What Is a CMMC Readiness Assessment?

A CMMC readiness assessment is a pre-certification evaluation that measures your organization against the specific requirements of your target CMMC level. It examines your scope, implemented controls, System Security Plan (SSP), Plan of Action and Milestones (POA&M), and the evidence supporting them, then produces a gap analysis and a remediation roadmap.

The purpose is simple: surface every deficiency while it’s still cheap to fix. An assessor who finds a scoping error during a readiness review costs you a few weeks of rework. A C3PAO who finds the same error during a certification assessment can cost you the assessment fee, months of delay, and in some cases contract eligibility.

How It Differs From an Official C3PAO Audit

An official CMMC Level 2 certification assessment is conducted by a C3PAO accredited by the Cyber AB, the official accreditation body for the CMMC ecosystem. The C3PAO’s findings are binding. Results go into the DoD’s assessment systems, and a passing result produces a CMMC status that contracting officers verify before award. A readiness assessment carries no official weight. Nothing gets filed or certified, and a poor result costs you nothing beyond the work needed to fix it. That’s the whole point. It’s the only stage in the entire process where failure is free.

There’s also a conflict-of-interest rule worth knowing. A C3PAO cannot provide consulting and remediation services to an organization and then certify that same organization. If a C3PAO helps you prepare, a different C3PAO has to assess you.

How It Differs From a Mock Assessment

A mock assessment is a dress rehearsal. It simulates the certification assessment itself: assessors interview control owners, request evidence on the spot, and score findings the way a C3PAO would. A readiness assessment is broader and comes earlier, and its job is discovering and closing gaps rather than rehearsing the exam. Most organizations run a readiness assessment first, remediate, then run a mock assessment a few weeks before the real one to see whether staff and evidence hold up under live questioning.

How It Differs From a Self-Assessment

A self-assessment is a formal CMMC mechanism rather than a preparation exercise. CMMC Level 1 and a subset of Level 2 contracts let organizations self-assess, post the results to the Supplier Performance Risk System (SPRS), and have a senior official affirm compliance annually. That affirmation is a representation to the government, and false or careless affirmations carry False Claims Act exposure. A readiness assessment is the check you run before making that representation, so the number you affirm reflects reality.

Why a CMMC Readiness Assessment Matters

Why a CMMC Readiness Assessment Matters

Avoiding Failed Certification Attempts

CMMC Level 2 covers all 110 security controls of NIST SP 800-171, evaluated against 320 assessment objectives. Every objective has to be met for a control to score, and there’s no partial credit. Organizations that skip readiness work routinely walk into certification believing they’re compliant because controls are “mostly” implemented. Mostly implemented scores the same as not implemented.

Protecting DoD Contract Eligibility

Under the phased rollout that began in November 2025, CMMC status is a condition of award. Prime contractors also have to flow the requirement down to subcontractors that handle Federal Contract Information (FCI) or CUI, and they’ve been pushing their supply chains hard. So a missed certification hurts twice: you lose the immediate contract, and you risk dropping out of a prime’s approved supplier pool during the exact window when those pools are being rebuilt around CMMC status.

Reducing Remediation Costs and Delays

Gaps found early get fixed on your schedule with your choice of solution. Gaps found during certification get fixed under deadline pressure, often with whatever expensive tooling can be deployed fastest. There’s a conditional CMMC status for organizations that pass with a limited POA&M, but closeout has to happen within 180 days, and only certain lower-weighted controls are POA&M-eligible in the first place. Readiness work keeps you out of that corner.

Worth Knowing: The DoD Assessment Methodology

The DoD Assessment Methodology weights each NIST SP 800-171 control at 1, 3, or 5 points, deducted from a starting score of 110. The floor is -203. To achieve even a conditional Level 2 status, you need a minimum score of 88. A handful of unmet 5-point controls, such as FIPS-validated encryption or multifactor authentication, can put certification out of reach on their own, so a readiness assessment should always show the point weight attached to every gap.

Let Axipro help you build a business continuity plan that's practical, compliant, and audit-ready.

Schedule Your Free Assessment Today

When to Conduct a CMMC Readiness Assessment

  • Before your first self-assessment. If a contract requires a Level 1 or Level 2 self-assessment, run readiness work before you post a score to SPRS. The score you affirm is a legal representation, and it’s far easier to fix the environment than to explain a misstated score later.
  • When contract requirements are approaching. If CMMC language has shown up in a solicitation you plan to bid, or your prime has set a certification deadline, count backward. Remediation after a readiness assessment typically takes six to twelve months for organizations starting from a moderate posture, and C3PAO scheduling adds lead time on top.
  • After a significant environment or system change. A migration to a new cloud tenant, an acquisition, a new facility, or a redesigned CUI enclave can invalidate assumptions your entire compliance program rests on. Reassess whenever the boundary moves.
  • On a recurring basis. CMMC requires an annual affirmation of continued compliance by an affirming official. An annual internal readiness cycle gives that affirmation a factual basis and catches drift before it compounds.

What a CMMC Readiness Assessment Includes

A thorough readiness assessment covers nine areas, and the order matters because each builds on the last.

  1. Scope definition and CUI boundary mapping.
    Everything starts with scope. The assessment identifies where FCI and CUI live, which systems process, store, or transmit them, and whether the boundary is defensible. Plenty of organizations discover their assumed CUI enclave leaks: a backup job copies CUI to an out-of-scope server, or a shared mailbox pulls it into the corporate tenant.

  2. Information flow and asset inventory review.
    Assets get categorized the way CMMC scoping guidance requires, including CUI assets, security protection assets, contractor risk managed assets, and specialized assets. Data flow diagrams get tested against reality rather than against what the network diagram from 2022 says.

  3. Control evaluation against CMMC requirements.
    Each in-scope control gets evaluated at the assessment objective level. For Level 2, that means all 320 objectives across the 110 controls of NIST SP 800-171, judged as met, not met, or not applicable.

  4. SSP review. The System Security Plan is the anchor document of any CMMC assessment. Assessors check whether it describes the environment as it actually exists, addresses every control, and matches the scoping documentation. An SSP that contradicts the evidence is one of the fastest ways to lose an assessor’s confidence.

  5. POA&M validation. Open items get reviewed for POA&M eligibility, realistic milestones, and assigned owners. Items that should’ve been closed years ago get flagged, because a stale POA&M signals a compliance program that isn’t actually running.

  6. SPRS score calculation and review. The assessment recalculates your score under the DoD Assessment Methodology and compares it with what’s currently posted in SPRS. Discrepancies get corrected before they become a problem in an official review.

  7. Evidence and documentation compilation. For every objective, the assessment confirms that evidence exists, is current, and can be produced quickly. Policies, screenshots, configuration exports, training records, and log samples get organized into an evidence library mapped to objectives.

  8. Gap analysis and risk assessment. Every deficiency gets documented with its affected control, point weight, risk severity, and remediation difficulty.

  9. Remediation roadmap development. Findings become a sequenced plan: quick wins first, high-point-value controls next, long-lead items such as FIPS-validated cryptography or physical security changes scheduled with realistic dates and owners.

Insider Note: Scoping errors sink more certification attempts than technical control failures do. Assessors can only assess the boundary you present, and if CUI turns out to flow outside it, the assessment stops being a test of your controls and becomes a test of your credibility. Spend a disproportionate share of readiness time proving the boundary, especially anywhere email, file sharing, or managed service provider access touches CUI. Your MSP or MSSP belongs in a shared responsibility matrix that states, control by control, who does what. And if a cloud provider stores or processes CUI on your behalf, it needs to meet FedRAMP Moderate or equivalent.

CMMC Readiness Assessment Process: Step-by-Step

Step 1: Initial scoping and kickoff.
Define the target CMMC level, identify the contracts driving the requirement, map where CUI and FCI live, and agree on the assessment boundary. This step also sets logistics: who gets interviewed, what documentation exists, and what access the assessors need.

Step 2: Documentation and control review.
Assessors review the SSP, policies, procedures, network diagrams, asset inventories, and the existing POA&M. Documentation gaps surface here, and they’re usually extensive. Most organizations have implemented more than they’ve documented, which matters because an undocumented control often can’t be verified.

Step 3: Technical testing and interviews.
Assessors validate that controls operate as described. That means reviewing configurations, sampling logs, checking MFA enforcement, inspecting encryption settings, and interviewing the people who own each control. Interviews expose the difference between a policy that exists and a practice that happens.

Step 4: Gap analysis and reporting.
Findings get consolidated into a gap report scored against the assessment objectives, with an updated SPRS calculation and a severity ranking for each deficiency.

Step 5: Remediation planning.
The final step converts findings into a plan with owners, dates, dependencies, and budget implications, ordered so the highest-weight and longest-lead items start first.

Readiness Assessment by CMMC Level

CMMC 2.0 has three levels, and readiness work scales sharply between them.

  • Level 1 readiness verifies the 15 basic safeguarding requirements for FCI. The work is light, but the annual self-assessment and affirmation still carry legal weight, so evidence should exist for every requirement.
  • Level 2 readiness is where most of the DIB lives. It covers the full NIST SP 800-171 control set at the objective level, and it’s the level this article’s process describes. Contracts specify whether Level 2 requires a C3PAO certification or a self-assessment. The security bar is identical either way.
  • Level 3 readiness applies to a small slice of contractors supporting the most sensitive programs. It requires a final Level 2 certification first, then implementation of 24 enhanced requirements from NIST SP 800-172 built to resist advanced persistent threats. The assessment is performed by the government’s Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) rather than a C3PAO, and readiness work has to address the stricter Level 3 scoping model as well as the enhanced controls.

Let Axipro help you build a business continuity plan that's practical, compliant, and audit-ready.

Schedule Your Free Assessment Today

CMMC Readiness Assessment Deliverables

A credible readiness engagement ends with five artifacts.

  • The gap analysis report documents every deficiency at the objective level with severity and point impact.
  • The updated SSP and POA&M reflect the environment as found, with POA&M entries limited to genuinely eligible items.
  • The SPRS score summary shows your recalculated score, the delta from what’s posted, and where the score lands as remediation progresses. The prioritized remediation roadmap sequences the work with owners, dates, and cost estimates.
  • Finally, the executive summary gives leadership what they actually need: certification probability today, the investment required, the timeline, and the contract revenue at risk if the timeline slips.

CMMC Readiness Assessment Checklist

Use this as the closing pass before you schedule anything official.

  • Confirm every control is implemented and verifiable. Implemented means all assessment objectives are met, and evidence proves it. If you can’t produce the evidence within a day, treat the control as unverified.

  • Validate the SSP and POA&M are current. Both documents should describe today’s environment, reference today’s system names, and carry no entries that contradict each other or the network reality.

  • Recalculate and review your SPRS score. Run the DoD Assessment Methodology from scratch rather than editing last year’s spreadsheet, and reconcile the result with what SPRS currently shows.

  • Check consistency across systems and documents. Assessors cross-reference constantly. The asset inventory, the SSP, the data flow diagrams, and the actual configurations have to tell one story.

  • Validate control ownership. Every control needs a named owner who can speak to how it works. “The IT team handles that” is an interview answer that fails.

  • Conduct a mock assessment. Once gaps are closed, rehearse under live conditions with someone playing an unfriendly assessor.

  • Maintain continuous monitoring. Readiness decays. Patch cadence, log review, access recertification, and training records need to keep running between assessments, because the annual affirmation asserts that they did.

Pro Tip: Run Evidence Drills before any Assessment

Run evidence drills before any assessment, readiness or official. Pick ten random assessment objectives and give the control owner 30 minutes to produce current proof for each. Organizations that pass certification smoothly are rarely the ones with the best security tooling. They're the ones that can retrieve any artifact in minutes, because slow evidence retrieval reads as weak control operation even when the control itself is fine.

How Long Does a CMMC Readiness Assessment Take?

The assessment itself typically runs two to six weeks. Small organizations with a contained CUI enclave sit at the short end. Mid-sized contractors with a few hundred employees and multiple systems usually need four to six weeks, and large or multi-site environments can take two to three months before the report is final.

The larger number is what follows. Remediation commonly takes six to twelve months depending on where you start, and the biggest schedule drivers are consistent: unclear CUI boundaries that force re-scoping, long-lead technical items such as FIPS-validated cryptography, dependency on MSPs whose own posture has to be verified, and documentation debt that takes longer to clear than anyone budgets. Environment complexity, staff availability for interviews, and how much evidence already exists in retrievable form all move the timeline more than headcount does.

Common Challenges During a CMMC Readiness Assessment

Underestimating time and resources. Readiness work competes with day jobs. The interview schedule alone can eat dozens of staff hours, and remediation always uncovers second-order work.

Scoping and CUI boundary uncertainty. Many contractors can’t say with confidence where all their CUI is. Legacy file shares, email threads, and subcontractor exchanges scatter it, and every newly discovered location expands scope.

Manual documentation management. Spreadsheets tracking 320 objectives across policies, evidence files, and owners break down fast. Version confusion between the SSP, the POA&M, and reality is one of the most common findings in readiness work.

Linking controls, risks, and evidence. Assessors think in terms of objective, implementation, and proof. Organizations that store evidence by department or by tool rather than by control spend the assessment scrambling to translate.

Choosing a CMMC Readiness Assessment Partner

Look for credentials issued within the CMMC ecosystem. A Registered Provider Organization (RPO) is authorized by the Cyber AB to provide consulting and preparation services. Individual practitioners should hold the Certified CMMC Professional (CCP) or Certified CMMC Assessor (CCA) credential, with CCAs bringing direct experience of how official assessments actually get scored.

Before hiring, ask a few pointed questions. How many Level 2 environments has the team taken through readiness, and how many of those went on to pass certification? Will the assessment evaluate at the assessment objective level or only at the control level? Does the deliverable include an updated SSP and a costed roadmap, or just a findings list? How do they handle MSP and cloud provider responsibilities? Vague answers to any of these predict a shallow engagement.

On independence: an in-house readiness review beats none, and it builds internal capability. But independent assessors catch what familiarity hides, and their findings carry more weight with leadership when remediation needs budget. If your certification path runs through a C3PAO, remember that the assessing C3PAO can’t also be your preparation consultant, so plan for separate parties from the start.

A CMMC readiness assessment is the cheapest point in the entire certification journey to discover bad news. It defines your true scope, scores your real posture against every applicable assessment objective, aligns your SSP, POA&M, and SPRS score with reality, and converts everything it finds into a sequenced plan. With CMMC clauses now flowing into DoD contracts and full inclusion required by late 2028, the contractors who treat readiness as a project this year will be the ones still bidding in three.

Frequently Asked Questions

Is a CMMC Readiness Assessment Required?

No. Neither 32 CFR Part 170 nor the DFARS clauses require one. What the rules require is the outcome a readiness assessment protects: a truthful SPRS score, a passing assessment at the required level, and an annual affirmation you can stand behind.

Yes, and for Level 1 it’s often enough. For Level 2, internal reviews work best as a recurring discipline, supplemented by an external assessment before certification. Internal teams tend to assess intent while external assessors assess evidence, and certification is scored on evidence.

A gap analysis is one component: the comparison of your current state against the requirements. A readiness assessment wraps that comparison in scoping validation, SSP and POA&M review, SPRS recalculation, evidence compilation, and a remediation roadmap.

At minimum, annually, aligned with the affirmation cycle, plus after any major environmental change and before any official assessment. Continuous monitoring between cycles keeps the annual pass small.

No. It cuts the risk of surprise to near zero if you remediate what it finds, but the certification result depends on the official assessment of your environment on the day. Any provider guaranteeing certification is telling you something about their integrity rather than your posture.

A C3PAO can perform readiness and consulting work, but it can’t then conduct your official certification assessment. If you want a C3PAO’s perspective during preparation, engage one C3PAO for readiness and a different one for certification, and confirm the separation in writing.

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

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.

A green dashboard is not an audit opinion. Compliance automation platforms like Vanta, Drata, Secureframe, and Hyperproof have made SOC 2 readiness faster and cheaper, but every audit cycle produces the same pattern: controls that sat at “passing” for months come back from the auditor with exceptions or requests for re-testing. The four controls below account for a disproportionate share of those rejections, and they all fail for the same underlying reason. The tool confirmed that evidence exists. The auditor tested whether the control actually operated. This article walks through each of the four: what auditors reject, why, and how to fix the evidence before fieldwork starts. Why Compliance Tools Show “Passing” But Auditors Still Reject Controls​ The Gap Between Automated Checks and Auditor Judgment Compliance platforms run continuous control monitoring: API calls that check whether a configuration exists, a document is uploaded, or a task is marked done. That’s real value. It catches drift, keeps evidence in one place, and saves weeks of screenshot collection. An audit is a different exercise. A SOC 2 examination is an attestation performed by a CPA firm under AICPA standards, and the auditor’s job is to form an independent opinion on whether your controls met the Trust Services Criteria. That opinion rests on professional judgment, not on whether an API integration returned a 200 response. What “Passing” Actually Means in Your Compliance Dashboard​ When a control shows “passing,” the platform is telling you one narrow thing: at the moment of the last scan, an automated test found the artifact or setting it was programmed to look for: MFA enforced in the identity provider, a policy document uploaded, a training campaign sitting at 100%. The test says nothing about whether the underlying process ran the way your control narrative claims it did, or whether it ran that way across the whole audit period. How Auditors Evaluate Controls Beyond the Checkbox Auditors test two dimensions. Design effectiveness asks whether the control, as described, would meet the criterion if it worked as intended. Operating effectiveness, the core of a SOC 2 Type 2 report, asks whether it actually did throughout the audit period. To answer that, the auditor pulls a population (every access review, every change, every new hire in the period), selects a sample, and inspects the evidence item by item. A dashboard status feeds into that process. It doesn’t replace it. Insider Note: Auditors increasingly ask for evidence outside the compliance platform precisely because they know what the platform auto-collects. If every artifact you produce comes from the same tool export, expect the auditor to independently pull the population from the source system and compare. Discrepancies between the two are one of the fastest routes to an exception. Control #1: Access Reviews That Automation Marks Complete but Auditors Reject Why Auditors Reject Automated Access Review Evidence​ User access reviews sit under the logical access criteria (CC6.1 through CC6.3), and they are the single most common source of audit exceptions we see. The typical failure: the platform generated a user list, someone clicked “complete,” and the dashboard turned green. The auditor then asks a simple question the evidence can’t answer: what did the reviewer actually decide? The Missing Element: Documented Reviewer Judgment​ An access review is a judgment control. Someone with knowledge of the system must look at each account and confirm the access is still appropriate for the person’s role. A timestamped task closure proves the task was closed. It doesn’t prove anyone assessed anything, and an “approve all” review completed in ninety seconds gets exactly the skepticism it deserves. What Auditors Actually Want to See in Access Review Evidence Auditors look for four things: The full population of accounts at the time of review (including service accounts and admin roles), Evidence of who reviewed it and when, explicit dispositions per account or group (retain, modify, revoke), and Proof that flagged access was actually removed. That last item, the deprovisioning ticket showing revocation within a defined window, is the piece most companies can’t produce. How to Fix Your Access Review Control Before the Audit​ Assign a named control owner per in-scope system, run reviews quarterly, and require reviewers to record a disposition for every line, not a blanket approval. When access is revoked, link the removal ticket to the review record. If a quarter was missed, don’t backfill it. Document it honestly and show the remediation, because auditors treat fabricated retroactive evidence far more severely than a disclosed gap. Control #2: Change Management Approvals That Pass Automated Scans​ Why Ticket Closure Isn’t Proof of Approval​ Change management (CC8.1) automation typically verifies that production changes link to a ticket and the ticket is closed. Auditors test something stricter: that each sampled change was approved by an authorized person before deployment. An approval added after the merge, or a ticket closed by the same engineer who wrote the code, fails that test even though every automated check came back green. The Segregation of Duties Problem Automation Misses Segregation of duties is the requirement that no single person can develop, approve, and deploy the same change. NIST’s SP 800-53 control catalog treats it as a foundational access control principle, and SOC 2 auditors apply the same logic. Small engineering teams trip on this constantly. Self-approved pull requests, admins who can bypass branch protection, direct pushes to main: a scanner sees “changes with tickets” while an auditor sees SoD violations. Emergency Changes and Retroactive Approvals: Common Rejection Triggers​ Every audit period contains hotfixes. Auditors don’t reject emergency changes. They reject emergency changes with no documented post-hoc review. If your policy says urgent changes get retroactive approval within two business days, the auditor will sample your emergency changes and check exactly that. No policy, or a policy nobody followed, produces an exception. Rebuilding Change Management Evidence Auditors Will Accept​ Enforce the control technically: branch protection requiring at least one independent reviewer, no admin bypass, and deploy pipelines that only run from protected branches. Then write the emergency change procedure down and generate the review artifact every time it fires.