---
title: "SOC 2 Common Criteria, explained for small SaaS teams"
description: "All 33 SOC 2 Common Criteria explained for small SaaS teams, with practical examples, typical evidence and a free evidence gap worksheet."
canonical: "https://auditbadger.com/soc2/common-criteria/"
last-updated: "2026-10-17"
---

# SOC 2 Common Criteria, explained for small SaaS teams

By Maciej Litwiniuk, founder of AuditBadger. Reviewed 2026-09-23.

## What the Common Criteria are

The Common Criteria are 33 criteria, numbered CC1.1 to CC9.2, that underpin the five SOC 2 trust services categories. They cover governance, risk, access, operations, change management and vendor relationships. This guide explains what they mean for a small SaaS team and gives examples of controls and evidence you can use to prepare.

Security uses the Common Criteria without additional category-specific criteria. Availability, Confidentiality, Processing Integrity and Privacy each add criteria of their own. Security is the usual starting scope for a SaaS company, although the AICPA allows examinations covering other categories without Security. Choose the categories with your auditor based on your services, commitments and system requirements. This guide covers the Common Criteria, not the additional criteria in those other categories.

The criteria come from two places. CC1 to CC5 align with the 17 principles of the COSO internal control framework, so they read like a corporate governance textbook. CC6 to CC9 add detail on access, operations, change and risk mitigation. These criteria also support the other trust services categories. That is why the first half sounds like it was written for a bank's board and the second half sounds like it was written for your engineering team.

A criterion is not a control. It is a statement of an outcome. You decide which controls get you there, and the auditor evaluates them against the applicable criteria. Two companies can meet the same criterion with different controls. One control may support several criteria, and one criterion may need several controls.

A Type I examination evaluates the system description and the suitability of control design at a specified date. A Type II examination also evaluates whether controls operated effectively over a specified period. Many of the evidence examples below describe that Type II trail.

| Series | Name | The question it really asks |
| --- | --- | --- |
| CC1 | Control environment | Does leadership take this seriously, and does anyone own it? |
| CC2 | Information and communication | Do people know the rules, and does bad news travel? |
| CC3 | Risk assessment | Have you thought about what could go wrong, in writing? |
| CC4 | Monitoring activities | Do you check that your controls still work, and fix them when they don't? |
| CC5 | Control activities | Are your controls deliberate, documented and built into how work gets done? |
| CC6 | Logical and physical access | Who can get to what, and how do you know? |
| CC7 | System operations | Would you notice an attack, and what happens when you do? |
| CC8 | Change management | Are production changes authorized, tested and traceable? |
| CC9 | Risk mitigation | What happens when a vendor or a disaster hits you? |

Each criterion below has three parts: the outcome it expects in plain words, an implementation example for a small software company, and typical evidence. The "where companies slip" sections highlight gaps to look for in your own setup.

The examples are starting points, not a mandatory checklist. The Common Criteria do not prescribe one tool, policy set or review schedule for every company. Choose controls and frequencies that fit your risks, commitments and applicable obligations, then operate them as documented. The AICPA's points of focus help interpret the criteria; they are not separate requirements that every company must implement individually.

Evidence requests depend on your scope, controls and examination type. Agree them with your auditor. Completing this guide does not establish audit readiness or replace the system description and other work needed for a SOC 2 examination.

## CC1 Control environment: does leadership own this?

CC1 is about tone at the top. Five criteria ask whether leadership sets and follows clear standards, exercises oversight, assigns responsibilities, supports competent people, and holds them accountable. Technical safeguards need that foundation too.

### CC1.1 Integrity and ethical values

**What it expects.** Leadership demonstrates a commitment to integrity and ethical behavior, communicates standards of conduct, checks adherence, and acts on departures from those standards. Relevant contractors and vendor personnel need to be considered too.

**At a small SaaS company.** A two-page code of conduct in the handbook. Every new hire and contractor signs it in the HR tool during onboarding, and everyone re-signs once a year. There is a named person or an anonymous form for reporting concerns.

**Typical evidence.** The current code of conduct with its approval date, signed acknowledgments for a sample of people, and either a record of a handled violation or a statement that none happened.

