How to read a vendor SOC 2 report: what to check

How to read a SOC 2 report from a vendor before you rely on it

A SOC 2 report is an independent CPA firm's opinion on a vendor's controls over a stated period, so start by checking the period, scope and opinion before anything else. Confirm that the report covers the services you buy, the trust services categories the vendor included, and whether the opinion is a Type 1 (as of a date) or a Type 2 (over a period that overlaps your engagement). A report that ends months before your contract starts tells you little about today's environment, and a scope that omits the product or data center you use answers a different question from the one you are asking.

The report is not a pass or fail certificate, and it does not certify compliance with any law. Its value depends on what you do with it: whether the exceptions in the tests of controls touch risks you care about, whether management's responses describe fixes you can verify, and whether the complementary user entity controls (CUECs) in the description are controls your own team must run. Check the subservice organizations too, since a carve-out means their controls are outside the opinion and need their own review. Ask the vendor which CUECs apply to you and who on your side owns each one before you sign.

Finally, judge the CPA firm, not only the document. Confirm the firm holds a valid license through CPAverify, which is a free license search, and ask whether the firm is independent of the vendor's own consulting work. Record your review decision, the exceptions you accepted and any open follow-ups in your third-party risk file, because examiners assessing your oversight will ask how you reached it.

Which sections of a SOC 2 report to read first

The reading order moves from what the vendor claims, to what it built, to what the auditor concluded, to what actually happened in testing, so each step checks the one before it. Finishing the sequence gives you a view of the period, scope, exceptions and the duties you keep on your side.

Confirm the report type and examination period
Start with the cover and the auditor's opening letter, not the opinion. Confirm whether the report is a Type 1 or a Type 2, the date or period it covers, and the report's issue date. A Type 1 speaks as of a single date, while a Type 2 covers an observation window, so the period on the cover tells you which controls were actually tested. Write down the start and end dates and whether they overlap the period you need. Your output is a one-line note on the period, and a question to the vendor if the gap to today is large or the report is not the one you expected.
Read management's assertion
Management's assertion is the vendor's written statement that its description of the system is fair and that its controls were suitably designed and operated effectively. It is prepared by the vendor, not the auditor, so read it as the vendor's claim. Check that it names the same services, locations and trust services categories that you buy, and that it refers to the same period as the cover. Your output is a short list of the claims you will test against the rest of the report, such as the categories included or the subservice organizations named.
Test the system description against your service
The system description explains the infrastructure, software, people, procedures and data the examination covers, along with the boundaries of the system. Read it with your own use case in mind: which products are in scope, which regions host your data, how customer data flows, and which carve-outs are listed. Mark any service you buy that the description does not mention. Your output is a scope gap list, which you take back to the vendor before you rely on the report for that service.
Read the service auditor's opinion and its type
The service auditor's report is issued by the independent CPA firm, and it states the opinion. Check the opinion type: an unqualified opinion means the auditor found no issues that required qualification, while a qualified opinion points to a specific exception or limitation. Also check whether the report says the criteria were met for the categories in scope, and whether it includes any emphasis paragraph or restriction on use. Your output is a note on the opinion type and any paragraph that changes how you read the rest of the report.
Map the tests of controls and results
The tests of controls and results lists each criterion, the control activities the vendor says it runs, the procedures the auditor performed, and the results. This is where the report shows whether a control operated across the period and how samples were selected. Read the results column for each area you care about, such as access reviews, change management, incident response and backups. Your output is a list of exceptions and deviations, with the criterion, the number of occurrences noted and the management response beside each one, so you can follow each one up with the vendor.
Check management responses to exceptions
Management responses explain what the vendor did about each exception, such as a root cause, a corrective action and a completion date. Microsoft's SOC reports place these responses toward the end of the attestation report, so you may need to read backward from the tests to find them. Assess whether each response addresses the cause, whether the corrective action would have prevented the exception, and whether the vendor describes evidence of the fix. Your output is a follow-up list for each exception, with a question you will ask the vendor or a note that the response is adequate.
Read the complementary user entity controls and carve-outs
Complementary user entity controls (CUECs) are controls the vendor expects you to run on your side, such as reviewing your user access or protecting your credentials. Microsoft places user entity responsibilities at the very end of its SOC reports, so this step closes the reading order. Also check the subservice organizations: whether the report includes or carves out their controls, and whether complementary subservice organization controls are listed. Your output is a list of your own controls that the report relies on, which your team must confirm it operates, and a list of subservice providers whose reports you must request separately.

Checking the SOC 2 report period, scope and categories against your service

