SOC 2 audit exceptions are the line item every founder dreads seeing in a draft report: a note from the auditor that a control didn't operate as designed for some portion of the observation period. They're far more common than vendors like to admit, and they don't automatically fail an audit — but they do end up in the final report, where prospective customers and their security teams will read them. Compliance automation platforms such as Drata have built entire product categories around continuously monitoring controls so exceptions surface early instead of during audit fieldwork. But automated monitoring only catches what it's watching, and a large share of real-world exceptions trace back to evidence gaps that ticket-based control tracking never touches: unreviewed dependency changes, unsigned build artifacts, and access control drift in CI/CD systems that sit outside the HR and cloud-config integrations most GRC tools connect to. This post explains what exceptions actually are, why they happen, and where supply chain evidence closes gaps that compliance automation alone leaves open.
What exactly is a SOC 2 audit exception?
A SOC 2 audit exception is the auditor's formal note that a specific control did not operate effectively for some or all of the observation period — it's different from a finding in a penetration test and different from a control simply being "missing." Under AICPA's attestation standards, auditors test each control against its stated description, and if evidence shows even one instance of a control failing to operate as designed — say, a terminated employee's GitHub access wasn't revoked within the company's own stated 24-hour SLA — that becomes a documented exception in Section III or IV of the report. Exceptions come in two flavors that matter to buyers reading the report: a qualified opinion, where the auditor states the exception materially affects reliance on one or more controls, and a routine exception noted in testing detail without qualifying the overall opinion. Most Type II reports ship with a handful of the latter; a qualified opinion is the version that actually derails deals, because it tells a prospective customer's security team the control they care about didn't hold.
How common are SOC 2 exceptions, and does one exception fail the audit?
No single exception automatically fails a SOC 2 audit — Type II reports routinely go out the door with two, three, or more noted exceptions and still land an unqualified opinion, because the standard evaluates whether the control environment as a whole supports the auditor's conclusion, not whether every control performed perfectly for 100% of a 6-12 month window. In practice, access review lapses (a quarterly access recertification that slipped to week 14 instead of week 13) and change management gaps (a production deploy that skipped the required approval step once in a 6-month period) account for a large share of the exceptions auditors note across SaaS companies going through their first Type II. What turns a routine exception into a qualified opinion is frequency and materiality: one missed access review in a 6-month period reads very differently to an auditor than the same control failing in 4 of 6 monthly test samples. Compliance platforms that continuously poll HR systems and cloud IAM have meaningfully reduced access-review exceptions industry-wide since automated evidence collection became standard around 2019-2020 — but they poll what they're connected to, and CI/CD pipelines, build artifact registries, and dependency approval workflows are frequently outside that connector list.
Why do compliance automation tools like Drata still miss common exception sources?
Drata and similar platforms connect to identity providers, cloud infrastructure, HR systems, and ticketing tools to pull continuous evidence for controls like access reviews, vendor risk, and infrastructure change management — which is exactly the category of control where automated evidence collection has cut manual effort dramatically. The gap shows up in controls that reference the software development and build process itself: a company's SOC 2 control set typically includes something like "changes to production code require review and approval before deployment" or "third-party components are assessed for known vulnerabilities before use." Those controls exist inside CI/CD systems, dependency manifests, and build pipelines — surfaces a GRC connector built for cloud config and HR data generally doesn't reach into with the same evidentiary depth. When an auditor samples a quarter's worth of production deploys and asks for proof that each one went through code review and passed a dependency vulnerability check, a screenshot-based evidence trail or a manually maintained spreadsheet is exactly the kind of thing that produces an exception, because it can't show the auditor a complete, unbroken chain for every sampled change.
What are the most common exception triggers in the software supply chain specifically?
Three control areas generate a disproportionate share of exceptions for companies with active engineering teams: unreviewed dependency introductions, missing artifact integrity evidence, and stale access to build and signing systems. On dependency review, auditors commonly sample 20-25 production deploys from the observation window and ask for evidence that new third-party packages were vetted for known CVEs before merge — if even 2-3 of those samples lack that evidence trail, it's typically enough to trigger a noted exception. On artifact integrity, a control stating that "only reviewed and approved code is deployed to production" requires evidence tying a specific deployed artifact back to a specific approved commit and build; without cryptographic provenance or a signed attestation, teams fall back on Slack threads and deploy logs, which auditors treat as weaker evidence and are more likely to flag as insufficient. On access, service accounts and CI/CD bot tokens with standing write access to production registries are a frequent quarterly-review gap, since they don't show up in the same access recertification workflow as human employee accounts and often go unreviewed for the full audit period.
How should a team fix an exception once an auditor has flagged it?
The fix has to address the underlying control gap and produce evidence covering the remainder of the observation period — a corrected process going forward without documentation of the fix date and subsequent compliant samples doesn't resolve an exception already noted in a Type II report. For a dependency-review gap, that means implementing automated CVE scanning gated on merge (not just on a schedule) and retaining scan output as evidence for every subsequent deploy, so the next audit period shows a complete sample set rather than another partial trail. For artifact integrity gaps, generating a signed SBOM or build attestation for every release closes the evidentiary hole permanently, because the proof is generated automatically at build time instead of reconstructed after the fact when an auditor asks. Auditors generally want to see at least one full quarter of clean, automated evidence after a remediation before they'll consider the underlying issue closed in the next report — which is also why fixing exceptions in month 10 of a 12-month observation window rarely helps the current report and instead sets up the next one.
How Safeguard Helps
Safeguard closes the specific evidence gap that produces the exceptions described above: dependency review, build integrity, and CI/CD access control. Every build processed through Safeguard's pipeline generates a signed SBOM and a provenance attestation automatically, so "third-party components were assessed before use" and "only approved code reached production" aren't reconstructed from tickets during audit fieldwork — they're a queryable, cryptographically verifiable record for every single release in the observation window, not just the samples an auditor happens to pull. Safeguard's dependency scanning runs at merge time, not on a nightly schedule, so a CVE introduced in pull request 4,412 is flagged and blocked before it ships rather than discovered in a quarterly review that leaves a gap in the evidence trail. And because Safeguard tracks service accounts and CI/CD tokens with write access to build and artifact systems as first-class identities, that population gets included in access review evidence instead of falling into the blind spot between HR-driven identity tools and infrastructure-focused GRC connectors. Teams already running Drata or a similar GRC platform for HR, IAM, and cloud config evidence can layer Safeguard in specifically for the supply chain control set — the two aren't competing for the same evidence, they're covering adjacent halves of the control matrix that, left unaddressed on the supply chain side, are exactly where exceptions keep showing up.