### CC1.2 Board oversight

**What it expects.** The board or equivalent governing body exercises objective oversight of internal controls and has enough expertise to challenge management. The criterion addresses independence, but the AICPA recognizes that smaller, less complex businesses can meet the oversight objectives with simplified structures, without necessarily retaining independent board members.

**At a small SaaS company.** Document who exercises governance and how they review security risks, control failures and management's follow-up. A quarterly meeting with an agenda, decisions and tracked actions is one approach. An outside adviser can add expertise, but hiring one does not by itself establish effective oversight. Discuss how your arrangement meets the criterion with your auditor.

**Typical evidence.** A charter or policy naming who exercises oversight, their responsibilities and relevant expertise, meeting minutes, and evidence that decisions and corrective actions were followed up.

### CC1.3 Structure, reporting lines and responsibilities

**What it expects.** Management establishes clear structures, reporting lines, authority and responsibilities, with governance oversight. Those responsibilities cover the people and service providers involved in meeting the system's objectives.

**At a small SaaS company.** An org chart, a paragraph in the security policy naming the CTO as security owner, and a control list with accountable people or roles. Make clear who currently holds each role and who covers absences.

**Typical evidence.** The org chart, job descriptions for security-relevant roles, and the control ownership matrix.

### CC1.4 Competent people

**What it expects.** You attract, develop and retain people with the competence needed for their responsibilities. You identify skill gaps and address them through hiring, training, support or succession planning. Relevant service providers need suitable competence too.

**At a small SaaS company.** Role descriptions, structured interviews and a technical exercise where relevant. Background screening appropriate to the role and permitted by applicable law. Security awareness training at onboarding and yearly, with additional training for specialist roles. A backup for key security responsibilities when someone is unavailable.

**Typical evidence.** Hiring and screening procedures, records showing the required checks were completed for sampled hires, training completion records and plans for covering key roles. Share sensitive personnel evidence through the agreed audit process.

### CC1.5 Accountability

**What it expects.** The responsibilities from CC1.3 are enforced. Performance is reviewed, incentives do not undermine controls, and violations have consequences.

**At a small SaaS company.** Security responsibilities appear in job descriptions and performance reviews. Overdue control tasks get escalated to a manager. The handbook says what happens if you share credentials or bypass a control.

**Typical evidence.** The sanctions section of the handbook, a performance review template, and overdue-task or escalation reports from your compliance tool.

**Where companies slip on CC1.** Relevant contractors never receive or acknowledge the standards that apply to them. Governance meetings happen but security is never on the agenda. Controls are assigned to "engineering" with nobody accountable for getting them done.

## CC2 Information and communication: do people know the rules?

CC2 asks whether the information your controls run on is reliable, and whether the right people inside and outside the company know what is expected of them. It is the criterion that turns a policy folder into something people actually use.

### CC2.1 Reliable information for controls

**What it expects.** Your controls depend on reliable information: which servers exist, which users have access, where customer data flows. That information needs to be relevant, complete, accurate and timely enough for the control to work.

**At a small SaaS company.** An asset inventory reconciled with your cloud account and device management tool, whether it lives in a spreadsheet or a dedicated system. A one-page data classification scheme. A diagram showing where customer data enters, lives, and leaves. Checks that reports used in control reviews include the right systems and records.

**Typical evidence.** The asset inventory export with owners, the classification policy, and a dated data flow diagram. Report filters and reconciliations showing that information used in control reviews is complete and accurate, including relevant service accounts in an access review.

### CC2.2 Internal communication

**What it expects.** Staff receive the information they need to perform their control responsibilities: the system's objectives, relevant policies and changes, and ways to report concerns. Significant control issues also reach the people responsible for oversight.

**At a small SaaS company.** Policies live in one place everyone can find. New hires acknowledge them on day one. There is a Slack channel or email alias for reporting anything suspicious, and it is written in the incident policy. Security training runs at onboarding and once a year.

**Typical evidence.** The acknowledgment report, training records, and a screenshot of where the incident reporting instructions are published. The auditor may also ask an employee how they would report an incident.

