A SOC 2 report is an independent CPA firm’s attestation on a service organization’s controls against the AICPA trust services criteria: security, which every report covers, plus any of availability, processing integrity, confidentiality and privacy (AICPA, SOC suite of services, AICPA, Trust Services Criteria). A Type I report covers the design of controls at a point in time; a Type II report also tests whether they operated effectively over a period. It is an auditor’s opinion, not a certification, and it covers only the systems in its stated scope.
In an FDE interview
It comes up when a customer’s security team reviews you, as in getting a project through a strict security or compliance review. A strong candidate reads the report instead of waving it: checks that the system being deployed is in scope, notes which subservice organizations, such as the cloud provider, are carved out rather than included, and lists the complementary user entity controls the customer must run themselves, such as reviewing who has access. Then read the exceptions in the auditor’s testing and the report period; if the period ended months ago, offer your bridge letter, management’s statement covering the gap until the next report.
When you deploy inside the customer’s own cloud, as in a retrieval assistant inside a court’s own tenancy, say plainly what your report’s scope covers: your company’s environment, not the system running in theirs, unless the report says otherwise. Controls for that system are agreed in the deployment plan. Say which controls you provide and can evidence; never say the customer’s deployment is compliant.
The lesson Data, PII and compliance covers how to read a SOC 2 report and what to leave to the auditor, and a planned court procedures assistant design prompt will be the practice for the in-tenancy case.