If you're reading this, you probably just received your SOC 2 report and it didn't come back clean. Maybe your auditor used the word "qualified." Maybe there are exceptions listed in the report. Maybe someone on your team said "we failed" and now you're trying to figure out what that means and what to do next.

First, take a breath. A SOC 2 audit with exceptions is not a failure in the way most people think of failure. It doesn't mean your company is insecure. It doesn't mean you wasted the money you spent on the audit. It doesn't mean your enterprise customers will leave. And it absolutely doesn't mean you need to start over from scratch.

What it does mean is that your auditor identified specific areas where your controls weren't designed properly or weren't operating effectively during the observation period. Those specific areas need to be addressed. But the vast majority of your security program — all the controls that passed without exception — is working as intended. Your report proves that.

This guide explains what a "failed" SOC 2 audit actually means, how to read and interpret exceptions, how to communicate with customers honestly, and how to build a remediation plan that leads to a clean report. Many of the strongest compliance programs we've seen were built by companies that had exceptions in their first audit and used those findings as a catalyst for improvement.

Understanding SOC 2 Opinion Types

The word "failed" gets thrown around loosely, but SOC 2 reports don't use pass/fail language. Instead, your auditor issues an opinion that falls into one of four categories. Understanding these categories is essential for knowing where you actually stand.

Unqualified Opinion (Clean Report)

An unqualified opinion means your auditor found no significant issues. Your controls are designed properly and (for Type II) operated effectively throughout the observation period. This is the result everyone aims for, and it's what most enterprise customers expect to see.

An unqualified opinion doesn't mean your security is perfect — it means your controls met the criteria during the period examined. You could still have areas for improvement that the auditor noted informally without including them as exceptions.

Qualified Opinion (Exceptions Noted)

A qualified opinion means your auditor identified specific exceptions — controls that weren't designed properly or didn't operate effectively — but the exceptions are limited in scope. The report is still usable, and it still provides assurance about all the areas where controls did pass.

This is what most people mean when they say they "failed" their SOC 2 audit. It's the most common non-clean outcome, and it's far more recoverable than most companies realize. A qualified opinion with two or three well-explained exceptions and strong management responses is worlds apart from a fundamentally broken security program.

Adverse Opinion

An adverse opinion means your auditor found pervasive, material issues with your controls. This is rare and indicates systemic problems, not isolated gaps. An adverse opinion significantly undermines the value of the report and typically indicates that the organization wasn't ready for the audit.

If you received an adverse opinion, the situation is more serious than isolated exceptions, and you likely need significant remediation before pursuing another audit. However, even adverse opinions can be recovered from with focused effort and appropriate investment.

Disclaimer of Opinion

A disclaimer means the auditor couldn't obtain sufficient evidence to form an opinion. This can happen when the organization couldn't provide requested evidence, when the observation period was too short, or when there were significant limitations on the audit scope. A disclaimer is essentially an incomplete audit rather than a negative finding.

Why Qualified Opinions Aren't Automatically Disqualifying

Here's something that most companies don't realize until they've been through the process: many enterprise customers will accept SOC 2 reports with exceptions. Not all of them, and not for any exceptions, but a qualified opinion is not the automatic deal-killer that companies fear.

Enterprise procurement and security teams evaluate SOC 2 reports holistically. They look at the nature and severity of the exceptions, your management response explaining what happened and what you're doing about it, whether the exceptions are relevant to how they'll use your service, and your overall security posture as demonstrated by the controls that did pass.

A qualified opinion with exceptions in an area that doesn't affect the customer's use case (say, a gap in your physical security controls when the customer only cares about logical access to their cloud-hosted data) may be perfectly acceptable. Similarly, an exception where the control existed but wasn't operating for a brief period during the observation window — and your management response shows you've already fixed it — is often acceptable because it demonstrates awareness and corrective action.

The key factor is your management response. A management response that says "we acknowledge the finding and are working on it" without specifics is weak. A management response that explains what caused the gap, what specific steps you've taken to remediate it, and what controls you've implemented to prevent recurrence demonstrates maturity and accountability. Enterprise security teams have seen plenty of SOC 2 reports with exceptions, and they know the difference between a company that's genuinely improving and one that's just checking boxes.

Types of Exceptions and What They Mean

