How to review a SOC 2 report

A SOC 2 report is not a certificate with two hundred pages of supporting decoration. It is an attestation about a described system, against selected criteria, during a defined period. Each qualifier in that sentence matters.

Read it in seven passes

Pass 1: identify the examination

Confirm the legal entity, report dates, service, Type I or Type II, and Trust Services Criteria. The AICPA SOC 2 reporting guide defines the examination framework. Type I addresses design at a point in time. Type II also tests operating effectiveness over a period. Neither matters if the service you plan to use is outside the scope of the audit.

Pass 2: read the auditor's opinion

Read the independent service auditor's report in full. Identify any qualified opinion, scope limitation, or deviation from the applicable criteria. Capture the wording rather than translating it immediately into green, yellow, or red.

Pass 3: read management's assertion

Compare what management asserts with what the auditor opines on. Watch for differences in dates, systems, and criteria. This is also where responsibility becomes clear: management describes and operates the system; the CPA evaluates the subject matter under professional attestation standards. The AICPA SOC suite overview explains the CPA examination role and the intended users of the resulting reports.

Pass 4: draw the boundary

Use the system description to identify infrastructure, software, people, procedures, data, locations, and external services. Mark subservice organizations and whether they are included or carved out. Compare this boundary with your proposed integration.

Pass 5: inspect the tests

For each material requirement, read the vendor control, the auditor's procedure, and the result. A control statement may sound broad while the test is narrow. Record evidence citations and classify each requirement as meets, partial, does not meet, or pending.

Pass 6: investigate exceptions

An exception is not automatically a rejection, and a management response is not automatically remediation. Ask how large the affected population was, how long the condition existed, what caused it, what exposure resulted, when it was fixed, and whether anyone independently retested it.

Pass 7: identify shared responsibilities

Complementary user entity controls describe what customers must do for the control environment to work. Complementary subservice organization controls may describe dependencies the report did not test. Turn both into implementation requirements or follow-up questions.

A worked example: the clean report with a relevant exception

Assume a customer-support platform will store names, email addresses, support history, and occasional screenshots. The report is a current Type II examination of the production platform. The opinion is unmodified. Security, availability, and confidentiality are included. At first glance, this looks like a simple approval.

The exceptions tell a more useful story. The auditor sampled new-user access approvals and found one support engineer whose approval was documented after access had already been granted. Management says the delay was administrative, the access was appropriate, and the workflow has been corrected. That may be true, but the exception still needs interpretation.

Start with population and consequence. Was this one late ticket among fifty correctly approved accounts, or one of three? Did the employee receive ordinary support access or a role that could impersonate customers? How long did access exist before approval? Did logs show the account touching customer data? Was the corrected workflow retested, or is remediation only a management statement? The report may answer some questions. The rest become focused follow-up requests.

Then apply the proposed use. If the platform stores public documentation questions, the residual risk may be acceptable with normal provisioning controls. If it stores regulated case files and support personnel can assume customer sessions, the same exception deserves greater scrutiny. The audit result did not change. Your consequence did.

A defensible conclusion might be conditional approval: require single sign-on and automated deprovisioning, prohibit regulated attachments until the vendor provides remediation evidence, verify that customer impersonation is separately authorized and logged, and reassess after the next audit period. This conclusion respects the clean opinion without pretending the opinion answered a question outside its evidence.

Operating effectiveness is not security sufficiency

SOC 2 engagements are performed by independent licensed CPA firms under AICPA attestation standards. That means the engagement team is grounded in accounting and audit discipline, but individual team members are not necessarily security practitioners. Their work is exceptionally useful for verifying whether the company implemented and operated the controls it claimed. The AICPA Trust Services Criteria establish the criteria against which those controls are evaluated.

The security review has a different question: were the stated controls sufficient for the threats and use under consideration? A control can operate exactly as designed while its design remains too weak for your use. The AICPA itself distinguishes a SOC 2 examination from a broader SOC for Cybersecurity examination. I rely on the audit work, then independently evaluate the adequacy of the controls that passed. NIST SP 800-53A is useful here because it separates assessment procedures from the organization's risk-based judgment about whether a control set is adequate.

Do not flatten every exception into severity

SOC 2 reports do not give you a universal vulnerability score for an exception, and they should not. An exception is evidence that a described test produced a result outside the expected condition. Its importance depends on the control objective, affected population, duration, cause, exposure, and the way you intend to use the service.

Separate three questions. First, what did the auditor actually test? "Inspected a sample of approvals" is different from independently verifying that the application prevented unapproved access. Second, what failed? A missing signature on an otherwise timely approval is different from an account that remained active after termination. Third, what happened next? A management response describes management's position. It is not the same thing as an auditor retesting the changed control.

Also watch for the opposite mistake: dismissing an exception because management calls it isolated. Sampling supports conclusions about a defined population under a defined method. It does not make the untested items disappear. Use the report's procedure, sample, and result as the evidence they are, then decide whether additional proof is warranted for your use. The assessment logic in NIST SP 800-53A is helpful because it keeps assessment method, object, and result visible instead of collapsing everything into one score.

Write questions that can produce evidence

Avoid "Please explain your security." Ask: "The report tests MFA for workforce access but does not identify customer-support impersonation paths. What controls prevent support personnel from assuming a customer session, and what evidence demonstrates operation during the review period?" Focused questions reveal whether the gap is documentation, scope, or control design.

Document the result

Your conclusion should identify the evidence reviewed, material controls, exceptions, scope gaps, unanswered questions, complementary controls, and residual risks. Use approve, conditional, pending, or deny. If an exception is accepted, name the accepting human. If approval depends on configuration, make it a tracked condition.

Turn complementary controls into assignments

Complementary user entity controls are not boilerplate to skim on the way to the auditor's tests. They describe controls the service organization assumes its customers will perform. A requirement to remove departed users, protect API credentials, configure retention, review logs, or maintain a recovery plan is not operating merely because it appears in the report. Name the internal owner, required configuration, verification evidence, and due date. If nobody owns the control, treat it as a deployment gap.

Apply the same discipline to subservice organizations. A vendor may use the inclusive method, which brings relevant subservice controls into the description, or the carve-out method, which excludes those controls and identifies complementary subservice organization controls. The report should explain its approach. Record which providers matter to your data flow and what other evidence covers the carved-out responsibility. Otherwise, a strong opinion can sit beside an unexamined dependency.

Sources and further reading

• AICPA, SOC 2 Reporting Guide
• AICPA, 2017 Trust Services Criteria with revised points of focus
• AICPA, Key distinctions between a SOC 2 examination and a SOC for Cybersecurity examination
• NIST SP 800-53A Rev. 5, Assessing Security and Privacy Controls

Managing repeated SOC 2 reviews

Can I Run That? can organize control extraction, requirement mapping, citations, follow-up evidence, and decision history across many reports. The reviewer still tests material conclusions against the report and adds business context.