What a SOC 2 report actually tells you

A Type I report speaks to a point in time. It says that on a given date the described controls existed and were suitably designed. A Type II covers a review period, commonly six to twelve months, and adds the question that matters: did the controls operate effectively across that period. A vendor can hold a clean Type I while the quarterly access reviews it describes have never actually run. For any vendor that will hold your data, ask for the Type II. A Type I is reasonable for a young company on its first cycle; expect a Type II on the next pass.

Then do the arithmetic on dates. A Type II whose period ended ten months ago describes a company that may no longer exist in that form. The standard patch is a bridge letter, written by the vendor rather than the auditor, stating that no material changes have occurred since the period ended. It is unaudited and still worth requesting, and a vendor unwilling to provide one has earned a follow-up question. Check the length of the period too; a short first window is legitimate and has simply tested less.

The trust services criteria come in five categories: security, availability, processing integrity, confidentiality, and privacy. Security is the baseline that every report in practice includes; the other four are selected by the vendor. Check that selection against your own dependence. If your business stops when the platform is down, an availability opinion is worth having. If the vendor processes personal information on your behalf, confidentiality and privacy coverage matter, and if they are absent you should record that in your own review even when the report itself is clean.

The second scope decision is the system description. It names the product, the infrastructure, the locations, and the parts of the organisation the opinion covers. Vendors with several product lines sometimes commission a report over one flagship platform, and sales teams are not always precise about the difference. Confirm the service you actually buy sits inside the described system, because the opinion attaches to that description and to nothing else.

Almost every SaaS vendor's report uses the carve-out method for its subservice organisations: the cloud provider underneath is excluded from scope, and the description lists the controls the vendor relies on that provider to operate. A carve-out of AWS, Azure or Google Cloud is routine, and those providers publish their own reports you can chase in turn. What deserves attention is which functions were carved out. Hosting is expected. A carved-out security monitoring function, or a carved-out development contractor, changes who you are actually trusting.

The description also lists complementary user entity controls, the controls the vendor assumes you operate: administering your users, enforcing multi-factor authentication on your tenancy, configuring retention and offboarding. The opinion depends on those assumptions holding. If nobody in your organisation has read that list, part of the control environment may simply not exist on your side. When something goes wrong at a SaaS customer, the cause often sits on the customer's side of exactly this boundary.

Exceptions are the deviations the auditor found while testing, listed with each test result. A small number of exceptions in a genuine Type II is normal, and their presence is weak evidence the testing was real. Weigh three things for each one: whether it touches a control you rely on, such as access revocation, backups or change approval; whether the same exception appears in the prior year's report, because a repeat means it was accepted rather than fixed; and what management's response says. Responses usually live in the unaudited section, so they are the vendor's own words. A specific response with a completed remediation date reads very differently from a paragraph of reassurance.

ISO 27001 certifies a management system against a fixed standard. The organisation declares its control applicability in a Statement of Applicability across the 93 Annex A controls, an accredited certification body audits on a three-year cycle with surveillance visits between, and the artefact you receive is a certificate, typically one page. SOC 2 attests to controls the vendor itself defined, judged against criteria rather than a fixed control set, and the artefact is the detailed report. The certificate is easy to verify through the certification body and carries almost no detail; the report shows you the actual controls and test results, and the vendor chose its own scope and its own auditor.

In Australia, ISO 27001 remains the more commonly requested artefact, and SOC 2 typically arrives with US software vendors or with Australian companies selling into the US market. Mature vendors often hold both, assessed in a combined audit cycle. When you are handed both, verify the ISO certificate's scope and issuing body, then read the SOC 2 for the operational detail the certificate cannot carry.

The report tests whether described controls operated. It does not test whether the product resists attack. A vendor can carry an unqualified opinion while the application holds an authorisation flaw a tester would find in an afternoon, because no SOC 2 procedure exercises the software the way an attacker does. Descriptions often state that penetration testing is performed; the report will not show you the findings or whether they were remediated. Ask separately for the test's scope, date and a remediation summary.

It is also silent on your side of the arrangement: how your tenancy is configured, whether the assumed user entity controls exist, and what data your teams have pushed into the platform. And it does not discharge your own obligations. Your responsibilities under the Privacy Act 1988 for the personal information you hand to a provider do not lapse because the provider holds a report, and APRA-regulated entities carry an explicit duty under CPS 234 to assess the information security capability of third parties that manage their information assets. Filing the PDF does not satisfy that duty; satisfying it means reading the report against how you use the service and recording the conclusion.

Most of the value of a SOC 2 review arrives in the first focused half hour, provided the reading happens in the right order:

That reading answers what the report can answer. A fuller vendor review puts the report alongside the contract, the data flows, the questionnaire responses and your own controls, and checks that they agree with each other, which is where the real findings tend to surface. That correlation work is what we do inside supply-chain and vendor review engagements. The reading order above is the part you can run yourself on the next report that lands in your inbox.