The Complete Guide to SOC 2 Compliance

SOC 2 has become the de facto security standard that B2B SaaS companies, cloud service providers, and technology vendors need to win enterprise deals. But the path from "we need a SOC 2 report" to "we have a clean SOC 2 report" is more complex than most organizations expect when they start.

This guide covers what SOC 2 actually measures, how the audit process works, the difference between Type I and Type II reports, what auditors are looking for in practice, common failures that derail readiness programs, and how to scope your program so you get the report you need without building unnecessary overhead.

---

What SOC 2 Is (and What It Is Not)

SOC 2 - System and Organization Controls 2 - is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA). A SOC 2 report represents an independent auditor's assessment of whether a service organization's controls meet the Trust Service Criteria relevant to its services.

SOC 2 is not a certification. Unlike ISO 27001, which results in a certificate valid for three years, a SOC 2 report is a point-in-time assessment (Type I) or a period-of-time assessment (Type II). The report documents what was audited, what controls were tested, and whether those controls were designed and/or operating effectively.

SOC 2 is also not a fixed set of requirements. The Trust Service Criteria are flexible by design - the specific controls an organization implements to meet the criteria depend on the nature of its services and systems. This flexibility is both SOC 2's greatest strength and a common source of confusion for organizations approaching it for the first time.

---

Trust Service Criteria

SOC 2 reports are organized around five Trust Service Criteria (TSC). The Security criterion (also called the Common Criteria) is required in every SOC 2 engagement. The remaining four are included only if they are relevant to the services being provided.

Security (Required)

The Security TSC - formally "Common Criteria" - governs whether the system is protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information.

The Security TSC is organized into nine logical control groupings (CC1 through CC9):

• CC1 - Control Environment: Commitment to integrity, ethical values, organizational structure, accountability
• CC2 - Communication and Information: Internal and external communication of information quality requirements
• CC3 - Risk Assessment: Identification, analysis, and management of risks
• CC4 - Monitoring Activities: Ongoing monitoring, evaluation, and communication of deficiencies
• CC5 - Control Activities: Control selection and development, deployment through policies
• CC6 - Logical and Physical Access Controls: Restriction and management of access to information assets
• CC7 - System Operations: Detection and response to security events
• CC8 - Change Management: Authorization, design, implementation, and communication of changes
• CC9 - Risk Mitigation: Management of risks from vendors and business partners

Availability

Covers whether systems are available for operation as committed. Relevant for services where downtime has material impact on customers. Requires monitoring, incident response procedures, and business continuity planning.

Processing Integrity

Covers whether system processing is complete, accurate, timely, and authorized. Relevant for transaction processing systems, financial applications, and any service where data processing accuracy is a customer commitment.

Confidentiality

Covers whether information designated as confidential is protected throughout its lifecycle. Relevant for services handling confidential business information, trade secrets, or NDA-protected data.

Privacy

Covers whether personal information is collected, used, retained, disclosed, and disposed of in conformity with commitments in the entity's privacy notice and AICPA's Generally Accepted Privacy Principles. Relevant for services processing consumer personal data.

---

Type I vs. Type II Reports

The most common question in early SOC 2 conversations is whether to pursue a Type I or Type II report.

Type I: Design of Controls at a Point in Time

A Type I report assesses whether controls are suitably designed to meet the Trust Service Criteria as of a specific date. There is no evidence requirement for control operation - the auditor evaluates whether, on the report date, the right controls exist and are designed appropriately.

Type I reports are faster (typically 4-8 weeks of audit work after readiness preparation) and less expensive than Type II. They signal that an organization has built the right control structure, but they do not demonstrate that controls have operated consistently over time.

When a Type I makes sense:

• You need a report quickly (customer demand, deal requirement)
• You have recently implemented your control environment and cannot demonstrate 6+ months of operation
• You are using Type I as a stepping stone to Type II

When a Type I is insufficient:

• Enterprise customers require Type II as a vendor qualification requirement (increasingly common)
• You are responding to a security questionnaire asking for evidence of sustained control operation
• You are trying to differentiate on security maturity, not just having completed an audit

Type II: Operating Effectiveness Over an Audit Period

A Type II report assesses both the design of controls and their operating effectiveness over a defined audit period, typically 6 or 12 months. Auditors sample control evidence from throughout the period to assess whether controls operated consistently as designed.

Type II reports are what sophisticated buyers actually require. A 12-month Type II period signals sustained security operations, not just a well-documented control structure at a single point in time.

The Type II audit period: Your audit period begins the day you commit to starting it. Many organizations begin their audit period the day they finish a readiness assessment. Building 6 or 12 months of evidence while simultaneously remediating gaps is resource-intensive - starting readiness work early pays dividends.

---

The SOC 2 Audit Process

1. Scope Definition

Before any audit work begins, you define the scope of the engagement:

• System description - What systems, services, and infrastructure are in scope? Clear boundary definition is critical. Include what you need to include; exclude what genuinely falls outside your service delivery.
• Trust Service Criteria selection - Which criteria apply? Most first-time engagements cover Security only. Adding Availability or Confidentiality is common. Privacy is less common for B2B SaaS.
• Subservice organizations - Do you rely on AWS, Azure, or GCP for infrastructure? Do you use Salesforce, Stripe, or other third parties? Subservice organization treatment (carve-out vs. inclusive) affects scope and evidence requirements.

2. Readiness Assessment

A readiness assessment (gap assessment) maps your current controls against the applicable Trust Service Criteria and identifies gaps. Good readiness work produces:

