SOC 2 exceptions and qualified opinions: what they mean

SOC 2 exceptions and qualified opinions: what they mean for your decision

You have a vendor's SOC 2 report in front of you, or a customer's security review has surfaced one, and a decision is due. An exception is a documented deviation from a control during the examination period, and a qualified opinion means the CPA reached a modified conclusion on part of the report rather than a clean conclusion on all of it. Neither result automatically disqualifies a vendor. What matters is how the deviation affects the risk you carry, and that depends on four things: which control failed, how often it failed, whether the vendor fixed it and can show the fix, and what your own contract and risk tolerance require.

Start by mapping each exception to the criterion it touches and to the service you buy. A failed access review on a system that holds your production data is a different decision from a missed training record for staff who never touch it. Check whether the exception is isolated or repeated, whether the period in which it occurred overlaps the data you rely on, and whether the management response describes a root cause and a dated corrective action that the auditor could test. Ask the vendor for a bridge letter if the report period ends long before your review. Confirm with the vendor, not the report summary, which controls the exception touched and whether any complementary user entity controls on your side were affected.

Responsibility stays clear throughout. The organization owns its controls and its management response. An implementation partner, if one is engaged, can help prepare the evidence, design the remediation and rehearse the explanation, but it does not test the controls or issue the report. Only the independent CPA firm that performed the examination issues the report and its opinion, and only that firm can say whether a remediated control would change the conclusion. Ask the vendor for the written corrective action plan and the evidence it will produce before the next period, and ask the CPA firm how the follow-up will be tested.

Which exceptions change your risk decision

An exception is not automatically disqualifying, and a clean opinion does not prove the controls never failed. Readers weigh the same handful of factors together, and each one is read from the description of tests and results, which shows how the result affects their own organization.

Nature of the failed control

Start with what broke. A missed quarterly access review and a missed termination removal do not carry the same weight. Failures in access removal, change approval or production access usually affect many other controls, so they deserve closer reading than a documentation gap in a low-risk process. Ask which criterion the exception sits under, such as CC6 for logical access or CC8 for change management, and whether it touches the controls your contract depends on.

Frequency within the period

A single deviation in a sample of several hundred items reads differently from repeated deviations across the observation period. The description of tests and results should state how many items were tested and how many failed. Ask whether the failures clustered in one month, which can point to a broken process, or spread across the period, which can point to a control that was never reliably operated.

Effect on customer data and availability

Ask whether the failed control protected customer data, system availability or both. An exception in a control that guards confidentiality or availability commitments may matter more to your data exposure than one in an internal control with no customer-facing effect. Compare the affected in-scope system with the service you buy, since a failure in an environment you never use may not change your risk.

Compensating controls

A compensating control is a different control that reduces the same risk while the primary control was failing. Check whether the report or management response describes one, whether the auditor tested it, and whether it covered the full period or only part of it. An unsupported claim that a compensating control existed should lower your confidence, not raise it.

Root cause fixed before period end

Confirm whether the vendor corrected the underlying cause before the observation period closed, or only the specific instance. A fix made after period end still matters, but it is evidence of response, not proof that the control operated during the period. Look for a described change to the process, tool or ownership, not only a note that the item was completed.

Owner and completion evidence

Management's response should name an accountable owner, a target completion date and the evidence path that will show the fix works. This is where the CC4.2 expectation appears in practice: deficiencies are evaluated, communicated and corrected. A response with no owner, no date or no way to verify the fix is a signal to ask the vendor for the remediation evidence before you rely on the next period.

What a SOC 2 qualified opinion means for your risk decision

A qualified opinion tells you that the examining CPA reached a modified conclusion on some part of the engagement while the rest of the report stands. In a SOC 2 Type 1 or Type 2 report, the CPA gives an opinion on whether management's description of the system is fairly presented, alongside the opinions on the controls. A qualification can attach to any of these. Start with the opinion paragraph, identify which opinion is modified, and then find the criteria, controls or system components the qualification refers to. The wording of the qualification names the scope of the problem, and that scope decides whether the issue touches the service you are buying.

