Most Common Exceptions Found During a SOC 2 Audit

TL;DR

SOC 2 audit exceptions are specific instances where a control did not operate as designed or where evidence was unavailable. The most common exceptions involve access control failures (late deprovisioning, missed access reviews), change management gaps (missing approvals or code reviews), and incomplete evidence collection. Most are preventable with proper automation, clear processes, and continuous monitoring throughout the audit period.

What Is an Exception in a SOC 2 Audit?

An exception, sometimes called a "deviation" or "finding," occurs when an auditor tests a control and finds that it did not operate as designed during the audit period. Specifically, an exception means one of three things:

1. A control was not operating as described in the system description
2. Evidence of control operation was missing or incomplete
3. A process was not followed according to documented policy

Exceptions are documented in Section 5 of your SOC 2 report, alongside the auditor's description of the control tested, the testing procedure performed, and your management response.

For a Type I audit, auditors evaluate whether controls are suitably designed at a specific point in time. For a Type II audit, they test whether controls operated effectively over an observation period (typically 6 to 12 months), which means there are far more opportunities for exceptions. A single missed access review in month 4 of a 12-month observation period becomes a documented exception, even if reviews were completed in every other month.

Understanding where exceptions typically occur lets you prioritize your preparation efforts. Here are the most common exceptions, organized by Trust Services Criteria category.

1. Access Control Gaps (CC6.1 - CC6.8)

Access control exceptions are the single most common finding in SOC 2 audits. According to industry analysis from multiple audit firms, roughly 68% of qualified opinions stem from weaknesses in the CC6 criteria (Schneider Downs, CountSure).

Untimely Deprovisioning of Terminated Users

This is the most frequently cited exception across the industry. When an employee or contractor leaves the organization, their access to all in-scope systems must be revoked within the timeframe defined in your policies, typically within 24 hours or one business day.

Why it happens: HR notifies IT late, offboarding checklists are incomplete, or the organization lacks integration between HR systems and identity providers. A typical scenario: an employee resigns on Friday, but their AWS and GitHub access is not revoked until the following Tuesday.

How to prevent it:

• Integrate your HR system (BambooHR, Rippling, Workday) with your identity provider (Okta, Azure AD, Google Workspace) using SCIM provisioning
• Automate deprovisioning triggers on termination date
• Maintain a checklist of all in-scope systems for manual offboarding steps
• Conduct weekly audits of recent terminations against access logs

Missed or Delayed Periodic Access Reviews

Most organizations commit to quarterly or semi-annual access reviews across all in-scope systems. Missing a single review, or failing to document the results, generates an exception.

Why it happens: Reviews are manual, time-consuming, and easy to deprioritize when other work is pressing. Ownership is unclear, or the reviewer does not have the context to determine whether access is appropriate.

How to prevent it:

• Assign clear ownership for each system's access review
• Set calendar reminders with buffer time before deadlines
• Use automated review workflows that generate timestamped evidence
• Document the reviewer, review date, systems reviewed, and any changes made

Missing Access Approval Documentation

New access should be granted through a documented request and approval process. When auditors cannot find evidence that access was formally approved before being provisioned, it becomes an exception.

Why it happens: Access is granted informally via Slack messages or verbal requests, particularly in fast-moving startups where formal processes feel slow.

How to prevent it:

• Require ticket-based access requests (Jira, ServiceNow, or even a simple form)
• Configure systems to require manager approval in the provisioning workflow
• Archive approval evidence automatically

Privileged Access Not Restricted to Appropriate Personnel

Super user and admin access must follow the principle of least privilege. Auditors will flag exceptions when users have elevated access beyond what their role requires, or when the number of admin accounts is disproportionate to the organization's size.

Why it happens: Broad admin access is granted for convenience during early-stage growth, and no one revisits it as the team scales. Engineers receive root or admin access "just in case" rather than role-based access scoped to their responsibilities.

How to prevent it:

• Define specific roles with minimum necessary permissions for each job function
• Limit super user and root access to a small, documented group with a clear business justification
• Review privileged access as part of your quarterly access reviews
• Use just-in-time privilege escalation tools where possible, granting temporary elevated access with automatic expiration

Multi-Factor Authentication Not Enforced

MFA must be enabled for all remote access to in-scope systems. A missing MFA requirement on any system that handles customer data, or that provides access to the production environment, is a common exception.

Why it happens: MFA is enabled on the primary identity provider but not enforced on all downstream applications. Legacy systems or developer tools may not support the organization's MFA solution, creating gaps.

How to prevent it:

