A supplier says "we're SOC 2 Type II certified." Worth pausing on that phrase before going any further, because "certified" isn't quite the right word for what SOC 2 actually is, and the sentence alone tells you almost nothing about what the report actually covers.

They hand over a document running well past a hundred pages. The tempting shortcut is to search for the word "exceptions," find none, and mark the supplier approved. That misses most of the value sitting in the report. Before deciding how much assurance it actually gives you, there's a longer list of questions worth answering first: which service does this cover, and which legal entity? Which locations? What time period? Which Trust Services Criteria were actually included? Which controls, tested how? Which subservice providers does the supplier itself depend on? What's the report quietly assuming your own organisation is doing? Were there deviations, and if so, what do they actually mean? Does any of this even touch the risks you actually care about?

That's the whole article in one paragraph. A SOC 2 report is a genuinely valuable piece of independent assurance evidence, and its value depends entirely on actually reading it, not on the fact that it exists.

Remember this

A SOC 2 report's value comes from scope, period, criteria, control design, testing, results, exceptions, customer responsibilities, subservice organisations, and relevance to your specific risk, together. Leave any one of those out and the conclusion is incomplete.

This article continues directly from Security Assurance for SOC Analysts, Third-Party Cyber Risk and Supplier Assurance, and Present Is Not Effective: How to Test Security Controls. Where those articles taught the general method, requirement, evidence, testing, findings, this one applies that method to one specific, extremely common artefact you'll be handed constantly in supplier assurance work.

Watch out

SOC 2 reports are typically confidential, restricted-use documents, shared under NDA or similar terms for a specific purpose. This article uses fictional examples throughout, never real report content, and nothing here should be taken as reproducing or summarising any actual supplier's report.

analyst@thefish.nz:~$ cat contents.txt

What is SOC 2?

SOC 2, "SOC for Service Organizations," is a reporting framework developed by the AICPA. In plain terms, a SOC 2 report is an independent auditor's report on a service organisation's controls, relevant to a defined set of Trust Services Criteria, for a specific system, at a specific point in time or across a specific period.

Worth being precise on terminology here, because "SOC 2 certified" is genuinely common shorthand and genuinely a bit misleading. SOC 2 is an attestation engagement, an independent practitioner examines management's own description and assertion about its system, then reports on it, rather than a certification in the same sense as ISO 27001, where an organisation is certified against an international management-system standard by an accredited certification body. Both are genuinely useful forms of independent assurance. They're structured differently, and it's worth not treating the words as interchangeable.

SOC 1, SOC 2 and SOC 3, briefly

You'll encounter all three names, so it's worth being able to tell them apart quickly. SOC 1 focuses on controls relevant to a user entity's internal control over financial reporting, not really a security document at all, though you'll sometimes see it mentioned alongside SOC 2 in supplier due diligence. SOC 2 is the one this article is about, controls relevant to the Trust Services Criteria. SOC 3 covers the same underlying examination as a SOC 2, but is always a Type 2, and deliberately omits the detailed control descriptions, test procedures and test results, which is exactly what makes it safe to distribute publicly as a general-use summary, unlike a SOC 2 report, which is restricted to an audience with sufficient knowledge of the system to interpret it properly. A supplier handing you a SOC 3 instead of a SOC 2 has handed you the marketing summary, not the evidence.

Type 1 vs Type 2

This distinction needs to be genuinely automatic. A Type 1 report addresses whether relevant controls were suitably designed as of a specific date, a snapshot. A Type 2 report addresses whether those same controls were suitably designed and operated effectively across a defined period, typically somewhere between three and twelve months.

Type 1 asks something close to: was this control suitably designed on this date? Type 2 asks something closer to: was it suitably designed, and did it actually operate throughout the period under review? This maps directly onto the design-versus-operating-effectiveness distinction from the control testing article: Type 1 speaks only to design, Type 2 speaks to design and genuine operation over time.

