What Happens If You Fail a SOC 2 Audit? (2026 Guide)

That framing matters, because it changes what you do next. You are not appealing a verdict or retaking a test. You are holding a document that says something specific about a specific set of controls over a specific window of time, and your job is to work out how much of your business that document actually touches. This guide covers what each outcome does to a deal, whether an isolated control failure makes the report unusable, how common unfavorable opinions really are, how auditors handle a security incident that lands inside your observation period, and the sequence back to a clean report. If you have not been through fieldwork yet, the SOC 2 audit prep checklist covers the four-phase roadmap for getting controls in place first.

What a Failed SOC 2 Audit Looks Like in the Report

The auditor’s conclusion lives in Section I of the report, and its wording is precise. Most people picture two possible results, passed or failed, when the report can land in five practical states.

What you receive	What the auditor concluded	What it means for you
Unqualified, no exceptions	The description is fairly presented and controls were suitably designed and (for Type 2) operating effectively throughout the period.	The clean outcome. Hand it to procurement and move on.
Unqualified, with exceptions noted	Same clean opinion, but the test-results section documents specific deviations the auditor judged immaterial.	Still a passing report. Expect thorough reviewers to read the exceptions and ask about them.
Qualified	Fairly stated except for one or more matters material enough to prevent specific criteria from being achieved.	The most common unfavorable outcome. Scoped and explainable, but it will slow deals.
Adverse	Failures were both material and pervasive; the system as a whole did not achieve the criteria.	Reads as “do not rely on this system.” Usually a deal-breaker with enterprise buyers.
Disclaimer of opinion	The auditor could not obtain sufficient evidence to form any opinion at all.	Rare, and often read as worse than adverse, because there is nothing for a reviewer to evaluate.

The first two rows carry the same opinion. That distinction trips up a lot of teams: an unqualified report is not a report with nothing in it, and finding exceptions in the testing section of your own report does not mean you failed.

For the mechanics of how a deviation becomes an exception and how auditors decide whether an exception is material, see our guide to SOC 2 exceptions and qualified opinions. For how the five report sections fit together, see the SOC 2 audit report guide.

Qualified vs. Adverse: Which Opinion Blocks a Deal?

A qualified opinion is survivable in most sales cycles. An adverse opinion generally is not.

The difference is scope. A qualified opinion names the matter that caused it and confines the problem to specific criteria — the auditor is saying the report is fair except for that. A prospect’s security reviewer can read the qualification, see that it covers, say, change management evidence for a subset of production deployments, and decide whether that touches the data they are about to hand you. An adverse opinion offers no such boundary. The auditor has concluded that the failures were pervasive enough that the system as described did not achieve its criteria, which leaves a reviewer nothing to carve out.

The practical consequences also differ in kind, not just degree:

• Sales cycles stall rather than end. With a qualified opinion, expect a longer security review, escalation to someone more senior on the buyer’s side, and a request for remediation evidence before contract. With an adverse opinion, expect most enterprise procurement teams to stop.
• Your customers’ auditors lose reliance. When a customer’s own auditors can no longer rely on your controls, that work does not disappear — it moves to them, and they will look to you to fund or accommodate it.
• Contracts can be reopened. Many Master Service Agreements require a clean SOC 2 report, so an unfavorable opinion can put you in breach. A common negotiated outcome is a contract amendment granting the customer direct audit rights over the affected area, which is far more intrusive than the report you were trying to avoid.
• Regulated customers escalate faster. In financial services and healthcare, an unfavorable opinion at a service provider frequently triggers the customer’s own regulatory notification and vendor-review obligations.

The financial side is easier to underestimate than the commercial side. The original audit fee is sunk, and you now carry remediation costs for tooling and staff time, retesting or re-audit fees, and the opportunity cost of a pipeline that sits still for three to six months. Fixing a gap in a readiness assessment is a project. Fixing the same gap after an unfavorable opinion, with deals on hold and customers asking questions, consumes the whole company.

