A SOC 2 Compliance Guide to the SOC 2 Standard

The SOC 2 standard is an information security compliance framework developed by the American Institute of Certified Public Accountants (AICPA) for service organizations that store, process, or transmit customer data. It defines criteria for managing this data based on five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. A SOC 2 audit results in an attestation report issued by a licensed CPA firm, which provides independent assurance that an organization’s internal controls are designed and operating effectively to meet its commitments and system requirements.

What Is the SOC 2 Standard

Unlike prescriptive regulations such as PCI DSS, the SOC 2 standard is a flexible framework. It does not provide a rigid checklist of controls. Instead, it allows organizations to design and implement controls that are specifically tailored to their business operations, technology stack, and the service commitments made to customers. The flexibility means you have to work out how to apply the framework’s principles to your own environment.

The entire audit is based on the Trust Services Criteria (TSCs). The AICPA mandates that every SOC 2 audit must evaluate controls against the Security criterion, also known as the Common Criteria. This set of criteria, including specific requirements like CC6.1 (Logical Access Control) and CC8.1 (Change Management), forms the baseline for the audit. An organization then adds any of the other four criteria (Availability, Processing Integrity, Confidentiality, and Privacy) to the audit scope based on its service offerings and contractual commitments to customers.

The Business Impact of a SOC 2 Report

For service organizations, particularly in B2B SaaS, FinTech, and HealthTech, a SOC 2 report is part of enterprise readiness. It is a main way to show potential and existing customers your security posture. It answers many of the questions in vendor security questionnaires, which are often a bottleneck in the sales cycle. Without a SOC 2 report, enterprise deals can stall or be delayed, because it is a common prerequisite for vendor onboarding.

The value extends beyond sales:

• Market Differentiation: A clean SOC 2 report can set you apart from competitors that have not been audited.
• Reduced Sales Cycles: A SOC 2 report answers security and compliance questions up front, which removes friction from procurement; see prioritizing SOC 2 to accelerate deals.
• Improved Internal Security Posture: Preparing for the audit means implementing and documenting formal controls and identifying vulnerabilities, which can reduce the risk of a data breach.

Why This Matters for SOC 2 Compliance

The standard dictates how controls must be designed, implemented, and evidenced. Misinterpreting it can lead to gaps, wasted effort on irrelevant controls, and ultimately a qualified opinion. A properly scoped SOC 2 program gives enterprise buyers the assurance they ask for in vendor reviews. The SOC 2 compliance guide follows that program from the first scoping decision to the issued report.

The Five Trust Services Criteria

The SOC 2 standard is structured around the five Trust Services Criteria (TSCs). These are the specific benchmarks against which an auditor evaluates an organization’s system and controls. The five criteria are Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Selecting the TSCs is a scoping decision. The Security criterion (also called the Common Criteria) is mandatory for all SOC 2 audits. The other four are optional and must be included if they are relevant to the services provided or have been promised to customers in contracts or Service Level Agreements (SLAs). An incorrect scope can result in an audit that is either insufficient for customer needs or unnecessarily broad and expensive. In CBIZ’s 2024 SOC Benchmark Study of 73 SOC 2 reports, Confidentiality appeared in 64.4% and Availability in 75.3%.

Security: The Mandatory Foundation

The Security criterion is the core of every SOC 2 report and addresses whether a system is protected against unauthorized access (both logical and physical), unauthorized use, and unapproved modification. It contains the “Common Criteria,” a set of foundational controls that apply universally across all five TSCs.

An auditor will request evidence of effective controls across the in-scope environment, such as:

• Access Controls (CC6 series): Evidence of logical access controls, including user authentication (CC6.1), restriction of access to authorized users (CC6.2), and periodic review of access rights. Physical access controls for facilities and workstations (CC6.4, CC6.5) are also tested.
• Network and System Monitoring (CC7 series): Proof of controls to monitor the system, including detection of security events (CC7.2) and response procedures for security incidents (CC7.3).
• Change Management (CC8.1): A formal process for authorizing, designing, developing, testing, approving, and implementing changes to infrastructure, data, software, and procedures.

Availability

The Availability criterion concerns whether the system is available for operation and use as committed or agreed. This is not about achieving 100% uptime but about meeting specific SLAs.