Start by confirming the time window the report covers, because the opinion only speaks to that window. A Type 1 report gives an opinion on the system description and the design of controls as of a single date, so it tells you what the vendor looked like on that day and nothing about the months that followed. A Type 2 report gives an opinion on whether controls operated effectively over a stated period. Write down the period you rely on, which may be the whole time the vendor holds your data, and check that the report's period starts and ends around it. A gap at the start or end of the window, or a Type 1 offered as evidence for a continuing service, is a reason to request a bridge letter or a newer report before you sign.

Next, match the system description to the service you actually buy. The description should name the products, infrastructure, regions, data centers and support locations that serve your tenant, and the versions or modules you are licensing. If the description covers a platform generally but your contract covers a specific product line, a regional deployment or a managed environment that is not named, the report may not describe your system. Look for the boundary of the system, the subservice organizations it relies on, and any product excluded from scope. Ask the vendor to confirm in writing which parts of the description apply to your deployment, and record any mismatch as an open item for your risk review.

Finally, read the categories. Security is always in scope because the common criteria, series CC1 to CC9, apply to every SOC 2 report. Availability, processing integrity, confidentiality and privacy appear only when the vendor included them, so a report that lists only security says nothing about uptime commitments, data accuracy, confidentiality handling or personal data practices. Compare each category listed against the service promises in your contract, such as uptime targets, data deletion terms or handling of personal information. If a promise has no matching category, ask whether the vendor will extend the examination or provide separate evidence, and confirm that the scope is not narrower than the commitments you rely on.

What the opinion, exceptions and management responses tell you

The auditor's output is where a SOC 2 report says what it actually found. The cards below take the opinion, exceptions, management responses, test results and relevance to your own organization in turn, with a question to put to the vendor for each.

The auditor's opinion type

The opinion is the CPA firm's conclusion on whether the description is fairly presented and whether the controls were suitably designed and, in a Type 2 report, operated effectively over the stated period. A clean, unmodified opinion means the auditor found no reason to qualify it. A qualified opinion means the auditor found a problem serious enough to modify the conclusion. Ask the vendor which period and which criteria the opinion covers, and whether any modification exists.

Exceptions and deviations

An exception is a case where a control did not operate as described during the observation period. One exception does not automatically mean the report fails, but it tells you the control was not reliable at that point. Check which criteria the exception touches, how many instances the auditor recorded, and whether the exception concerns a control that protects your data. Ask the vendor for the full list of exceptions and the root cause of each.

Management's responses to exceptions

Management's response explains what the vendor did about each exception, including the root cause, the fix and any change to the control. Responses are written by the vendor, not the auditor, so they describe the vendor's view. Read whether the response describes a corrective action that is in place, or a plan that was not yet operating when the report was issued. Ask for evidence that the fix works and for the date it took effect.

Tests performed and results

The tests and results section shows what the auditor sampled, how they tested each control, and what they found. A Type 2 test description tells you whether the auditor inspected records, observed a process or re-performed a check, and over what sample. Journal of Accountancy has noted that this detail lets users determine how results affect their own organization. Look for tests that match the control's risk, and ask whether the sample covered the full period.

Relevance to your own organization

Test results only matter if they bear on the risk you carry. For example, an exception on access reviews matters more to a customer storing regulated records than to one using a read-only public feed. Map each exception and control to your own data flows and contract obligations. A bank or regulated buyer may also decide whether the scope and results are relevant to the activity it outsources, or whether more scrutiny of the vendor is needed. Ask the vendor how each result applies to a customer in your position.

Clean results and what they cannot show

A clean result means the tested controls operated as described in the sampled cases during the period. It does not show that controls remain in place today, that the description covers every system you use, or that the vendor meets your legal obligations. Check whether the report covers the period you need and whether changes after the period were significant. Ask the vendor what changed since the observation period ended and whether a bridge letter is available.

Type 1 or Type 2: which SOC 2 report answers which question

This table compares a SOC 2 Type 1 report, a Type 2 report and a SOC 3 report across what each covers, what a reviewer can conclude and when each fits a vendor review. Read the first two columns against the service you plan to buy, then confirm the report type with the vendor before relying on it.

Question	SOC 2 Type 1	SOC 2 Type 2
What it covers	The system description and the suitability of control design as of a specified date	The system description and the suitability of control design, plus an opinion on operating effectiveness over a specified period
What the opinion speaks to	A single point in time, so it says nothing about whether controls ran day to day	Whether controls operated effectively throughout the period stated in the report
What the reviewer can conclude	The controls were designed to meet the criteria on that date	The controls operated as described across that window, and the test results and exceptions show how
Where to look for test detail	Limited to the description and design opinion	The tests of controls and results section, including any exceptions and management responses
When it fits a vendor review	An early-stage vendor that has designed controls but has not yet run them long enough to test	Most third-party reviews, especially where the vendor will hold or process your data over time
SOC 3 (general use)	Not a substitute for either report in detail; covers the same categories in less detail	A general use report that can be freely distributed, useful for public or early-stage questions
Distribution	SOC 2 use is generally restricted to specified parties under NDA	SOC 2 use is generally restricted; ask the vendor for the report under its terms
What to confirm with the vendor	Report type, date of the opinion and the scope of systems and categories	Report type, the full observation period and whether the period still covers your contract term

