SOC 2 Deepdive

1. Overview

What SOC 2 Is

SOC 2 (System and Organization Controls 2) is an attestation engagement performed by a licensed CPA firm under the AICPA's attestation standards (SSAE 21, specifically AT-C section 105 and AT-C section 205). The CPA firm reports on whether the service organization's controls meet the Trust Services Criteria (TSC) relevant to one or more of five categories: Security, Availability, Confidentiality, Processing Integrity, and Privacy.

Who It Applies To

Any service organization handling customer data — particularly B2B SaaS, cloud services, data processors, and outsourced service providers that impact the security, availability, confidentiality, processing integrity, or privacy of customer information.

Outcome

An independent service auditor's report:

• SOC 2 Type I — opinion on the design and implementation of controls at a specific point in time.
• SOC 2 Type II — opinion on the design, implementation, and operating effectiveness of controls over a defined observation period (typically 3 to 12 months).

The report is not a certification — it is a CPA attestation. Security Consultants is not a CPA firm and does not issue SOC 2 reports; we prepare clients for the audit and represent the program through the engagement. For a buyer-friendly explainer, read our blog post What SOC 2 is (really), and how do you get there. For the prep work and remediation, see our SOC 2 compliance consulting service.

High-Level Goals and Risk Domains

• Demonstrate that customer data is protected against unauthorized access
• Show that committed service levels for availability are met
• Evidence that confidentiality and privacy commitments to customers are operationalized
• Provide an independent third-party opinion that enterprise buyers can rely on for vendor due diligence

‍2. Scope & Applicability

Typical In-Scope Elements

• Production infrastructure hosting customer data
• SaaS platforms and customer-facing APIs
• Identity and access management systems
• Security tooling: SIEM, EDR, vulnerability scanners, secret management
• Operational processes: change management, incident response, risk management, vendor management
• Employees and contractors with logical or physical access to production systems
• Vendors and subservice organizations supporting production or customer data processing

Common Out-of-Scope Elements

• Internal corporate systems not connected to service delivery
• Marketing websites (unless tied to customer authentication or data)
• HR systems (unless processing customer data)
• Personal devices outside corporate control (BYOD without MDM coverage)

Subservice Organizations — Carve-Out vs Inclusive Method

If your service relies on a subservice organization (for example, AWS, GCP, Azure, Snowflake, or a payment processor), you must disclose it in your System Description and choose how its controls are handled:

• Carve-out method: the subservice organization's controls are excluded from your report scope. You list the controls the subservice organization is expected to perform (the Complementary Subservice Organization Controls, or CSOCs) so report users understand the dependency. This is the most common choice.
• Inclusive method: the subservice organization's controls are tested as part of your audit. Requires their cooperation and is rarely used in practice.

Complementary User Entity Controls (CUECs)

The System Description must also disclose controls the user entity (your customer) is expected to implement to achieve the TSCs. Examples include enforcing strong password policies on accounts they manage, configuring SSO correctly, and reviewing audit logs you provide. These are listed in the report so customers know their responsibilities.

Assumptions and Dependencies

• Cloud infrastructure is configured to a baseline (CIS Benchmarks or vendor best practice)
• Identity provider supports SSO and MFA enforcement at the organizational level
• Engineering practices include change tracking and code review (git history, PR approval records)
• Vendor inventory is current and risk-tiered

‍

3. Core Principles (Trust Services Criteria)

The Trust Services Criteria were issued by the AICPA in 2017 and refreshed with points-of-focus updates in 2022. They are organized into five categories. Security is required in every SOC 2 engagement; the other four are added when relevant to the service commitments.

CategoryFocusSecurity (Common Criteria, CC1–CC9)Protect systems against unauthorized access, use, disclosure, modification, or destructionAvailability (A1)Ensure the system is operational and accessible per the entity's commitmentsConfidentiality (C1)Protect information designated as confidential from unauthorized disclosureProcessing Integrity (PI1)Ensure system processing is complete, valid, accurate, timely, and authorizedPrivacy (P1–P8)Manage personal information in line with the entity's privacy notice and AICPA privacy principles

