SOC 2 Common Criteria (CC) Controls Explained

The Common Criteria (CC) are the backbone of every SOC 2 report. They correspond to the Security Trust Service Criterion — the only mandatory criterion in every SOC 2 examination — and they define the specific control objectives your auditor evaluates. Understanding all nine CC categories is essential for designing a control framework that passes audit and actually protects your systems.

The CC categories are derived from the COSO (Committee of Sponsoring Organizations of the Treadway Commission) internal control framework, adapted by the AICPA specifically for information security. They cover everything from organizational culture and governance to technical access controls and vendor risk management. For SaaS companies, this means SOC 2 isn’t just about firewalls and encryption — it’s about how your entire organization operates.

This guide breaks down each CC category with what auditors test, what evidence they expect, and how SaaS companies should implement controls to satisfy each one. If you’re still getting oriented with SOC 2, start with our What Is SOC 2? overview before diving into the criteria details.

CC1: Control Environment

Criteria covered: CC1.1 through CC1.5

The control environment establishes the foundation for everything else in your SOC 2 program. It’s about organizational commitment — does your company take security seriously at every level, from the board to individual contributors?

What auditors look for:

• A code of conduct or ethics policy signed by all employees
• Defined organizational structure with clear security roles and responsibilities
• Board-level or executive oversight of the security program (meeting minutes, reporting cadence)
• Management accountability for security objectives
• HR policies that reinforce security (background checks, onboarding security training, termination procedures)

SaaS implementation:

• Organizational chart with security responsibilities. Map who owns what: CISO or security lead, engineering managers responsible for secure development, the compliance owner, and anyone with privileged system access. This doesn’t require a massive org — a 30-person startup can document security responsibilities across existing roles.
• Code of conduct. Every employee signs an acceptable use and ethics policy during onboarding. Review and re-acknowledge annually.
• Board or leadership reporting. Document regular security briefings to your board or executive team. Even if you’re a startup without a formal board, quarterly security status reports to your leadership team satisfy this requirement.
• HR security integration. Background checks for new hires, mandatory security training during onboarding, and a documented offboarding process that includes access revocation within 24 hours of termination.

In practice: CC1 is where auditors assess whether security is part of your company’s DNA or an afterthought. The controls here are less technical and more organizational, but they’re foundational. If your control environment is weak — if there’s no executive ownership, no documented structure, no accountability — auditors will question whether the technical controls in CC3-CC9 are sustainable. For comprehensive policy guidance, see our policies and procedures guide.

CC2: Communication and Information

Criteria covered: CC2.1 through CC2.3

CC2 addresses how your organization communicates security information internally and externally. Auditors want to see that security responsibilities, expectations, and commitments are clearly communicated — not buried in a wiki nobody reads.

What auditors look for:

• Security awareness training records with completion tracking
• Internal communication channels for security information (incident alerts, policy changes, security updates)
• External security commitments documented and communicated (trust pages, SLAs, security whitepapers)
• Procedures for communicating with external parties about security matters (customer inquiries, vendor questionnaires)

SaaS implementation:

• Security awareness training program. Annual training for all employees, with additional role-specific training for engineers (secure coding) and administrators (privileged access management). Track completion rates and follow up on overdue training.
• Internal communication processes. A defined channel (Slack channel, email list, or intranet) for security announcements. Documented procedures for notifying teams about security incidents, policy changes, and system changes that affect security controls.
• External security page. A public-facing security practices page (trust page) that describes your security commitments at a level appropriate for customers and prospects. This is both a CC2 control and a sales enablement tool.
• Vendor and customer communication procedures. Documented processes for responding to customer security questionnaires, handling vendor security inquiries, and managing security-related contractual obligations.

SaaS example: When you deploy a significant infrastructure change — migrating to a new database, enabling a new authentication method, changing your encryption configuration — CC2 requires that affected stakeholders are informed. Internally, that’s a change notification to engineering and security teams. Externally, if the change affects customers, it’s a communication via your status page or changelog.

For details on building evidence artifacts for these communications, see our evidence collection guide.

CC3: Risk Assessment

Criteria covered: CC3.1 through CC3.4

CC3 requires your organization to have a formal, documented process for identifying, analyzing, and managing risk. This isn’t a one-time exercise — it’s an ongoing program that feeds into every other control category.