Not all exceptions are equal. Understanding the type of exception in your report helps you prioritize remediation and frame your communication with customers.

Design Deficiency

A design deficiency means that a control wasn't designed properly to achieve its intended objective, even if it was operating consistently. In other words, you were doing what your policies said, but your policies weren't adequate.

For example, your access control policy might specify annual access reviews, but your auditor determined that annual reviews are insufficient for the level of access your team has to customer data. The control was operating as designed (you did perform annual reviews), but the design itself didn't meet the standard.

Design deficiencies are addressed by updating your policies, procedures, or control design. They're typically straightforward to remediate because the fix is changing how the control works, not changing organizational behavior.

Operating Effectiveness Failure

An operating effectiveness failure means that a control was designed properly but didn't operate consistently during the observation period. Your policy says the right thing, but your team didn't follow it consistently.

For example, your change management policy requires code review approval before production deployment, but your auditor found three instances during the observation period where code was deployed to production without the required approval. The policy is sound, but execution fell short.

Operating effectiveness failures are more challenging to remediate because they often reflect cultural or process issues rather than documentation gaps. Fixing them requires not just updating procedures but ensuring your team consistently follows those procedures going forward, which often means adding automation, monitoring, or accountability mechanisms.

Distinguishing Between the Two

Your remediation approach depends heavily on which type of exception you received. Design deficiencies are typically faster to fix because they involve updating documentation and control specifications. Operating effectiveness failures require both the fix itself and evidence of sustained compliance over time, which means your next audit's observation period needs to show consistent control operation.

Ask your auditor to clarify whether each exception is a design deficiency or an operating effectiveness failure. Some reports make this distinction clearly; others require interpretation. Understanding the type guides your remediation strategy.

Most Common Exception Areas

Certain control areas generate exceptions far more frequently than others. Knowing the common patterns helps you understand that your exceptions are part of a well-known landscape, not evidence of unique incompetence.

Access control exceptions are the most common category. These typically involve access reviews that weren't performed on schedule, terminated employees whose access wasn't revoked within the required timeframe, or excessive permissions that weren't identified and remediated. Access control is operationally demanding because it requires consistent, repeated action across the entire observation period.

Change management exceptions frequently arise when production deployments bypass the documented approval process. This often happens during emergency fixes or when development velocity outpaces the change management process. The root cause is usually a process that's too cumbersome for the team's deployment frequency, leading to shortcuts that become audit findings.

Monitoring and logging exceptions appear when logging is configured for most systems but misses some, when log retention doesn't meet the defined policy, or when security alerts aren't investigated within documented timeframes. These often reflect infrastructure growth that outpaced the monitoring configuration.

Vendor management exceptions occur when critical vendors are missing from the vendor inventory, when vendor security assessments are overdue, or when contracts lack required security provisions. Vendor management requires periodic attention that's easy to defer when other priorities compete for time.

Risk assessment exceptions appear when risk assessments haven't been updated annually or when significant system changes occurred without corresponding risk assessment updates. These are typically documentation issues rather than genuine security gaps, but they still generate findings.

Immediate Steps After Receiving Exceptions

When you receive a SOC 2 report with exceptions, resist the urge to panic or launch into frantic remediation. Take a methodical approach instead.

Step 1 — Read the Report Carefully

This sounds obvious, but many people skim the exceptions without fully understanding them. For each exception, note the specific control or criteria that was cited, the auditor's description of the deficiency, any evidence referenced that contributed to the finding, and whether it's a design deficiency or operating effectiveness failure.

If anything in the report is unclear, contact your auditor for clarification. They want you to understand their findings and address them properly. Auditors are not adversaries — they have a professional interest in seeing your program improve.

Step 2 — Understand the Root Cause

For each exception, dig into why it happened. Surface-level root causes ("we forgot to do the access review") aren't sufficient. Ask why you forgot. Was there no reminder system? Was the person responsible overloaded? Was the process unclear? Was there no accountability mechanism?

Understanding the true root cause is what prevents recurrence. If you fix the symptom without addressing the cause, you'll likely see the same exception in your next audit.

Step 3 — Assess Customer Impact

Determine which of your current customers have access to your SOC 2 report and which are likely to notice the exceptions. Review your contracts for specific SOC 2 requirements. Consider whether the exceptions are relevant to your customers' specific use cases. This assessment helps you prioritize your communication strategy.

