Almost everything written about SOC 2 is published by somebody selling a way through it. What follows is a description of the thing itself: where it comes from, what it measures, what the report contains, what it costs, and the part most guides skip, which is how little of it can be observed from outside your company.
We have an interest to declare. Trufend runs a free external scan, and we are blunt that a scan is not a SOC 2 certificate and never will be. That position is only worth anything if we can say precisely what SOC 2 is and where our own tool stops. So here it is.
What SOC 2 actually is
SOC stands for System and Organization Controls. A SOC 2 report is the output of an attestation engagement carried out by a licensed CPA firm under the attestation standards of the American Institute of Certified Public Accountants, specifically AT-C section 205. The firm examines controls that you designed, at a company you run, and forms an opinion on whether they meet criteria the AICPA publishes in TSP section 100.
Three things follow from that sentence, and between them they account for most of the confusion in the market.
There is no certificate, and no certifying body. Nobody grants SOC 2. A CPA firm expresses an opinion in a report addressed to you. There is no public register to appear on, no mark you are licensed to display, and no certificate number. The phrase "SOC 2 certified" describes something that does not exist, which is worth remembering the next time it appears in a vendor's footer.
You write the controls. The AICPA sets the criteria, not the controls. A criterion says that the entity restricts logical access to information assets. It does not say "enforce multi-factor authentication on your identity provider". You decide what you do, you write it down, and the auditor judges whether what you wrote meets the criterion and whether you actually did it. Two companies with clean SOC 2 reports can be run very differently.
The report is restricted, not public. A SOC 2 report is a restricted-use document. It goes to you, your customers, their auditors and other specified parties, usually under an NDA. That is why you cannot look up a vendor's SOC 2 the way you can look up their TLS certificate. If a company wants something freely publishable, that is a SOC 3.
SOC 1, SOC 2 and SOC 3
All three are attestation reports from a CPA firm. They differ in what they are about and who may read them.
| Report | What it examines | Who may read it |
|---|---|---|
| SOC 1 | Controls at a service organisation that affect its customers' financial reporting. Payroll processors and billing platforms need one. | Restricted: customers and their financial auditors. |
| SOC 2 | Controls measured against the trust services criteria: security, and optionally availability, processing integrity, confidentiality and privacy. | Restricted: named parties, usually under an NDA. |
| SOC 3 | The same examination as a SOC 2, summarised. No detailed system description, no list of tests, no results. | General use: publish it on your website. |
A SOC 3 cannot stand alone. It is a public summary of a SOC 2 examination that has already been performed, which is why you sometimes see a company publish a SOC 3 badge and offer the SOC 2 on request.
The five trust services criteria
The criteria are organised into five categories. You choose which apply, and the choice is written into the report.
Across all five categories the current criteria run to 61 individual criteria supported by roughly 300 points of focus. The points of focus are not requirements. They are illustrations of what meeting a criterion might look like, and an auditor will not tick them off one by one.
Security on its own is the common criteria, and for most software companies the first report covers security alone, sometimes with availability and confidentiality. Privacy is the category people add casually and regret, because it drags your entire personal-data lifecycle into scope, along with every data processing agreement you should already have signed.
The optional categories are not decorative. Availability brings your recovery objectives and your behaviour when a dependency fails into scope, so numbers you can defend and what your app does when something it depends on goes down both become evidence. Confidentiality brings the question of whether one customer can reach another customer's data, which is where row-level security and a ten-minute IDOR test with two accounts earn their place, along with how widely your service-role keys are scoped.
The nine common criteria, and what each one is really asking
The first five series come straight from the COSO internal control framework, which is why CC1 to CC5 read like governance rather than security. CC6 to CC9 are the technology-specific additions.
| Series | The question underneath it | Where to start |
|---|---|---|
| CC1 Control environment |
Does anyone own this, are people competent and vetted, and is there consequence when policy is ignored? | Security training records |
| CC2 Communication and information |
Do the people who need to know a control exists actually know, inside the company and outside it? | A written incident response plan |
| CC3 Risk assessment |
Have you identified what could go wrong, rated it, and decided what to do about it, in writing? | Documenting a risk assessment |
| CC4 Monitoring activities |
Do you check that your own controls are still working, rather than assuming they are? | Testing a restore |
| CC5 Control activities |
Did you choose controls that address the risks you just listed, and deploy them? | The readiness guide |
| CC6 Logical and physical access |
Who can reach what, how is that granted and removed, and is customer data separated? | Requiring MFA, offboarding, key rotation |
| CC7 System operations |
Do you find vulnerabilities, watch for anomalies, and respond to incidents in a way you can evidence? | External posture, exposed secrets |
| CC8 Change management |
Is a change to production authorised, tested and traceable to a person and a reason? | Branch protection, secrets out of Git, webhook signatures |
| CC9 Risk mitigation |
What happens when something disruptive occurs, and what have you done about the vendors you depend on? | Vendor inventory, vendor reviews, RTO and RPO |
Read that table twice and the shape of SOC 2 becomes obvious. Two of the nine series are about systems in the way an engineer would recognise. The rest are about governance: decisions, ownership, records and follow-through. That is the single most useful thing to understand before you start, and it is why buying tooling rarely moves the needle on its own.
Type I and Type II
The same criteria, examined over a different span of time.
A Type I says the controls were suitably designed as at a stated date. A Type II says they were suitably designed and operated effectively throughout a stated period. The difference matters because almost every real control failure is an operating failure, not a design failure. Nobody writes a policy saying leavers keep their access. They just do.
First observation windows are commonly three to six months. Renewals run twelve months, so that consecutive reports leave no gap. Shorter windows are permitted and do get noticed, because they give the auditor less to sample from.
What happens, from decision to report
Two things surprise people. The first is that the report arrives months after the window closes, so the document you hand a customer always describes a period that has already ended. Firms cover the gap between the period end and today with a bridge letter, a short signed statement that nothing material has changed since. The second is that the clock never stops: the moment one report is issued, the next window is already running.
What it costs
Audit fees vary more than any other part of this, mostly by the kind of firm you hire. Published directory pricing gathered across roughly 190 audit firms in 2026 puts the ranges at:
| Kind of firm | Type I | Type II |
|---|---|---|
| Specialist CPA firm | 10,000 to 35,000 USD | 15,500 to 50,000 USD |
| Full-service CPA firm | 20,000 to 60,000 USD | 30,000 to 80,000 USD |
| Big Four | 40,000 to 145,000 USD | 65,000 to 200,000 USD |
Those are quotes, not invoices, and a small team on simple infrastructure with controls already in place can land well under the bottom of the specialist range. Around the audit fee sit the costs nobody quotes you for: a readiness assessment, a penetration test, which is almost never included, a compliance platform if you use one, remediation work, and the internal time of whoever is collecting evidence instead of doing their job. For most first-time companies the fee is somewhere between a third and half of the real spend.
What is inside the report
A SOC 2 report has five parts, and the useful ones are not the ones people read first. If you are reviewing a vendor's report, start at section four.
- Section I, management's assertion. Your own signed statement that the description is accurate and the controls met the criteria. Written by you, not the auditor.
- Section II, the independent service auditor's report. The opinion. Unqualified means clean. Qualified means one or more criteria were not met and the auditor says exactly which. Adverse and disclaimer are rare and serious.
- Section III, the system description. What the system is, where the boundary sits, which subservice organisations you rely on, and the complementary user entity controls: things the report assumes you do. Skipping those is how buyers inherit risk they never priced.
- Section IV, the criteria, controls, tests and results. The substance. Every criterion, the controls mapped to it, what the auditor tested, and whether there were exceptions.
- Section V, other information. Unaudited. Management's response to exceptions usually lives here, and it carries no assurance at all.
A qualified opinion is not automatically a reason to walk away. An exception on one criterion, disclosed plainly with a remediation date, tells you more about a vendor than a clean report from a firm that tested one sample. A report with no exceptions anywhere across a twelve-month window is worth a second look, not less scrutiny. The same principle applies to our own output, which is why our report explains what each grade does and does not mean.
What a scan can reach, and what it cannot
This is the part that gets misrepresented, and it is the reason this site exists. An external scan looks at your domain from the internet, as any stranger could. It sees configuration. It cannot see conduct.
Everything above that line is real, testable and worth fixing today. Expired or weak TLS breaks trust in the most literal way. Missing SPF, DKIM and DMARC lets anyone send email as you. Absent security headers leave ordinary attacks unmitigated. A dangling DNS record hands a stranger a subdomain you own. An API key in public code is a breach waiting for someone to notice. Those map onto CC6 and CC7, and an auditor will look at them.
But they are the minority. We have written at length about the 80% a scan cannot see, and the number is not rhetorical: most of the common criteria are satisfied by records of decisions and actions, not by configuration. No tool that never sees your ticketing system, your identity provider or your board minutes can say anything about them.
So use the free things for the visible part. Run the external check for TLS, DNS, email and headers. Generate your records with the SPF and DMARC generator and your policy with the CSP builder. Then move to the part that matters more: write the incident response plan, build the vendor and DPA register, and work through the readiness guide, which follows the same ground the common criteria cover.
Is SOC 2 changing?
The criteria are not. Reports issued today still map to the 2017 trust services criteria, with the points of focus revised in 2022. Anyone telling you the criteria have been rewritten is selling something.
What is genuinely in motion is the examination standard underneath. In early 2026 the AICPA's Auditing Standards Board issued exposure drafts proposing revisions to AT-C sections 105, 205 and 210, which would raise the bar on how auditors evaluate the relevance and reliability of evidence and how they assess engagement risk. They are proposals. The drafted effective date is engagements beginning on or after 15 June 2029, and the board is still working through comments. If it lands, Type II examinations feel it most, because that is where evidence volume lives. None of it is a reason to change anything you are doing this year.
If a customer just asked and you have nothing
Do these in order, and do not skip the first one.
- Ask what they will accept. Sometimes the answer is a questionnaire and a call, and you have just saved six months.
- Fix the visible things this week. They are cheap, they are in scope, and they are the first thing anyone technical will check.
- Write down what you already do. Most teams are doing two thirds of CC6 and CC8 already. Undocumented controls do not count, and documenting them costs nothing but an afternoon.
- Work out the real gaps. Usually access reviews, a risk assessment, vendor records and tested backups.
- Only then talk to auditors. Get three quotes. The range above is not a typo.
SOC 2 rewards companies that were already running carefully, and punishes the ones hoping to buy their way past it. The good news is that the uncomfortable part, writing down what you do and then doing it, is worth doing whether or not anyone ever audits you.