What auditors look for:

• A formal risk assessment document produced at least annually
• A risk register that catalogs identified risks with severity ratings, likelihood assessments, and treatment plans
• Fraud risk considerations (yes, even for SaaS companies)
• A process for identifying and evaluating significant changes that could introduce new risks

SaaS implementation:

• Annual risk assessment. Conduct a structured risk assessment at least once per year. Identify threats to your system (data breach, unauthorized access, service outage, insider threat, vendor compromise), assess the likelihood and impact of each, and document your response — accept, mitigate, transfer, or avoid.
• Risk register. Maintain a living document that tracks each identified risk, its current rating, the controls that mitigate it, the risk owner, and the status of any remediation activities. Review and update quarterly.
• Fraud risk evaluation. Auditors specifically look for fraud risk considerations — unauthorized data access, financial manipulation, management override of controls. SaaS companies should document how segregation of duties, access controls, and monitoring mitigate fraud risk.
• Change impact assessment. When you make significant changes — new product features that handle sensitive data, infrastructure migrations, new vendor relationships, major organizational changes — you need a documented process for evaluating the security impact.

In practice: Many SaaS teams treat risk assessment as a compliance checkbox — they fill out a template once a year and forget about it. Strong programs integrate risk assessment into operational decisions. When your engineering team evaluates a new third-party SDK, that evaluation should include a risk assessment entry. When you expand into a new market with different regulatory requirements, the risk register gets updated.

For a complete walkthrough of building a SOC 2-ready risk assessment, see our risk assessment guide.

CC4: Monitoring Activities

Criteria covered: CC4.1 through CC4.2

CC4 requires that your organization actively monitors the effectiveness of its controls and addresses deficiencies when they’re identified. This is the “trust but verify” category — you can’t just implement controls and assume they work forever.

What auditors look for:

• Ongoing monitoring procedures that evaluate control effectiveness over time
• Internal assessment processes (self-assessments, internal audits, control testing)
• A deficiency management process — how are control failures identified, tracked, and remediated?
• Evidence that monitoring results are reported to management

SaaS implementation:

• Automated monitoring dashboards. Configure dashboards that track key security metrics: MFA adoption rate, access review completion, patch management status, vulnerability scan results, incident response times. Flag deviations from expected baselines automatically.
• Regular control effectiveness reviews. At least quarterly, review whether your controls are operating as designed. Are access reviews happening on schedule? Are code reviews being completed before merges? Is security training completion at 100%?
• Deficiency management process. When a control fails or a gap is identified, you need a documented process for logging the deficiency, assigning an owner, defining a remediation plan, and tracking resolution. Auditors specifically test whether deficiencies identified in prior periods were resolved.

SaaS example: Your access review policy requires quarterly reviews, but monitoring reveals that Q2’s review was completed three weeks late. Under CC4, you need to log this as a deficiency, investigate the root cause (was the owner on leave? was the process unclear?), implement corrective action, and document the entire sequence. Pretending it didn’t happen is worse than the late review itself.

For a deep dive into building a monitoring program, see our continuous monitoring guide.

CC5: Control Activities

Criteria covered: CC5.1 through CC5.3

CC5 bridges the gap between risk identification (CC3) and control implementation. It requires that you select and deploy controls that actually address the risks you’ve identified, and that these controls are enforced through both technology and policy.

What auditors look for:

• Controls mapped to specific risks (a control matrix or similar document)
• Technology controls deployed and configured appropriately
• Policies and procedures established and communicated for each control area
• Evidence that controls are designed at a level of precision sufficient to mitigate identified risks

SaaS implementation:

• Control matrix. Create a mapping document that links each identified risk to the specific controls that mitigate it. This is one of the most important audit artifacts — it demonstrates that your controls are deliberate, not ad hoc. A well-designed control matrix maps each Common Criteria point to one or more controls, with evidence requirements documented for each.
• Technology control deployment. Implement the technical controls your risk assessment identified as necessary: encryption at rest and in transit, intrusion detection, network segmentation, endpoint protection, automated vulnerability scanning.
• Policy enforcement. Every control should be backed by a policy that defines the requirement and a procedure that describes how it’s executed. Deploy policies through your GRC platform or policy management system, track acknowledgments, and enforce through technical controls where possible (e.g., enforcing MFA through your identity provider rather than relying on voluntary adoption).