What procurement, security and compliance teams check in the report

Start with the opinion page and the period covered. A Type 1 report speaks as of one date, while a Type 2 report gives an opinion on whether controls operated effectively over a stated period. Your contract usually needs the second kind, and the period should end recently enough to satisfy your vendor review cycle. Confirm that the system named in the report is the product you are buying, not a parent company or a different environment. Check whether the vendor offers a bridge letter covering the gap between the period end and today.

Period and report type: Confirm whether the report is Type 1 or Type 2 and the exact start and end dates of the period.
Scope and categories: Compare the listed Trust Services Categories with the service you buy. Security is always included, but availability, confidentiality, processing integrity or privacy may not be.
Bridge letter: Ask whether the vendor will issue one for the period between the report end date and the current date.
Contract fit: Ask whether the report frequency and distribution terms match the clauses in your agreement.
Exceptions summary: Note any deviations before you sign, and ask how the vendor will address them.

Before you rely on the report, ask the vendor these questions in writing and file the answers with the report.

CUECs and subservice carve-outs: the controls you must run yourself

A SOC 2 report often assumes that you, the customer, run certain controls of your own. These are complementary user entity controls (CUECs): the vendor designed its controls on the expectation that you will perform specific actions, such as reviewing the access you grant to your users, approving changes to your configuration, or promptly reporting suspected misuse of your account. The report's description and the CUEC list usually sit near the end of the report. If you skip them, the vendor's opinion may still be accurate, but the protection it implies may not reach your data. Copy each CUEC into your own control register, assign a named owner from security, IT, procurement or the business unit that uses the service, and record how and how often that owner performs the check. Where a CUEC is ambiguous, ask the vendor in writing what evidence it expects you to keep.

Vendors also rely on other companies. Complementary subservice organization controls (CSOCs) are the controls the vendor expects its own subservice providers, such as a cloud hosting platform or a payments processor, to operate. The vendor can handle subservice organizations in one of two ways. With inclusive treatment, the subservice provider's relevant controls are described and tested as part of the vendor's examination. With carve-out treatment, those controls are excluded from the vendor's tests, and the report says so. A carve-out is not a defect in the report, but it means the vendor's opinion does not cover that layer. To close the gap, request the subservice provider's own SOC report, confirm that its scope covers the service you use, and review the CSOCs it lists. If you do not get that report, document that those controls sit outside the opinion and decide whether your own risk assessment accepts that.

Treat the CUEC list and the carve-out statement as a short action plan before you sign. For each item, decide whether you already operate the control, need to build it, or have agreed with the vendor that another party covers it. Keep the mapping with the vendor file so an auditor of your own organization can trace it. Ask the vendor to confirm any CUEC that depends on features only you can configure, such as single sign-on enforcement or log export. Then ask whether the vendor's own review of its subservice providers is reflected in its third-party risk process. Where the answers are unclear, the vendor's security or compliance team should provide them, and the CPA firm that issued the report can explain what the opinion does and does not cover.

Checking the CPA firm that issued the report

The report is only as credible as the firm that signed it. Four checks confirm that the issuer holds a valid CPA license, has a peer review record, is independent of the vendor, and clearly stands behind the report. A clean license search does not replace reading the report itself.

Confirm the CPA license

Search the firm and the signing partner in CPAverify, a free license search hosted by NASBA and built on official data from 53 participating jurisdictions. It shows license status and flags state board disciplinary actions. Record the license status and date you checked, because a report signed while a license was lapsed or disciplined raises questions about who actually examined the controls. Ask the vendor for the partner's name if the report does not show it clearly.

Review peer review information

Peer review is the AICPA program in which accounting firms have their quality controls reviewed by another firm. Ask whether the issuing firm participates and request its most recent peer review report and rating. Read any letter of comments for findings about attest engagements, since those findings bear directly on how carefully the firm runs examinations like yours. A firm with no peer review history is not automatically unqualified, but you should understand why it is missing before you rely on its work.

Check independence and experience

The firm must be independent of the vendor it examines. Look for signs of conflict, such as the firm also designing the controls it tests, running the vendor's compliance program, or holding a financial stake in the vendor. Then check experience with SaaS or hosting providers similar to your vendor, and with the specific categories in scope. An examination that the firm is not equipped to perform can produce a clean-looking report that tests the wrong things.

Read the firm name, signature and date