Take privileged access review, reviewed quarterly. A Type 1 report can only really tell you the process and tooling existed and looked reasonable on the report date. A Type 2 report can tell you whether the review actually happened, consistently, across every quarter the period covers, which is meaningfully stronger evidence for anything meant to operate continuously. That said, don't collapse this into "Type 2 equals secure." Scope, the actual criteria included, and the testing results still matter just as much on top of the Type designation.

Trust Services Criteria

SOC 2 reports against five possible Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is mandatory in every SOC 2 engagement and carries the Common Criteria (CC1 through CC9) underpinning it; the other four are optional, selected based on what's actually relevant to the service and the commitments made to customers.

Security, at a high level, covers protection against unauthorised access, use and disclosure that could affect the entity's ability to meet its commitments. Availability covers whether the system is available for operation and use as committed or agreed. Processing Integrity covers whether processing is complete, valid, accurate, timely and authorised, relevant to what's actually being promised. Confidentiality covers whether information designated confidential is protected in line with commitments and requirements. Privacy covers the handling of personal information across its lifecycle, against a distinct set of privacy criteria, genuinely separate territory from the other four.

Security doesn't mean every security control

A very common assumption worth correcting immediately: seeing "Security" listed as an included criterion does not mean every conceivable cyber control was assessed. The report covers a specified system, a defined set of controls, the selected criteria, and a defined period, nothing more. The only way to know what was actually assessed is to read the report itself.

Check which criteria are actually included

One supplier's report might cover Security alone. Another might cover Security, Availability and Confidentiality. A third might cover all five. Don't assume Privacy is included just because personal data is involved, plenty of reports genuinely omit it. If Confidentiality or Availability matters specifically to your risk picture, check directly whether the report you've been handed actually includes that criterion before assuming it answers the question.

A practical reading order

Report structure varies somewhat between auditors and engagements, but a reasonable sequence for a security-minded reader: report metadata and period, the auditor's opinion, the system description, scope and boundaries, which Trust Services Criteria are included, subservice organisations, complementary user entity controls, individual control descriptions, test procedures, test results and exceptions, any management response, and finally anything discussing relevant changes or incidents. Don't assume every report you're handed matches this exactly; use it as a starting map, not a fixed template.

Reading the report, step by step

Check the report period first

If today is September 2026 and the report period runs 1 January to 31 December 2025, there's a real gap worth thinking about. What's happened since? New cloud provider, an acquisition, a major incident, a new platform launched? The report simply can't answer any of that. Suppliers sometimes offer a bridge letter covering the gap between the report period's end and the current date; understand that a bridge letter is management's own representation that nothing material has changed, not new independent testing, and it doesn't carry the same weight as the underlying audited report itself.

Check the entity and the system

Supplier company: MegaCloud Holdings Ltd. Service you're actually purchasing: MegaCloud Health Platform. Report's stated system: MegaCloud Payroll SaaS. That report tells you essentially nothing about the service you care about. Check the legal entity, the specific service or product, infrastructure, locations and business units named in scope, exactly the same discipline as checking an ISO 27001 certificate's scope statement.

Read the auditor's opinion

The service auditor's report states a conclusion, most commonly unqualified (sometimes phrased as unmodified), meaning no material issues were found and the system description, control design and, for Type 2, operation are all fairly presented. Less commonly, a qualified opinion flags a specific material issue while the rest stands; rarer still, an adverse opinion indicates widespread material failure, meaning the report shouldn't be relied on; and a disclaimer of opinion means the auditor genuinely couldn't reach a conclusion, often because access to information was limited. Most reports you'll actually see are unqualified.

Watch out

An unqualified opinion does not mean no exceptions, no vulnerabilities, no incidents, and no room for improvement. It means the auditor's overall conclusion on design, and for Type 2, operation, wasn't materially affected by whatever issues were found. Individual exceptions can, and routinely do, sit inside an otherwise unqualified report; read the actual test results rather than stopping at the opinion.

Read the system description

Often the single most useful section for a security reader, covering the service's architecture, infrastructure, software, people, processes, data, boundaries, locations, relevant third parties and significant system components. This is where you actually learn what you're getting assurance over, not the marketing description from the sales call.

Worth reconstructing a simple flow from it, the same instinct as tracing a supplier's data flow in general supplier assurance work:

