10 Fundamentals in SOC 2 Reports: Practice Points

Treat the report as the start of your vendor review rather than the end of it. Alexandra described a SOC 2 as independent evidence about a defined system and its controls at a particular time. That gives you a starting place for your inquiry, and it does not finish the review. You still have to connect the evidence to the service you are actually buying and the commitments you actually need. Her example landed hard, a vendor with a clean report ending December 31st that launched the AI feature you want in March, which means the feature nobody examined is the one you are paying for.

Read the system description next to the order form. Alexandra kept four checks bookmarked in her head, covering product and environment, entity relationship, criteria selected, and period and dependencies. On product and environment she looked at the platform, the modules, the infrastructure, the locations, and the exclusions, and she asked specifically about newly acquired products to find out whether they sit inside the circus tent or outside it. On entity relationship, a parent's report can cover a subsidiary, and different legal names are a question to resolve rather than automatic proof of a gap. Reading the description is how you find out what was in scope and what quietly was not.

Confirm the report covered the categories you actually depended on. Every SOC 2 covers security against the AICPA trust services criteria, and that is the only mandatory one. Availability, confidentiality, processing integrity, and privacy are optional, and the vendor decides which ones to include. Stephanie made the point that a company leaning hard on a service provider's uptime needs to see availability covered and not just data security. The same logic applies to the system itself, since a report covering the web application and not the mobile application leaves you holding the half you cannot see.

Push for a Type 2 and negotiate around a Type 1 when that is all you can get. A Type 1 tests control design at a single point in time, and a Type 2 also tests whether those controls actually worked over a period, usually six to twelve months. Stephanie worked with a lot of early stage startups that started with a Type 1 simply because they have no operating history, and her answer was never to walk away. She asked when the Type 2 was coming, got that date into the contract, and paired it with a right to terminate early and get a refund when serious unremediated deficiencies showed up. Where the last reporting period ended months ago, a bridge letter plus a contractual assurance that the controls have not changed fills the gap.

Read past the opinion into the exceptions underneath it. You get an unqualified opinion, a qualified opinion, an adverse opinion, or a disclaimer, and Stephanie was clear that a qualified opinion is not a disqualification. It points you straight at the area that needs a remediation commitment or an added contract term. Even an unqualified opinion can sit on top of exceptions worth reading, so keep going into the testing results. Alexandra cared less about how many exceptions there were than about what failed, how widely it failed, and whether it touched the way you use the service.

Get in front of a finding before your customer finds it themselves. The report looks backward, so nobody gets to clean it up after the fact. What you can do is update the control, fix the underlying procedure, and roll the report out alongside the remediation that has already been implemented. Alexandra described starting the conversation early, and offering an amendment committing to remediate within a defined window when the customer matters enough. Both speakers pointed at the side letter as the place that forward-looking commitment belongs, since the auditor is only reporting on the past.

Follow the chain to the vendors sitting behind your vendor. Sub-service organizations are the cloud hosting, the data centers, the subprocessors, and the payment processors your vendor depends on and does not control. A report either carves them out or includes them, and either way the vendor still has to monitor them as part of its own controls. Stephanie's line was that no vendor gets to say it has nothing to do with what happens over at AWS. Alexandra added the limit from the other side, since a vendor cannot promise you functionality that its own upstream provider never promised it.

Give the complementary user entity controls an owner on your side. Alexandra reached for the cueca, the national dance of Chile, where both partners circle each other waving a handkerchief and each one has to keep waving their own. CUECs are the customer controls the vendor's control design assumes you already have in place, covering things like approving access, configuring authentication, managing user permissions, and telling the vendor when access should change. Read the actual requirements rather than assuming single sign-on covers it. Then assign an owner in security, IT, or the business unit who confirms the requirement is feasible and takes it on.

Write the delivery cadence and the remediation path into the contract. Stephanie's typical arrangement had the vendor provide an annual Type 2 report, and the sticking point was always whether delivery happened automatically after issuance or only on request. Available on request alone leaves a gap when you have your own downstream timing to meet. A trust center that customers can log into satisfies delivery for both sides, and the contract can say so explicitly. Add an obligation to remediate findings marked high or medium severity within a defined period and report back on status, and think about what happens to the contract when the risk stays unacceptable.

Know what the report never covered in the first place. A SOC 2 does not map to GDPR, HIPAA, or CCPA, it does not take the place of your DPA, and it is an attestation rather than a certification like ISO 27001. It also says almost nothing about AI beyond general data security. Alexandra started from the data, the business dependency, and the consequences of failure, then asked for what filled the remaining gaps, including a recent penetration test summary, remediation status, access and encryption details, retention and deletion practices, and recovery objectives with continuity testing for anything business critical.