Each criterion is supported by points of focus — specific control characteristics auditors look for when evaluating whether the criterion is met. The points of focus are guidance, not mandatory checklists, but auditors expect to see most of them addressed in some form.

‍

4. Control Breakdown

The structured summary below covers the Common Criteria (CC) categories and the four additional criteria.

CC1 — Control Environment

Purpose: Establish governance, structure, and top-level accountability.
Minimum Expectations: Defined roles and responsibilities; code of conduct; background checks; organizational oversight.
Evidence: Org charts, HR files, signed code of conduct, board minutes covering security oversight.
Common Gaps: No documented roles; no periodic HR checks; no evidence of management oversight.
Example: Annual leadership review of organizational responsibilities, documented in management review minutes.
Mapping: ISO 27001 Clauses 5 and 7.

CC2 — Communication & Information

Purpose: Ensure relevant security information is communicated internally and externally.
Minimum Expectations: Policies communicated to staff; security incident notification process; customer-facing commitments published.
Evidence: Acknowledgement records, training completion, communication logs.
Common Gaps: Stale policies, no acknowledgement workflow.
Mapping: ISO 27001 Annex A 6.3, 5.1.

CC3 — Risk Assessment

Purpose: Identify and manage risks to objectives.
Minimum Expectations: Documented risk methodology; risk register; treatment decisions; periodic review.
Evidence: Risk register, treatment plan, risk acceptance approvals.
Common Gaps: Risk register treated as a one-time exercise; no link to treatment actions.
Mapping: ISO 27001 Clauses 6.1, 8.2, 8.3. See our Risk Assessment service.

CC4 — Monitoring Activities

Purpose: Detect and respond to issues that affect controls.
Minimum Expectations: Continuous monitoring; periodic control self-assessment; internal audit program.
Evidence: Monitoring dashboards, internal audit reports, deficiency tracking.
Common Gaps: No internal audit cycle; alerts not tuned.
Mapping: ISO 27001 Clauses 9.1, 9.2.

CC5 — Control Activities

Purpose: Implement policies, procedures, and technology controls that mitigate identified risks.
Minimum Expectations: Policies translate to implemented controls; technology supports control objectives; segregation of duties where relevant.
Evidence: Policy documents, configuration baselines, segregation evidence, system reports.
Common Gaps: Policies exist but controls aren't enforced; manual workarounds proliferate.

CC6 — Logical and Physical Access

Purpose: Restrict access to systems and data.
Minimum Expectations: Identity lifecycle (provisioning, modification, de-provisioning); MFA; least privilege; periodic access reviews.
Evidence: Access provisioning tickets, quarterly access review attestations, MFA enrolment records.
Common Gaps: Slow de-provisioning; stale privileged access; inconsistent MFA enforcement.
Mapping: ISO 27001 Annex A 5.15–5.18, 8.2–8.5.

CC7 — System Operations

Purpose: Detect, respond to, and recover from security events.
Minimum Expectations: Logging and monitoring; incident response procedures; recovery testing.
Evidence: SIEM exports, incident records, post-incident reviews, DR test results.

CC8 — Change Management

Purpose: Control changes to infrastructure, data, software, and procedures.
Minimum Expectations: Documented change process; code review; testing; segregation between dev and production.
Evidence: Pull request approvals, change records, deployment logs.

CC9 — Risk Mitigation

Purpose: Identify, select, and develop risk mitigation activities, including vendor risk management.
Minimum Expectations: Vendor inventory; risk-tiered due diligence; ongoing vendor monitoring; business continuity planning.
Evidence: Vendor risk assessments, contractual security requirements, BCP test results.

Additional TSC Categories

Availability (A1) — Uptime SLAs, capacity planning, environmental safeguards, disaster recovery testing. Evidence: uptime metrics, DR test reports, capacity dashboards. ISO 27001 Annex A.5.30, A.8.13–A.8.14.

Confidentiality (C1) — Data classification, encryption, restricted access, secure disposal. ISO 27001 Annex A.5.12, A.8.10–A.8.12.

Processing Integrity (PI1) — Input validation, processing controls, output verification. Less common in ISO 27001 mapping.