A qualified report still needs to be read end to end. The test results, the exceptions table and the management responses often explain whether the gap is a missing review in one quarter or a missing control across the whole period. Check the observation period, the trust services categories in scope, and whether any subservice organization or complementary user entity control sits behind the qualified area. Compare what the qualification covers with the data, availability or processing commitments in your contract. A practitioner quoted by the *Journal of Accountancy* in February 2026 said a SOC 2 report that business partners reject has little value, so the report's usefulness depends on how your organization reads it.

Decide the risk in writing before you accept or reject the vendor. Record which qualified criterion maps to your data flows, whether the gap is closed by a later period or a bridge letter, and which compensating controls you can verify yourself. Ask the vendor for a dated remediation plan and evidence that the corrective action was tested, and confirm with the vendor, rather than assume, whether the next examination period will cover the fix. If the qualification affects a control your own obligations depend on, add a contract clause, an interim assessment or an additional control on your side. Some qualifications are acceptable for a low-sensitivity use case and unacceptable for a regulated one, and that judgment belongs to your risk owner, not the auditor.

How management responses are presented and what to check in them

A SOC 2 report is a bundle of sections, and management's responses to exceptions are not placed next to the testing results in every report. Microsoft, which publishes its SOC reports for Azure customers, tells readers that management responses to exceptions appear toward the end of the attestation report, and that user entity responsibilities sit at the very end. That layout means a reviewer who stops reading after the opinion will miss the response entirely.

Opinion first: The auditor's opinion states whether controls were suitable and operating effectively, and an exception can change how that opinion reads.
Test results second: The Type 2 description of tests and results shows which criteria produced an exception and over which sample or period.
Management response near the end: The vendor's answer to each exception is usually collected in a separate part of the report, so match each one back to its test row.
User entity responsibilities last: These list the controls your organization must run, which can be where a gap is shifted to you.
Layout varies by provider: Confirm where the responses sit in each report you receive rather than assuming the same order.

Before you rely on a response, find the exception it answers and confirm that both appear in the same report version and period.

How to remediate an exception before the next period

The sequence turns a reported exception into a corrected control with dated records that the next examination can test, so the organization can explain the deviation to customers with evidence rather than assertion.

Confirm the exception against the test results
Start by reading the service auditor's description of tests and results for the control in question. Confirm which control, which period, which sample and which attribute failed, and whether the deviation was a single occurrence or a pattern. Compare the auditor's wording with your own records of the same activity. The output is a short exception register entry that names the criterion, the control, the test performed and the observed deviation. The step is complete when the control owner and the compliance lead agree the register entry matches the report.
Determine the root cause
Work out why the control did not operate as designed. Common causes include an unclear owner, a manual step with no trigger, a tool that was misconfigured, a process that changed without the control being updated, or a policy that assumed a practice nobody followed. Interview the people who performed the control and review the system logs for the affected population. The output is a root cause note that separates the failure of design from the failure of operation, because each one needs a different fix. The step is complete when the note explains the cause with supporting records, not opinion alone.
Communicate the deficiency to responsible leaders
Under the principle restated in CC4.2, deficiencies should be evaluated and communicated promptly to the people responsible for corrective action, including senior management and, where appropriate, the board. Send the root cause note and the proposed corrective plan to the control owner's management chain and record the date and recipients. Escalate to the board when the exception affects a commitment made to customers or when it reflects a wider governance gap. The output is a dated communication record, such as meeting minutes or an approval email. The step is complete when the people who must act have acknowledged the deficiency and assigned an owner.
Redesign and implement the fix
Change the control, not just the paperwork. Depending on the root cause, this may mean assigning a named owner, automating a manual check, tightening an access list, adding a review step with a defined reviewer, or updating a procedure so it matches practice. Where a system change is needed, route it through the organization's change management process so the fix is itself evidenced. The output is a revised control description, the updated procedure or configuration, and a dated change record. The step is complete when the new design is in use for real transactions or systems, with the first operating instance recorded.
Document the remediation record
Write a remediation record that links the exception to the root cause, the changed control, the date the change took effect, the owner and the evidence location. Include the management response wording you expect to provide for the next report, reviewed by the people who will sign it. Avoid claims the evidence cannot support. The output is a single remediation file that an auditor can follow from exception to fix. The step is complete when someone outside the control team can trace the chain without help.
Monitor the corrective action
Check that the fixed control keeps operating. Set a recurring review of the control's output, such as a sample of the affected population, a dashboard of exceptions, or a report reviewed by someone independent of the operator. Record the results and escalate any new deviation through the same communication path. The output is a monitoring report or review log for each cycle. The step is complete when the monitoring has run enough times to show the fix is stable, and you have confirmed that cadence with your auditor.
Collect evidence the auditor can test
Prepare the population, samples and records the auditor will request in the next period. Confirm that the evidence shows the control operating over the whole period, not only after the fix date, and that the records are complete, timestamped and retained. Ask the auditor which evidence form they expect for the changed control before the period starts. The output is an evidence index mapped to the control and criterion, with the monitoring records attached. The step is complete when the auditor has confirmed the evidence approach or raised questions while there is still time to answer them.
Explain the exception to report users
Prepare the account that customers and prospects will read. Use the management response in the report as a starting point, and have a short factual summary ready for security questionnaires and trust pages, stating what failed, what changed and what evidence now exists. Confirm with counsel or your contract team what can be shared and under what terms. The output is an approved customer-facing summary and a question and answer note for sales and support. The step is complete when the wording matches the report and the remediation record exactly.