In practice: The most common CC5 finding is a disconnect between the control matrix and reality. The matrix says “quarterly vulnerability scans” but the scans are actually run ad hoc. The matrix says “all code changes require peer review” but the Git history shows direct pushes to main. Auditors compare your documented controls against operational evidence — make sure they match. For policy development guidance, see our policies and procedures guide.

CC6: Logical and Physical Access Controls

Criteria covered: CC6.1 through CC6.8

CC6 is the most control-dense category in the Common Criteria and produces the highest volume of evidence during an audit. It covers every aspect of access management — how identities are provisioned, how authentication works, how access is restricted, and how system boundaries are protected.

What auditors look for:

• Identity provider configuration with centralized user management
• MFA enforcement across all critical systems
• Role-based access control (RBAC) implementation following least privilege
• Network security controls (firewalls, WAF, network segmentation)
• Endpoint protection on all company devices
• Encryption of data at rest and in transit
• Physical access controls for any data center or server room (cloud providers handle this via their own SOC reports)
• User access provisioning and deprovisioning procedures
• Periodic access reviews with documented evidence

SaaS implementation:

• Single sign-on (SSO) with MFA. Centralize authentication through an identity provider (Okta, Azure AD, Google Workspace) with mandatory MFA for all users. This is non-negotiable — auditors test MFA enforcement on every critical system.
• Role-based access with least privilege. Define roles for each system and assign the minimum permissions necessary for each role. Engineers don’t need admin access to billing systems. Sales doesn’t need access to production databases.
• Quarterly access reviews. Every quarter, system owners review who has access to their systems, verify that access levels are appropriate, and revoke access that’s no longer needed. Document the review, the findings, and any access changes made.
• Network security. Implement WAF (Web Application Firewall) on public-facing services, segment your network to isolate production from development, restrict SSH/RDP access to authorized networks only, and maintain firewall rules that default-deny inbound traffic.
• Endpoint protection. Deploy MDM (Mobile Device Management) and EDR (Endpoint Detection and Response) on all company devices. Enforce disk encryption, screen lock policies, and automatic updates.
• Encryption everywhere. TLS 1.2+ for all data in transit. AES-256 or equivalent for data at rest. Encrypted database connections. Encrypted backups. Auditors verify encryption configuration in your cloud environments.
• Provisioning and deprovisioning. Documented procedures for granting access during onboarding and revoking all access during offboarding. Auditors specifically test whether terminated employees’ access was revoked promptly.

In practice: CC6 is where the majority of SOC 2 audit findings occur. The most common issues: MFA not enforced on all systems (that one legacy admin console without MFA), access reviews not completed on schedule, terminated employees with lingering access, and overly permissive IAM roles. Invest disproportionate attention here — the thoroughness of your access controls directly determines audit outcomes.

CC7: System Operations

Criteria covered: CC7.1 through CC7.5

CC7 covers how your organization detects, evaluates, and responds to security events and incidents. It’s the operational heartbeat of your security program — the controls that run continuously rather than periodically.

What auditors look for:

• Security event monitoring and detection tools (SIEM, log aggregation, alerting)
• Alert triage and escalation procedures
• Incident response plan with defined roles, severity classifications, and response procedures
• Evidence of incident detection, response, and resolution
• Post-incident review documentation

SaaS implementation:

• SIEM or log aggregation. Centralize security-relevant logs — authentication events, authorization failures, system changes, network activity, application errors — into a single platform. Configure alerting rules for suspicious patterns: brute force attempts, privilege escalation, unusual data access patterns, configuration changes outside of maintenance windows.
• Alert triage process. Define how alerts are classified (informational, warning, critical), who receives each classification, expected response times by severity, and escalation paths when the primary responder is unavailable.
• Incident response playbook. Document your response procedures for each incident category: data breach, unauthorized access, service disruption, malware detection, insider threat. Include contact lists, communication templates, containment procedures, and recovery steps. See our incident response guide for a complete framework.
• Post-incident reviews. After every significant incident, conduct a blameless post-mortem. Document the timeline, root cause, impact, response effectiveness, and corrective actions. These reviews become audit evidence and demonstrate a mature security culture.