Privacy (P1–P8) — Notice, consent, collection limits, use and retention, access rights, disclosure, security, monitoring and enforcement. Maps closely to ISO 27701 and GDPR principles.

‍

5. Minimum Requirements (Non-Negotiable)

Mandatory Documents

• System Description (the central narrative artifact — see Section 8)
• Information security policy and supporting policies (access, incident, DR, change management, vendor, encryption, data retention)
• Risk assessment and treatment plan
• Asset inventory
• Data flow diagrams covering each in-scope system
• Vendor management documentation, including any carved-out subservice organizations
• Incident response plan and incident log
• Disaster recovery and business continuity plan, plus annual test results
• Complementary User Entity Controls (CUECs) — documented expectations of your customers
• Complementary Subservice Organization Controls (CSOCs) — documented expectations of carved-out subservice organizations

Mandatory Processes

• Background checks (or equivalent screening)
• Onboarding / offboarding with timely access provisioning and revocation
• Quarterly access reviews with documented attestation
• Change management with code review and approval
• Patch management with risk-based SLAs
• Vulnerability scanning (at least monthly; weekly preferred)
• Security awareness training, annual minimum, plus role-specific training

Technical Controls (Baseline)

• MFA on all administrative and remote access
• Encryption in transit (TLS 1.2 or 1.3) and at rest (KMS-managed keys)
• Centralized logging, monitoring, and alerting on critical events
• Endpoint protection on company-managed devices
• Backups and tested recovery procedures

Recurrence

• Annual risk assessment
• Quarterly access reviews
• Annual policy reviews
• Annual incident response tabletop or live test
• Annual DR test
• Continuous vulnerability scanning and patching
• Type II only: evidence must be retained for the full observation period — typically 3 to 12 months — for every recurring control

‍

6. Technical Implementation Guidance

Infrastructure Security

• Harden cloud resources using CIS Benchmarks (AWS Foundations, Azure, GCP, Kubernetes)
• Apply security groups and least-privilege network rules
• Use infrastructure-as-code with policy-as-code guardrails (Terraform + OPA, AWS Config, Azure Policy)

Access Control

• Enforce SSO and MFA at the identity provider
• Role-based access with periodic recertification
• Automated de-provisioning on offboarding (SCIM or scripted)
• Privileged access reviewed monthly; standard access quarterly

Logging & Monitoring

• Centralized log aggregation across cloud, application, and identity logs
• Alerts tuned for critical events (privilege escalation, anomalous access, security tool tampering)
• Minimum 90 days online retention; 12 months total retention is typical

Vulnerability Management

• Weekly automated scans of cloud infrastructure and applications
• SLA-based remediation: critical within 30 days, high within 60, medium within 90
• External penetration testing at least annually

Backup & DR

• Immutable backups with offline or cross-region copies
• Recovery time and recovery point objectives defined per system
• Annual DR failover test with documented results

Encryption

• TLS 1.2+ for data in transit (1.3 preferred); HSTS enforced
• KMS-managed keys for at-rest encryption with documented key rotation
• Customer-managed keys offered where contractually required

Tooling Suggestions (Neutral)

• SIEM: any cloud-native or third-party SIEM with TSC-relevant detections
• Compliance automation: Drata, Vanta, Secureframe, ControlMap — useful for evidence collection, never a substitute for control design
• EDR / vulnerability management: per organizational preference

‍

7. Policy & Procedure Requirements

Typical documents include:

• Information Security Policy
• Access Control Policy
• Asset Management Policy
• Logging & Monitoring Policy
• Incident Response Plan
• Disaster Recovery & Business Continuity Plan
• Change Management Policy
• Vendor Risk Management Policy
• Encryption Policy
• Data Retention & Disposal Policy
• Privacy Policy (if P criteria included)
• System Description with CUECs and CSOCs

Each document should define:

• Purpose
• Scope
• Roles and responsibilities
• Processes and procedures
• Controls and expectations
• Review frequency (typically annual minimum)

For organizations also pursuing ISO 27001, most of these documents can be reused with minor scope additions. See our ISO 27001 consulting service for the dual-standard approach.

‍

8. Audit Evidence & Verification

The System Description (DC1–DC9)