Bridge letters and explaining exceptions between reports

A bridge letter is a written statement from the service organization's management that covers the time between the end of the examined period and a later date, usually the date a customer asks about. It is not part of the SOC 2 examination. It does not carry the CPA's opinion, it does not extend the period the auditor tested, and it cannot erase an exception that the report already states. If the Type 2 report lists a deviation in access reviews for the period, a bridge letter can describe what has changed since, but the deviation stays in the report. The AICPA's SOC 2 Report Walkthrough lists bridge letters as a key topic and includes considerations related to exceptions among its learning outcomes, which is a useful reference for anyone reading one.

When a vendor offers a bridge letter to explain an exception, ask it three things: what has changed in the control since the period closed, when each change took effect, and what evidence supports the statement. Strong answers point to dated artifacts such as a revised access review procedure, a completed review record, an updated ticket workflow, or a remediation log entry, and they name the owner of each control. Weak answers describe intent, such as a commitment to improve, without records. Treat the letter as a claim to test, not a finding. Where the change touches controls your organization relies on, consider asking for samples of the evidence, or ask whether the next examination period will test the remediated control.

Before you rely on a bridge letter, confirm with your own counsel what your contract says about report currency. Some agreements require a report covering a recent period, others accept a bridge letter for a stated gap, and others define a maximum age for the report. Whether a bridge letter satisfies the clause is a contract question, not a technical one. Also note that the vendor's management writes and signs the letter, so its standing depends on the vendor's own representations, which is why the supporting evidence matters more than the letter's wording.

Which response fits each customer situation

This table compares five responses a customer can take after finding an exception or qualified opinion in a vendor's SOC 2 report. Each row shows when the option fits, the effort it asks of the customer, and what the vendor should provide. No single response suits every case, so the right choice depends on the risk the exception touches and how the service is used.

Response	When it fits	Customer effort	What the vendor must provide
Accept with documented risk acceptance	The exception affects a control that does not protect data or services you rely on, and compensating controls on your side cover the gap	Moderate: a written risk assessment, sign-off by an accountable owner, and a review date	A clear description of the deviation, the root cause, and the management response
Request a bridge letter and remediation evidence	The report period ended a while ago, or the fix happened after period end and you need current assurance	Low to moderate: one written request, then review of the letter and supporting records	A signed bridge letter covering the gap, dated remediation records, and a statement of any new exceptions
Add contract terms with a corrective action date	You need the vendor to close the gap, but the service is important enough to keep	Moderate: negotiating clause wording and tracking the agreed date	Committed remediation milestones, a named owner, and notice of slippage before the date passes
Apply compensating controls on the customer side	The exception sits in a vendor control that your own controls can detect or limit, such as access reviews or data export monitoring	High: designing, running and evidencing the controls, usually as complementary user entity controls	Confirmation of which complementary user entity controls the vendor expects you to run
Reject the vendor and escalate	The exception is repeated, the root cause is unresolved, or it touches confidentiality or access to regulated data	High: vendor reassessment, possible migration planning and contract exit steps	Escalation contacts, the vendor's remediation plan, and its response to your written questions