I Failed One Control. Can I Still Use the Report?

In almost every case, yes — and the single failed control probably did not qualify your opinion in the first place.

A control that failed testing is written up as an exception in the test-results section of the report. Whether that exception reaches Section I and modifies the opinion depends on materiality, and one isolated deviation in a well-controlled environment rarely does. This is why “unqualified with exceptions noted” is such a common outcome: the opinion stays clean while the testing detail records exactly what went wrong.

Two things follow from that.

The report is yours to use regardless of the opinion. SOC 2 produces an attestation report, not a certificate. Nothing gets revoked, no listing gets pulled, and there is no body to notify. Even a qualified report is a valid deliverable you can share under NDA. Withholding it usually costs you more credibility than the finding does, because a prospect who has asked for a report and received silence will assume the worst available explanation.

What buyers ask about is the shape of the failure, not its existence. Be ready with four specifics: which control failed, how many sampled items failed out of how many tested, what the root cause was, and what evidence proves the fix is now operating. A finding that reads “two of twenty-five terminated users retained access beyond the policy window, caused by a manual handoff between HR and IT, now automated” is a conversation. The same finding with no numbers and no cause is a red flag.

The one pattern that genuinely damages a report is a failure that reveals a control was never really operating — most often because it was performed but never evidenced. Auditors can only test the evidence you produce, so an undocumented control is, for the purposes of the examination, a control that did not happen.

How Often Do SOC 2 Audits Come Back Qualified?

Nobody knows precisely, and any page quoting you a tidy SOC 2 “pass rate” is guessing.

The reason is structural. SOC 2 reports are distributed under NDA rather than published, there is no registry of issued reports or opinions, and the AICPA does not publish statistics on the opinions its member firms issue. Individual audit firms know their own numbers and do not release them.

The only public quantification we could find comes from the third-party risk vendor Vendict, whose co-founder published a breakdown of the SOC 2 reports the company had analyzed:

Opinion outcomes across 457 SOC 2 reports analyzed by Vendict, published 15 June 2026.

Outcome	Reports	Share
Reports analyzed	457	—
Qualified opinions	13	2.8% of all reports
Unqualified opinions	433	94.7% of all reports
Unqualified reports that still listed exceptions	131	30% of unqualified reports
Not accounted for in the published summary	11	2.4% of all reports

Read that carefully before you take comfort from it. It is a single vendor’s sample with an unpublished methodology, the categories do not fully reconcile, and — most importantly — it counts reports that companies chose to hand over during vendor reviews. Reports nobody circulates are not in the denominator.

That selection effect explains why the number sits so oddly against what auditors say. Audit firms including Linford & Co describe qualified opinions as “quite common”, particularly in a first examination or during a period of rapid growth or staff turnover. Both accounts can be true at once: audit firms see every opinion they issue, while a third-party risk platform sees the subset that survived to circulation. There are also documented ways an unfavorable result gets restructured before issuance, such as extending the reporting period to cover remediated controls.

The useful takeaway is not a percentage. It is that exceptions are ordinary and qualifications are not, so a report with findings in it is a normal artifact rather than evidence that you are an outlier.

Does a Security Incident During the Audit Period Mean an Automatic Fail?

No. Auditors test whether your controls operated as you described them and whether you met your service commitments and system requirements. They do not test whether anything bad happened.

An incident that your controls detected, escalated, and contained the way your incident response procedure says they should is, in evidentiary terms, a control that worked. The examination is far more interested in that sequence than in the existence of an attacker.

What the Description Criteria Require

Whether the incident appears in your report at all is a judgment call, not an automatic disclosure. AICPA description criteria DC 200 includes a criterion for identified system incidents, and the factors that drive disclosure are how significantly the incident affected your ability to fulfill service commitments and system requirements during the period, and whether any law or regulation required you to disclose it. When an incident is disclosed, the description covers its nature, its timing, and its effect and disposition — not a forensic narrative.