The System Description is the central narrative artifact in a SOC 2 engagement. Auditors test controls described in it; report users (your customers) read it to understand your service. The AICPA's Description Criteria (DC sections) define what it must cover:

• DC1 — Types of services provided
• DC2 — Principal service commitments and system requirements
• DC3 — Components of the system: infrastructure, software, people, procedures, data
• DC4 — System incidents that occurred during the observation period that were the result of controls not operating effectively
• DC5 — Applicable trust services criteria and the related controls designed to provide reasonable assurance
• DC6 — Complementary User Entity Controls (CUECs) — controls assumed in the design that user entities must implement
• DC7 — Complementary Subservice Organization Controls (CSOCs) — if using the carve-out method, the controls expected of the subservice organization
• DC8 — Specific criteria not relevant to the service organization, with justification
• DC9 — Significant changes during the observation period (Type II only)

What Auditors Request

• System description
• Architecture diagrams
• Policy acknowledgements
• Access provisioning tickets and review records
• Change management tickets
• Incident records and post-incident reviews
• Security tool exports (vulnerability scans, EDR alerts, SIEM detections)
• HR onboarding and offboarding evidence
• Vendor risk assessments and contractual security commitments

Formats

• Screenshots (timestamped, showing the test date and the system being evidenced)
• Tickets (Jira, Linear, ServiceNow exports)
• Logs (CSV exports from SIEM or cloud-native logging)
• Meeting notes (management review, incident reviews, risk reviews)

Sampling

Type II samples are typically 25–40 items per control area, larger for access reviews and change management. The CPA firm selects samples randomly across the observation period.

Common Remediation Items

• Missing approval workflows on changes
• Poor evidence timestamps (no proof the control ran on the right date)
• Unclear control ownership
• Inconsistent access provisioning
• Stale CUECs or CSOCs that don't match current reality

An independent pre-audit review — usually framed as a SOC 2 readiness assessment or as part of an internal audit program — catches these issues before the CPA firm does.

‍

9. Implementation Timeline Considerations

Typical Duration

• Type I: 4–12 weeks from kickoff to report, depending on the maturity of existing controls
• Type II: the audit itself runs in weeks after the observation period, but the observation period adds 3–12 months. A typical first Type II report covers a 3-month observation period; subsequent reports usually cover 12 months

Type I to Type II Bridge

Many organizations issue a Type I to demonstrate readiness to customers, then transition to Type II once they have 3+ months of operating evidence. The transition does not restart the engagement — the controls described in the Type I report become the controls tested in the Type II observation period.

Bridge Letter

Between Type II reports, customers may ask for a bridge letter from management (and sometimes counter-signed by the CPA firm) confirming no material control changes since the last report. Management bridge letters can be prepared in-house; CPA-signed bridge letters require the CPA firm's involvement.

Milestones

• Scoping and TSC selection
• Gap assessment
• Remediation
• System Description drafting
• Evidence collection setup
• Audit readiness review
• Audit fieldwork (CPA firm)
• Report issued

Dependencies

• Policy completion
• Hiring or access to security roles (often supported by a vCISO engagement)
• Cloud baseline maturity
• Subservice organization reports available (AWS, GCP, Azure SOC 2 reports are public)

‍

10. Ongoing Security BAU Requirements

• Quarterly access reviews with documented attestation
• Continuous vulnerability scanning and risk-based remediation
• Monthly patching cadence
• Annual security awareness training plus role-specific training for engineers and admins
• Annual risk assessment refresh
• Annual DR and incident response test
• Vendor risk reviews on a risk-tiered cadence
• Asset inventory updates as systems are added or retired
• Logging, alerting, and on-call response to security events
• Evidence collection for Type II observation periods (continuous, not bursty)

‍

11. Maturity Levels

Minimum Compliance

• Policies in place and acknowledged by staff
• Controls implemented but largely manual
• Basic tooling for logging, MFA, vulnerability scanning
• Manual reviews and evidence collection

Intermediate

• Automated user provisioning and de-provisioning
• Mature monitoring with tuned alerts
• Documented procedures with named owners
• Compliance automation tool integrated for evidence collection

Advanced