Pitfalls that turn an exception into a longer dispute

An exception in a Type 2 report is rarely the problem on its own. Disputes grow when readers skip the detail, accept reassurance in place of evidence, or let remediation drift past the period under review. Each pitfall below has a short check that keeps the conversation with the vendor on facts.

Reading only the opinion page

The opinion page states whether controls operated effectively, but the exception itself sits in the description of tests and results. A Type 2 report lists the criteria tested, the sample or procedure the service auditor used, and the deviation found. Read that section for every control tied to your data, then decide how each deviation affects your own controls. Avoidance step: before any call with the vendor, list each exception with its criterion and the control it affects.

Trusting a clean summary

A summary that says the controls were effective is a headline, not a finding. A vendor's sales deck, trust page or questionnaire answer can omit a deviation that the auditor recorded in the test results. Compare every summary statement against the auditor's own section of the report. Avoidance step: ask the vendor in writing whether any deviation appears in the report, and check the answer against the test results.

Accepting a response with no owner

The management response explains what the service organization did about an exception, and it appears in the attestation report. A response that names no accountable person, gives no date and cites no evidence leaves the exception open in practice. Look for a named owner, a root cause, a completion date and the artifacts that prove the fix, such as a change record or a re-performed access review. Avoidance step: request those artifacts before accepting the response as closed.

Assuming a bridge letter closes the gap

A bridge letter is a management statement covering the time between the end of the examination period and the date a reader needs. It does not test controls, and it does not change the opinion already issued. Treat it as a short-term signal of management's current position, and ask what changed, whether the exception recurred, and whether the auditor has reviewed the statement. Avoidance step: read the bridge letter alongside the exception section, not instead of it.

Remediating after the next period starts

If a fix lands after the next observation period has started and no one tests it, the next report may show the same deviation again or a gap in the period between. Ask for the date the control changed, the evidence that it operated from that date, and whether the auditor plans to test it in the coming period. Avoidance step: set a dated checkpoint for the fix and request the test evidence at that checkpoint.

Marketing the report beyond its scope

A SOC 2 Type 2 report covers the systems, period and categories described in it, and it does not certify that the vendor is compliant with every regulation. Describing an exception-laden report as proof of security, or sharing a restricted-use report beyond its permitted audience, creates a second dispute. Check any public claim against the report's scope and opinion, and keep the report under the rules the AICPA sets for its use. Avoidance step: have counsel or the auditor review any public wording that cites the report.

Who does what when an exception is found

The service organization owns every control in its SOC 2 and every decision about what happens when one fails. When the auditor records an exception, management is responsible for explaining what went wrong, why it happened, what it has changed and how customers are told. Those statements are written by management and appear in the report as management's response, so they must match what the organization can prove.

Root cause analysis: Management determines why the control failed, whether the cause was a people, process, tooling or design problem, and whether other systems share the same weakness.
Management response: Management writes the response to the exception, which the report presents alongside the auditor's findings. The response should describe actions and dates that the organization can evidence.
Remediation ownership: Management assigns the corrective action to named owners, tracks it and escalates it to senior management or the board as the CC4.2 points of focus expect.
Customer communication: Management decides what customers hear, when, and through which channel, including whether a bridge letter or direct explanation is needed.
Control redesign decisions: Management chooses the fix, accepts the residual risk and records that decision.

Before relying on a vendor's report, check that the management response names concrete actions rather than general commitments.

Questions buyers ask about SOC 2 exceptions and qualified opinions

Does an exception in a SOC 2 report mean the vendor failed its audit?

Not by itself. An exception is a deviation: the auditor tested a control over the period and found an instance where it did not operate as described. A Type 2 report lists tests and results, so the reader can see what was tested, how many items were sampled where the report says so, and what went wrong. The question for a buyer is whether the deviation is isolated or systemic, whether it touches data or services they rely on, and whether management has a credible response. Ask for the full section that contains the exception, the root cause analysis, and the date the corrective action was completed. Read the management response in the report, not only the auditor's summary, because that is where the vendor explains its position.

Does a qualified opinion make a SOC 2 report unusable?