• Enforce MFA through your identity provider (Okta, Azure AD, Google Workspace) for all SSO-integrated applications
• Require MFA for direct access to cloud consoles (AWS, GCP, Azure), version control systems, and production databases
• Audit MFA enrollment regularly to ensure all users, including contractors, have enrolled
• Use hardware security keys or authenticator apps rather than SMS-based tokens, which are vulnerable to SIM-swapping attacks

2. Change Management Failures (CC8.1)

Change management is the second most common source of exceptions, particularly for engineering-heavy organizations deploying code frequently.

Code Changes Without Documented Approval

Auditors expect to see evidence that every production deployment was reviewed and approved before release. If code goes to production without a documented pull request approval, that is an exception.

Why it happens: Developers deploy directly to production without peer review, branch protection rules are not enforced, or approvals happen verbally but are not captured in the version control system.

How to prevent it:

• Enable branch protection rules in GitHub or GitLab requiring at least one approval before merge
• Use CI/CD pipelines that enforce approval gates before production deployment
• Train developers on the change management process and why it matters for compliance

Missing Code Review Evidence

Even if changes are approved, auditors may flag exceptions when there is no evidence that the code was actually reviewed, not just rubber-stamped.

Why it happens: Pull requests are auto-approved, self-approved, or merged without meaningful review comments. The organization lacks a policy distinguishing approval from review.

How to prevent it:

• Require pull request reviews from someone other than the author
• Configure repository settings to prevent self-approval
• Maintain pull request history as evidence (most Git platforms do this automatically)

Developers With Direct Production Access

SaaS companies that develop custom applications should restrict developers from making changes directly to production systems. Auditors test for segregation of duties between development and production environments, and direct developer access to production code files is a common exception.

Why it happens: In small teams, the same engineers who write code also manage production infrastructure. Separating environments feels like overhead when the team is small.

How to prevent it:

• Restrict production deployment to CI/CD pipelines that require a separate approval step
• Remove direct SSH, console, or database access to production for developers
• If full separation is not feasible, implement file integrity monitoring that alerts management when production code files change, so unauthorized or unexpected changes can be investigated immediately
• Document any compensating controls if full separation of duties is not practical for your team size

Undocumented Emergency Changes

Hotfixes deployed outside the normal change management process must still be documented retroactively. An emergency change without documentation is an exception.

Why it happens: The urgency of the situation takes priority, and the team forgets to circle back and document the change after the incident is resolved.

How to prevent it:

• Define a clear emergency change process in your change management policy
• Require retroactive documentation within 24 to 48 hours
• Review all emergency changes in your next team retrospective

3. Risk Assessment Deficiencies (CC3.1 - CC3.4)

Risk assessment exceptions often surprise organizations because they involve governance processes rather than technical controls.

Incomplete or Outdated Risk Assessments

SOC 2 requires organizations to conduct a formal risk assessment that identifies threats to the achievement of their service commitments. Many organizations either skip this entirely, perform it once and never update it, or fail to cover all in-scope systems.

Why it happens: Risk assessments feel abstract and low-priority compared to shipping features. The organization does not have a clear owner for the risk management process.

How to prevent it:

• Conduct a formal risk assessment at least annually, following NIST SP 800-30 Rev. 1 guidance for identifying threat events, assessing likelihood and impact, and calculating overall risk levels
• Cover all in-scope systems, data flows, and third-party dependencies
• Document risk treatment decisions (accept, mitigate, transfer, or avoid)
• Have executive leadership review and sign off on the risk assessment results
• Update the assessment when significant changes occur (new products, infrastructure changes, acquisitions)

No Documented Risk Treatment Decisions

Identifying risks is only half the requirement. Auditors also expect to see documented decisions on how each risk is being addressed.

Why it happens: Risks are discussed in meetings but decisions are not formally recorded. There is no risk register or treatment plan.

How to prevent it:

• Maintain a risk register with each risk's likelihood, impact, treatment decision, and owner
• Review the register quarterly and update treatment status
• Link risk treatment actions to specific controls in your SOC 2 scope

4. Monitoring Gaps (CC7.1 - CC7.4)

Monitoring exceptions relate to how the organization detects, responds to, and learns from security events.

Inadequate Security Monitoring and Alerting

Auditors expect evidence that your organization actively monitors systems for anomalies, unauthorized access, and security events. If you cannot demonstrate continuous monitoring coverage, that is an exception.

Why it happens: Organizations rely on ad-hoc monitoring, lack centralized logging, or have monitoring tools configured but no one actively reviewing alerts.

How to prevent it:

• Deploy centralized logging and SIEM (Datadog, Splunk, AWS CloudTrail, or similar)
• Configure alerts for critical events (failed login attempts, privilege escalation, configuration changes)
• Document alert review and response procedures
• Maintain evidence of alert triage (tickets, response logs)

Incomplete Incident Response Documentation