### CC2.3 External communication

**What it expects.** Customers, vendors and partners are told what your system does, what you commit to, what they are responsible for, and how to reach you when something goes wrong.

**At a small SaaS company.** Terms of service and relevant agreements that state your commitments. A data processing agreement where applicable. A public security page or Trust Center, a monitored security@ address and a status page. Customer documentation explaining responsibilities such as managing their users and configuring available security settings.

**Typical evidence.** Relevant terms, agreements and notices, the security page, customer responsibility documentation, and communications about material changes or incidents where they occurred.

**Where companies slip on CC2.** The asset inventory is out of date. Nobody can say where the incident reporting channel is. There is no published way for an outsider to report a vulnerability.

## CC3 Risk assessment: have you written down what could go wrong?

CC3 is the hinge of the whole framework. Your controls are supposed to exist because of risks you identified, not because a template listed them. Four criteria ask you to state what you are protecting, find the risks to it, include fraud, and redo the exercise when things change.

### CC3.1 Clear objectives

**What it expects.** You cannot assess risk without a reference point. State what the system promises (uptime, confidentiality, data handling) and how much risk you are willing to carry.

**At a small SaaS company.** A short section in your system description listing your service commitments. A risk policy that defines the scoring scale and says what score counts as acceptable. A register of laws and contracts you must comply with.

**Typical evidence.** The risk methodology with its tolerance statement, the commitments section of the system description, and the compliance obligations register.

### CC3.2 Identify and analyze risks

**What it expects.** A real risk assessment: list threats and weaknesses, including ones coming from vendors, rate likelihood and impact, decide what to do about each one, and record what risk remains.

**At a small SaaS company.** A risk register with one row per risk: the asset, the threat, likelihood, impact, score, treatment, owner, residual score and review date. Refreshed at least yearly, with management sign-off. Pen test findings and vendor reviews feed into it.

**Typical evidence.** The risk register and methodology applicable during the examination period, records of reviews and approvals due under your process, and assessments of relevant vendor risks.

### CC3.3 Consider fraud

**What it expects.** Consider the potential for fraud when assessing risks to your objectives. Fraud is not only a finance topic: data theft, privilege abuse and unauthorized changes to records may be relevant. Assess plausible scenarios, including incentives, opportunities and attempts to bypass controls.

**At a small SaaS company.** Fraud risks in the register that match your business, such as insider data theft, privilege abuse or billing manipulation. Independent review of production code changes through branch protection. Administrative activity logged and reviewed, including actions by senior staff.

**Typical evidence.** Register entries tagged as fraud risks, the segregation of duties setup, and privileged activity review records.

### CC3.4 Assess significant change

**What it expects.** Identify and assess changes that could significantly affect internal controls. A cloud migration, a new critical vendor, a leadership change, a major incident or a relevant new regulation can trigger a fresh look at the risks and controls affected.

**At a small SaaS company.** The risk policy lists the triggers. Major change tickets carry a security impact question. Onboarding a new vendor creates a risk review. Someone owns watching for new threat classes.

**Typical evidence.** The trigger list in the policy, register entries added during the period with the triggering change noted, and a security impact assessment attached to a major change.

**Where companies slip on CC3.** The risk assessment was done once for the first audit and never touched again. Risks are generic template text with no link to real systems. Fraud never appears. Vendors are assessed in a separate spreadsheet that never meets the register.

## CC4 Monitoring activities: do you check your own controls?

CC4 asks whether you find out that a control has stopped working before the auditor does. Two criteria: run evaluations, and do something about what they find.

### CC4.1 Ongoing and separate evaluations

**What it expects.** Use ongoing evaluations, separate evaluations, or a combination to check whether the components of internal control are present and functioning. Choose their scope and frequency based on risk and change, and use people with suitable competence and objectivity.

**At a small SaaS company.** Scheduled checks of cloud configuration, MFA and laptop posture. Management reviews of missed offboarding steps, overdue tasks and unresolved findings. A periodic assessment of the wider control system, including governance and communication. Access reviews, restore tests and penetration tests can contribute evidence about particular safeguards, but do not cover the whole control system by themselves.

