Trust Services Criteria
The criteria used to evaluate whether controls provide reasonable assurance that service commitments and system requirements were achieved for the categories in scope.
Trust Services Criteria · practical SaaS guide
SOC 2 Requirements: A Practical Guide for SaaS Teams
SOC 2 requirements, explained without the compliance jargon.
Understand the Trust Services Criteria, see practical examples of security controls and audit evidence, and identify what your SaaS team should prepare before an independent SOC 2 examination.
- Practical SaaS examples
- Trust Services Criteria explained
- Free requirements explorer
- No account required
This guide provides general educational information. It is not legal advice, an AICPA publication, a certification, or a determination that your organization meets SOC 2 criteria. Controls and evidence depend on your system, commitments, risks, and examination scope.
What SOC 2 actually requires
SOC 2 is an attestation examination performed by an independent CPA firm, resulting in a SOC 2 report. It is not a certification, and it is not a universal fixed checklist of mandatory technical products.
System description & commitments
Management describes the system and the commitments customers rely on. Scope and boundaries matter before control lists.
Controls & evidence
Controls are designed to address applicable criteria. Evidence supports design — and for Type II, operating effectiveness over a period.
Independent examination
A CPA firm examines management’s description and controls and issues the report. Software vendors do not issue SOC 2 reports.
Specific controls and evidence depend on the system, services, risks, commitments, and selected Trust Services Categories. Illustrative SaaS examples — not a universal mandatory control checklist.
Trust Services Categories overview
Security, based on the Common Criteria, forms the foundation of a SOC 2 examination. Additional categories are selected based on relevant service commitments and system requirements — not all five are mandatory.
| Category | What it addresses | Typical SaaS examples | Potential evidence |
|---|---|---|---|
| Security | Protection of information and systems against unauthorized access and related security risks, using the Common Criteria. | Access control, MFA where appropriate, logging, incident response, secure change processes. | Access reviews, provisioning tickets, security policies, monitoring alerts, incident records. |
| Availability | Whether the system is available for operation and use as committed or agreed. | Uptime monitoring, capacity planning, backup and recovery, failover design. | Monitoring dashboards, recovery test results, incident timelines affecting availability. |
| Processing Integrity | Whether system processing is complete, valid, accurate, timely, and authorized as committed. | Input validation, batch reconciliation, exception handling, processing authorization. | Exception reports, reconciliation records, processing job logs, change tickets for processing logic. |
| Confidentiality | Protection of information designated as confidential, as committed or agreed. | Encryption in transit/at rest where appropriate, data classification, restricted sharing. | Encryption configurations, DLP or sharing settings, confidentiality-related access records. |
| Privacy | Collection, use, retention, disclosure, and disposal of personal information against privacy criteria and commitments. | Privacy notice, retention schedules, subject-request handling, vendor privacy reviews. | Privacy notices, retention records, request tickets, DPIA-like analyses where used. |
Illustrative SaaS examples — not a universal mandatory control checklist.
Security Common Criteria (CC1–CC9)
Security examinations evaluate controls against the Common Criteria series. Below are plain-English educational themes aligned to CC1–CC9 — not verbatim AICPA criterion text.
CC1 — Control Environment
Tone at the top, integrity and ethical values, board/oversight where applicable, organizational structure, and accountability for security responsibilities.
Startup first. Name one accountable owner and write down who can approve access and security exceptions.
Common gap. Nobody owns the program beyond “we’ll figure it out”
CC2 — Communication and Information
How the organization obtains, generates, and communicates quality information needed to support security controls — internally and with external parties where relevant.
Startup first. Document what is in scope and tell the team how to report security issues.
Common gap. Training never tracked
CC3 — Risk Assessment
Identifying and analyzing risks to achieving service commitments and system requirements, including fraud considerations and significant changes.
Startup first. Run a lightweight risk review covering access, vendors, and availability — then assign owners.
Common gap. One-time risk spreadsheet never revisited
CC4 — Monitoring Activities
Ongoing and separate evaluations of control performance, and communication of deficiencies so they can be addressed.
Startup first. Pick a monthly review: open access exceptions, critical vulns, and overdue tickets.
Common gap. Findings discovered but never closed
CC5 — Control Activities
Actions established through policies and procedures that help ensure management’s directives to mitigate risks are carried out — including technology general controls where relevant.
Startup first. Write short procedures for joiner/mover/leaver, production deploy, and incident response.
Common gap. Policies with no matching operating procedure
CC6 — Logical and Physical Access Controls
Restricting logical (and, where applicable, physical) access to systems, applications, and information to authorized users, and protecting credentials and infrastructure access paths.
Startup first. Enforce SSO/MFA on production admin paths and run a first access review this month.
Common gap. Former employees retaining access
CC7 — System Operations
Detecting and responding to security events, managing vulnerabilities, and operating the system so security commitments can be met.
Startup first. Define severity levels, an on-call path, and a one-page incident runbook with a place to record outcomes.
Common gap. Logs exist but nobody reviews or responds
CC8 — Change Management
Authorizing, designing, developing, configuring, documenting, testing, approving, and implementing changes to infrastructure, data, software, and procedures.
Startup first. Require review on the production branch and keep deploy history for the period you care about.
Common gap. Direct production changes without review
CC9 — Risk Mitigation
Identifying, selecting, and developing risk mitigation activities — including business-process and vendor/business-partner considerations related to meeting commitments.
Startup first. List vendors with production or customer-data access and review the top risk ones first.
Common gap. Critical vendors never reviewed
Use the explorer below for SaaS practice examples and potential evidence by theme. Official criteria live in the AICPA Trust Services Criteria publications cited in Sources.
Free requirements explorer
Explore SOC 2 requirements by category
Educational discovery — not a compliance score, checklist tracker, or policy analyzer. Illustrative SaaS examples — not a universal mandatory control checklist.
Showing 9 themes
CC1 · Security
Control Environment
What this covers. Tone at the top, integrity and ethical values, board/oversight where applicable, organizational structure, and accountability for security responsibilities.
Example SaaS practices
- • Named security/compliance ownership (founder, CTO, or security lead)
- • Written code of conduct or acceptable-use expectations
- • Role descriptions that match who can touch production
- • Leadership review of security priorities in planning
Potential evidence
- • Org chart or RACI for security responsibilities
- • Approved policies showing ownership and review dates
- • Board or advisory notes if that oversight exists
Common gaps
- • Nobody owns the program beyond “we’ll figure it out”
- • Policies exist but no named approver or review cadence
Startup first. Name one accountable owner and write down who can approve access and security exceptions.
CC2 · Security
Communication and Information
What this covers. How the organization obtains, generates, and communicates quality information needed to support security controls — internally and with external parties where relevant.
Example SaaS practices
- • Security awareness for people who handle customer data
- • Clear channels for reporting incidents or suspicious activity
- • Customer-facing security pages or commitments that match practice
- • Internal documentation of systems in scope
Potential evidence
- • Training completion records
- • Incident reporting instructions
- • System description drafts used for the report
Common gaps
- • Training never tracked
- • System description does not match how the product actually works
Startup first. Document what is in scope and tell the team how to report security issues.
CC3 · Security
Risk Assessment
What this covers. Identifying and analyzing risks to achieving service commitments and system requirements, including fraud considerations and significant changes.
Example SaaS practices
- • Periodic risk assessment covering product, infrastructure, and vendors
- • Tracking of significant changes (new regions, M&A, major features)
- • Prioritized remediation of high risks
Potential evidence
- • Risk register or assessment notes
- • Meeting notes where risks were reviewed
- • Tickets linking risks to remediation
Common gaps
- • One-time risk spreadsheet never revisited
- • No link between identified risks and control changes
Startup first. Run a lightweight risk review covering access, vendors, and availability — then assign owners.
CC4 · Security
Monitoring Activities
What this covers. Ongoing and separate evaluations of control performance, and communication of deficiencies so they can be addressed.
Example SaaS practices
- • Periodic control self-checks or readiness reviews
- • Tracking of open security findings to closure
- • Management review of exceptions and overdue remediation
Potential evidence
- • Internal readiness checklists with dates
- • Finding trackers with owners and due dates
- • Screenshots or exports of monitoring reviews
Common gaps
- • Findings discovered but never closed
- • No cadence for reviewing whether controls still operate
Startup first. Pick a monthly review: open access exceptions, critical vulns, and overdue tickets.
CC5 · Security
Control Activities
What this covers. Actions established through policies and procedures that help ensure management’s directives to mitigate risks are carried out — including technology general controls where relevant.
Example SaaS practices
- • Documented procedures for high-risk workflows (access, deploy, incidents)
- • Segregation of duties where headcount allows, or compensating reviews
- • Automated enforcement where it reduces manual failure modes
Potential evidence
- • Procedures aligned to policies
- • Workflow screenshots or tickets showing the procedure was followed
- • Configuration baselines for key systems
Common gaps
- • Policies with no matching operating procedure
- • Controls described but never performed
Startup first. Write short procedures for joiner/mover/leaver, production deploy, and incident response.
CC6 · Security
Logical and Physical Access Controls
What this covers. Restricting logical (and, where applicable, physical) access to systems, applications, and information to authorized users, and protecting credentials and infrastructure access paths.
Example SaaS practices
- • Role-based access and least privilege for production
- • MFA on admin and production-facing accounts where appropriate
- • Joiner / mover / leaver provisioning with approvals
- • Periodic access reviews for critical systems
- • Privileged access controls for cloud and database admins
Potential evidence
- • Access control policy
- • User access listings and review sign-offs
- • Provisioning and deprovisioning tickets
- • MFA / IdP configuration evidence
Common gaps
- • Former employees retaining access
- • Missing approval records for privileged access
- • Inconsistent access reviews
Startup first. Enforce SSO/MFA on production admin paths and run a first access review this month.
CC7 · Security
System Operations
What this covers. Detecting and responding to security events, managing vulnerabilities, and operating the system so security commitments can be met.
Example SaaS practices
- • Centralized logging for critical systems
- • Alerting and on-call response for security-relevant events
- • Vulnerability scanning and patch triage
- • Documented incident response with severity levels
Potential evidence
- • Incident tickets with timeline and outcome
- • Vulnerability scan exports and remediation tickets
- • Alert configurations and sample alert handling
Common gaps
- • Logs exist but nobody reviews or responds
- • Incidents handled in Slack with no durable record
Startup first. Define severity levels, an on-call path, and a one-page incident runbook with a place to record outcomes.
CC8 · Security
Change Management
What this covers. Authorizing, designing, developing, configuring, documenting, testing, approving, and implementing changes to infrastructure, data, software, and procedures.
Example SaaS practices
- • Pull-request review before production deploy
- • Separate environments for development and production where feasible
- • Change tickets or PR history linking approval to release
- • Emergency-change process with after-the-fact review
Potential evidence
- • Sample PRs with reviewers and CI status
- • Deploy logs for the examination period
- • Change management policy or engineering handbook section
Common gaps
- • Direct production changes without review
- • No record of who approved a release
Startup first. Require review on the production branch and keep deploy history for the period you care about.
CC9 · Security
Risk Mitigation
What this covers. Identifying, selecting, and developing risk mitigation activities — including business-process and vendor/business-partner considerations related to meeting commitments.
Example SaaS practices
- • Vendor inventory for systems that touch customer data or production
- • Risk-based vendor reviews and contracts/DPAs where relevant
- • Business continuity / disaster recovery planning proportionate to commitments
Potential evidence
- • Vendor inventory and review notes
- • Signed DPAs or security addenda for key vendors
- • Backup/restore test records
Common gaps
- • Critical vendors never reviewed
- • Recovery plan exists but untested
Startup first. List vendors with production or customer-data access and review the top risk ones first.
SOC 2 Type I vs Type II requirements
Type choice changes evidence collection, calendar, and how much recurring operation you must demonstrate — not a mandatory sequence.
Type I
Evaluates the description of the system and the suitability of control design as of a specified date. Less emphasis on proving month-after-month operation.
Type II
Also evaluates operating effectiveness over a review period. Expect more samples of recurring activity: access reviews, tickets, alerts, deploys.
Planning impact
Type II usually needs earlier discipline on evidence hygiene. Type I is not always required before Type II — ask what customers actually need.
Budget
Examination fees and internal effort often differ by type and readiness. Compare planning ranges on the SOC 2 cost calculator.
What evidence do SOC 2 auditors typically request?
Actual requests depend on the auditor, scope, controls, and reporting period. Distinguish policies, configurations, operating records, approvals, monitoring outputs, and testing evidence.
| Area | Example objective | Example artifact | Owner | Common problem |
|---|---|---|---|---|
| Access management | Only authorized users have access to production systems, and access is reviewed periodically. | Access review spreadsheet or IdP export with reviewer sign-off for the period. | Engineering / IT lead | Reviews happen verbally with no dated record. |
| Risk assessment | Risks to service commitments are identified, evaluated, and addressed. | Risk register with owners, dates, and disposition. | Founder / security lead | A one-time risk doc with no update trail. |
| Change management | Production changes are reviewed and authorized before release. | PR history and deploy logs for sampled changes. | Engineering manager | Hotfixes pushed without review and never documented. |
| Incident response | Security incidents are detected, responded to, and recorded. | Incident tickets with severity, timeline, and outcome. | On-call / security lead | Incidents live only in Slack threads. |
| Vendor management | Vendors that can affect security commitments are identified and reviewed. | Vendor inventory plus review notes for high-risk vendors. | Ops / security lead | No inventory of who can touch customer data. |
| Security awareness | Personnel receive security expectations appropriate to their roles. | Training completion records or briefing attendance. | People ops / founder | Training claimed but not evidenced. |
| Business continuity | The organization can recover critical systems consistent with commitments. | Backup configuration plus restore test record. | Infrastructure lead | Backups configured but never restored successfully in a test. |
| Monitoring and logging | Security-relevant events are logged and actionable alerts are handled. | Alert configs and sample alert-handling tickets. | Engineering / SRE | Dashboards without an owner who responds. |
| Policies and governance | Security policies describe current practice and are reviewed on a cadence. | Approved policy versions with owners and review dates. | Compliance owner | Downloaded templates that do not match operations. |
| Additional Trust Services Categories | Controls support Availability, Processing Integrity, Confidentiality, or Privacy commitments when those categories are in scope. | Category-specific monitoring, processing exception logs, encryption configs, or privacy request records — as applicable. | Product / security / privacy lead | Category selected without matching commitments or evidence. |
Having a policy document does not automatically demonstrate that a control operated effectively for a Type II period.
SOC 2 requirements for startups
Small SaaS teams can prepare without enterprise bureaucracy — but they do not get a blanket exemption from applicable examination criteria.
Scope tightly
Define the system, environments, and commitments customers actually care about before expanding criteria.
Name owners
Access, incidents, vendors, and change need named humans — even if one person wears several hats.
Document real practice
Write policies that match how you operate today, then fix the gaps that matter.
Evidence as you go
Tickets, reviews, and deploy history beat a scramble at the end of an observation period.
Deeper founder path: SOC 2 for startups.
A practical SOC 2 preparation roadmap
Practical guidance for lean teams — not an official AICPA-prescribed sequence.
01
Define scope
Systems, services, commitments, boundaries, and relevant Trust Services Categories.
02
Understand control expectations
Review applicable criteria themes and identify appropriate controls for your stack.
03
Assess current readiness
Find existing controls and gaps with a structured readiness pass.
04
Document policies and ownership
Write policies that match operations and assign responsibilities.
05
Implement and operate controls
Close material gaps and perform recurring activities consistently.
06
Organize evidence
Keep artifacts appropriate to Type I design testing or Type II operating periods.
07
Engage an independent CPA firm
Confirm scope, approach, timing, and evidence expectations with the auditor.
08
Maintain the program
Keep operating controls, addressing exceptions, and reviewing changes.
Common SOC 2 misunderstandings
“SOC 2 is a certification.”
It is an attestation examination resulting in a report from an independent CPA firm.
“Every company needs all five Trust Services Categories.”
Security is foundational; other categories are selected based on commitments and system requirements.
“SOC 2 requires the same controls for every company.”
Controls are designed to address applicable criteria given your system, risks, and commitments.
“Buying compliance software makes us SOC 2 compliant.”
Software can organize preparation. Only an independent CPA examination produces a SOC 2 report.
“Type I must come before Type II.”
Type I is not always a required stepping stone. Ask what customers actually need.
“A policy document alone proves a control is working.”
Type II typically needs evidence that the control operated over the review period.
“SOC 2 requires a specific security tool vendor.”
Criteria are tool-agnostic. Auditors care whether controls address the criteria, not your brand of scanner.
“A SOC 2 report guarantees a company is secure.”
A report provides assurance relative to the criteria and period examined — not a permanent security guarantee.
Free AuditBird SOC 2 resources
Each tool has a distinct job. None of them certify compliance or replace an auditor.
SOC 2 Readiness Assessment
Find potential gaps in your preparation — planning score, not an audit opinion.
Start assessment →SOC 2 Checklist
Track practical preparation tasks in your browser.
Open checklist →SOC 2 Policy Templates
Editable starting points — still need review against how you operate.
Browse templates →SOC 2 Policy Checker
Review selected policy coverage indicators in pasted text.
Check a policy →SOC 2 Cost Calculator
Estimate examination and preparation budgets with transparent assumptions.
Estimate cost →SOC 2 software & automation
How platforms help — and what they cannot automate.
Explore software →Turn SOC 2 requirements into an ongoing compliance workflow.
AuditBird is being built to help SaaS teams organize controls, responsibilities, evidence, and recurring compliance work without the complexity of oversized enterprise platforms. Planned features and early-access pricing are separate from the free educational tools on this page.
AuditBird does not issue SOC 2 reports, certify organizations, replace independent CPA firms, or guarantee a successful examination.
Sources & references
Educational content last reviewed 2026-10-15. Prefer AICPA primary materials for official criteria text.
- System and Organization Controls (SOC) suite of services
AICPA & CIMA · checked 2026-10-15
Official overview of SOC services and that examinations are performed by independent CPAs.
Explains the SOC suite conceptually. Does not replace TSP section 100 Trust Services Criteria text.
- 2017 Trust Services Criteria (With Revised Points of Focus — 2022)
AICPA & CIMA · checked 2026-10-15
Authoritative criteria set used in SOC 2 examinations (Security Common Criteria and additional categories).
AuditBird does not reproduce the criteria verbatim. Explorer content is plain-English educational paraphrase plus illustrative SaaS examples.
- 2017 Trust Services Criteria landing
AICPA & CIMA · checked 2026-10-15
Entry point to Trust Services Criteria materials.
Confirm you are reading the current AICPA-published version before relying on any point of focus.
Continue on the SOC 2 hub, automation, or pricing.
Questions
SOC 2 is an independent attestation examination against applicable Trust Services Criteria — not a fixed universal product checklist. Requirements center on your system description, management’s responsibilities, suitably designed controls (and for Type II, operating effectiveness), and evidence an independent CPA firm can examine.
Requirements first. Then a program you can maintain.
Use the explorer and free tools to understand the work. Join early access when you want AuditBird as the home for ongoing compliance.
SOC 2 · ISO 27001 · EU AI Act · More coming