Having an incident response plan is a start, but auditors also test whether the plan has been exercised. If no tabletop exercise or real incident documentation exists during the observation period, you may receive an exception.

Why it happens: Incident response plans are written once and filed away. Teams respond to incidents informally without following the documented process.

How to prevent it:

• Conduct at least one annual tabletop exercise and document the results
• When real incidents occur, document them in your ticketing system with root cause analysis
• Review and update the incident response plan based on exercise findings

Missing Vulnerability Management Program

Regular vulnerability scanning and timely remediation are expected. If critical vulnerabilities go unpatched beyond your stated SLA, or if scanning is not performed regularly, auditors will flag it.

Why it happens: Vulnerability scans are run but findings are not tracked to resolution. Remediation timelines are unrealistic, or there is no escalation process for aging vulnerabilities.

How to prevent it:

• Run automated vulnerability scans at least quarterly at minimum (monthly or weekly for production systems)
• Track vulnerabilities in a ticketing system with assigned owners and deadlines
• Set realistic remediation SLAs: critical (7 days), high (30 days), medium (90 days)
• Escalate vulnerabilities approaching their SLA deadline

Independent Assessments Not Performed

Service organizations are expected to engage independent third parties to assess their internal controls. This typically includes penetration tests (including web application testing for any cloud-based products in scope) and regular vulnerability scans. Missing or outdated independent assessments are a common exception.

Why it happens: Penetration tests are expensive and require coordination. Organizations postpone them or assume internal vulnerability scans are sufficient.

How to prevent it:

• Engage an independent firm to perform a penetration test at least annually, covering all in-scope applications and infrastructure
• Include web application penetration testing for any customer-facing SaaS products
• Run infrastructure vulnerability scans on at least a quarterly basis to identify misconfigurations and missing patches
• Track and remediate all findings from independent assessments with documented evidence

5. Vendor Management Issues (CC9.2)

Vendor management exceptions are increasingly common as organizations depend on more third-party services.

Incomplete Vendor Inventory

Auditors expect a comprehensive inventory of third-party vendors who handle, process, or have access to customer data. Missing vendors from the inventory, especially cloud infrastructure providers, is an exception.

Why it happens: The vendor inventory is not updated when new tools are adopted. Shadow IT introduces vendors without security review.

How to prevent it:

• Maintain a centralized vendor inventory with data classification
• Require security review for any new vendor with access to customer data
• Review and update the inventory quarterly

Missing Vendor Security Assessments

Critical vendors should have their security posture assessed, typically by reviewing their SOC 2 report or completing a security questionnaire. If no assessment exists, that is an exception.

Why it happens: Organizations assume that large vendors (AWS, Google) are inherently secure and do not need review. Smaller vendors do not have SOC 2 reports, and the organization does not follow up with alternative assessments.

How to prevent it:

• Request SOC 2 reports from all critical vendors annually
• Document your review of each vendor's SOC 2 report, noting any exceptions or complementary user entity controls (CUECs)
• For vendors without SOC 2 reports, conduct a security questionnaire or equivalent assessment

6. Missing or Incomplete Evidence

Evidence gaps cut across all Trust Services Criteria and are among the most frustrating exceptions because the control may have been operating perfectly, but you cannot prove it.

Security Awareness Training Not Completed

All employees and contractors with system access must complete security awareness training, typically annually. Missing completions, even one person out of 50, can generate an exception.

Why it happens: New hires miss the onboarding window, training reminders go ignored, or completion is tracked informally without platform-generated evidence.

How to prevent it:

• Use a training platform (KnowBe4, Curricula, or similar) that tracks completion with timestamps
• Set automated reminders and escalation for non-completers
• Block system access provisioning until training is completed
• Run a completion report monthly and address gaps immediately

Missing Background Checks

If your policies require background checks for employees with system access, every employee must have one on file. A single missing background check is an exception.

Why it happens: International hires are harder to screen, contractors are overlooked, or the process is not integrated into the hiring workflow.

How to prevent it:

• Integrate background checks into your onboarding workflow
• Do not provision system access until the background check is confirmed
• Maintain evidence of completed checks in your HR system

Missing Policy Acknowledgments

Employees are typically required to acknowledge security policies (acceptable use, information security, incident response). Missing signatures generate exceptions.

Why it happens: Policy acknowledgment is a manual process, new hires are not prompted, or the acknowledgment evidence is lost.

How to prevent it:

• Distribute policies through a platform that tracks acknowledgments (DocuSign, your compliance tool, or your HR system)
• Include policy acknowledgment in your onboarding checklist
• Re-distribute policies annually and track re-acknowledgments

7. Lack of Formal Policies

While less common than operational exceptions, policy gaps can generate findings when auditors cannot find a documented policy covering a specific control area.