**Typical evidence.** The evaluation schedule and rationale, monitoring history, management reviews and assessment results, with findings and follow-up actions. Technical test reports where those tests form part of your approach.

### CC4.2 Evaluate and communicate deficiencies

**What it expects.** When monitoring, audits or tests find a problem, someone rates its severity, tells the person who can fix it, escalates to management or the board when it is serious, and tracks it until it is closed and verified.

**At a small SaaS company.** One findings register for everything: pen test issues, failed monitoring tests, audit observations, incident follow-ups. Each row has severity, owner, due date and status. Fix deadlines by severity. Open items reported to leadership quarterly.

**Typical evidence.** The findings register export, a management deck showing open deficiencies, a ticket trail from finding to verified fix, and the remediation deadline policy.

**Where companies slip on CC4.** Pen test findings sit in a PDF and are never tracked to closure. Alerts fire into a channel nobody watches. Leadership first hears about a control gap from the auditor.

## CC5 Control activities: are your controls deliberate?

CC5 is short but it is where the auditor tests whether your controls are a real system or a checklist you downloaded. Three criteria: controls trace back to risks, technology has its own layer of controls, and every control is backed by a policy and a procedure.

### CC5.1 Controls that address risks

**What it expects.** Select and develop controls that reduce risks to acceptable levels. Choose preventive or detective and manual or automated controls as appropriate. Separate conflicting duties where practical; where it is not, develop alternative controls that address the risk.

**At a small SaaS company.** The risk register links each risk to the controls that treat it, and each control links back. MFA and code review prevent, logging and access reviews detect. A short segregation of duties list: who can approve a deploy, who can grant access, and what compensates when the team is too small to split them.

**Typical evidence.** The risk-to-control mapping, the control library with type and owner, the segregation of duties setup, and a ticket showing a control was added because of a risk.

### CC5.2 General controls over technology

**What it expects.** Select and develop general controls over the technology that supports your objectives, including infrastructure, access and the acquisition, development and maintenance of systems. This criterion is the umbrella. More detail lives in CC6 to CC8.

**At a small SaaS company.** A list of the systems supporting the service and its controls, including relevant CI/CD, ticketing and HR tools. Assess other supporting tools based on their role in the examined system. Infrastructure as code with configuration monitoring. SSO and role-based access. A secure development lifecycle.

**Typical evidence.** The system inventory tied to processes and owners, the infrastructure-as-code repository, the access control policy, and the SDLC policy.

### CC5.3 Policies and procedures

**What it expects.** Put control activities into practice through policies that set expectations and procedures that explain how to carry them out. Assign responsibility, act in time, address problems and reassess whether the procedures still work. One policy can support several controls.

**At a small SaaS company.** Policies covering information security, access control, change management, incident response, vendors, data handling, continuity and acceptable use. Combine topics when that makes them easier to maintain; there is no required document count. Assign owners and review dates. Use runbooks for recurring tasks like access reviews and offboarding.

**Typical evidence.** The policy index with owners and review dates, sampled policies with approval history, runbooks for key controls, and the acknowledgment report.

**Where companies slip on CC5.** Controls copied from a template with no link to the risks. The chosen controls leave important risks untreated. Supporting SaaS tools that the controls depend on are overlooked. Policies still name people who left last year.

## CC6 Logical and physical access: who can get to what?

CC6 is the largest series. Eight criteria cover the full life of access: how it is protected, granted, scoped and removed, and how data is protected across devices, networks and software.

### CC6.1 Access security architecture

**What it expects.** Protect information assets through logical access safeguards that support your objectives. Identify and authenticate users and services, restrict access, and choose safeguards appropriate to the data and systems involved. Relevant design considerations include network boundaries, encryption and key management.

**At a small SaaS company.** SSO and MFA for human access to cloud, code and administrative systems. Suitable authentication and limited permissions for service accounts. Emergency access that remains usable during an identity-provider outage, with strong protection, logging and review. Encryption at rest and in transit with managed keys. An access policy and a security design review before a new component goes live.