Customer → SSO → SaaS application → cloud hosting → database → backup service

Support engineer → corporate identity → PAM → production support

Then ask directly: does this match what the supplier actually told you during earlier due diligence? Differences between the two are worth chasing down.

Management's assertion

Management's assertion is the service organisation's own statement that its system is described fairly, and that its controls were suitably designed, and for Type 2, operated effectively, over the stated period. It's prepared and signed by the organisation itself, dated alongside the auditor's own report. Worth being clear about what this is and isn't: it's management's claim, not independent evidence by itself. The independent auditor's opinion, sitting alongside it, is what actually tests that claim.

Control descriptions and test procedures

A fictional example of how a control might be written up: "administrative access to production systems requires multifactor authentication." On its own, that's a claim, not evidence, exactly the same distinction from the assurance article. What actually matters is what the auditor did to test it.

Control Test procedure Result
Privileged access is reviewed quarterly Inspected access-review evidence for a sample of quarters and sampled privileged accounts within those reviews No exceptions noted

Common test procedures include inspection (examining documents or records), observation (watching a process actually happen), inquiry (asking personnel, generally the weakest evidence type on its own), reperformance (the auditor independently repeats the control's activity), and sample testing across a defined population. "No exceptions noted" tells you the sample tested came back clean, not that the control is flawless everywhere, at every moment, forever.

Don't stop at the control description alone. If a control reads "all terminated users are removed promptly" and the test sampled 25 employees, ask directly: were contractors included in that population? Service accounts? Administrators specifically? Different office locations? Scope, testing and results all need reading together, never the control description in isolation.

Population and sample

The same discipline from the control testing article applies directly here: what was the actual population the auditor drew from, how many items were sampled, across which periods, and did the sample genuinely represent higher-risk parts of that population, not just the easiest ones to pull. Sampling itself is entirely normal in an audit and isn't a weakness to criticise on its own. The real question is whether the test, as actually performed, gives you enough relevant confidence for the risk you're assessing.

Exceptions

This deserves to be the section you spend the most time on, because it's where a SOC 2 report actually earns its keep as real evidence rather than a polished summary. An exception is not automatically "the supplier failed SOC 2." It's also not something to skim past because the overall opinion was unqualified.

A worked example: control states terminated accounts are disabled within one business day. The auditor tested 40 samples and found two exceptions, accounts disabled after five and nine days respectively. Worth asking: were either of those accounts privileged? Is there any evidence of authentication happening after termination but before disablement? What was the actual root cause? Does it look isolated, or systemic? What remediation followed? Has anything like this shown up before? And, most importantly for your own risk picture, does this exception actually touch anything you rely on this supplier for?

Analyst tip

One exception can matter more than a hundred clean control results. If most of a report is unremarkable but one exception describes a shared production administrator account, and this supplier holds privileged access into your own environment specifically, that single line deserves more attention than the rest of the report combined. Risk, not exception count, should decide where your attention goes.

Not every exception carries equal weight, either. One employee completing security-awareness training four days late is a genuinely different finding from a terminated administrator's privileged access not being revoked on schedule. Both are technically deviations from a stated control. They are not remotely the same risk, and treating them identically flattens exactly the distinction that makes exception review valuable in the first place.

Where a management response is included, read the explanation, the corrective action taken, the timing, and any mitigating factors described, and then assess it independently rather than accepting it at face value; it's useful context, not a substitute for your own judgement. If you have access to a prior year's report for the same supplier, compare them: the same exception appearing three reports running is a genuinely different signal than a one-off, pointing toward a root-cause or remediation weakness rather than an isolated slip.

Complementary user entity controls

This is one of the most consistently overlooked parts of any SOC 2 report, and arguably the single most important concept in this whole article. Complementary User Entity Controls, CUECs, are controls the service organisation's management assumed, in designing the system, would be implemented by the customer, and which are necessary, in combination with the service organisation's own controls, for the stated criteria to actually be met.

In plain terms: the supplier's controls were designed on the assumption that you, the customer, do certain things too. A supplier providing a secure authentication platform might still expect the customer to remove departed users promptly, assign roles appropriately, and protect administrative credentials on their own end. The supplier's controls can operate flawlessly and a security failure can still happen entirely on the customer's side of that boundary.

A worked example, entirely fictional: the report states the customer is responsible for managing user roles and promptly removing users who no longer require access. That's not a suggestion buried in an appendix, it's a stated precondition for the report's own conclusions to hold. Don't read CUECs and move on. For anything genuinely material, identify an internal owner, check whether an existing control actually satisfies it, gather evidence, and name the gap honestly if there is one. It's entirely possible for a supplier assurance review to surface a weakness in your own organisation rather than theirs, and that's not a failure of the exercise, it's exactly what it's for.

Subservice organisations

A supplier frequently depends on other organisations to deliver its service: a cloud provider, a data centre, a support vendor, an identity provider, a payment processor, a managed security provider. Any of these that are relevant to the service organisation's own controls are its subservice organisations, and how they're treated in the report matters.

Under the carve-out method, the subservice organisation's own controls are excluded from the scope of the report and testing, though the service organisation is still expected to describe complementary subservice organisation controls, CSOCs, controls it expects the subservice organisation to have in place. CSOCs are a disclosure, not something the service auditor actually tests; the service organisation represents it has a reasonable basis to expect those controls exist, and monitors accordingly, but the testing itself stops at the boundary. Under the inclusive method, the subservice organisation's relevant controls and functions are genuinely included in the description and tested as part of the same engagement.

Carve-out treatment is common, especially for major cloud providers, and it isn't automatically a red flag on its own. It does mean some of the controls your assurance actually depends on were tested somewhere else, or not tested within this report at all. Worth asking: does independent assurance exist for that subservice organisation separately? Does the supplier actually monitor it in a meaningful way, not just assert that it does? Is responsibility for that dependency genuinely clear on both sides?

Incidents, changes and currentness

Whether a SOC 2 report addresses relevant system changes or incidents during the period depends on the specific engagement and what actually occurred; don't assume every incident must appear without checking. If you independently know a supplier had a material breach during, or shortly after, the report period, that's worth following up regardless of what the opinion says, since the report may simply predate whatever changed as a result.

A SOC 2 report doesn't replace incident-specific due diligence. A supplier that had a breach last month, with a report period that ended six months ago, has handed you a document that genuinely cannot answer "what changed after the incident." Request proportionate, updated assurance rather than treating the old report as still current by default.

More broadly, ask whether anything material has shifted since the period ended: new infrastructure, an acquisition, a new product line, a hosting migration, a change in identity provider, a new subprocessor, significant staffing change in a security-relevant function. None of these automatically invalidate the report. They do determine how much weight it should still carry for your specific decision today. On period length itself, there's no universally "correct" duration to demand; the real question is whether the period covered is recent enough, and representative enough, for what you actually need assurance about right now.

The criteria in practice

Without reproducing the Trust Services Criteria themselves, it's worth knowing roughly what kind of controls tend to show up under each, in practical terms.

Security commonly touches access and identity management, logical security, change management, risk assessment, monitoring, incident response, vendor management and system operations, genuinely broad territory, but still bounded by whatever specific controls the service organisation actually described and the auditor actually tested, not an open-ended technical checklist.

Availability, where included, is particularly relevant for a critical SaaS platform, a healthcare system, payment processing, or anything else where uptime commitments genuinely matter. Look for controls around capacity management, continuity planning, recovery capability, and how availability commitments are actually monitored and met.

Confidentiality matters most where the supplier holds sensitive business data, security-relevant information, or customer confidential material generally. Worth looking for how information gets classified or designated as confidential in the first place, how access to it is controlled, and how it's protected through retention and eventual disposal.

Privacy deserves a specific caution: its inclusion should never be casually read as "we comply with all applicable privacy law." It's a defined, narrower set of criteria concerning personal information handling, not a legal compliance statement, and this article isn't offering legal advice on privacy obligations that may separately apply to your specific situation.

Processing Integrity matters concretely for something like a payroll service, where security alone genuinely isn't the whole story; it also has to matter that processing is complete, accurate, timely and properly authorised, relative to whatever commitments were actually made.

SOC 2 vs ISO, pen tests, questionnaires

SOC 2 vs ISO 27001. ISO 27001 is certification against an international management-system standard; a concise certificate, backed by an ISMS assessed against a fixed set of clauses and a reference control set, covered in depth in the ISO 27001 article. A SOC 2 Type 2 report is typically far more detailed about specific controls, exactly how they were tested, and what the results actually were. Neither replaces genuine supplier-specific assessment on its own; a supplier holding both gives you a management-system view and a detailed control-testing view of overlapping but not identical territory, worth treating as complementary evidence, not simply counted as "two certificates, therefore fine."

SOC 2 vs a penetration test. Genuinely different questions. SOC 2 examines whether stated controls and processes exist and operate as described. A penetration test actively probes for exploitable technical weaknesses within a defined scope and time window. A SOC 2 report can show that a vulnerability-management process genuinely operates; a pen test can still turn up one specific, exploitable weakness that process hadn't caught yet. Neither substitutes for the other.

SOC 2 vs a questionnaire. A questionnaire is the supplier's own self-reported response. A SOC 2 report is independent, tested evidence. Where a report genuinely and directly answers a question you'd otherwise be asking, use it, and don't ask the supplier to restate in a form what an independent auditor already tested directly. Reserve fresh questions for genuine gaps or risks specific to your own relationship with the supplier that the report simply doesn't reach.

When it's enough, and when it isn't

For a genuinely low or medium-risk SaaS supplier, a recent Type 2 report that includes the relevant system, with the specific control you care about directly tested and no material exception attached, can reasonably be sufficient evidence for that control on its own, no separate screenshot collection required. Risk should decide how far you push beyond that.

Additional assurance is worth pursuing when the supplier holds privileged access into your own environment, handles highly sensitive data, delivers a genuinely critical service, when the report's scope is ambiguous relative to what you're buying, when the report is stale, when exceptions are material, when a recent incident has occurred, when a criterion that matters to you was left out entirely, when significant architecture has changed since the period, when a critical subservice dependency was carved out with no independent assurance behind it, when a material CUEC clearly isn't being met on your side, or when a specific contractual or government-specific requirement demands more than the report alone provides.

The MedConnect scenario

The same fictional supplier used across the ISO 27001, NZISM and supplier assurance articles, this time handing over a SOC 2 Type 2 report instead of, or alongside, its ISO certificate.

Scope. Does the system description actually include the patient portal, the API, the AWS environment, the support function, the overseas support activity, and production operations specifically? If any of those sit outside the described system, that's a genuine scope gap worth naming precisely, not glossed over because the document as a whole looks thorough.

Trust Services Criteria coverage. Say the report includes Security, Availability and Confidentiality, but not Privacy. That doesn't mean privacy controls don't exist, it means this specific report's selected criteria don't cover that territory. Given MedConnect handles health information, additional privacy-specific assurance is genuinely worth pursuing separately, without this article drawing any legal conclusion about what that actually requires.

An access exception. Fictional finding: privileged access is reviewed quarterly; the auditor's testing found one sampled overseas support account remained enabled 36 days after the staff member's role changed. Management's response states the account was never actually used during that window and was disabled once discovered. Work through it properly: was the account genuinely privileged? Does the evidence actually support "never used," or is that an unverified claim? What was the underlying root cause? Does it look isolated, or does the pattern suggest a systemic gap in the leaver process for the overseas support team specifically? What remediation followed, and has this happened before? None of this automatically means rejecting the supplier, it means the finding earns a proper, proportionate follow-up rather than being waved through or treated as disqualifying.

A CUEC. The report states the customer is responsible for managing user roles and promptly removing customer-side users. Directly worth asking: does your own organisation actually have a control that does that, with real evidence behind it, or is this a gap sitting quietly on your side of the relationship rather than MedConnect's?

The AWS carve-out. Assume AWS is treated as a subservice organisation under the carve-out method, a common pattern for cloud dependencies generally. That alone isn't cause for alarm. The follow-up questions are: what independent assurance exists for AWS itself, does MedConnect actually monitor that dependency in a way that's more than a documented assumption, and is responsibility for it genuinely clear between MedConnect and you. None of this requires demanding AWS's own internal evidence directly, that's neither proportionate nor how the relationship is actually structured.

Checklist and documentation

A reusable review checklist, grouped by the same dimensions this whole article has walked through: report (Type 1 or 2, period, auditor, opinion), scope (correct entity, correct service, locations, architecture, support model), criteria (which of the five are included), controls (relevant to your actual key risks, clear ownership, technical or process), testing (what was tested, over what period, what sample, what result), exceptions (material to you, root cause, remediation, repeated), dependencies (subservice organisations, carve-out or inclusive, complementary controls described), customer responsibilities (CUECs, an internal owner assigned, are you actually meeting them), and currentness (changes since the report, any known incidents, whether a bridge letter is needed).

Document your own review with a simple structure: report name, period, service or system covered, criteria included, opinion, the specific controls actually reviewed, exceptions found, CUECs identified, subservice organisations and their treatment, the assurance actually obtained, open questions remaining, the impact on your residual-risk assessment, and any follow-up required. Not a universal standard, just a genuinely useful model, the same one this series has used throughout for documenting any assurance conclusion.

Don't copy the whole report into your own assessment record. Capture what actually matters to your decision, the relevant evidence, your conclusion, the gaps, and the follow-up, and handle the underlying report itself appropriately given its usual confidentiality: it commonly contains sensitive detail about architecture, controls, third parties and operations, and shouldn't end up attached indiscriminately to a ticket, a shared drive, or anywhere outside the access it was actually provided under.

Red flags and good signs, with nuance

Worth closer scrutiny: the wrong service described in scope, a stale report period, a significant qualified or worse opinion, exceptions repeating across multiple reports, deviations specifically touching privileged access, an unclear or undisclosed subservice dependency, important CUECs that clearly aren't being met, a major incident known to have occurred after the period ended, or a scope that excludes a genuinely critical operational component. None of these should trigger an automatic "reject the supplier" reflex; they indicate where deeper analysis is actually warranted.

Equally, genuinely good signs: a clearly and precisely defined scope, a recent Type 2 period, detailed control and test evidence rather than vague summary language, exceptions disclosed transparently with documented remediation rather than buried or absent, clearly described CUECs, and an unambiguous dependency model. None of this means the residual risk is zero either; a well-written, well-tested report is still a report about the past, over a defined scope, not a permanent guarantee.

How a SOC analyst should approach it

The transition here is genuinely intuitive once it's named. A SOC analyst asks "what does this log actually prove"; reading a SOC 2 report means asking what a given test actually proves. A SOC analyst asks "what's the scope of this investigation"; here it's what system and period the report actually covers. A SOC analyst asks "were there any anomalies"; here it's where a control didn't operate as described. A SOC analyst asks "what else could be affected"; here it's which dependencies and CUECs actually matter to the conclusion. Same discipline, a different kind of evidence in front of you.

Practical exercises

Exercise 1, Type 1 vs Type 2. Supplier A provides a Type 1 report dated 1 August. Supplier B provides a Type 2 report covering the previous twelve months. Which gives you greater assurance about operating effectiveness, and why? Then consider the nuance: a Type 2 report with a poor sample or a material exception can still tell you less than a clean Type 1 tells you about design, depending on exactly what you're trying to learn.

Exercise 2, wrong scope. A report covers corporate IT generally. You're purchasing a specific production SaaS platform. Is the report sufficient on its own? It isn't, necessarily, work out precisely why using the entity-and-system reasoning above.

Exercise 3, an exception. Control: leavers disabled within one business day. Sample: 30. Two exceptions found, at four days and twelve days respectively. What questions come next? Consider privilege level, whether authentication occurred in the gap, root cause, and whether this looks isolated or part of a pattern.

Exercise 4, a CUEC. The report states the customer is expected to review privileged tenant roles quarterly. Your own organisation doesn't currently do this. Who actually holds the resulting control gap? Very possibly you, not the supplier, one of the more useful shared-responsibility lessons a SOC 2 review can surface.

Exercise 5, a subservice organisation. A critical backup provider is carved out of the report entirely. What assurance question should follow directly from that? Consider what independent evidence exists for the backup provider itself, and how the supplier actually monitors that dependency day to day.

Exercise 6, an old report. The report period ended fourteen months ago. The supplier migrated its cloud platform six months ago. How much confidence should this report reasonably give you about the supplier's current architecture? Considerably less than it would if nothing material had changed since, worth stating plainly rather than assuming the report ages gracefully by default.

Interview questions

"What's the difference between SOC 2 Type 1 and Type 2?" Type 1 addresses control design at a point in time; Type 2 addresses design and operating effectiveness across a defined period. "What do you look for first in a SOC 2 report?" The period, the entity and system in scope, and the auditor's opinion, before going anywhere near the detailed controls. "What is a CUEC?" A control the service organisation's own system design assumes the customer will perform, necessary alongside the supplier's own controls for the stated criteria to actually be met. "What is a subservice organisation?" An organisation the supplier itself depends on to deliver the service, whose controls may be carved out of the report or included and tested directly. "What does carve-out mean?" The subservice organisation's controls are excluded from testing, with the service organisation instead describing complementary controls it expects that subservice organisation to have. "If there are exceptions, does the supplier fail?" No, exceptions are evidence to be assessed on their own risk and context, not an automatic failure. "Would you accept a SOC 2 report instead of a questionnaire?" Where it genuinely and directly answers the question at hand, yes, reserving fresh questions for real gaps rather than duplicating what's already been independently tested. "How do you assess whether a SOC 2 report is relevant to your supplier risk?" Check scope, period, criteria, and whether the specific controls that actually matter to your risk were tested and came back clean, or not.

Common misunderstandings

"SOC 2 certified." Worth using more precise language, a SOC 2 report or attestation, rather than "certification," which implies something closer to ISO 27001's model. "Type 2 means better security than Type 1." Too simplistic, Type 2 means more evidence about operation over time, not an inherently higher security bar. "Clean opinion means zero exceptions." Not necessarily, individual exceptions can sit inside an otherwise unqualified report. "Security criterion means every security control is tested." No, only what's actually described and tested within the report. "Having SOC 2 means we don't need supplier assurance." No, it's strong evidence feeding into assurance, not a substitute for the whole exercise. "An exception means automatic supplier rejection." No, it means the finding needs proper risk analysis. "CUECs are the supplier's problem." No, they're explicitly the customer's responsibility, named in the supplier's own report. "AWS is carved out, therefore the report is useless." No, carve-out is common and simply shifts where the follow-up question needs to go. "SOC 2 proves legal privacy compliance." No, and this article isn't offering a legal conclusion on that point either.

A reusable review workflow

Confirm the report's authenticity and that it's current. Confirm the Type. Check the period. Check the scope. Check which criteria are included. Read the opinion. Understand the system description. Identify subservice organisations and how they're treated. Identify CUECs. Review the specific controls relevant to your actual risk. Read the test procedures. Read the results and exceptions. Assess any remediation described. Check for material changes or incidents since the period. Work out what assurance is still genuinely missing. Update your supplier residual-risk assessment accordingly.

The point

A SOC 2 report is neither a security guarantee nor a pile of paperwork to skim for the word "exception." It's independent, tested evidence about a specific system, over a specific period, against specific criteria, with specific things assumed of you as the customer along the way. Read it properly, the scope, the opinion, the testing, the exceptions, the CUECs, the subservice dependencies, and it becomes genuinely strong evidence in a supplier risk decision. Skim it for a headline and it becomes exactly the checkbox exercise this entire series has been arguing against from the very first article.

The skill this article has actually been teaching isn't SOC 2 terminology for its own sake. It's the same evidence-based reasoning running through the whole series, applied to one specific, extremely common document you'll be handed again and again: what does this actually prove, what does it not, and what still needs asking once you've read every page that matters.