For a SaaS company, a SOC 2 is the report a serious customer wants before they trust you with their data. Here is what the Trust Services Criteria actually mean, how SOC 2 differs from SOC 1, and how to read one properly.
Marco Cavani
Cybersecurity Analyst
Sell software as a service for long enough and the same question starts arriving in every enterprise deal: “Can we see your SOC 2?” For a SaaS provider it has become the default proof that you can be trusted with a customer’s data, the report that unblocks procurement and shortens the security questionnaire. It is also widely misunderstood, treated as a badge to display rather than an opinion to read. This article is about what a SOC 2 actually says, how it differs from the SOC 1 covered earlier, and how both a provider and its customers should treat it.
A SOC 2 is an independent auditor’s report on a service organisation’s controls, measured against the AICPA’s Trust Services Criteria (TSC) (AICPA, 2017). Where a SOC 1 is about controls relevant to a customer’s financial reporting, a SOC 2 is about the controls that protect the data and systems a customer entrusts to the provider. For most SaaS companies, that is the report that matters.
As with SOC 1, there are two types, and the distinction is the same:
And, as with SOC 1, only a Type II is real assurance. A customer trusting you with their data for years is not reassured by a snapshot of how your controls looked on one day; they want evidence they worked over time.
The two reports are constantly confused, so it is worth being blunt about the split. A SOC 1 covers controls relevant to the customer’s financial reporting, useful when your platform processes transactions that flow into their books. A SOC 2 covers security and related qualities of the service itself, useful when customers are trusting you with sensitive data and want comfort it is protected.
Many SaaS providers need one or the other; some need both. A payments or payroll platform might issue a SOC 1 for the financial-processing controls and a SOC 2 for the security around them. The test is simple: if the question is “does this affect our financial statements,” it is SOC 1 territory; if it is “is our data safe with them,” it is SOC 2.
A SOC 2 is built on up to five criteria, and understanding them is the key to reading the report, because a SOC 2 only covers the ones in its scope.
Security is always present; the other four are included only if the provider chooses and the auditor tests them. This is why the scope of a SOC 2 matters as much as its existence: a report covering only Security tells a customer nothing about the availability they may be relying on.
A SOC 2 is not a trophy. It is a Type II over the right criteria, read for its scope and its exceptions, or it tells the customer nothing.
For a customer evaluating a SaaS provider, the report is only useful if it is read, not merely collected. The questions that matter:
A customer who works through these has done real vendor due diligence. One who files the PDF unread has a document, not assurance.
From the other side of the table, a SOC 2 is not a certificate you buy; it is an audit you must be ready for. Behind a clean Type II sits a functioning control environment: IT general controls that actually operate, least-privilege access with prompt deprovisioning, disciplined change management, monitored operations and tested backups, plus documented policies and, above all, the evidence that all of it happened consistently across the whole period. Providers who treat SOC 2 as a year-round operating standard pass comfortably; those who scramble to assemble evidence in the final month tend to earn the exceptions they were trying to avoid. The report, in the end, only reflects how the business was already run.
For a SaaS provider a SOC 2 is the currency of trust: the report that lets a cautious enterprise hand over its data. But its value depends entirely on how it is treated. Read as a badge, it is meaningless; read as an opinion, a Type II over the criteria that matter, its exceptions understood, its subservice cloud provider followed through, and its complementary controls performed, it is genuine, transferable assurance. Earning one is not about the document; it is about running the controls the document reports on, every day of the period, so that when the customer finally asks to see your SOC 2, the honest answer is yes, and it holds up when they read it.
Written by
Marco Cavani
Cybersecurity analyst and IT governance professional. Author of digital reports on threat intelligence, critical infrastructure security, and IT audit frameworks.
In an online gaming platform the financial truth lives in a database, and that database increasingly lives in the cloud on infrastructure the operator does not run. Here is how a SOC 1 gives assurance over it, and what an auditor actually tests.
An e-gaming platform is a stack, not a single system. Audit only the application and you have checked the shop window. Here is how to scope the full three layers, application, operating system and database, in the cloud.
Attackers do not always break through your front door. Sometimes they walk in through a vendor's access. The Target breach is the textbook case, and the lessons still apply a decade later.
Get the latest cybersecurity reports, threat intelligence, and IT governance insights delivered straight to your inbox. No spam. Unsubscribe any time.
No spam. Unsubscribe at any time.
The RACM ITGC SaaS platform helps audit professionals manage IT General Controls assessments, from risk and control mapping to workpaper generation and evidence tracking.