• A clear picture of what evidence exists and what needs to be built
• A prioritized remediation roadmap
• A realistic timeline to audit readiness
• Decisions about scope that affect the overall audit complexity

Do not skip a readiness assessment. Organizations that go directly from "we need a SOC 2" to "let's start the audit" consistently encounter surprises that extend timelines and increase costs.

3. Remediation

Gaps identified in readiness must be addressed before or during the audit period. Common remediation work includes:

• Writing or updating policies (information security policy, access control policy, change management policy, incident response plan, business continuity plan)
• Implementing or improving technical controls (MFA everywhere, vulnerability scanning, encryption, access reviews)
• Standing up monitoring and alerting
• Building evidence collection processes (access review documentation, change approval records, security training records, vendor review documentation)

4. Audit Fieldwork

The auditor conducts fieldwork by requesting evidence across all in-scope controls. For Type I, evidence is as-of the report date. For Type II, evidence is sampled across the audit period.

Evidence types auditors typically request:

• Screenshots and exports from identity platforms (Okta, AWS IAM) showing access controls
• Change tickets showing approval workflows
• Vulnerability scan results and remediation tracking
• Security training completion records
• Incident records and post-mortems
• Vendor risk assessment documentation
• Penetration test reports

5. Report Issuance

After fieldwork, the auditor produces the SOC 2 report. The report includes:

• Management's description of the system
• Auditor's opinion on the description's fair presentation
• Auditor's opinion on control design (and operating effectiveness for Type II)
• A list of controls tested and results

---

Common SOC 2 Failures and How to Avoid Them

1. Weak System Description

The management's description of the system is the foundation of the SOC 2 report. Auditors test whether your controls match what you describe. Vague descriptions create ambiguity; overly narrow descriptions exclude controls customers care about.

Write a system description that accurately reflects how your service delivers value, where data flows, and what controls govern it. Review it with your auditor before fieldwork begins.

2. Failing Access Reviews

Periodic user access reviews are one of the most commonly tested controls in SOC 2 and one of the most frequently failed. Requirements: reviews must occur on a defined frequency, cover all in-scope systems, be documented, and show evidence of remediation when exceptions are found.

Organizations that conduct reviews informally - verbal confirmation that access is appropriate - cannot produce the documentation auditors require.

3. Change Management Gaps

Not every change goes through the change management process. Emergency changes happen without documentation. Infrastructure changes made directly in AWS without a ticket are common. Auditors sample change records and test whether the process was followed consistently, including for exceptions and emergency changes.

4. Undocumented Vendor Risk

Most organizations have more vendors with data access than they realize. A vendor management program requires: an inventory of vendors, risk classifications, documented due diligence for high-risk vendors, BAAs or security addenda where required, and evidence of periodic reviews.

5. Policy-Reality Gaps

Policies say "quarterly access reviews" but reviews happen annually. Policy says "all changes are reviewed by two engineers" but solo deployments happen. Auditors look for evidence that policies are followed in practice, not just written. If your policy describes a process you do not actually follow, fix the policy or fix the process - but align them before the audit.

---

Scoping Decisions That Affect Your Audit

Carve-out vs. Inclusive for Cloud Infrastructure

If your service runs on AWS, you can either:

• Carve out AWS (auditor notes that you rely on AWS, customers review AWS's own SOC 2 independently)
• Include AWS as a subservice organization (you demonstrate that you have implemented user entity controls that complement AWS's controls)

Most B2B SaaS companies use the carve-out approach for infrastructure providers. This is simpler and appropriate as long as you address the complementary user entity controls (CUECs) that AWS specifies in its own reports.

Production vs. Non-Production Scope

Development and staging environments often do not need to be in scope. If you have strong environment separation and no customer data in non-production, you can often scope these out and reduce audit complexity.

Personnel Scope

Not all employees are in scope for all controls. Security training applies to all. Access controls apply to employees with access to in-scope systems. Be precise about who has access to what when defining scope.

---

Timeline Expectations

Phase	Duration
Readiness assessment	2-4 weeks
Remediation	4-12 weeks (depends on gap depth)
Type I audit fieldwork	4-6 weeks
Type II observation period	6-12 months
Type II audit fieldwork	6-8 weeks
Report issuance	2-4 weeks after fieldwork

Total from start to Type II report: 10-18 months for organizations starting from a low baseline. Organizations with mature security practices already in place can move faster - but rushing the process results in failed controls and qualified opinions.

---

How DarkRock Helps

DarkRock's SOC 2 practice is grounded in operational experience on both sides of the audit relationship. We have seen what auditors test, what evidence formats work, and what control structures survive examination.

Readiness Assessments - We conduct structured gap assessments against the applicable Trust Service Criteria, producing a prioritized remediation plan and realistic audit timeline. No surprises in fieldwork.

Policy and Procedure Development - We write policies that describe what you actually do, not generic templates that create policy-reality gaps. Policies are reviewed for testability - if a control is difficult to evidence, we flag it before audit.

Technical Control Implementation - We help implement the technical controls that underpin SOC 2: access control configurations, vulnerability management programs, encryption standards, monitoring and alerting.

Audit Preparation and Evidence Management - We organize and review evidence packages before auditor request, reducing back-and-forth and accelerating fieldwork.

Ongoing Compliance Support - SOC 2 is not an annual project - it is a continuous program. We provide fractional compliance support to maintain control operation between audits.

The organizations that achieve clean SOC 2 reports do so because they build programs, not just audit responses. DarkRock helps you build the program.

---

Ready to start your SOC 2 journey? Contact DarkRock for a readiness assessment scoped to your environment.