AICPA Trust Service Criteria, explained: a founder's reading guide

The AICPA Trust Services Criteria (TSC) is the control framework every SOC 2 examination tests against. It's a 70-page document with a lot of legal-flavored prose. This article walks through the Common Criteria (CC1-CC9) and the four additional categories in plain language, with the engineering practice or organizational mechanism that typically satisfies each one for a small SaaS company.

This isn't a substitute for reading the source. TSP Section 100 (2017) is freely available. This is the reading guide we wish someone had handed us when we started.

Structure: how the TSC is organized

Every SOC 2 report covers the Security category, which is implemented through the nine Common Criteria (CC1 through CC9). The other four categories (Availability, Processing Integrity, Confidentiality, and Privacy) are additive, meaning a Security-only report is fully valid SOC 2.

CC1: Control Environment

What it asks: does the organization have a tone at the top that takes security seriously? Are roles, responsibilities, and reporting lines clear?

Satisfied by: a board (or founder, in seed stage) that has approved the information security policy; a designated security owner (CTO or CEO is fine at this stage); an organizational chart in the system description; a Code of Conduct that all employees sign at hire.

CC2: Communication and Information

What it asks: does the organization communicate relevant security information internally and externally? Do employees know what's expected of them?

Satisfied by: a security awareness training program (one-time at hire plus annual refresh; KnowBe4, Hoxhunt, and many others are sub-$10/user/year), an internal security wiki page, publicly-accessible documentation about your security posture (typically a trust center or a "security" page on your site).

CC3: Risk Assessment

What it asks: does the organization identify and assess risks to its security objectives?

Satisfied by: an annual risk assessment document listing each risk category (threat actor categories, data exposure scenarios, infrastructure failures), with each risk rated for likelihood and impact and assigned a treatment (accept, mitigate, transfer, avoid). One spreadsheet, reviewed annually, with the most recent revision date stamped.

CC4: Monitoring Activities

What it asks: does the organization monitor whether its controls are operating as intended?

Satisfied by: quarterly access reviews (managers attest that their direct reports' access is appropriate), a documented vulnerability scan cadence with evidence of scans actually running, log monitoring (CloudTrail / GuardDuty for AWS, your tool of choice), and a runbook for what triggers a review of a control deviation.

CC5: Control Activities

What it asks: does the organization design and implement controls to mitigate the risks identified in CC3?

Satisfied by: the controls themselves (this is the umbrella criterion under which the rest sit). At evidence-collection time, the artifacts are the policy documents (which name the controls) plus the implementation evidence (which shows they exist).

CC6: Logical and Physical Access Controls

The largest criterion family. Eight sub-criteria:

• CC6.1: Logical access is restricted to authenticated principals. → SSO + MFA enforced on all systems.
• CC6.2: Access is provisioned based on job responsibility. → Role-based access control, least privilege, documented onboarding.
• CC6.3: Access is removed in a timely manner upon termination. → Same-day SSO revocation, offboarding checklist.
• CC6.4: Physical access to information assets is restricted. → For cloud-native SaaS, this is largely carved-out to AWS/GCP via the subservice carve-out method.
• CC6.5: Logical and physical protections over physical assets. → Endpoint protection (MDM + EDR) on all company-issued laptops.
• CC6.6: Logical access is restricted to assets in use. → Auto-expiring sessions, screen lock policies on laptops, session timeouts on internal tools.
• CC6.7: Transmission of data is restricted to authorized users with appropriate protections. → TLS 1.2+ everywhere, encrypted backups, mTLS or VPN for internal services that handle customer data.
• CC6.8: Data classification informs control requirements. → A data classification scheme (public, internal, confidential, restricted), tagged on each data store.

CC7: System Operations

What it asks: does the organization monitor system components, detect anomalies, and respond to incidents?

• CC7.1: Detection of configuration changes that represent vulnerabilities. → Infrastructure-as-code with PR review, configuration drift detection (CloudConformity, AWS Config, or similar).
• CC7.2: Monitoring for anomalous activity. → GuardDuty, CloudTrail event analysis, log aggregation.
• CC7.3, 7.4, 7.5: Incident identification, evaluation, response, and recovery. → IR policy plus at least one tabletop exercise per year. See our 5 common control failures article on this exact pitfall.

CC8: Change Management

What it asks: are changes to systems authorized, tested, approved, and documented?

Satisfied by: a documented SDLC, GitHub branch protection requiring code review, CI tests that gate deploys, deployment authorization (the merge IS the authorization in GitHub-Flow), and an audit trail tying each production change back to a ticket and a reviewer.

CC9: Risk Mitigation

What it asks: does the organization mitigate risks associated with business disruption, vendor relationships, and significant changes?

• CC9.1: Business disruption risks identified and mitigated. → Business continuity plan, documented RTO/RPO, backup verification.
• CC9.2: Vendor and business partner risks assessed. → Vendor risk register with at minimum: vendor name, data shared, security posture (typically their SOC 2 status), and review cadence.

The four additional categories (when applicable)

Availability (A1)

Capacity planning, monitoring, business continuity, disaster recovery. Adds ~5-8 control points. Sub-criteria A1.1, A1.2, A1.3. Add this if customer contracts require SLA attestations.

Processing Integrity (PI1)

System processing is complete, valid, accurate, timely, authorized. Adds ~5 control points. Most relevant for transaction-processing systems (payments, settlements, regulated workflows). Most early-stage SaaS skip this.

Confidentiality (C1)

Protection of confidential information (a separate concept from PII). Adds ~2 control points. Common for companies handling customer source code, M&A data, or pre-public financials.

Privacy (P1-P8)

Notice, choice, collection, use, retention, access, disclosure, quality, monitoring. Adds ~20+ control points. The Privacy category is by far the largest evidence burden. Add only when a contract specifically demands it.

How Polara Labs maps to this

Polara's intake covers CC1-CC9 across 8 question categories. The deterministic gap engine maps each answer to one or more control points and the specific evidence the CPA will request. Our thirteen generated policies collectively name every control under CC1-CC9. Scope is Security only, fixed rather than a setting. We do not scope Availability, Confidentiality, Processing Integrity or Privacy. When one of those becomes a customer requirement, you've outgrown us and we'll tell you so.

Further reading

• TSP Section 100 (2017), the source document
• AICPA Trust Services hub
• NIST SP 800-53 Rev. 5, adjacent control catalog used by many SOC 2 control mappings