The firm's name, the signature and the report date appear in the service auditor's report. Confirm the signature matches the firm you searched in CPAverify, and that the date falls within or after the period the report covers. A report with no signature, an unnamed firm, or a date that does not align with the examination period is incomplete for due diligence. Note the firm name exactly as printed so you can match it to a license record and peer review file.

Questions reviewers ask about a vendor SOC 2 report

Is a vendor's SOC 2 report enough on its own to approve them?

No. A SOC 2 report is evidence about one system, for one period or date, against the criteria in scope, and it is only as useful as its match to the service you buy. Read the scope, the period, the categories and the opinion, then decide what else you need, such as a security questionnaire, a contract review or your own assessment of the vendor's subservice providers. The report tells you what the vendor's auditor tested. It does not tell you that the vendor is compliant with your regulations, which is your own judgment to make with your legal and risk teams.

How old can a SOC 2 report be before it is stale?

A SOC 2 report has no expiry date, but its opinions are tied to a period (Type 2) or a date (Type 1), so the question is how far that period sits from today. Many customers treat a report as current for about a year, and contracts often set the required frequency. If the period ended long ago, ask the vendor for a bridge letter covering the gap and check what changed in the platform, staffing or subservice providers in between. Confirm your contract's wording with your own counsel, since the frequency clause is what binds the vendor.

What should I do when the report lists an exception?

Read the exception, the management response and the test results together before deciding anything. An exception is a control that did not operate as described during the period, and the opinion's type and the report's description show how serious the deviation was. Ask the vendor what caused it, what was changed afterward and whether the change has been tested since. Record your decision in your third-party risk file, and check whether the exception touches a control your own data depends on, such as access reviews or change management.

Can a SOC 3 report replace the SOC 2 report?

Usually not for due diligence. A SOC 3 covers the same categories in less detail, and because it is a general use report it can be shared freely, which makes it useful for public assurance. It does not include the system description, the tests of controls or the exceptions, so you cannot tell which controls were tested or how they performed. Ask the vendor for the restricted-use SOC 2 under an NDA when you need to assess controls, and use the SOC 3 as a summary only.

How long does a review take, and what must my team do itself?

The time depends on the report's length, your familiarity with SOC reports and how many subservice organizations and complementary user entity controls appear in it. Your team must do the parts only you can do: confirm the scope matches the service you buy, map the complementary user entity controls to your own owners and processes, and decide whether the vendor's carve-outs are acceptable. Plan for those tasks in your procurement calendar and ask the vendor for the report early, because the review can stall while you wait for an NDA or a bridge letter.

Can an implementation partner review the vendor's SOC 2 report for us?

An implementation partner can help your team read the report and build a checklist, but the judgment on whether the report meets your requirements stays with you and your risk owners. DeployOpen prepares systems and evidence for assessments and does not issue audit reports or attestations, so it cannot assess a third party's report on behalf of an auditor. For questions about the report's opinion, the test procedures or the CPA firm's independence, go to the vendor and the CPA firm directly. You can check a CPA's license status through CPAverify, which is a free NASBA search.

What should I check about the CPA firm that issued the report?

Check that the firm is licensed and in good standing, because a report from an unlicensed or disciplined firm does not give you the assurance you need. CPAverify, hosted by NASBA, is a free license search built on official data from 53 participating jurisdictions and flags state board disciplinary actions. Also ask whether the firm's peer review is current, using the AICPA Peer Review Program information, and confirm the firm's name and signature appear on the report itself.

How DeployOpen prepares your review and the evidence you ask for

DeployOpen works on the evidence side of a SOC 2 review: preparing the systems, controls and documentation a service organization needs so its report can be read against your requirements. We do not issue reports or opinions, and an independent CPA firm remains the only party that does.

How we scope

Engagements are fixed-scope, with the systems, controls and deliverables agreed in writing before work starts.
We map the services you buy to the report's categories, period and system boundary so the review questions are defined up front.
Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the review.

How we build

We help a service organization prepare its complementary user entity controls list so your team knows which controls you must run.
We review subservice carve-outs against the vendors you rely on and flag where separate assurance is needed from those parties.
We check that the description, control matrix and test evidence in a prepared environment match the operating reality described.

How we hand over

You receive a written checklist of report sections, the questions each one answers and the owner of each follow-up item.
We document the exceptions, management responses and user entity responsibilities that your third-party risk file should record.
Handover includes a list of what to confirm directly with the CPA firm, such as the report date, period and opinion type.

How we support

We can help your team prepare the questions to send a vendor when a report raises exceptions or a scope gap.
Support can cover reviewing the next report period when your contract requires a fresh report or a bridge letter.
Retainer support is available for ongoing vendor review work, with the scope confirmed in writing before it starts.