• Full automation across IAM, CI/CD, and monitoring
• Continuous compliance with controls and evidence checked daily
• Predictive risk analytics and threat intelligence integration
• Integrated SOC 2, ISO 27001, ISO 27701, and AI governance evidence

‍

12. FAQs

Is SOC 2 mandatory?

No. SOC 2 is not a regulatory requirement — it is a customer-driven assurance standard. Enterprise B2B customers and procurement teams routinely require it before signing.

How long is a SOC 2 report valid?

A SOC 2 report covers a specific point in time (Type I) or a defined observation period (Type II). Customers typically treat the report as "current" for 12 months after the as-of date, often supplemented by a bridge letter for the gap until the next report.

Do we need all five Trust Services Criteria?

Only the Security (Common Criteria) is required. Availability, Confidentiality, Processing Integrity, and Privacy are added when the service commitments make them relevant. Most B2B SaaS engagements include Security plus Availability and Confidentiality.

Is SOC 2 the same as ISO 27001?

No, but there is substantial control overlap — usually 65–75% of the underlying controls map across both. Many organizations build a single security program and report against both standards. See the ISO 27001 service page for the dual-standard approach.

Can we use a compliance automation tool?

Yes — Drata, Vanta, Secureframe, ControlMap and similar tools accelerate evidence collection significantly. They are not a substitute for control design, gap remediation, or audit preparation.

How long does it take to get SOC 2 Type I vs Type II?

A Type I engagement runs 4–12 weeks for a typical B2B SaaS, depending on current maturity. A Type II requires an additional observation period of 3–12 months on top of that — you cannot compress the observation period, since it is the entire point of a Type II.

What does a SOC 2 report cost?

Costs split into two parts. The CPA firm's audit fee typically runs $20,000–$60,000 for a Type II, depending on scope and report complexity. Consulting and remediation costs vary based on the gap between current state and audit readiness — this is where Security Consultants engagement scope is set after the initial gap assessment.

Do we need a CPA firm or can our consultant write the report?

The SOC 2 report can only be issued by a licensed CPA firm. Consultants prepare the System Description, remediate control gaps, and represent the program through the engagement. We coordinate with the CPA firm but do not issue the report.

What's the difference between SOC 1, SOC 2, and SOC 3?

SOC 1 covers controls relevant to financial reporting (ICFR). SOC 2 covers controls relevant to the Trust Services Criteria (security, availability, confidentiality, processing integrity, privacy). SOC 3 is a public-facing general use report based on the same SOC 2 examination — shorter, no detailed control descriptions, suitable for marketing or trust centers.

What's a bridge letter?

A bridge letter (or gap letter) covers the period between the end of one SOC 2 Type II observation period and the start of the next, confirming no material control changes occurred. Management can issue these directly; CPA-signed versions require the audit firm's involvement.

What are CUECs and CSOCs?

CUECs (Complementary User Entity Controls) are controls your customers must implement to achieve the TSCs — for example, configuring SSO correctly. CSOCs (Complementary Subservice Organization Controls) are controls expected of carved-out subservice organizations — for example, AWS physical security. Both must be disclosed in your System Description.

When should we transition from Type I to Type II?

As soon as you have 3+ months of operating evidence for the controls described in your Type I report. Most B2B SaaS issuers do Type I in months 1–3, then start a Type II observation period that ends 6–12 months later.

‍

13. Summary

SOC 2 provides independent assurance that a service organization protects customer data and operates effective controls aligned with the AICPA's Trust Services Criteria. Achieving SOC 2 attestation requires well-defined governance, documented processes, technical safeguards, consistent operational discipline, and a credible System Description that auditors can test and customers can rely on.

With proper scoping, systematic remediation, and continuous evidence collection through the observation period, organizations can obtain and maintain Type I and Type II reports with predictable timelines and cost.

To scope an engagement, book a call from the SOC 2 consulting service page, or talk to us about combining SOC 2 with ISO 27001, ISO 27701, or ISO 42001 for AI-handling services. For the practical case for stacking AI governance on top of an existing ISMS, see our deep-dive blog post How to integrate ISO 42001 with ISO 27001 without rebuilding your ISMS.

‍