Practitioners at CohnReznick, writing in December 2025, list three factors that in practice push toward disclosure: one or more controls were deemed ineffective, significant changes were made as part of remediation, or public or regulatory reporting was already required.

Where the Opinion Usually Gets Damaged

The risk to your opinion is usually second-order, and this is the part teams do not plan for:

• The incident destroys your evidence. Ransomware and prolonged outages frequently take out the logs, reports, and records that prove unrelated controls were operating. Controls that genuinely ran can still produce exceptions if the artifacts supporting them no longer exist.
• Recovery work displaces routine controls. During an extended response, the people who run daily monitoring reviews, backup verifications, and access approvals are working on the incident instead. Each skipped occurrence is a testable gap in an otherwise healthy control.
• Availability commitments get breached directly. If Availability is in scope and a prolonged outage meant you did not meet the commitments in your description, that failure can drive a qualified opinion on its own terms, independent of how well security controls performed. Your auditor will weigh any compensating controls before reaching that conclusion.

Your Reporting Options If the Opinion Is Affected

If your service auditor concludes the event does affect the opinion, CohnReznick describes two routes worth raising early:

1. Extend the reporting period so it covers the remediated controls operating after the incident, letting the report show the recovery rather than only the failure.
2. Issue two reports — one covering the period containing the incident, qualified if necessary, followed immediately by a separate report over a shorter subsequent window that demonstrates the rebuilt controls operating cleanly.

Raise these with your auditor while you are still in the response, not after fieldwork ends. The questions worth putting to them are whether your controls detected and escalated the event, whether your service commitments were met throughout, whether your control evidence survived, and what disclosure the description now needs. For how the period itself is set, see the SOC 2 observation period guide.

Building Your Remediation Action Plan

A qualified or adverse opinion is an auditor-validated map of your control weaknesses. Your first task is to turn it into a formal Remediation Action Plan — the playbook for fixing the deficiencies, reassuring stakeholders, and preparing for retesting.

Start with a root cause analysis for each finding, because every finding is one of two things. A design deficiency means the control was never capable of meeting the objective: there was no formal offboarding process at all. An operating effectiveness failure means a sound control was not followed consistently: the offboarding process existed and someone skipped it. The two demand completely different fixes, and teams routinely rebuild a process that was fine when the real problem was that nobody ran it.

Prioritize and Assign Ownership

Findings do not carry equal weight. Rank them on three axes:

1. Risk level. Failures in core Trust Services Criteria come first. Terminated users retaining production access (CC6.2, CC6.3) outranks a documentation gap by a wide margin.
2. Client impact. Address the findings your customers and prospects can see, so you can unblock the sales conversations that are costing you the most.
3. Effort. Balance long projects against quick wins so stakeholders and your auditor see steady, evidenced progress rather than a six-month silence.

Then assign a single named owner to each task — one person accountable for implementing the fix, collecting the evidence, and reporting progress. Remediation plans owned by a committee do not close.

Document Everything and Set Timelines

Your plan is a formal artifact. It is both an internal project plan and the primary evidence you will show stakeholders and your auditor to demonstrate you are addressing the deficiencies.

Component	Description	Example
Finding ID	Unique identifier from the audit report.	CC8.1-01
Root Cause Analysis	Why the control failed — design or operating effectiveness.	Design deficiency: the change management policy did not require peer review for emergency code changes.
Remediation Action	The specific steps that will fix it.	Update the change management policy to mandate peer review for all code changes including emergencies, and enforce it through GitHub branch protection rules.
Owner	The single individual accountable.	Head of Engineering
Timeline	A realistic deadline, dated from report issuance.	45 days from report issuance
Evidence	What will prove the fix is in place and working.	Updated policy document, branch protection configuration export, and a peer-reviewed emergency change request.