**Typical evidence.** Identity provider screenshots showing MFA enforcement, the access policy, the asset inventory, and a design review record from the period.

### CC6.2 Granting and removing accounts

**What it expects.** Register users and services and authorize their access before issuing credentials, with approval from the asset owner or another authorized custodian. Remove access when it is no longer authorized, and periodically review whether access remains valid.

**At a small SaaS company.** Access requests recorded and approved by the designated approver. Provisioning linked to the HR system where possible. An offboarding checklist that disables access at the agreed departure time, revokes sessions and removes access in tools outside SSO. Immediate action for an involuntary termination or suspected compromise. Contractor access has a review or expiry date.

**Typical evidence.** Approval tickets for sampled new users, offboarding records for sampled leavers with timestamps against the termination date, and the HR leaver list reconciled with the user lists.

### CC6.3 Roles, least privilege and segregation of duties

**What it expects.** Having an account is CC6.2. What the account can do is CC6.3. Grant, change and remove permissions based on roles, responsibilities and least privilege. Address incompatible duties through separation or suitable alternative controls, and follow up on access that no longer fits the role.

**At a small SaaS company.** A role and permission matrix for production, cloud, code and key SaaS. Role changes go through a ticket, and permissions no longer needed are removed. No standing admin in the cloud; elevation is time-boxed. Developers cannot approve their own pull requests. Quarterly access reviews with documented decisions and any resulting access changes.

**Typical evidence.** The role matrix, access change tickets, the cloud IAM policy export, branch protection settings, and completed access reviews with evidence of follow-up changes where needed.

### CC6.4 Physical access

**What it expects.** Restrict physical access to facilities, equipment and protected information to authorized people. Remove access when it is no longer needed. Where a provider operates the facilities, understand its safeguards and the responsibilities that remain yours.

**At a small SaaS company.** Badge or key access and visitor records for an office, if you have one. Rules for protecting laptops and information at home or while traveling. Laptop return on the offboarding checklist. Review the cloud provider's relevant assurance documentation and identify the controls your company still needs to operate.

**Typical evidence.** The physical security policy, badge holder list, device return records for sampled leavers, and the provider report review.

### CC6.5 Disposal

**What it expects.** Before disposing of, releasing or reusing physical assets, remove or protect the information and software so that the next holder cannot access them without authorization. Choose and verify a sanitization method appropriate to the media and the sensitivity of the data.

**At a small SaaS company.** Encrypted laptops with a documented sanitization process before reassignment or disposal. Use an appropriate secure erase, cryptographic erase or destruction method, verify the outcome, and record it. Reinstalling the operating system or issuing a remote-wipe command alone is not proof of sanitization. For cloud resources, manage deletion and retention of volumes, snapshots and backups, and understand how the provider handles the underlying media.

**Typical evidence.** The disposal procedure, records identifying the asset, method, date and verified outcome, destruction certificates where used, and relevant cloud deletion records and provider assurances.

### CC6.6 Threats from outside

**What it expects.** Protect the system against threats from outside its boundaries. Restrict external access and use safeguards appropriate to the interfaces, information and risks involved.

**At a small SaaS company.** Deny-by-default security groups with no unrestricted public access to administrative or database ports. A WAF and rate limiting for relevant web interfaces. TLS for network communications and HSTS for web services. Administrative access to production through a protected path with MFA, while intended customer-facing services remain reachable.

**Typical evidence.** Security group rules with an explanation of each exposed port, WAF configuration, TLS evidence, and the remote access configuration showing MFA.

### CC6.7 Data in motion and on devices

**What it expects.** Data only moves where it is authorized to move and is protected while moving. That covers transfers, sharing, removable media and the endpoints that hold data.

**At a small SaaS company.** A data handling policy that says which classes of data can go through which channels. TLS on all integrations, SFTP or encrypted APIs for file exchange. External sharing restricted in the productivity suite, with alerts on bulk downloads. Storage buckets private by default. USB storage blocked or encrypted.

