Common Controls Failures That Generate SOC 2 Exceptions
Five common control gaps—especially access failures—drive nearly every SOC 2 exception.
CC6 (access control), CC8.1 (change management), CC9.2 (vendor risk), CC7 (logging and monitoring), and shadow AI account for almost every exception a SOC 2 report contains, year after year, firm after firm. The common thread is the gap between what a policy says on paper and what a team actually does under deadline pressure, the gap between the written procedure and what happens on a Tuesday afternoon when nobody's watching. Access control deserves the most attention of the five, by a wide margin: it alone drives roughly two-thirds of qualified opinions, more than the other four combined. Treat it as an afterthought and the rest of the compliance program stops mattering much, because everything else gets built on top of an identity layer nobody bothered to lock down.
A SOC 2 Type II report is an attestation. Auditors write down what they found and issue an opinion on it, and buyers now read these reports closely enough that the distinction changes deals. Roughly two-thirds of B2B buyers now demand a SOC 2 report before they'll even consider working with a vendor, and Gartner's 2024 Digital Markets report found 46% of software buyers weigh security certifications heavily when picking who to work with. Accenture's Risk Study found 27% of risk leaders call compliance an urgent concern, while 44% admit they can't see their own risk clearly before an audit even starts. This problem occurs at scale, and it occurs in the same handful of places every single time.
How exceptions are classified and the factors driving the auditor's opinion
Exceptions fall into three buckets. A design deficiency means the control, as written, can't meet the criteria it's supposed to satisfy, no matter who runs it or how carefully. An operating effectiveness deficiency means the control was designed fine but didn't run consistently across the audit period. A system description misstatement means the written description of how controls work doesn't match what's actually happening. Auditors do not treat these three the same way: design deficiencies draw the sharpest scrutiny, because they signal the problem is baked into the process, not a one-off slip somebody made on a bad day.
Three patterns feed those three buckets, over and over. A control might never get built during the period at all. It might get half-applied, like two of four required quarterly scans getting done instead of all four. Or it might run exactly as intended but leave no evidence behind, and an auditor treats that the same as if it never happened.
Whether an exception pushes a report toward a qualified opinion comes down to three things: materiality (which criteria got hit), frequency (how many instances failed), and downstream impact (whether customer data or a contractual commitment actually got touched). Adverse opinions are rare and almost always avoidable with real pre-audit prep. Most reports carrying exceptions still land an unqualified opinion. Section 4 lays out each exception in a consistent format: control description, test applied, exception found, frequency. Management responses, when a company includes them, are in Section 5. Buyers doing diligence read all four sections, not just the summary page.
The pattern behind most of this is mundane, almost boring. Human-run steps drift as people change roles or leave the company. Evidence collection gets pushed to "later" and then never happens. Written procedures stop matching the system as it evolves, because once the process changed, nobody went back and updated the document to match it.
Access control failures under CC6, the single largest source of exceptions
Roughly 68% of qualified opinions trace back to a weakness somewhere in CC6, according to industry analysis pulled across multiple audit firms. That single number is the reason access control earns more attention during implementation than anything else in the framework. CC6 covers logical and physical access, and together with CC7 it accounts for a disproportionate share of exceptions across the Common Criteria series.
The first recurring failure sits in CC6.8, deprovisioning. Someone leaves the company, and their access to AWS, Salesforce, the production database, or some other in-scope system stays live well past their last day. This is almost always a symptom of one thing: no real wiring between HR systems and IT or IAM tooling. Policy usually calls for revocation within one business day, and auditors test the exact gap between the termination date in HR records and the date access actually got pulled. The fix is connecting the HRIS directly into identity and access management so offboarding fires automatically. Manual deprovisioning, someone remembering to file a ticket on their way out the door, is the failure mode itself, not some fallback that occasionally works.
The second failure sits in CC6.3, periodic access reviews. Policy usually calls for quarterly reviews of user access, with extra scrutiny on privileged accounts. The exception occurs when a review gets skipped, gets started but never finished, or gets done but leaves no record of who reviewed it and signed off. That last case occurs most often. Quarterly reviews are genuinely hard to sustain across a full twelve-month window: people go on vacation, headcount churns, and without some kind of nudge or alert, gaps open up quietly and nobody notices until fieldwork. Calendar automation and evidence capture inside a GRC tool close most of this. A missing evidence trail disqualifies a review just as completely as skipping it.
There's a harder version of this problem for companies running multi-tenant or multi-brand environments. When several customers' data sits on shared infrastructure, keeping clean boundaries between them gets harder, and auditors want proof that one customer can never see another's data through a misconfigured role or a shared credential. That proof takes the form of role-based access controls at the application layer, database-level segregation, and logs showing exactly who touched which tenant's data and when. An agency running content operations across multiple client brands on one shared platform needs each brand's account demonstrably walled off, at both the access layer and the data layer. That's a CC6 requirement that has to be met even under deadline pressure.
Change management failures under CC8.1, where process discipline breaks down under development velocity
CC8.1 sits among the most frequently cited sources of exceptions alongside access control, and change management remains a consistently scrutinized area heading into 2026. The most common failure pattern is almost embarrassingly simple: a developer approves and ships their own change to production. CC8.1 requires separation of duties in the approval process, and this one pattern is a leading driver of CC8 exceptions found at early-stage companies.
Auditors now expect continuous, system-generated evidence covering the entire observation period. For CC8.1, that means CI/CD logs, branch protection settings, and deployment records showing a consistent process from day one of the audit window forward. A Type II audit spanning six or twelve months can cover a large volume of production changes, and auditors sample across the whole window. A gap anywhere inside it is fair game, even if the team fixed the process three months before the audit closed.
AI systems have widened what counts as a "change." Model version updates, fine-tune runs, system-prompt edits, and RAG configuration changes are production changes now, and auditors are starting to treat them the way they treat code deployments. Expect questions about review, testing, approval, and rollback, backed by actual records that document how the team usually handles it. For teams running GEO or AEO services, every prompt template update or model version swap applied to a client's content workflow falls inside CC8.1 scope, whether anyone thought of it that way at the time or not.
Closing this gap means enforcing branch protection rules in version control, requiring a second approver on every production deployment, and making sure CI/CD systems generate audit logs that can't be edited after the fact. The log has to exist before the audit window opens. Building it retroactively doesn't work: by definition, it can't show what happened during the period under review.
Vendor and subprocessor risk failures under CC9.2, the control area most consistently underinvested
Vendor risk is the area companies put off longest, right up until it appears as a line item in their own exception report. A subprocessor is any third party that touches customer data: cloud infrastructure providers, payment processors, customer support platforms, email tools, monitoring services, and any AI or ML vendor with access to production data. That list runs longer than most companies assume going in, especially once engineers have quietly signed up for SaaS tools that never went through formal vendor approval.
CC9.2 requires documented risk assessments and evidence of ongoing oversight. A static spreadsheet of vendor names doesn't cut it. Auditors want proof of periodic review, tuned to how risky each vendor actually is: high-risk vendors need at least annual reviews, sometimes more often. During fieldwork, auditors check for vendor incidents during the period, expired certifications, missed SLAs, subprocessors the vendor added without telling anyone, and whether the organization responded to any of that in a structured, documented way.
AI vendor governance is getting tested harder under this same CC9.2 heading going into 2026, which reflects tighter auditor expectations across the board. Organizations relying on third-party model APIs need to document those relationships, assess the risk they carry, and produce evidence of ongoing oversight, same as any other vendor. The ongoing behavior of third-party models introduces risk that vendor reassessment processes may not fully address, and organizations should ensure their risk documentation covers the model relationship over time, not just the underlying infrastructure.
Weak vendor management rarely stays confined to CC9. It tends to appear under CC6 too, in the form of offboarded vendors that still hold active credentials, because the failure happened in vendor management but the evidence trail lives in the access logs. For agencies embedding third-party AI APIs into client-facing services, the fix is a living subprocessor inventory, annual or more frequent documented risk reviews, and treating the LLM provider as a material subprocessor, not a commodity utility that gets a pass on the scrutiny everything else touching customer data receives.
Shadow AI as an emerging exception source that crosses multiple control domains simultaneously
The adoption numbers here are stark. More than 80% of employees now use AI tools nobody approved, while fewer than 20% stick to sanctioned tools. Roughly 60% reach for a public AI tool instead of an enterprise-approved one, and around 38% admit they've shared sensitive company data with an AI tool without asking first. None of that sits off in some future quarter. It's already the default behavior inside most organizations, today, right now, while the vendor inventory says otherwise.
Shadow AI generates exceptions because it drags unvetted third-party services inside the system boundary without anyone noticing it happened. Confidential data leaves through a channel nobody's governing, and the tool bypasses change management, access control, and vendor oversight all at once, the exact three domains auditors examine hardest. The tool never made it onto the subprocessor inventory, so CC9.2 fails. No vendor risk assessment ever happened, so CC9.2 fails a second time. No change management approval was sought for the new capability, so CC8.1 fails. And if customer data got disclosed to that unauthorized third party, CC6.8 fails too. One unapproved tool trips four separate control failures in a single move, which is worse than almost any other single mistake a team can make on a SOC 2 audit.
Auditors running 2025 and 2026 Type II audits are specifically testing for a complete AI tool inventory now. If interviews reveal an undisclosed tool, that's a control gap on its own, even if the tool itself turns out to be low-risk. They're also checking whether the organization's AI Acceptable Use Policy addresses hallucination risk and requires a human to review AI output before it reaches a customer or touches anything financial, mapping that requirement back to CC6.8.
For agencies, the exposure is concrete: someone using an unapproved AI writing or SEO tool to generate content that pulls in client brand guidelines, analytics data, or conversion benchmarks creates a direct CC9.2 and CC6.8 gap in one move. Client data has left the governed environment through a subprocessor nobody vetted. The fix is an AI tool registry treated as a living document, not a one-time list, shadow AI detection folded into security awareness training, and a hard rule that no AI tool touches customer data without approval first.
Monitoring, logging, and incident response failures under CC7, where evidence gaps become exceptions
CC6 drives the largest share of exceptions across the Common Criteria series, and CC7 failures add substantially to the overall count, and CC7 failures skew heavily toward missing evidence rather than a broken process. The control usually ran fine. Nobody kept proof it did, which sounds like a paperwork problem until an auditor explains that no proof means no control, full stop.
CC7.1 covers configuration and vulnerability management, and scan records plus patch management evidence rank among the most requested items during fieldwork. If policy calls for quarterly scans, auditors expect all four quarters' worth of results across the whole observation period. Two missed quarters isn't a rounding error, it's a partially implemented control. The usual cause is workload: scans get skipped when the team's underwater, with no compensating control, no documented exception, and no alert flagging the missed scan before the audit finds it first.
CC7.2 and CC7.3 cover monitoring and incident response. Auditors look for evidence that monitoring actually ran on an ongoing basis and that identified deficiencies triggered documented corrective action. A dashboard or an alert configuration is an artifact, not proof the monitoring worked. Incident response testing needs documented evidence too. A written incident response plan that's never been exercised reads as a design-level finding, not a minor gap. And if a real security incident happened during the observation period, it becomes an exception only if the incident response control didn't operate as designed when it mattered most. The incident itself isn't the exception; the failure of the control to respond the way it was built to respond is the exception.
CC4 covers monitoring of control effectiveness generally, and the bar here has moved. Auditors used to accept manual attestations before automated monitoring tools became common. Now that automation is standard, the absence of automated evidence collection reads less like an oversight and more like a choice somebody made to skip it. Corrective action records give auditors proof that a deficiency, once found, triggered actual remediation. Treating log retention, scan scheduling, and corrective-action documentation as audit artifacts from day one of the observation period is the only real fix, because evidence that never got captured in the moment can't be rebuilt later, no matter how good the team's memory is.
The written-policy-versus-actual-practice gap that turns design deficiencies into exceptions
Most companies that struggle on their first SOC 2 audit don't fail because paperwork went missing. They fail because a control got misunderstood at the design stage or only half-built, and the gap between what the policy says and what the team actually does day to day causes nearly every exception described above.
That gap appears in three forms. Sometimes the policy was written correctly at the start, but the process changed since then and nobody went back to update the document, so paper and practice quietly drifted apart. Sometimes the control runs exactly as intended but leaves nothing behind to prove it ran, which from an auditor's seat is functionally identical to never running at all. And sometimes the control gets performed by the wrong person, outside the required timeframe, or without the sign-off the policy calls for: technically satisfying the spirit of the requirement while failing the actual test applied during fieldwork.
None of these three patterns need an exotic technical failure to produce them. They need ordinary organizational drift, the kind that happens whenever a team grows, a process ages past its original design, or evidence collection gets treated as paperwork instead of part of the job itself. Recognizing this is what explains why exceptions cluster the way they do, year after year, firm after firm. And knowing where they cluster turns prevention into something a team can actually build toward, instead of something an auditor hands them as a surprise on the last day of fieldwork.