Typical policy gaps include:

• No formal data retention and disposal policy
• No documented encryption policy specifying standards for data at rest and in transit
• No business continuity and disaster recovery plan, or an existing plan that has never been tested
• No acceptable use policy for company devices and systems

These policies form the foundation of your control environment. Without them, individual controls lack the governance framework auditors expect. For a complete list of required policies, see our guide on essential SOC 2 policies.

How Exceptions Impact Your SOC 2 Report

Not all exceptions lead to the same outcome. Auditors evaluate each exception in context to determine its impact on the overall opinion.

The Four Types of SOC 2 Opinions

The critical nuance: An unqualified opinion does not mean zero exceptions. Many organizations receive clean reports with exceptions noted. The key is whether exceptions indicate systemic problems or isolated incidents, and whether compensating controls exist. For example, if a single access review was missed in one quarter but all other reviews were completed and monitoring controls were active, the auditor may conclude that the exception is isolated and does not rise to a material deficiency.

What Your Customers Will Look At

When prospective customers or partners review your SOC 2 report, they evaluate:

• Number of exceptions: Fewer is better, but one or two exceptions are common and accepted
• Nature of exceptions: Access control exceptions are more concerning than a single late training completion
• Management response: A thoughtful response with concrete remediation steps demonstrates maturity
• Pattern across years: Recurring exceptions from year to year signal systemic issues

How to Prevent Common Exceptions

Automate Your Control Environment

The single most effective step is to integrate your systems so that controls operate automatically rather than relying on manual processes.

Conduct a Readiness Assessment

Before your audit observation period begins, run through your controls as if you were the auditor. A readiness assessment identifies gaps while there is still time to fix them, rather than discovering them during the audit itself.

Collect Evidence Continuously

Do not wait until the audit to gather evidence. The most common evidence-related exceptions happen because organizations scramble to collect documentation retroactively and discover gaps that cannot be filled after the fact. Build evidence collection into your daily operations.

Assign Clear Ownership

Every control should have a named owner who is responsible for its operation and evidence collection. When ownership is ambiguous, controls fall through the cracks during busy periods.

What to Do If You Receive an Exception

Receiving an exception is not the end of the world. Here is how to handle it effectively:

1. Understand the Root Cause

Before responding, determine whether the exception is:

• An isolated incident (a single missed review, one late deprovisioning)
• A systemic issue (a process that is fundamentally broken or missing)
• An evidence gap (the control operated correctly but documentation was not captured)

2. Write a Strong Management Response

Your management response appears in the SOC 2 report alongside the exception. It should:

• Acknowledge the finding without making excuses
• Explain the root cause concisely
• Detail the corrective actions already taken
• Specify timelines for full remediation
• Describe compensating controls that mitigate the risk in the interim

3. Remediate Before Your Next Audit

Customers and auditors expect to see that exceptions from previous audits have been addressed. A recurring exception in the same area across multiple audit periods is a much bigger red flag than a one-time finding.

4. Strengthen Compensating Controls

If a primary control fails, compensating controls can prevent the exception from becoming a qualified opinion. For example, if an access review was missed, continuous activity monitoring and real-time alerting for suspicious access may demonstrate that the risk was still adequately managed.

Conclusion

SOC 2 audit exceptions are common, but most are entirely preventable. The pattern is consistent: organizations that automate their control environments, collect evidence continuously, and assign clear ownership experience far fewer exceptions than those relying on manual processes and last-minute preparation.

If you are preparing for your first SOC 2 audit or looking to reduce exceptions in your next cycle, focus on the areas that generate the most findings: access control automation, change management enforcement, and continuous evidence collection. These three areas alone account for the majority of exceptions across the industry.

Need help preparing for a clean SOC 2 report? Talk to our team about building an audit-ready control environment.

Sources

• AICPA Trust Services Criteria - Official SOC 2 control requirements and criteria definitions
• AICPA SOC 2 Reporting Guide - Guidance on testing, exceptions, and audit opinions
• NIST SP 800-30 Rev. 1 - Guide for Conducting Risk Assessments - Framework for identifying threat events, assessing likelihood and impact
• Schneider Downs - The Most Common SOC 2 Exceptions - Analysis of frequently observed audit findings
• CountSure - Remedies for 8 Most Common SOC 2 Control Exceptions - Data on exception frequency and remediation approaches
• Schellman - What Determines a Qualified Opinion in a SOC Report - Explanation of opinion types and materiality assessment
• Linford & Co - SOC Audit Failure: Common Mistakes - Common audit pitfalls and prevention strategies
• Secureframe - SOC 2 Audit Exceptions - Overview of exception types and management responses
• CLA - Key Strategies for an Unqualified SOC Report - Best practices for maintaining a clean opinion