**Typical evidence.** The transmission section of the data handling policy, TLS configuration, sharing and DLP settings with a sample alert, and the bucket public access block.

### CC6.8 Unauthorized and malicious software

**What it expects.** Prevent unauthorized or malicious software from entering the environment, or detect it and take action. Select protections appropriate to the systems you operate, including how software is installed, changed and monitored.

**At a small SaaS company.** Restricted installation privileges or approved, logged elevation. Endpoint protection on supported laptops and servers, with suitable protections for other workloads. Production changes through a controlled pipeline, with a documented emergency path. Infrastructure as code with drift detection, and investigation of unapproved software or changes.

**Typical evidence.** Device management policy on admin rights, the endpoint detection console showing coverage and a sample detection, sampled production changes with approvals, and drift or integrity alerts.

**Where companies slip on CC6.** MFA on SSO but unprotected human access remains in cloud or code systems. Leavers removed from SSO but still in GitHub or cloud IAM. Everyone in engineering has production admin "for convenience". Access reviews find inappropriate access but nobody removes it. Remote teams overlook device recovery and physical safeguards. Contractors have broad data access without appropriate device protections.

## CC7 System operations: would you notice an attack?

CC7 connects five activities: find weaknesses, watch for anomalies, decide whether an event is an incident, respond, and recover. Keep enough of the record to show what was investigated, decided and done. Not every alert becomes an incident or needs a post-incident review.

### CC7.1 Find vulnerabilities and configuration drift

**What it expects.** Detect configuration changes that introduce vulnerabilities and exposure to newly discovered vulnerabilities. Establish what an acceptable configuration looks like and identify departures from it. Assess findings and address them through your vulnerability and change-management processes.

**At a small SaaS company.** A hardening baseline informed by relevant CIS Benchmarks for servers, containers and cloud accounts. Configuration checks that flag drift. Scheduled authenticated vulnerability scans where appropriate, dependency scanning in CI, and checks after significant changes or new threats. Remediation targets based on severity and exposure, with documented decisions for exceptions.

**Typical evidence.** The baseline, configuration and vulnerability reports, the monitoring schedule, and records of triage, fixes, verification and any justified exceptions.

### CC7.2 Monitor for anomalies

**What it expects.** Watch systems in operation, spot unusual activity, and triage it to decide whether it is a security event. Also make sure the monitoring itself keeps working.

**At a small SaaS company.** Central logging from infrastructure, application, identity provider and cloud control plane. A detection service with rules for the usual suspects: compromised credentials, insider misuse, external access, third parties, unknown devices. Endpoint detection on servers and laptops. A health check that alerts when a log source goes quiet.

**Typical evidence.** The logging standard, detection configuration showing rules and sources, sampled alerts with triage notes and outcome, and agent coverage reconciled to the asset inventory.

### CC7.3 Decide whether it is an incident

**What it expects.** Evaluate security events to determine whether they could or did prevent you from meeting service commitments and system requirements. Decide whether an incident has occurred and what action is needed. Assess affected data and notification obligations where relevant to the event, scope and applicable obligations.

**At a small SaaS company.** The incident policy defines "event" versus "incident" and severity levels. A triage checklist asks what systems, services and data were affected and whether applicable law or customer contracts require notification. Preserve triage decisions, including false-positive dispositions, in the monitoring system or incident tracker. A separate manual ticket for every raw alert is not necessary if your process retains a usable record.

**Typical evidence.** The classification criteria, event and triage records for the examination period, and sampled impact, escalation and notification assessments where relevant.

### CC7.4 Respond

**What it expects.** Respond to identified incidents through a defined process for understanding, containing, remediating and communicating about them. Assign responsibilities and review the response. Assess notification obligations and communicate as required. Address misconduct under applicable policies and law where warranted; involvement in an incident does not itself justify disciplinary action.

**At a small SaaS company.** An incident response plan assigning coordination, technical response, communications and access to legal advice. People may cover more than one role, with backups identified. A severity matrix with response targets. Runbooks for leaked cloud keys, credential compromise, malware and data exposure. The ability to isolate a host, revoke sessions and rotate secrets quickly.