Step 4 — Talk to Your Auditor

Schedule a meeting with your auditor to discuss the findings. Ask what specific remediation they would expect to see, what evidence would demonstrate that the gap has been addressed, whether a bridge letter would be appropriate, and what the timeline should be for remediation before your next audit.

Your auditor has seen many companies navigate exceptions. Their guidance on remediation is valuable and helps ensure your corrective actions will actually address the findings in the next audit cycle.

How to Communicate with Customers

Communicating about exceptions requires honesty, professionalism, and context. Most companies either over-communicate (sending alarming notifications that make the situation seem worse than it is) or under-communicate (hoping nobody notices), and neither approach serves them well.

What Procurement Teams Actually Focus On

Enterprise procurement and security teams reviewing your SOC 2 report focus on specific elements. They look at the auditor's opinion type to understand the overall assessment. They review the exceptions themselves to understand what controls were deficient. They read your management responses carefully to evaluate whether you understand the issues and have credible plans to address them. And they assess relevance — whether the exception areas affect their specific use of your service.

Experienced security reviewers see SOC 2 reports with exceptions regularly. What distinguishes a company that handles exceptions well is the quality of the management response and the evidence of remediation progress.

Proactive vs Reactive Communication

If a customer requests your SOC 2 report and it contains exceptions, don't try to hide them or distract from them. Instead, provide the report with a brief cover message that acknowledges the exceptions, summarizes your remediation actions, and offers to discuss any concerns directly.

Something like: "Our most recent SOC 2 Type II report covers [dates]. The report includes [number] exceptions that our auditor identified. We've completed remediation for [number] of these and have an active plan for the remaining items. I'm happy to discuss the specifics and our remediation progress in detail if that would be helpful."

This approach demonstrates transparency and accountability. It shows the customer that you're aware of the issues and actively addressing them, which builds more trust than a clean report from a company that seems to be hiding things.

Bridge Letters

A bridge letter is a letter from your auditor that covers the gap between your observation period end date and the current date. Bridge letters are particularly valuable when you've remediated exceptions since your report was issued because they provide independent verification that the issues have been addressed.

Ask your auditor about issuing a bridge letter if your report has exceptions that you've since remediated, if there's a significant gap between your report date and when customers are requesting it, or if a specific customer requires assurance about remediation. Bridge letters typically cost $2,000 to $5,000 and can be issued within two to four weeks. For important customer relationships, this is a worthwhile investment that demonstrates your commitment to continuous improvement.

Building a Remediation Plan

Your remediation plan transforms audit findings into concrete action items with owners, timelines, and success criteria.

Prioritizing Exceptions

If you have multiple exceptions, prioritize them based on customer impact (exceptions in areas your customers care most about should be addressed first), complexity and timeline (quick wins that can be completed rapidly should be prioritized to show progress), and risk (exceptions that represent genuine security risks to your systems or data should take precedence regardless of customer visibility).

Creating Action Items

For each exception, document the specific finding from the audit report, the root cause of the exception, the remediation action with enough detail that someone could execute it, the owner responsible for completing the remediation, the target completion date, the evidence that will demonstrate the remediation is effective, and the verification method confirming the remediation resolves the finding.

Tracking and Accountability

Create a remediation tracker that's reviewed regularly — weekly during active remediation, monthly once the most critical items are resolved. The tracker should show the status of each action item, any blockers or delays, evidence collected demonstrating remediation, and whether the remediation has been verified as effective.

Share the remediation tracker with your auditor if they're willing to review it. Getting informal feedback on whether your remediation approach will satisfy the finding before your next audit is far more efficient than guessing and potentially missing the mark.

Preventing Recurrence

Remediating the specific exceptions is only half the battle. Preventing recurrence requires addressing the systemic issues that allowed the exceptions to occur in the first place.

Root Cause Analysis

For each exception, identify the root cause category. Common categories include process gaps where no defined process existed for the control activity, resource constraints where the team was too busy or understaffed to execute controls consistently, awareness gaps where team members didn't understand the control requirements, tooling gaps where manual processes that should have been automated were prone to human error, and ownership gaps where nobody was clearly responsible for the control activity.

Each category suggests different preventive measures. Process gaps require documented procedures. Resource constraints might require additional headcount or simplified processes. Awareness gaps need training. Tooling gaps need automation. Ownership gaps need clear RACI assignments.

