SOC 2 (System and Organization Controls 2) is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates an organization's controls relevant to security, availability, processing integrity, confidentiality, and privacy.
Continue your mission
# SOC 2 Type II
SOC 2 (System and Organization Controls 2) is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates an organization's controls relevant to security, availability, processing integrity, confidentiality, and privacy. A SOC 2 Type II report provides assurance that these controls were not only designed appropriately (Type I) but operated effectively over a defined period, typically 6 to 12 months.
SOC 2 has become the de facto trust standard for SaaS companies, cloud service providers, managed service providers, and any B2B organization that processes, stores, or transmits customer data. When an enterprise buyer evaluates a vendor, "Do you have a SOC 2 Type II report?" is often the first security question asked. A current SOC 2 Type II report opens doors. The absence of one closes them.
SOC 2 is not a certification. It is an attestation. A CPA firm (the auditor) examines the organization's controls against the AICPA's Trust Services Criteria (TSC) and issues a report that expresses an opinion on whether those controls are suitably designed and operating effectively. The report is the auditor's professional opinion, not a pass/fail score. That said, a "qualified" or "adverse" opinion (indicating material deficiencies) is functionally equivalent to failure in the marketplace.
SOC 2 evaluates controls across five Trust Services Criteria. Security is always included. The other four are optional, selected based on the organization's services and customer expectations:
Security (Common Criteria). Required for every SOC 2 engagement. Covers the organization's ability to protect information and systems against unauthorized access, unauthorized disclosure, and damage. The Common Criteria (CC1 through CC9) address control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. Security is the foundation. Every SOC 2 report includes it.
Availability. The system is available for operation and use as committed or agreed. Relevant for organizations whose customers depend on uptime: SaaS platforms, cloud infrastructure, managed services. Availability criteria address system monitoring, incident response, disaster recovery, and business continuity.
Processing Integrity. System processing is complete, valid, accurate, timely, and authorized. Relevant for organizations that process transactions, calculations, or data transformations on behalf of customers: payment processors, data analytics platforms, financial services technology.
Confidentiality. Information designated as confidential is protected as committed or agreed. Relevant for organizations that handle confidential business information (trade secrets, financial data, intellectual property) beyond what the Security criteria cover. Confidentiality criteria address data classification, encryption, access restrictions, and secure disposal.
Privacy. Personal information is collected, used, retained, disclosed, and disposed of in accordance with the organization's privacy notice and applicable regulations. Relevant for organizations that collect and process personal data. Privacy criteria align with common privacy principles (notice, choice, consent, collection limitation, use limitation, access, disclosure, retention, disposal).
Most B2B SaaS companies pursue SOC 2 with Security + Availability. Organizations handling sensitive data add Confidentiality. Organizations processing personal data add Privacy. Processing Integrity is less commonly included unless the organization's core service involves data processing accuracy.
Type I evaluates whether controls are suitably designed and implemented at a specific point in time. It answers: "As of this date, do appropriate controls exist?" Type I is faster to achieve (no observation period) and is sometimes used as a stepping stone to Type II. Its limitation: it proves controls exist. It does not prove they work over time.
Type II evaluates whether controls operated effectively over a defined observation period (typically 6 to 12 months, with 12 months being the standard expectation for mature organizations). It answers: "Over this period, did the controls function as designed?" Type II requires the auditor to test controls through the observation period: sampling evidence, reviewing logs, examining incident records, and verifying that controls were not just configured but consistently applied.
Enterprise buyers and security-conscious customers expect Type II. Type I is viewed as an interim step, acceptable for early-stage companies pursuing SOC 2 for the first time but insufficient for organizations that have been operating for more than a year.
Scoping. Define the system boundaries: which services, infrastructure, data, and personnel are in scope. The scope should be as narrow as practically defensible. A broader scope means more controls to implement, more evidence to collect, and more audit hours. The scope must cover the services described to customers but should not include internal systems unrelated to customer service delivery.
Readiness assessment (optional but recommended). A pre-audit evaluation that identifies gaps between current controls and the Trust Services Criteria. The readiness assessment is the dress rehearsal: it reveals what the auditor will find before the auditor finds it, giving the organization time to remediate. CDA's RGA-D01 mission (Compliance Readiness Audit, 24 hours) serves this function.
Evidence collection. Throughout the observation period, the organization collects evidence that controls are operating: access review records, change management approvals, incident response documentation, vulnerability scan reports, training completion records, monitoring dashboards, and configuration verification. Evidence collection is the most operationally intensive aspect of SOC 2 because it is continuous. Every control must have documented evidence of consistent operation for the entire observation period.
Audit fieldwork. The CPA firm's audit team examines the evidence, tests controls through sampling, interviews personnel, and evaluates whether the controls meet the Trust Services Criteria. Fieldwork typically takes 2 to 6 weeks depending on scope and organizational complexity.
Report issuance. The auditor issues the SOC 2 Type II report containing: management's description of the system, the auditor's opinion on whether controls were suitably designed and operating effectively, a detailed description of each control tested, the test procedures performed, and the results. If exceptions are found (controls that did not operate effectively during the observation period), they are documented in the report. Exceptions do not automatically result in a qualified opinion, but material or pervasive exceptions do.
The most frequently audited control areas across the Common Criteria:
Access control (CC6). User provisioning and deprovisioning, role-based access, MFA, privileged access management, access reviews. This is where IAT domain controls are tested.
System operations (CC7). Monitoring, alerting, incident detection and response, vulnerability management. This is where TID and SPH domain controls are tested.
Change management (CC8). Change request, approval, testing, deployment, and rollback procedures for systems in scope. Changes without proper approval are audit exceptions.
Risk mitigation (CC9). Vendor management, business continuity, disaster recovery. This is where RGA domain controls are tested.
Logical and physical access (CC6). Encryption, network segmentation, physical access to data centers, endpoint security. This is where DPS and SPH domain controls are tested.
SOC 2 Type II is a market requirement for B2B technology companies. Enterprise procurement teams include SOC 2 in vendor security assessments. RFPs require it. Security questionnaires ask for it. Partner agreements reference it. For a SaaS company selling to mid-market and enterprise customers, SOC 2 Type II is not optional. It is the price of admission.
The absence of a SOC 2 report does not mean the organization is insecure. It means the organization cannot demonstrate its security posture to customers through an independent, recognized assessment. In a market where buyers evaluate dozens of vendors, the vendor with a SOC 2 report has a structural advantage over the vendor without one.
A SOC 2 Type II report from a reputable CPA firm provides third-party validation that the organization's security controls are real, operational, and independently verified. This trust reduces friction in sales cycles, accelerates procurement decisions, and strengthens customer retention. Customers who have seen the SOC 2 report and reviewed the controls have a factual basis for trust rather than relying on the vendor's self-assessment.
The annual SOC 2 cycle creates a forcing function for continuous improvement. Each year's audit observation period requires the organization to maintain controls consistently. Gaps found in one year's audit must be remediated before the next year's observation period. The audit cycle prevents the compliance decay that occurs when organizations achieve a one-time certification and then drift. SOC 2 is not a one-time achievement. It is an annual commitment.
First-time SOC 2 Type II typically requires 9 to 18 months from initial readiness assessment to report issuance: 3 to 6 months for gap remediation and control implementation, followed by a 6 to 12 month observation period, followed by 2 to 6 weeks of audit fieldwork. Cost varies by scope and auditor: $30,000 to $100,000+ for the audit itself, plus internal costs for implementation, evidence collection, and audit coordination.
Subsequent annual audits are less expensive (the foundation exists) but still require sustained operational investment in evidence collection and control maintenance throughout the observation period.
SOC 2 sits in the RGA (Risk Governance and Assurance) domain of the Planetary Defense Model. RGA is the strategic envelope: it ensures the governance structures exist to sustain operational controls over time. SOC 2 is the assurance mechanism that proves those controls to external stakeholders.
CDA's Perpetual Compliance Assurance (PCA) methodology directly addresses the operational burden of SOC 2. "Compliance is not an event. It is a state." Organizations that treat SOC 2 as an annual project (scramble to collect evidence before the audit, relax after the report is issued) experience the worst of both worlds: high stress during audit prep and control decay between audits. PCA replaces this cycle with continuous evidence collection, automated control monitoring, and perpetual audit readiness.
The mapping between SOC 2 Common Criteria and PDM domains:
| Common Criteria | PDM Domain | Key Controls | |----------------|-----------|-------------| | CC6 (Logical/Physical Access) | IAT, DPS | MFA, RBAC, PAM, encryption, access reviews | | CC7 (System Operations) | TID, SPH | SIEM monitoring, incident response, vulnerability management, endpoint security | | CC8 (Change Management) | SPH | Change request/approval, testing, deployment procedures | | CC9 (Risk Mitigation) | RGA | Vendor management, BCP/DR, risk assessment |
Four TOP missions connect directly to SOC 2:
CDA's approach to SOC 2 differs from conventional compliance consultancies in one way: we build the operational controls, not just the documentation. A compliance consultancy writes the policies and procedures. CDA implements the IAT controls (MFA, PAM, access reviews), the SPH controls (endpoint hardening, configuration management), the TID controls (SIEM, monitoring, incident response), and the DPS controls (encryption, data classification) that the SOC 2 audit will test. When the auditor tests whether MFA is enforced for all users, CDA has already deployed it through IAT-B03. When the auditor tests whether vulnerability scanning occurs, CDA has already built the program through VSD-B01. The compliance documentation reflects operational reality because CDA builds both.
Word count: 2,118
CDA Theater missions that address topics covered in this article.
Written by Evan Morgan
Found an issue? Help improve this article.