SaaS example: Your SIEM detects multiple failed authentication attempts against an admin account at 3 AM. Your alerting rules trigger a notification to the on-call engineer. The engineer follows the incident response playbook: locks the account, investigates the source, determines it was a credential stuffing attack, verifies no successful access occurred, documents the event, and implements additional rate limiting. The entire sequence — detection, triage, response, resolution, documentation — is the evidence chain your auditor reviews.

CC8: Change Management

Criteria covered: CC8.1

CC8 has a single criterion but it’s one of the most heavily tested areas in a SaaS company’s SOC 2 audit. It covers how changes to your infrastructure, applications, data, and procedures are managed, approved, tested, and deployed.

What auditors look for:

• A documented change management policy
• Code review requirements (peer review before merge)
• CI/CD pipeline with automated testing
• Deployment procedures with approval workflows
• Staging or pre-production environments for testing changes before production
• Emergency change procedures with retroactive review
• Rollback capabilities and documentation

SaaS implementation:

• PR-based code review. All code changes require a pull request reviewed and approved by at least one peer before merging. Enforce this through branch protection rules in GitHub, GitLab, or Bitbucket. Auditors pull sample PRs and verify reviews were completed.
• CI/CD pipeline controls. Automated testing (unit tests, integration tests, security scans) must pass before deployment. Pipeline configurations should be version-controlled and changes to the pipeline itself should require review.
• Staging environments. Changes deploy to a staging or pre-production environment before reaching production. Auditors verify that you have a non-production environment and that it’s used consistently.
• Deployment approval workflow. For production deployments, define who can approve and who can execute. Segregation of duties — the person who wrote the code shouldn’t be the only person who approves it — is a key control.
• Emergency change process. Sometimes production issues require immediate fixes that bypass normal review. Document an emergency change procedure that allows expedited deployment with mandatory retroactive review and documentation within 24-48 hours.
• Rollback procedures. Document how to roll back a failed deployment. Auditors want to see that you’ve considered deployment failures and have a documented recovery path.

In practice: Auditors love examining change management because the evidence is rich and easily verified. They’ll pull your Git history, look at PR approval patterns, check CI/CD pipeline configurations, and compare deployment logs against your stated procedures. The most common finding: developers with the ability to push directly to the main branch, bypassing code review. Lock this down before your audit.

CC9: Risk Mitigation

Criteria covered: CC9.1 through CC9.2

CC9 focuses on risk mitigation activities, with a particular emphasis on vendor and business partner risk management. For SaaS companies that rely on dozens of third-party services, this category is increasingly significant.

What auditors look for:

• A vendor management program with documented processes
• Vendor inventory with risk classifications
• Due diligence evidence for critical vendors (SOC 2 reports, security questionnaires, certifications)
• Contracts with security requirements and data protection clauses
• Periodic vendor reassessment procedures

SaaS implementation:

• Vendor inventory. Maintain a comprehensive list of all vendors that access, process, or store your data or your customers’ data. Classify each by risk level based on data sensitivity and business criticality.
• Vendor risk assessments. For high-risk vendors (those with access to customer data or critical infrastructure), conduct formal risk assessments. Review their SOC 2 reports, security certifications, and responses to your security questionnaires. Document the assessment and any accepted residual risks.
• Contractual security requirements. Ensure contracts with vendors include data protection obligations, breach notification requirements, audit rights, and termination clauses. For vendors processing personal data, include data processing agreements.
• Annual reassessment. Review vendor risk classifications and security posture annually. Request updated SOC 2 reports, review any security incidents the vendor disclosed, and reassess whether the vendor still meets your risk tolerance.

SaaS example: Your application uses Stripe for payments, AWS for hosting, SendGrid for email, and a startup analytics tool for product metrics. AWS and Stripe are well-established with SOC 2 reports you can review. SendGrid has a SOC 2 report as well. The startup analytics tool has no SOC 2 and limited security documentation. Your vendor risk assessment documents this gap, and your risk acceptance decision (or your decision to find an alternative vendor) is the evidence your auditor reviews.

For a comprehensive vendor management framework, see our vendor management guide.

Mapping Controls to Common Criteria

Creating a control matrix — a document that maps each CC point to the specific controls that satisfy it — is one of the most valuable exercises in your SOC 2 program.