**Typical evidence.** The plan and runbooks with review dates, the on-call schedule, sampled incident records showing timeline, containment, communications and closure, and any customer or regulator notifications sent.

### CC7.5 Recover

**What it expects.** Identify, develop and carry out activities to recover from security incidents. Restore trusted operations, investigate causes, reduce the risk of recurrence, communicate as needed and improve recovery procedures. Test whether your recovery approach works for relevant scenarios.

**At a small SaaS company.** Rebuild from trusted images or infrastructure as code, restore from verified backups and replace affected credentials. Post-incident reviews above a defined severity, with corrective actions tracked through change management. Scheduled tabletop and practical recovery exercises, including a restore test. A discussion exercise alone does not show that a backup can be restored.

**Typical evidence.** Post-incident review reports, corrective action tickets and the changes that closed them, recovery runbooks with evidence of a real restore, and the test plan with results.

**Where companies slip on CC7.** Scans run but findings never close. Alerts go to a channel nobody reads. There is no written difference between an event and an incident. Real incidents were handled ad hoc and the record does not match the plan. Root cause is recorded as "human error" with no control change. Lessons learned are written down but the plan never changes.

## CC8 Change management: are production changes controlled?

CC8 is a single criterion covering changes across the system. For a Type II examination, an auditor may select changes from the period and trace their authorization, testing, approval and implementation. Incomplete change records can prevent reliable sampling or leave control operation unsupported.

### CC8.1 Controlled changes

**What it expects.** Control changes to infrastructure, data, software and procedures through authorization, design or acquisition, configuration, documentation, testing, approval and implementation. Address incompatible responsibilities through separation or suitable alternative controls. Account for relevant security, confidentiality and privacy requirements when assessing changes.

**At a small SaaS company.** A change policy covering application code, infrastructure, configuration, relevant data changes and operating procedures. Pull requests with independent review, branch protection and controlled deployment permissions. CI tests and relevant security checks before release. An emergency path with defined authorization, records and follow-up review. Cloud console changes, security-sensitive feature flags and database migrations are recorded too. Where staffing limits separation of duties, document alternative safeguards and assess their adequacy with your auditor; a weekly retrospective review alone is not automatically sufficient.

**Typical evidence.** The change policy with its approval date, the complete list of production changes for the period, sampled pull requests showing author, reviewer, CI results, approval and deployment, and the branch protection and production access settings.

**Where companies slip on CC8.** A person can make and deploy changes without the review or other safeguards the control calls for. Infrastructure and configuration changes bypass the process that covers code. Emergency changes happen but are never recorded or reviewed. The change list cannot be reconciled to what actually reached production.

## CC9 Risk mitigation: disasters and vendors

CC9 connects back to the risk assessment in CC3. Two criteria ask what you have put in place to manage business disruption and the risks from vendors and business partners.

### CC9.1 Business disruption

**What it expects.** Identify, select and develop ways to reduce the risks from potential business disruptions. Match those measures to the impact on your services and commitments. Consider operational responses and whether risk transfer, such as insurance, would help with financial consequences.

**At a small SaaS company.** A business impact analysis naming critical services, dependencies and recovery targets. A continuity and disaster recovery plan covering relevant scenarios such as a cloud outage, key-person absence or critical vendor failure. Recovery options might include multiple availability zones, alternate suppliers or temporary manual workarounds. A crisis communication plan. Record the rationale for any insurance decision; buying a policy does not replace operational preparation.

**Typical evidence.** The business impact analysis, the plan with approval and review dates, the communication plan with contact lists, and the insurance summary or the documented decision not to insure.

### CC9.2 Vendors and business partners

**What it expects.** Assess and manage risks from vendors and business partners that could affect your system's objectives. Set appropriate requirements, evaluate performance and changes, address problems, and plan for ending the relationship. Tailor the depth of review and safeguards to the relationship's risks.

**At a small SaaS company.** A vendor inventory with owner, service, data shared, access, criticality and review dates. Reviews at onboarding, on a risk-based schedule and after relevant changes. For critical vendors, review available assurance: a SOC 2 report's scope, period, findings and customer responsibilities, or an ISO 27001 certificate's scope and validity with supporting information where available. These are different forms of assurance. Use suitable contracts, including data processing terms where applicable, incident communication and exit arrangements for access and data.