With this criterion in scope, you need evidence of business continuity and disaster recovery practices. An auditor will examine controls related to A1.2, which covers system backup processes, storage of backups, and recovery testing. They will ask for proof of performance monitoring, disaster recovery plans, and successful failover tests. The goal is to show you can meet your committed uptime and recover from disruptions.

Processing Integrity

The Processing Integrity criterion addresses whether system processing is complete, valid, accurate, timely, and authorized. This applies to services that perform transactions or critical computations, such as a financial platform or data analytics tool.

For example, a payroll service with Processing Integrity in scope would need to prove that its system correctly calculates taxes and deductions for every employee, processes payments exactly as submitted, and generates accurate reports. This relates to criterion PI1.2, which requires the entity to implement controls over processing activities.

Auditors will want evidence of data validation checks, input-output reconciliation procedures, and quality assurance (QA) testing, and will verify that the system functions as intended and that data integrity is maintained throughout its lifecycle. For a deeper analysis, see this guide on the SOC 2 Trust Services Criteria.

Confidentiality and Privacy

While often confused, these two criteria are distinct in the SOC 2 standard.

Confidentiality applies to information designated as “confidential” by agreement or law. This can include intellectual property, business plans, or sensitive customer data. The criterion focuses on the organization’s ability to protect this data from unauthorized disclosure. For SOC 2 compliance, this means implementing controls like data encryption (both in transit and at rest) and strict access controls, as required by C1.1 and C1.2.

Privacy applies specifically to Personally Identifiable Information (PII). It evaluates how an organization collects, uses, retains, discloses, and disposes of personal information in conformity with its privacy notice and the criteria set forth in the AICPA’s Privacy framework (P series). If an organization handles any consumer data, it should expect to demonstrate compliance with Privacy criteria like P3.1 (Notice and Communication) and P6.1 (Use, Retention, and Disposal).

For a more detailed comparison, see our guide on SOC 2 trust services criteria.

The Five Trust Services Criteria Explained

A properly scoped audit produces a report that meets customer requirements.

SOC 2 Type 1 vs. Type 2: What’s the Real Difference?

The choice between a Type 1 and a Type 2 report affects the audit timeline, the cost, and the report’s value to buyers.

A SOC 2 Type 1 report evaluates the design of an organization’s security controls at a single point in time. An auditor provides an opinion on whether the controls, on paper, are suitably designed to meet the relevant Trust Services Criteria.

A SOC 2 Type 2 report evaluates the operating effectiveness of those controls over a period of time, typically 3 to 12 months. The auditor tests whether the controls were consistently functioning as designed throughout this observation period.

Enterprise buyers increasingly treat SOC 2 as a prerequisite for doing business. If you are choosing between the two report types, see our guide on whether to start with a Type 1 or a Type 2.

The Value of a SOC 2 Type 1 Report

A Type 1 report is a useful first step. It gives an auditor’s opinion on the design of your controls, and it is faster and less expensive to obtain than a Type 2.

A Type 1 report is useful for:

• Meeting Initial Due Diligence Requirements: For startups or companies new to compliance, it can satisfy initial vendor security requests and demonstrate a commitment to security.
• Identifying Design Gaps: The process formally identifies weaknesses in control design, which gives you a list to fix before a Type 2 audit.
• Signaling Compliance Intent: It tells prospects and partners that the organization is working toward full SOC 2 compliance.

The Assurance of a SOC 2 Type 2 Report

A SOC 2 Type 2 report is what most enterprise customers demand. It gives a higher level of assurance because it tests whether controls operate effectively over time, not only whether they are designed correctly.

A Type 2 report is the difference between having a policy for employee offboarding and providing evidence that, for a sample of terminated employees over a six-month period, all system access was revoked within the 24-hour SLA defined in that policy.

To test operating effectiveness, an auditor will perform sampling. For a control like CC8.1 (Change Management), an auditor will select a sample of change requests from systems like Jira or GitHub from the observation period and verify that each one followed the documented approval, testing, and deployment process. Any deviation is an audit exception.

Comparing Type 1 and Type 2

A Type 1 can serve as a stepping stone, but the end goal for most companies is a Type 2 report, which is the assurance enterprise customers require before signing contracts.

The SOC 2 Audit Process and Timelines

