What it is
The SOC 2 Trust Services Criteria are the control objectives an independent CPA firm uses to examine a service organization. The AICPA publishes them. Each criterion describes an outcome a control should achieve, such as limiting logical access or managing changes. It does not name a product or setting. The report gives an opinion on the system description and on control design. A Type II report also covers operating effectiveness over a period.
The criteria sit in five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is required. The other four are optional and follow what you promise customers and what data you handle. Security uses the common criteria CC1 through CC9. They cover control environment, communication, risk assessment, monitoring, control activities, access, operations, change management and risk mitigation.
Each added category brings its own criteria and evidence. Availability covers whether systems are available for operation and use as committed. Processing Integrity covers complete, valid, accurate, timely and authorized processing. Confidentiality covers data marked confidential under agreements. Privacy covers personal information from notice through retention and requests. Pick a category because a contract, customer promise or data type requires it, not to look complete.
How it works
Start with the system description. Define the service, the infrastructure and software that deliver it, the people and procedures involved and the data that moves through it. Draw a data flow diagram. Set the boundary: which locations, products and supporting systems are in scope. The boundary drives controls and evidence.
Map each selected criterion to controls. For access, that can mean approval before account creation, multifactor authentication, quarterly access reviews and a removal ticket. For operations, monitoring, incident response, backups and restore tests. For change management, code review, testing, deploy approval and rollback. For vendor risk, review before onboarding and annual reassessment. Give each control an owner, a frequency and an evidence source.
Evidence is the hard part. Auditors sample across the period. A quarterly access review gives four samples. A monthly backup test gives twelve. Automated controls still need configuration records and failure alerts. Manual controls need a trail: who did it, when, what they checked and what happened when it failed. Build an evidence calendar and assign collection before the audit begins.
A readiness review tests control design and finds gaps before the CPA firm does. Then remediation runs. The audit tests the description and the controls. Expect requests for policies, screenshots, tickets, logs and meeting notes. Keep evidence in one place with dates and owners. If a control failed, show the auditor and show the fix. An exception with remediation is easier to defend than a hidden failure.
Why it matters for a business
A SOC 2 report answers security questionnaires with an independent opinion. Buyers can read what was tested and for which period instead of relying on sales claims. That helps procurement, security and legal review you with less back and forth. It is not a certificate and does not prove perfect security. It shows that controls were described and tested against a known standard.
The work also improves operations. Access reviews catch stale accounts. Change records show why a release happened. Incident logs make reviews possible. Vendor checks close a gap many small teams ignore. These controls help when you add staff, take on larger customers or handle a real incident.
Scope affects the sales conversation. A report scoped to Security alone may satisfy a buyer asking general questions about access. A buyer relying on your uptime commitment may want Availability. A buyer sending personal data may ask about Privacy or Confidentiality. Read the customer request and your contract before choosing. Check how subservice organizations are handled and which complementary user entity controls the report lists.
Common mistakes
Treating a policy as a control is the first mistake. A policy says what should happen. An auditor wants proof that it happened. An access policy without onboarding tickets, review records and removal logs is a promise, not evidence. Write policies to match practice you can prove.
Selecting all five categories by default is the second. Privacy is not a general label for security. It covers notice, choice, collection, use, retention, disclosure and data subject requests. If you cannot show those practices, leave Privacy out. Availability needs uptime commitments, capacity planning and recovery tests. Processing Integrity needs input validation, error handling and reconciliation. Add a category when the business case is clear.
Weak evidence discipline is the third. Teams take screenshots the week before the audit. Auditors sample the whole period. A missed quarterly review or skipped approval becomes an exception. Set recurring tickets and reminders. Store evidence as it is produced. If a control changes mid period, document the change and dates.
A boundary that does not match reality is the fourth. Critical systems, cloud accounts, support tools or vendors get left out. Or the description includes systems nobody can evidence. Review the data flow and vendor list with engineering and finance. Include subservice organizations and note the controls they provide. Make the system description match what customers receive.
How to get started
Name one owner and form a small group. Include engineering, IT, operations and the person who handles customer contracts. List the commitments you make about security, uptime, confidentiality and data handling. Inventory the data you collect and where it lives. Use those inputs to choose scope and criteria. Write a one page boundary statement before you buy a compliance tool.
Build a control matrix. Put each selected criterion in a row. Add the control, owner, frequency, evidence source and status. Mark gaps and set due dates. Start with access, change management, monitoring, incident response and vendor review. A tool can store evidence, but it cannot invent controls. Fix the practice, then automate collection.
Talk to independent CPA firms early. Ask how they handle your stack, what they need for sampling and when they can start. Prepare an evidence folder and run a dry run. A readiness assessment can shorten the path if the team is stuck. One option is the SOC 2 readiness assessment from Cloudverg, at a fixed price of $7,500 over three weeks, which covers scoping, a gap assessment and a remediation roadmap. Other options include a former auditor or a compliance platform with an advisory team.
Frequently asked questions
What are the five SOC 2 Trust Services Criteria?
They are Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is required. The other four are optional and chosen based on customer commitments, contracts and the data you handle.
Is Security the only required SOC 2 category?
Yes. Every SOC 2 report includes Security, built on the common criteria CC1 through CC9. You add Availability, Processing Integrity, Confidentiality or Privacy only when the scope calls for them. The report states which categories are covered.
What evidence does a SOC 2 auditor look for?
Auditors look for proof that controls operated during the period. That can include access approvals, review tickets, change records, incident logs, backup test results, vendor reviews and policy acknowledgments. Evidence needs a date, an owner and enough detail to show what was checked and what happened next.