**Typical evidence.** The vendor policy, inventory and risk classifications, sampled due-diligence and ongoing review records, follow-up on issues, and relevant agreements and exit records.

**Where companies slip on CC9.** The continuity plan covers servers and ignores people, vendors and communication. The vendor inventory misses tools that handle relevant data or support critical processes. Reviews are overdue under the company's own schedule. SOC 2 reports are collected as PDFs but nobody checks their scope, findings or customer responsibilities.

## What runs through all 33 criteria

These five habits make many controls easier to operate and demonstrate. They support the work across the criteria; they do not replace it.

1. **Clear accountability.** Give each control, policy, risk and vendor an accountable person or role. If a role owns it, make clear who currently fills that role and who covers absences.
2. **Evidence covering the right time.** For Type II, retain evidence showing how controls operated throughout the examination period, according to their stated frequency. A policy approved before the period can still be valid: retain the version in force and records of required reviews. Earlier activity alone does not show operation throughout a later period, and a screenshot taken today does not prove last month's configuration. Preserve when an activity happened and what period a record covers, even if you export it later.
3. **Complete, accurate records for sampling.** Auditors may need lists of relevant users, changes, departures, vendors or incidents. Keep the scope, dates and report filters clear, and reconcile the lists to their sources. Missing records can leave a control unsupported. The consequences depend on the control, other available evidence and the auditor's assessment; they are not an automatic verdict on the whole examination.
4. **Findings followed through.** Track issues from tests, reviews and incidents to remediation or another documented, justified treatment decision. Record responsibility, timing and verification. Calling something "accepted risk" does not make an unmet commitment or legal obligation disappear.
5. **A review rhythm you can demonstrate.** Set frequencies and change-triggered reviews based on risk, commitments and control design. Annual policy reviews and quarterly access reviews are examples, not universal SOC 2 rules. Keep evidence that the reviews happened and that resulting actions were handled.

**How to use this guide.** Read the "where companies slip" section under each series and mark the gaps that sound familiar. For each criterion, ask: what would I hand the auditor tomorrow morning to explain our controls and show they worked? Record the control, accountable owner, evidence you have and next action. A missing document may be a documentation gap; a missing activity is an implementation gap. Work through both with your team and auditor.

## Sources and scope

This is AuditBadger's plain-language interpretation of the [AICPA 2017 Trust Services Criteria, with revised points of focus from 2022](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022). The 2022 changes revised the points of focus, not the criteria themselves. The implementation and evidence examples are illustrative and are not official AICPA wording or a complete audit request list.

Relevant references in TSP Section 100:

- Paragraphs .03-.07: outcome-based criteria and the contextual use of points of focus.
- Paragraphs .10-.15: categories, Common Criteria and scope.
- Paragraph .16: Type I and Type II examinations.
- CC1.2, footnote 15: simplified governance for smaller, less complex businesses.
- CC5.1: alternative controls where separation of duties is impractical.
- CC6.1-CC9.2: access, operations, change management and risk mitigation.

The reviewed AICPA text is also available in this [public copy of TSP Section 100](https://gccertification.com/wp-content/uploads/2024/06/AICPA-TSP-Section-100-Trust-Services-Criteria-2022.pdf). For the secure-disposal example in CC6.5, see [NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization](https://csrc.nist.gov/pubs/sp/800/88/r2/final).


## Put the guide to work

[Download the editable evidence gap worksheet](https://auditbadger.com/downloads/soc2-evidence-gap-worksheet.xlsx). All 33 criteria, space for your controls, evidence, gaps, owners and next actions. No email required.

[Download the PDF](https://auditbadger.com/downloads/soc2-common-criteria.pdf).

AuditBadger helps your team organize controls, owners and evidence. [See how it works](https://auditbadger.com/soc2/) or [discuss a gap with a founder](https://cal.com/mlitwiniuk/live-demo).