The audit is a structured project with distinct phases. A poorly planned audit often leads to scope creep, evidence-gathering scrambles, and a strained relationship with the audit firm.

The Key Phases of a SOC 2 Audit

The process runs from initial planning to final report delivery, and each phase builds on the last, ending in the auditor’s formal opinion.

The typical phases:

1. Scoping: The organization and its chosen audit firm define the audit’s boundaries. This includes selecting the appropriate Trust Services Criteria (TSCs) and identifying the specific systems, data, people, and processes that will be subject to evaluation.
2. Readiness Assessment (Gap Analysis): An auditor or consultant performs a “mock audit” to compare the organization’s existing controls against the selected TSCs. The output is a gap analysis report detailing where controls are missing or deficient.
3. Remediation: The organization’s internal team works to address the gaps identified. This involves implementing new controls, writing formal policies, deploying security tools, and training employees. Document these fixes, because the auditor will ask for them.
4. Observation Period (for Type 2): For a SOC 2 Type 2 report, the organization must demonstrate that its controls are operating effectively over a sustained period, typically 3 to 12 months. During this window, evidence of control operation must be continuously collected and organized.
5. Audit Fieldwork & Reporting: The auditors conduct their formal testing by requesting and reviewing evidence samples from the observation period. They interview key personnel and validate control performance. Upon completion, they draft the SOC 2 report, which is then finalized and issued.

The timeline below shows how these phases unfold.

A Type 1 provides a point-in-time attestation, while a Type 2 requires a longer commitment to show sustained compliance.

A Realistic Timeline and Critical Milestones

Rushing the process can cause audit exceptions and qualified opinions.

The most common point of failure is underestimating the remediation phase. A control gap discovered during the formal audit is a potential exception; a gap identified during the readiness assessment is simply a task to be completed.

A sample project plan with milestones:

• Months 1-2 (Readiness & Scoping):
  • Finalize audit scope and select TSCs with the audit firm.
  • Complete the readiness assessment and receive the gap analysis report.
  • Develop a detailed remediation plan, assigning ownership and deadlines for each gap.
• Months 3-8 (Remediation & Observation Period Begins):
  • Implement new policies, procedures, and technical controls.
  • Begin collecting operational evidence (e.g., new hire checklists, change management tickets, vulnerability scan reports).
  • Conduct internal audits to ensure controls are operating as designed before the formal audit.
• Months 9-11 (Observation Period Continues):
  • Maintain consistent evidence collection and organization.
  • Prepare evidence artifacts for auditor review.
  • Schedule formal audit fieldwork with the CPA firm.
• Month 12 (Fieldwork & Report Issuance):
  • Auditors conduct formal testing and request evidence samples.
  • The internal team responds to auditor inquiries and provides additional evidence as needed.
  • Review the draft report for accuracy and receive the final, signed SOC 2 report.

A plan like this makes it easier to allocate resources, plan the budget, and keep leadership informed.

Common SOC 2 Gaps and How to Remediate Them

Expect control gaps to turn up during the readiness assessment. Fixing these common weaknesses early helps you reach a clean audit opinion without last-minute scrambles. The gaps often come from basic process failures rather than complex technical issues, and they can lead to audit exceptions if not addressed.

Informal Employee Onboarding and Offboarding

A frequent gap is the lack of a formalized, repeatable process for managing user access as employees join, change roles, or leave the organization. This affects core logical access controls under CC6.1 (Logical Access Security) and CC6.2 (User Access Management). An auditor will test this by comparing HR records of terminations with logs showing when system access was actually revoked. A delay between termination and deactivation is a clear control failure.

An ex-employee retaining access to sensitive systems is a major security risk and a clear audit exception. You must be able to prove that access is granted based on the principle of least privilege and revoked in a timely manner.

How to Remediate It:

• Create Role-Based Access Control (RBAC) Policies: Document the specific systems and permissions required for each job role.
• Use a Ticketing System for Audit Trails: Mandate that all access requests, modifications, and revocations are tracked in a system like Jira or ServiceNow. This creates an immutable record for auditors.
• Enforce and Document Offboarding SLAs: Establish a strict policy for access revocation upon termination (e.g., within 24 hours) and use ticket timestamps to prove consistent adherence.

Inconsistent Change Management

