Security is often the hardest vendor capability to verify. This guide explains the five SOC 2 Trust Services Criteria, the time-based difference between Type I and Type II, and what to check in a report so you can assess your own risk.
When buying a cloud service or tool, security is often the hardest capability to verify. You can try the features and compare prices, but a single demo cannot show you how a company manages access internally, responds to incidents, or where it stores data.
A SOC 2 report is designed for this purpose. It does not judge whether a product is easy to use. It answers a deeper question: does the service organization actually operate its security-related controls the way it says it does?
It audits the organization, not the product
SOC 2 (System and Organization Controls 2) is an auditing standard for service organizations developed by the American Institute of Certified Public Accountants. The report is issued by an independent accounting firm and includes an audit opinion. An Unqualified Opinion means the control system operated effectively throughout the audit period and is the strongest type of conclusion in this kind of audit.
The audit is organized around five Trust Services Criteria. Security is mandatory, while the other four are selected according to the nature of the business:
| Criterion | What it focuses on |
|---|---|
| Security | Preventing unauthorized access and intrusion |
| Availability | Keeping the service operating reliably as committed |
| Processing integrity | Processing data accurately, completely, and on time |
| Confidentiality | Encrypting confidential information and limiting who can access it |
| Privacy | Collecting, using, and ultimately disposing of personal information |
Type I and Type II differ mainly in time
This is the easiest distinction to confuse and one of the most important for understanding the value of a report.
Type I examines the design of controls at a specific point in time—in plain terms, whether the policies and controls are reasonably designed. Type II examines how those controls operate over a period, typically 6 to 12 months, tracing routine operations, code changes, personnel changes, and sampling evidence along the way.
One tells you whether the organization documented a control framework; the other tells you whether it followed that framework day after day over the previous several months. So when someone says they have “passed SOC 2,” first ask whether the report is Type I or Type II before discussing anything else.
How it relates to ISO 27001
The two are often mentioned together, but they serve different purposes. SOC 2 is issued by an accounting firm and is primarily a customer-facing assurance report containing control descriptions and test results. It is common in B2B procurement due diligence for North American customers. ISO 27001 is certified by a certification body and focuses on an organization’s information security management system, with a certificate as the main output and broader international recognition.
Many service providers have both, and there is no contradiction in that. ISO 27001 indicates that the management system has been established comprehensively, while SOC 2 Type II indicates that the controls have actually been operating. When assessing risk, the latter usually provides more detailed information.
What to check after you receive the report
Service providers generally share the report under a nondisclosure agreement. Several sections should not be skipped.
Start with the audit scope. Which product, data center, and business line are covered, and do they match what you actually plan to use? The report cannot provide assurance for anything outside its scope.
Next, check the coverage period. Is it continuous, and does it include the most recent complete cycle? A report from two years ago cannot tell you the organization’s condition today.
Then review the Exceptions section, which often contains the most useful information. It should explain which controls did not operate effectively, what was affected, and whether there is a remediation plan. An exception does not automatically mean the service is unusable. What matters is whether it falls within your risk exposure and whether remediation is clear and being followed through.
Finally, return to your own requirements. If you care about data availability but the report covers only security, then it does not answer the question you need answered. This is often overlooked: a report that is hundreds of pages long does not mean every page is relevant to your use case.
What certification cannot replace
A security certification demonstrates the service provider’s management practices; it does not prove that your own way of using the service is compliant.
Take account management as an example. Even if the provider’s own security system withstands an audit, the way you assign permissions, configure environments, and operate on different platforms still has to comply with each platform’s rules. Certification can tell you whether your data is handled appropriately by the provider, but not whether your own operations are compliant.
Clear environment isolation and access boundaries are recurring themes in these audits. Treating each environment as an independent unit and preventing sessions and data from bleeding across accounts follows the same basic idea; the difference is that implementation is in your hands. PurpleMark provides this type of capability at the environment-isolation layer.
This article is only an explanation of audit standards. The formal report supplied by the service provider governs the specific report content and scope.
