SOC 2 is an attestation, not a certification, and that distinction shapes everything else. Nobody issues you a SOC 2 licence. An independent CPA firm examines the controls you claim to operate, tests whether you actually operate them, and writes a report describing what they found. The report is the deliverable. It can contain exceptions and still be entirely usable with customers.
The framework comes from the AICPA and it is deliberately not a checklist. There is no list of controls you must implement. There is a set of criteria, and you describe the controls you use to meet them. Two companies with completely different architectures can both produce a clean report.
- 5Trust Services CategoriesOnly Security is mandatory
- 9Common Criteria series, CC1 to CC9All in scope when Security is
- 3 moShortest Type II window most auditors acceptSix or twelve is more credible
- 6-9 moNothing to first Type II reportFor a 20 to 100 person cloud company
The five Trust Services Categories
Only the first is mandatory. The rest you include if a contract or a customer requires them.
- SecurityCommon CriteriaProtection against unauthorised access, physical and logical. Every SOC 2 report includes it, and it expands into the nine CC series below.Required
- AvailabilityUptime and resilienceThe system is available for operation and use as committed. Adds A1.1 to A1.3: capacity management, environmental protections, recovery testing. Relevant if you sell an SLA.Optional
- ConfidentialityProtection of confidential dataAdds C1.1 and C1.2: identifying confidential information and disposing of it. Common for B2B platforms holding customer data.Optional
- ProcessingProcessing integrityAdds PI1.1 to PI1.5: processing is complete, valid, accurate, timely and authorised. Mostly transaction and payments systems.Optional
- PrivacyPersonal informationAdds P1 to P8, the largest optional set by far, covering notice, choice, collection, retention, disclosure and quality. Frequently skipped in favour of separate GDPR or CCPA work.Optional
The nine Common Criteria series, and what each one wants
When people say "SOC 2 has 60-odd controls" they are describing the Common Criteria, which map to COSO. Here is what each series actually asks for and the evidence that satisfies it.
- CC1Control environmentIntegrity and ethical values, board oversight, organisational structure, competence, accountability. Evidence: code of conduct, org chart, background check records, job descriptions, board or advisory minutes covering security.5 criteria
- CC2Communication and informationInternal and external communication of security responsibilities. Evidence: policies distributed and acknowledged, a security page or trust centre, a channel for reporting concerns.3 criteria
- CC3Risk assessmentObjectives specified, risks identified and analysed, fraud considered, change assessed. Evidence: the annual risk assessment with owners, scores and treatment decisions.4 criteria
- CC4Monitoring activitiesOngoing and separate evaluations, and communication of deficiencies. Evidence: internal control reviews, vulnerability scan cadence, tracked remediation.2 criteria
- CC5Control activitiesSelection of controls, technology controls, and deployment through policy. Evidence: the policy set itself and proof it maps to your risks.3 criteria
- CC6Logical and physical accessThe largest and most tested series. Provisioning, authentication, deprovisioning, encryption, physical access, disposal. Evidence: access reviews, MFA configuration, leaver tickets, encryption settings, key management.8 criteria
- CC7System operationsDetection of anomalies, incident response, monitoring of infrastructure. Evidence: logging and alerting configuration, the incident response plan, records of real incidents and a tabletop test.5 criteria
- CC8Change managementAuthorising, designing, testing and approving changes. Evidence: branch protection settings, a sample of pull requests showing review, a documented emergency change path.1 criterion
- CC9Risk mitigationBusiness disruption and vendor risk. Evidence: business continuity plan and test, the subprocessor list, vendor security reviews with a cadence.2 criteria
CC6 is where most first-time findings land, and within CC6 it is almost always deprovisioning. A leaver who kept access to a monitoring tool nobody inventoried is the single most common exception in this framework.
Type I and Type II answer different questions
This is the most common misunderstanding in the category. Type I is not a junior Type II.
| Type I | Type II | |
|---|---|---|
| Question answered | Are the controls designed properly? | Did the controls actually operate? |
| Period | One date | A window, three to twelve months |
| Evidence needed | The control exists and is documented | Samples drawn across the whole window |
| Auditor tests | Design only | Design and operating effectiveness |
| Typical use | Unblocking a deal quickly | What enterprise buyers actually want |
| Can you skip it? | Yes, many go straight to Type II | No, eventually every buyer asks |
| Repeatable? | Rarely repeated | Annually, continuously |
If a buyer is blocking a contract today, a Type I plus a written commitment to Type II within twelve months usually unblocks it. If you have time, going straight to Type II saves an entire audit fee.
Scoping decisions that change the price
Four decisions set your cost and your timeline, and all four are yours to make before you engage anyone.
Each additional Trust Services Category adds criteria, evidence and testing hours. Availability is the cheapest addition because most of it is infrastructure you already have. Privacy is by far the most expensive, adding eight criteria series of its own, and is usually better handled through separate GDPR or CCPA work unless a customer has specifically demanded SOC 2 Privacy.
Name the product, the environments and the supporting infrastructure explicitly. A tight, defensible boundary is far cheaper to audit than a vague one. Under-scoping is a real risk though: if your report excludes the system the customer cares about, it does not unblock the deal and you have paid for nothing.
Carve-out is the normal choice and means your report explicitly relies on your cloud provider own SOC 2 report for the controls they operate. Inclusive means their controls are tested as part of your audit, which is far more expensive and almost never necessary. If you choose carve-out you must list the complementary subservice organisation controls you are relying on.
Three months is the floor most auditors will accept, usually only when you already have a Type I. Six months is common for a first Type II. Twelve months reads best to enterprise buyers and is where you end up anyway once you are on an annual cycle. Longer windows do not cost meaningfully more in audit fees; they cost you time.
The evidence an auditor will request
Regardless of your architecture, requests cluster into the same areas. Use this to find your gaps before somebody bills you to find them.
Tick what you can evidence today, with records, for the period you intend to claim.
Access and identity, mostly CC6
0/6Change and operations, CC7 and CC8
0/7Governance and people, CC1 to CC5
0/5Third parties and continuity, CC9
0/4The parts of the report nobody mentions
A SOC 2 report has five sections and two of them are written by you, not the auditor. Teams discover this late and it delays the report.
- IIndependent service auditor reportThe opinion itself. Written by the CPA firm. This is the page your customer reads first.
- IIManagement assertionYour written assertion that the description is accurate and the controls were suitably designed. You sign this.You write it
- IIISystem descriptionYour description of the system, its boundaries, the services provided, infrastructure, software, people, procedures and data. Often 10 to 20 pages. Budget real time for it.You write it
- IVControls, tests and resultsThe criteria, your controls, the tests performed and the results. Exceptions appear here with your management response.
- VOther informationOptional. Roadmap items, context, anything you want on record that is not covered by the opinion.
A realistic timeline
Scoping and gap assessment
1-3 weeksDecide categories, systems, period and carve-out. Identify what is missing against the criteria. Book the auditor now, because their calendar drives your report date.
Owner: You
Remediation
3-8 weeksPolicies, MFA gaps, branch protection, log retention, risk assessment, vendor reviews. The bulk of the work and the phase that slips.
Owner: Engineering
Type I fieldwork and report
2-4 weeksOptional. Worth it if a deal is blocked now, because it tests design rather than operation.
Owner: CPA firm
Type II observation window
3-12 monthsControls run and you evidence them continuously. This cannot be compressed by spending money.
Owner: You
Type II fieldwork
1-3 weeksSampling across the window, walkthroughs, interviews.
Owner: CPA firm
Report
2-6 weeksDraft, management response, final. The next window usually begins the day after the last one ended.
Owner: CPA firm
What it costs
Three separate line items that get conflated constantly in budgeting.
| Line item | Paid to | What drives the number |
|---|---|---|
| Audit fee | The CPA firm | Number of categories, systems in scope, Type I versus Type II, and how organised your evidence is |
| Compliance platform | A vendor like Evidr | Optional. The alternative is spending the time in spreadsheets and headcount |
| Penetration test | A security firm, or your platform if it runs them | Scope of the application and whether authenticated testing is included |
| Readiness consulting | A consultancy | Optional. Useful if nobody internally has done this before |
| Internal time | Nobody, but it is real | Usually the largest cost and the one nobody budgets |
Most compliance platforms in this category do not publish prices and quote after a sales call. Evidr publishes its pricing, starts at a free Starter plan and includes all fourteen frameworks on every paid plan rather than charging per framework. Whatever you choose, get the number in writing, including years two and three, before the demo convinces you.
The mistakes that cost the most
- Scoping too wide on the first report. Every extra category is evidence and hours you did not need to spend yet.
- Writing policies nobody follows. The auditor tests whether the policy matches reality. A policy promising quarterly reviews you do not perform is worse than having no policy.
- Leaving evidence collection until the end. Type II samples across the whole window and you cannot retroactively produce a review that never happened.
- Treating offboarding casually. It is the single most failed control and it is entirely avoidable with a leaver checklist that lists every system.
- Choosing the auditor last. Their availability drives your timeline more than your readiness does.
- Forgetting the system description. Ten to twenty pages you have to write, discovered three weeks before the report is due.
- Treating the report as a finish line. The next observation window starts immediately, and teams that stop evidencing spend the following year reconstructing.
After the report
A Type II covers a stated window and is generally treated as current for twelve months from the end of that window. Beyond that, enterprise buyers read it as stale and will ask for the next one.
A short statement from management covering the gap between your report period end and the date a customer is asking, confirming no material changes to the control environment. Usually covers up to three months. It is not a substitute for an audit and your auditor can advise on wording.
In practice yes. Type II is continuous, and the next observation window usually begins the day after the last one ended. The second audit is an operating rhythm rather than a project, which is the real argument for tooling over spreadsheets.
Nothing automatically disqualifying. What matters is whether your incident response control operated as described: detected, escalated, contained, documented, communicated. A well-handled incident is evidence the control works. A badly documented one is an exception.
Yes, and teams do, usually over turnaround times or price. Expect the new firm to spend more time on your first year with them. Keep your evidence exportable so a switch does not mean rebuilding from scratch.
Where automation actually helps
Compliance automation is oversold, so the honest version: it does not make you secure and it does not pass the audit. It removes the clerical work, which is most of the work.
- Pulling configuration evidence from AWS, Azure, GCP, GitHub, Okta and the rest on a schedule, so nobody takes screenshots.
- Mapping one piece of evidence to every control it satisfies across every framework you run, instead of collecting it once per framework.
- Tracking expiry, so a stale policy acknowledgement surfaces in month two rather than during fieldwork.
- Generating the policy set as a starting point, which beats a blank page and a template pack.
- Giving the auditor a scoped read-only portal instead of a shared drive full of screenshots.
What it will not do: decide your scope, run your risk assessment, write your system description, or make a badly run company pass. The controls still have to be real and they still have to have operated.