How to build a control matrix:

1. List every CC criterion (CC1.1 through CC9.2) in a spreadsheet or GRC platform.
2. For each criterion, identify the controls in your environment that satisfy it. One control can (and should) map to multiple criteria.
3. For each control, document the evidence that demonstrates the control is operating. Link to specific evidence sources.
4. Identify gaps — criteria with no mapped controls. These are your remediation priorities.

One control, multiple criteria. Your quarterly access review satisfies CC6.3 (restricting access), CC4.1 (monitoring activities), and CC1.4 (accountability). Your incident response process satisfies CC7.3 (evaluating events), CC7.4 (responding to incidents), and CC2.2 (communicating information). Mapping these overlaps reduces the total number of controls you need to implement.

Start with the highest-impact controls. If you’re building your control framework from scratch, prioritize access management (CC6), change management (CC8), and monitoring (CC7). These three categories cover the most criteria, produce the most evidence, and address the risks that auditors weight most heavily.

Example mapping for a typical SaaS company:

Control	CC Criteria Satisfied	Evidence
SSO with MFA enforcement	CC6.1, CC6.2, CC6.6	IdP configuration screenshot, MFA policy, login logs
Quarterly access reviews	CC6.1, CC6.3, CC4.1, CC1.4	Access review records, remediation tickets
PR-based code review	CC8.1, CC5.2	Branch protection config, sample PRs with approvals
Annual risk assessment	CC3.1, CC3.2, CC3.3	Risk assessment document, risk register
Security awareness training	CC1.1, CC2.1	Training completion records, training content
Incident response plan	CC7.3, CC7.4, CC7.5	IR playbook, incident tickets, post-mortems
Vendor risk assessments	CC9.1, CC9.2	Vendor inventory, assessment records, SOC reports

Additional Criteria Beyond the Common Criteria

The Common Criteria cover the Security TSC, but if your SOC 2 report includes additional Trust Service Criteria, you’ll need to address supplementary control points. See our Trust Service Criteria guide for detailed selection guidance.

Availability (A1.1-A1.3). Covers recovery objectives, backup procedures, and disaster recovery testing. You’ll need documented RTOs and RPOs, automated backups with tested restore procedures, and a DR plan that’s been validated through at least annual testing.

Processing Integrity (PI1.1-PI1.5). Covers processing completeness, accuracy, timeliness, and authorization. Relevant for SaaS products that perform financial calculations, data transformations, or transaction processing. You’ll need input validation, reconciliation controls, and processing monitoring.

Confidentiality (C1.1-C1.2). Covers identification and protection of confidential information. You’ll need a data classification scheme, controls specific to each classification level, and evidence that confidential data receives enhanced protection (encryption, access restrictions, retention limits).

Privacy (P1-P8). Covers the full lifecycle of personal information — notice, choice, collection, use, disclosure, access, quality, and monitoring. This is the most extensive additional criterion and overlaps significantly with GDPR requirements. Only include it if your customers specifically require it or if privacy is core to your value proposition.

In practice: Most SaaS companies pursuing their first SOC 2 report should start with Security (Common Criteria) only. Each additional criterion adds 15-25% more controls, evidence, and audit scope. Add criteria in year 2+ based on actual customer requirements, not speculation about what might be needed.

How GRCTrail Helps

GRCTrail provides a structured framework for implementing and managing controls across all Common Criteria categories.

• Pre-built control framework mapped to all Common Criteria so you start with a complete CC1-CC9 control set designed for SaaS companies, not a blank spreadsheet
• Control implementation guidance for each CC category with step-by-step instructions, SaaS-specific examples, and recommended tooling for each control
• Evidence requirements linked to controls so your team knows exactly what artifacts to collect, where to find them, and how often they need to be refreshed
• Gap analysis showing which CC points have controls and which don’t — giving you a real-time view of your readiness and a prioritized remediation roadmap
• Automated control testing integration that continuously validates whether your controls are operating as designed, flagging drift before your auditor’s next sample pull

Get started with GRCTrail →

Related Guides

• What Is SOC 2? A Practical Guide for SaaS Companies
• SOC 2 Trust Service Criteria Explained
• SOC 2 Compliance Checklist for SaaS Companies
• SOC 2 Policies and Procedures Guide