Control Monitoring

Implement monitoring for the controls that received exceptions. Don't wait until your next audit to find out whether remediation is working. Set up regular checkpoints — monthly at minimum — where someone verifies that the remediated controls are operating effectively and documents the verification.

For example, if you received an exception for inconsistent access reviews, don't just perform the overdue access review and move on. Set up a calendar reminder, assign an owner, create a tracking mechanism, and verify monthly that the reviews are happening on schedule. By the time your next audit rolls around, you'll have months of evidence showing consistent operation.

Building Resilience

The most effective prevention strategy is making the right behavior easier than the wrong behavior. If developers can deploy to production without approval because the approval process is cumbersome, simplify the approval process rather than just telling developers to follow it. If access reviews are missed because they're manual and tedious, automate as much of the review process as possible.

Automation is your friend here. Automated controls don't forget, don't get busy, and don't cut corners. Every control that you can automate is a control that's less likely to generate an exception. Our guide on common SOC 2 audit findings covers the most frequent exceptions and practical approaches to preventing each one.

Timeline for Recovery

Understanding the timeline helps you set realistic expectations with your leadership team and your customers.

If Your Next Audit is 6-12 Months Away

This is the most common scenario and the most favorable for recovery. You have time to implement remediation, operate the fixed controls for several months to build evidence, and potentially get a readiness assessment before the next observation period begins.

Use the first two to three months for remediation — fixing the design deficiencies, implementing process changes for operating effectiveness failures, and deploying any new tools or automation. Use the remaining months to operate the fixed controls consistently and collect evidence of that consistent operation. By the time your next audit starts, you'll have months of clean evidence demonstrating that the issues have been resolved.

If a Customer Needs Your Report Now

When a customer or prospect needs your SOC 2 report immediately and it contains exceptions, you have several options. Provide the report with a cover letter explaining the exceptions and your remediation status. Request a bridge letter from your auditor if remediation is complete. Offer to discuss the exceptions directly with the customer's security team, which often resolves concerns faster than written communication.

Most customers will accept a timeline for remediation if you can demonstrate genuine progress. A conversation where you walk through your remediation plan with specifics — "we've completed items one through three, item four is in progress and will be complete by next month" — is far more effective than hoping they don't read the exceptions section.

If You're Mid-Observation Period

If your current audit is still in progress and you've identified issues that will likely result in exceptions, talk to your auditor immediately. They may be able to provide guidance on remediation steps that could reduce the severity of the finding. In some cases, fixing the issue promptly and operating the corrected control for the remainder of the observation period results in a less severe finding than waiting until the report is issued.

The Path to a Clean Report

Companies that navigate exceptions well often end up with stronger compliance programs than companies that got clean reports on their first try. The experience of receiving exceptions, understanding the root causes, building remediation plans, and implementing improvements creates organizational learning that's difficult to replicate through audit preparation alone.

Your auditor will view your remediation favorably if you've demonstrated that you understood the root causes rather than just fixing symptoms, that you implemented sustainable solutions rather than temporary patches, that the remediated controls have been operating effectively for a meaningful period, and that you've applied the lessons learned to other areas of your program proactively.

A readiness assessment before your next audit can verify that your remediation is complete and identify any new gaps that may have emerged. This is particularly valuable after an audit with exceptions because it gives you an independent check before committing to another observation period.

If you're preparing for your next audit cycle and want to minimize the risk of exceptions, preparation is the most effective investment you can make. Our Complete Bundle includes professionally written policies, document templates, and evidence guidance that have been refined through multiple SOC 2 audits. Starting with battle-tested documentation helps ensure your controls are designed properly from the outset, addressing the most common source of design deficiency findings.

A SOC 2 report with exceptions isn't a dead end — it's a starting point for building a genuinely strong security program. Companies that take exceptions seriously, remediate thoroughly, and learn from the experience consistently emerge with clean reports and more resilient compliance programs. If you're in that position right now, you're closer to a clean report than you probably think. Read the findings carefully, understand the root causes, build your remediation plan, and execute. The path forward is clear, and the destination is achievable.

For additional context on what to expect during your audit and how to understand the sections of your SOC 2 report, our detailed guides walk through the process and reporting format so you know exactly what you're working with.