A documented plan is not optional after an unfavorable opinion — it is your formal response to the findings, and it demonstrates the structured approach to risk management that the framework is testing for in the first place. For the end-to-end process, our guide on how to get SOC 2 certification provides the wider context. Once the findings are in a plan, keep them from recurring with continuous monitoring rather than waiting for the next examination to surface the same gap.

Communicating the Result to Customers and Prospects

How you communicate an unfavorable opinion matters as much as the remediation itself, and you have less control over the timing than you think. Customers with contractual reporting rights will ask, and the gap between their request and your answer is where trust is lost.

Crafting Your Management Response

Your primary instrument is the management response, a formal document included in the report alongside any qualified or adverse findings. It is your one chance to speak inside the report itself, and it needs four things:

• Acknowledgement. A direct statement accepting the auditor’s finding.
• Context without excuses. Relevant facts only — “this control applied to a system that was decommissioned in March” — with no blame assigned to individuals or third parties.
• The remediation summary. A high-level account of the corrective actions, referencing your detailed internal plan.
• A committed timeline. A target completion date you will actually hit.

Sophisticated readers treat a management response as a commitment rather than proof, so vague language costs you more than the finding does.

Arming Your Sales Team for Tough Questions

Your sales team will meet these questions before your compliance team does. Give them pre-approved talking points and three instructions: raise the finding proactively with serious prospects rather than waiting to be asked, explain it in non-technical terms with its scope attached (“a documentation gap on an internal system, no customer data involved, fixed in April”), and move quickly to the management response and remediation timeline. A team that can do this keeps control of the narrative. A team that improvises loses the deal to a competitor who had a rehearsed answer.

Choosing Your Path Back to a Clean Report

Once the plan is running, you have to decide how to prove the fixes worked. The route you pick sets your timeline, your budget, and how much assurance the result carries.

Retesting vs. Re-Auditing

• Retesting. If the findings were confined to a few specific controls — a missed quarterly access review, a gap in change approvals — you can engage your auditor to retest only those controls once remediated. This is the fastest and cheapest route for localized failures.
• Full re-audit. If the findings pointed to a fundamental design flaw, such as a risk assessment process that never really ran (CC3.1–CC3.4), a new examination over a fresh observation period is the honest answer. It costs more and takes longer, and it is the only thing that will satisfy a buyer who has read an adverse opinion.

End to end, most teams are looking at six to twelve months from an unfavorable opinion to a clean Type 2 covering a remediated period.

Bridge Letters and Auditor Changes

A bridge letter covers the gap between the end of your audit period and today, attesting that the fix has been implemented and that controls have operated effectively since. It is management-attested rather than auditor-tested, so it is interim assurance for a prospect who needs something now — not a substitute for a clean report. See the SOC 2 bridge letter guide for what one should contain and who signs it.

This is also the natural moment to reconsider your audit firm. A genuine professional disagreement on one technical judgment is not a reason to switch. A pattern of missed context, scope confusion, or unfamiliarity with your architecture is, because you are about to repeat the entire exercise with them. Switching mid-recovery costs time and re-explanation, so decide deliberately rather than emotionally — our directory lets you compare SOC 2 audit firms on pricing, timelines, and sector experience.

Carrying the Findings into Your Next Audit Cycle

The remediation plan should not close when the last task does. Keep the register open through the next examination, with each finding carrying its fix date, the evidence that proves closure, and the period over which the corrected control has now operated. That last column is what your next auditor will ask for, and it is what distinguishes a control you repaired from a control you merely promised to repair.

Practically, that means starting evidence collection for the corrected controls on the day the fix ships rather than the week fieldwork begins, and treating the first full quarter after remediation as a rehearsal you grade yourself. A finding that recurs in a second report is far more damaging than the same finding appearing once, because it tells a reader the problem is your process rather than your luck.

---

Finding an auditor who understands your architecture is the difference between a clean second attempt and a repeat of the first. SOC2Auditors helps you compare verified audit firms on real pricing and timelines. Send one scoped brief to matched firms and get tailored quotes without the sales calls.