SOC 2 Type 2 controls are the security policies, procedures, and technical safeguards a service organization implements to satisfy the AICPA’s Trust Services Criteria, tested by an independent CPA firm over a sustained observation window of three to twelve months. A Type 1 report asks whether controls exist on a single date. A Type 2 report asks whether they actually worked, day after day, for the entire period. That is a much harder question, and it is why the controls have to be designed as a system rather than a checklist.
The controls themselves fall into five Trust Services Criteria categories, with the Security category (and its nine Common Criteria groups) required in every engagement. What an auditor tests depends on which categories are in scope, but the pattern of scrutiny is consistent: access management, system monitoring, change control, encryption, personnel practices, and the evidence trail that shows each control operated without gaps.
The Five Trust Services Criteria Categories
Every SOC 2 audit is built on the Trust Services Criteria published by the AICPA’s Assurance Services Executive Committee. The current version is the 2017 Trust Services Criteria with Revised Points of Focus published in 2022.1AICPA & CIMA. 2017 Trust Services Criteria (With Revised Points of Focus – 2022) Only one of the five categories is required.
- Security (mandatory). Protects systems and data against unauthorized access, both digital and physical. Every SOC 2 report includes this category, and the Common Criteria (CC1 through CC9) are the control points that satisfy it.
- Availability. Confirms that systems stay operational and accessible in line with service level agreements. Common for organizations with meaningful uptime commitments.
- Processing integrity. Verifies that system processing is complete, accurate, timely, and authorized. Payment processors and analytics platforms often add this.
- Confidentiality. Covers protection of information designated as confidential, such as trade secrets, intellectual property, or business plans that go beyond personal data.
- Privacy. Addresses how personal information is collected, used, retained, disclosed, and disposed of. Frequently added by organizations handling consumer data.
An organization picks its optional categories based on the services it provides and what customers expect to see covered. A cloud hosting provider almost always includes availability. A healthcare data processor often adds confidentiality and privacy. The auditor examines only the categories selected, so a narrow scope can leave visible gaps when a customer reads the final report.
The Nine Common Criteria (CC1 Through CC9)
The mandatory Security category is organized into nine groups of criteria. Every control an organization implements maps to one or more of them.1AICPA & CIMA. 2017 Trust Services Criteria (With Revised Points of Focus – 2022)
- CC1 – Control environment. Leadership’s commitment to security: board oversight, ethical standards, organizational structure, and accountability.
- CC2 – Communication and information. How the organization identifies, captures, and shares security-relevant information internally and externally.
- CC3 – Risk assessment. Identifying and analyzing risks that could prevent the organization from meeting its objectives, including new threats from technology changes, regulatory shifts, or business growth.
- CC4 – Monitoring of controls. Tracking control effectiveness through automated alerts, dashboards, and periodic evaluations like internal audits.
- CC5 – Control activities. The specific actions and mechanisms that enforce policies, such as approval workflows, segregation of duties, and audit trails.
- CC6 – Logical and physical access controls. How access to systems, data, and facilities is granted, reviewed, and revoked. In practice, this category draws the most auditor scrutiny.
- CC7 – System operations. Detecting and resolving anomalies, incidents, and failures. Vulnerability management and incident response live here.
- CC8 – Change management. Authorizing, testing, and deploying changes to systems, infrastructure, and applications without introducing new vulnerabilities.
- CC9 – Risk mitigation. Vendor management, business continuity planning, and ongoing review of the security program.
A single control often satisfies several criteria at once. A quarterly access review, for instance, touches CC5 as a control activity, CC6 as access management, and CC4 as monitoring. Treating each CC group as a separate checklist misses the point; the criteria describe a connected system, and auditors evaluate it as one.
Controls Auditors Actually Test
Knowing the criteria is not the same as knowing what the auditor will pull evidence for. The following control areas generate the most testing and the most exceptions.
Logical and Physical Access
Logical access controls restrict digital entry to sensitive systems. Auditors expect multi-factor authentication on all administrative accounts and on any access to production environments containing customer data. Role-based access ensures employees can only reach the systems required for their job, and quarterly access reviews catch permissions that should have been revoked when someone changed roles or left. This is where auditors find the most exceptions, usually because access is granted promptly and revoked slowly.
Physical access controls supplement digital protections. Data centers and server rooms should require badge readers, biometric scanners, or both, with visitor logs, camera footage, and entry records as the audit trail. When the organization uses a colocation facility or cloud provider, the physical obligations may shift to that provider, but the organization still has to show it monitors the relationship.
System Operations and Incident Response
Automated monitoring tools track performance, flag unusual behavior, and alert security teams when something deviates from baseline. An intrusion detection system nobody checks is worse than useless, because it creates a documented record of ignored warnings. Auditors want evidence that alerts were triaged and resolved, not merely generated.
Incident response plans define who does what when a security event occurs. The plan itself is table stakes. What matters for Type 2 is evidence the plan was exercised during the observation period, whether through tabletop exercises, simulated incidents, or actual events with response timelines, root cause analysis, and remediation on file.
Change Management
Every modification to production systems should move through a controlled process: a formal request, peer code review, approval by someone other than the developer, and documented deployment. Auditors sample changes made during the audit period and check each one for the required approvals. Emergency changes are permitted, but they need retroactive documentation and approval within a defined timeframe. Skipping paperwork on “quick fixes” is how organizations accumulate exceptions.
Encryption
Encryption at rest and in transit is a baseline expectation. Most organizations use AES-256 for data at rest, which is one of three key lengths specified in the federal Advanced Encryption Standard.2National Institute of Standards and Technology. Federal Information Processing Standards Publication 197 – Advanced Encryption Standard (AES) For data in transit, TLS 1.2 or higher is standard. Auditors verify that encryption is configured correctly and applied consistently, not just that an encryption policy exists in a handbook.
Vulnerability Management
The Trust Services Criteria do not explicitly mandate penetration testing or vulnerability scanning, but auditors routinely expect evidence the organization can identify and remediate weaknesses. Annual penetration tests and regular vulnerability scans satisfy criteria under CC4 and CC7 by showing that controls are evaluated and system deviations are detected. Retain the scope, methodology, final report, remediation tickets, and retest results. An 18-month-old penetration test with open findings reads as a red flag rather than compliance.
Personnel and Organizational Controls
Technical controls draw most of the attention, but the auditor spends real time on the people side. CC1 evaluates whether the organization hires competent individuals and holds them accountable, and that translates into concrete documentation.
Background checks for employees, contractors, and vendors with access to systems and data address CC1.1 (integrity and ethical values) and CC1.4 (commitment to competent personnel). The auditor will select specific employees during the examination and request the corresponding records. SOC 2 does not prescribe exactly what a background check must include, but the organization needs a documented policy and evidence it follows the policy consistently.
Security awareness training is required for all employees with system access, with training records archived for the full audit period. Auditors check completion rates and content relevance. Organizational charts showing clear lines of authority within IT and security demonstrate the segregation of duties required under CC5. When one person can write code and push it to production without independent approval, the conflict gets flagged immediately.
Documentation and Evidence Collection
Before the audit, the organization compiles evidence mapping each implemented control to the criteria it satisfies. That mapping is where preparation either pays off or falls apart.
Core documents include a control matrix listing every control activity and the criteria it satisfies, a formal risk assessment identifying threats and mitigating controls, and current versions of security policies covering acceptable use, data classification, and incident response. Employee handbooks covering security expectations and consequences for violations serve as evidence that the organization communicates its standards internally.
System-generated evidence is the bulk of what auditors review: login logs, access attempt records, change management tickets, alert histories, and administrative action logs covering the full observation period. Automated compliance platforms can pull this evidence continuously, which is more reliable than exporting six months of logs the week before the audit.
Vendor management contracts and service level agreements demonstrate oversight of third parties. When the organization relies on a subservice provider like a cloud hosting platform, the SOC 2 report addresses that relationship through either the inclusive method, which incorporates the provider’s controls into the report, or the carve-out method, which excludes the provider’s controls but describes how the organization monitors them. Most organizations use the carve-out approach and reference their provider’s own SOC 2 report.
How the Auditor Tests Controls
A SOC 2 examination must be performed by a licensed CPA firm operating under AICPA attestation standards, specifically SSAE 18 (including AT-C Section 205 for examination engagements). Internal security teams, consultants, and non-CPA assessors cannot issue a valid SOC 2 report. The firm must remain independent and cannot audit controls it helped design or implement.
The auditor uses four testing methods: inquiry (interviewing the people who operate the control), observation (watching them do it), inspection (reviewing documented evidence), and re-performance (independently executing the control to confirm it produces the expected result).
Sampling is central. Rather than testing every occurrence of every control, the auditor selects a representative sample from the observation period.3Public Company Accounting Oversight Board. AS 2315 – Audit Sampling For a control that operates daily, auditors typically pull 25 to 30 samples across the audit window. Weekly controls might require 10 to 15. Monthly controls usually need three to five. If any sampled instance fails, the auditor expands the sample to determine whether the issue is isolated or systemic. A handful of exceptions does not automatically doom the report, but a pattern will.
What the Auditor’s Opinion Means
The report ends in one of four opinion types.
- Unqualified. Controls were fairly presented and operated effectively throughout the observation period. Minor findings may exist but did not prevent the organization from meeting its objectives. This is what customers want to see.
- Qualified. Material issues affected specific criteria but were not widespread. The report typically reads “except for” a particular deficiency, and it raises questions during vendor due diligence.
- Adverse. Substantial and pervasive deficiencies, meaning report users cannot rely on the organization’s controls. Lost contracts and failed sales cycles often follow.
- Disclaimer. The auditor could not gather enough evidence to form a conclusion, often because management restricted access or documentation was insufficient. Not technically a failure, but a signal that something prevented the audit from completing normally.
Keeping the Report Current
A SOC 2 Type 2 report is generally considered valid for twelve months from the end of the observation period. Because the audit itself takes weeks to months after the observation window closes, the report is often already partially stale by the time it is issued. Annual renewal cycles are therefore essential rather than optional.
When a gap opens between the expiration of one report and the issuance of the next, organizations use a bridge letter to cover the interim. A bridge letter is a self-attestation that the controls described in the previous report continue to operate effectively. The industry standard is that a bridge letter should cover no more than three months.
SOC 2 reports are restricted-use documents, not marketing materials. They can be shared with current customers, prospective customers, their advisors, and regulators, typically under a non-disclosure agreement. Organizations that want something for broader audiences issue a SOC 3 report, which is a general-use summary.
One section deserves particular attention from anyone receiving a report: the complementary user entity controls. These are controls the service organization expects its customers to implement on their own side, such as enforcing strong passwords for user accounts or restricting who can access the service. If a customer ignores those obligations and a security incident occurs, the service provider’s report does not cover the gap. The controls work as a system, and both sides have responsibilities.