DataSecureCheck that the report covers the service you use and the relevant period. Then read the independent auditor’s opinion, management’s system description, applicable controls and—on a Type II report—the tests and results. Follow up on exceptions, your own responsibilities and any excluded providers before recording a risk decision.
A practical sequence for reviewing a report
| Look for | What to check | Why it matters |
|---|---|---|
| Service and entity | Compare the named organization, product and system boundaries with what you buy. | A report for a different product or entity may not address your use. |
| Report type and dates | Note whether it is Type I or II and the date or period covered. | Type II addresses operating effectiveness during a defined period; neither report assures the future. |
| Auditor’s opinion | Read the full opinion and any basis for modification. | The opinion gives the auditor’s conclusion in its stated context. |
| Criteria and system | Compare the trust services categories, infrastructure and services described to your needs. | An important service or topic may be outside the scope. |
| Tests and results | For Type II, examine the relevant controls, tests, results and any exceptions. | The detail helps you judge how findings relate to your exposure. |
| Shared responsibilities | Identify complementary user entity controls and treatment of subservice organizations. | The provider’s controls may depend on actions by you or another provider. |
The AICPA’s SOC 2 report walkthrough identifies report sections, opinion types, customer controls and subservice organization treatment as key review topics. For report types, see our Type I versus Type II guide.
What do a qualified opinion and exceptions mean?
An unmodified opinion is not a guarantee that nothing went wrong or that the provider is secure in every respect. Read the auditor’s conclusion alongside its scope and the detailed results. A qualified opinion means the auditor has modified the conclusion for a stated matter; read the basis and determine its relevance to the service and risks you are assessing. Other modified opinions can have different implications and warrant careful review.
A control-testing exception is a deviation identified in a test; its existence does not automatically mean the overall opinion is qualified. Consider what control was affected, the nature and frequency of the deviation, the period and any explanation or remediation. Ask your risk or audit specialists for help where the impact is unclear.
Find what the report expects your team to do
Complementary user entity controls (CUECs) describe controls the provider assumes its customers will operate. For example, a provider may expect you to manage your own user access. Record each relevant responsibility, identify an owner and check whether your team actually performs it. A provider report cannot demonstrate that your organization has done so.
Also check whether other providers are included in the examination or described using the carve-out method. If relevant controls at a subservice organization are carved out, assess whether you need additional assurance, such as that provider’s own report. Read the actual description rather than assuming that a cloud provider’s name means all its controls were tested.
Worked example: evaluating a cloud application
Imagine your company uses a vendor’s analytics application to process customer data. Its Type II report covers the application and security category for a period ending three months ago. The vendor’s report identifies an exception in a sample of access removals, describes customer responsibility for managing application accounts, and carves out the cloud hosting provider.
Your reviewer checks whether the exception affected accounts with access to relevant data, asks about corrective action and considers whether a period-gap update is available. IT verifies its own account reviews; procurement asks for assurance about the hosting provider. The owner records the findings and a decision based on your company’s risk tolerance. This is illustrative, not a recommendation to accept or reject every similar report.
Questions to send your vendor
- Does this report cover the exact product, entity and infrastructure we use?
- Can you explain any opinion modification or test exception relevant to our service, and provide remediation status?
- Which customer controls are necessary for our implementation, and where are they documented?
- Which subservice organizations are carved out, and what assurance is available for them?
- What has changed since the report period ended? Is a bridge letter or other update available?
A bridge letter can provide information about the interval after a report ends, but it is not the same as an independent examination of that interval. Evaluate who issued it, what it covers and whether you need more evidence.
Document the review—not just the download
Keep the report and related communications in an access-controlled location, respecting its distribution restrictions. Record the reviewer, service, report period, scope fit, relevant findings, customer controls, follow-up owner, decision and next review date. SOC 2 reports often contain sensitive operational details, so share them only with authorized recipients under the applicable terms.
If you are preparing your own program, our evidence checklist helps you map controls to owners and records.
Educational guidance, not an audit opinion or a substitute for an assessment of your specific vendor and risks.
Make security evidence easier to manage.
Discuss your readiness and evidence process with DataSecure365.
Book a demo ↗