Another common failure is an ad-hoc approach to deploying changes to production systems. When developers can push code or modify infrastructure without formal review and testing, it introduces significant risk of outages and security vulnerabilities. This fails CC8.1, which requires a formal change management process.

Without a formal change management process, you cannot prove to an auditor that changes are authorized, tested, and approved before being deployed. Auditors will sample production changes and look for evidence of each step in your documented process. A single unapproved change can result in an exception.

How to Remediate It:

• Document a Formal Change Management Policy: Clearly define the lifecycle of a change: request, peer review, automated/manual testing, management approval, and deployment.
• Enforce Separation of Duties: The individual who writes the code must not be the one who approves and deploys it to production.
• Use System-Enforced Controls: Use features in tools like GitHub or GitLab, such as protected branches and required pull request approvals, to build the control directly into the development workflow.

Lack of Formal Vendor Management

Organizations often focus on internal security but neglect the risks posed by third-party vendors. Engaging a new vendor that handles sensitive data without conducting a formal security review is a major gap related to CC9.2, which covers vendor risk management.

Your organization is responsible for the security of customer data, even when it is handled by a third party. An auditor will expect to see a formal process for assessing and managing the risks associated with your critical vendors.

How to Remediate It:

• Develop a Vendor Risk Management Policy: Classify vendors into tiers based on their access to sensitive data and define the minimum security due diligence required for each tier.
• Conduct Pre-Contract Security Reviews: Before onboarding any critical vendor, review their security documentation (e.g., their SOC 2 report, ISO 27001 certificate) and ensure a Data Processing Addendum (DPA) is in place.
• Perform Annual Vendor Reviews: Vendor risk management is an ongoing process. Re-evaluate the security posture of critical vendors at least annually to ensure they remain compliant.

Formalizing and documenting these procedures strengthens your security posture and produces the evidence an auditor needs to see.

Choosing the Right SOC 2 Auditor

The choice of CPA firm affects the audit experience, the timeline, and how useful the report is. A misaligned auditor can add friction and delays, while a good fit can give useful guidance.

Key Auditor Evaluation Criteria

Evaluate an audit firm’s operational practices, not just its brand name. You want a firm that understands your business and can run the audit efficiently.

Key questions to ask potential auditors include:

• Industry Expertise: “How many B2B SaaS companies have you audited? Do you understand our cloud-native environment (AWS/GCP/Azure)?” An auditor with relevant experience provides contextual, actionable advice instead of generic checklists.
• Evidence Collection Process: “What platform do you use for evidence collection and communication? Can we see a demo?” Modern audit portals can streamline evidence submission compared to email and spreadsheets.
• Process for Handling Exceptions: “If you identify a control failure during fieldwork, what is your process for communication and remediation?” A collaborative partner will work with you to understand the issue, whereas a less engaged firm may simply document the failure.
• Audit Team Composition: “Who will be our primary point of contact, and what is their level of experience?” Direct access to a senior auditor gets you clear answers faster.

Finding the Right Fit for Your Business

ISO 27001 and other frameworks have value, but the SOC 2 standard remains the de facto requirement for technology companies selling into the US market, especially in regulated sectors like FinTech and HealthTech. SOC2Auditors.org provides tailored matches with vetted firms based on budget, timeline, and industry focus. Our guide on how to choose your SOC 2 auditor has more detail, or you can browse the SOC 2 auditor directory to compare firms directly.

A well-chosen auditor makes the process smoother and gives you a report with the level of assurance your customers expect.

Using the SOC 2 Report to Win Deals

The goal of a SOC 2 audit for most organizations is to use the final report in sales: to win larger enterprise deals, enter new markets, and build customer trust.

SOC 2 as an Ongoing Program

SOC 2 works better as an ongoing program than as a one-time project, with security and compliance built into how the company operates. Some organizations also work with cybersecurity compliance services that build trust for guidance beyond audit execution.

Connecting the Audit to Your Bottom Line

A SOC 2 report gives the sales team a direct answer to the security due diligence questions that often stall enterprise deals, which can shorten sales cycles. Describe it as an attestation report rather than a certificate (see is SOC 2 a certification), and check where to get the official SOC 2 logo before putting a badge on your site.

---

Tell us your scope once and we return 3–10 ballpark quotes from matched firms, free and anonymized: get SOC 2 audit quotes.