No, but it changes what the report can prove. A qualified opinion means the auditor concluded that, except for a specific matter, the description or controls were fairly presented or operated effectively. The qualification names the criterion or area affected. Whether that matters depends on whether the qualified area touches the service you buy. A customer whose data never passes through the affected system may accept the risk with documented reasoning. A customer whose requirements depend on that control may need compensating evidence, a remediation timeline, or a contract term. Ask the vendor which criteria are qualified, what the qualification says in plain terms, and what the next period's test is designed to confirm.

How long must a control fix run before the auditor can test it?

The answer depends on the control, the frequency it runs at, and the observation period the auditor agreed to. A Type 2 examination tests operating effectiveness over a specified period, so a fix made late in that period may only cover part of it, and the auditor will decide how much history is needed to form a view. Controls that run daily or per change produce many instances quickly. Controls that run quarterly or annually may need a full cycle before a test is meaningful. Ask the auditor, before the period starts, how many occurrences they expect to sample for each remediated control and whether the remediation will be tested as a new control or only as part of the existing one. The exact duration is set by the auditor and the control design, not by the vendor.

Can a customer require a bridge letter to cover an exception?

A customer can ask for a bridge letter, and whether it is required depends on the contract. A bridge letter is a management statement covering the period between the end of the report and a later date, typically stating whether management is aware of material changes or known issues in that gap. It is not an audit opinion and is not issued by the auditor. When an exception has been found, a bridge letter is where the customer checks whether the vendor has disclosed known problems that happened after the period. Write the clause into the contract, specify the date it must cover, and ask whether the vendor's management will sign it. Your legal team should confirm the wording, and the auditor should not be asked to sign it.

What should a vendor's team provide to explain an exception?

A credible explanation normally includes several parts that a reader can check:

The control as designed, and the criterion it supports, using the criterion's common criteria reference.
The root cause, including whether it was a design gap, a people or process failure, or a tool that did not behave as expected.
The scope of impact: which systems, customers, data or periods were affected, and how that was determined.
The corrective action, its owner, its completion date, and the evidence that it was completed.
Whether the control now runs with a higher frequency, more coverage, or an independent check.
Any monitoring that confirms the fix has held since.

Criterion CC4.2 expects deficiencies to be evaluated and communicated to people who can act on them, so ask who reviewed the deficiency and at what level of management.

Can an implementation partner fix a SOC 2 exception for the vendor?

A partner can help the vendor design, implement and evidence the corrective control, but it cannot change the audit result or write the management response on the vendor's behalf without the vendor owning the decision. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside a client's own infrastructure, and it prepares systems, controls and evidence for assessments. It does not issue reports or opinions, and only an independent CPA firm can do that. In scope, a partner might rebuild a logging pipeline, automate an access review, or document a change approval step so the next period has evidence. The vendor still owns the control, the root cause analysis, and the statement to customers. Scope, deliverables and timelines are agreed in writing before work begins.

How DeployOpen prepares remediation and evidence after an exception

DeployOpen works on the systems and evidence behind an exception, not on the opinion itself, which only an independent CPA firm issues. We help a service organization understand which control deviated, prepare the systems and records that show the corrected control operating, and document the work for the next examination period.

How we scope

Each engagement starts with a written scope that names the exception, the control and the systems involved.
We confirm with your CPA firm which evidence the auditor expects before any remediation work begins.
Scope and deliverables are agreed in writing before work starts, so the boundary of the fix is clear to everyone.

How we build

We configure, harden or integrate self-hosted open-source platforms to close the root cause of the deviation.
We test the corrected control and record results so the operating evidence exists before the next period.
Changes go through your own change process, with approvals and rollback steps kept as records for the auditor.

How we hand over

We document the root cause, the corrective steps, owners and dates in a form your management response can reference.
We deliver runbooks, configuration records and evidence packs that your team can maintain after the engagement.
Your organization keeps ownership of the controls and of the management response; we do not write the auditor's report.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer to keep corrected controls operating.
Retainers can cover monitoring of the control between audits, so drift is caught before the next examination period.
Ask your CPA firm and your DeployOpen contact to confirm the evidence expected for your specific exception before fixing it.

SOC 2 exceptions and qualified opinions: what they mean