What Is SOC 2? A Guide for Accounting and Audit Teams

Finance and audit professionals encounter SOC 2 from multiple angles: managing readiness internally, testing controls as part of an engagement, and reviewing vendor reports. Understanding the framework matters across all of them.

This guide breaks down the five Trust Services Criteria, the difference between Type I and Type II reports, how SOC 2 compares to SOC 1, and where internal audit teams fit into the picture.

What is SOC 2?

SOC 2 stands for System and Organization Controls 2. It’s a framework developed by the American Institute of Certified Public Accountants (AICPA) that governs how service organizations manage and protect customer data.

A few important distinctions upfront. SOC 2 is an attestation, not a certification. An independent CPA firm examines a service organization’s controls and issues a report with an opinion on whether those controls meet the AICPA’s Trust Services Criteria. The output is an auditor’s opinion on how well the organization’s controls are designed and, in the case of a Type II report, how effectively they operated over time.

SOC 2 is widely used in the United States and is increasingly required by enterprise buyers, partners, and investors as a baseline for vendor trust. Any organization that stores, processes, or transmits customer data may be asked to provide a SOC 2 report during vendor due diligence or procurement.

The Five Trust Services Criteria

SOC 2 is structured around five Trust Services Criteria (TSC), originally published by the AICPA in 2017 and updated with revised points of focus in 2022. These criteria define the areas auditors evaluate during a SOC 2 engagement.

1. Security (Common Criteria)

Security is required for every SOC 2 audit. It covers protection against unauthorized access to systems and data. The Security criteria, labeled CC1 through CC9, map directly to the COSO internal control framework and address governance, risk assessment, logical and physical access controls, system operations, change management, and risk mitigation. Because Security forms the foundation of every SOC 2 report, it’s often referred to as the Common Criteria.

2. Availability

Availability evaluates whether systems are accessible and operational as committed to customers. It covers areas like data backups, disaster recovery planning, business continuity, and capacity monitoring. This criterion is most relevant for organizations providing services where uptime directly affects their clients’ operations, such as cloud computing or hosting providers.

3. Processing Integrity

Processing integrity addresses whether system processing is complete, accurate, valid, and timely. It focuses on controls that prevent or detect processing errors and confirm that data inputs, processing, and outputs meet the organization’s commitments. Organizations whose platforms handle financial transactions, calculations, or data transformations often include this criterion.

4. Confidentiality

Confidentiality covers controls that restrict access to sensitive business information like trade secrets, intellectual property, or proprietary data. It addresses how that information is protected through access restrictions, encryption, and secure disposal. Confidentiality applies to broader categories of sensitive information beyond personal data.

5. Privacy

Privacy governs how personally identifiable information (PII) is collected, used, retained, disclosed, and disposed of. It aligns with the AICPA’s Generally Accepted Privacy Principles. PII includes information like names, email addresses, Social Security numbers, and, in some industries, health or biometric data. Privacy is relevant for organizations that collect or process personal information as part of their service.

Organizations choose which criteria apply based on their business model, the services they provide, and the expectations of their customers. Security is always in scope. The remaining four are optional and should align with the organization’s services and risk profile.

SOC 2 Type I vs. Type II

There are two types of SOC 2 reports, and the distinction matters for both the organizations being audited and the professionals reviewing those reports.

A Type I report is a snapshot. It tells the reader that, on a specific date, an auditor reviewed the organization’s controls and confirmed they were designed appropriately to meet the selected Trust Services Criteria. It does not test whether those controls actually operated as intended over time.

A Type II report goes further. The auditor evaluates the design of controls and tests evidence that those controls operated effectively throughout a defined observation period. Auditors sample access logs, change management tickets, incident response records, and other documentation across the full period to verify consistency.

Most enterprise buyers now require a Type II report. A Type I report can serve as a stepping stone, particularly for organizations early in their compliance journey, but it is increasingly viewed as insufficient on its own for long-term vendor assurance. 

Who Needs SOC 2?

SOC 2 is primarily relevant for service organizations that store, process, or transmit customer data. This includes SaaS companies, data centers, managed service providers, cloud infrastructure providers, and any technology vendor handling sensitive information on behalf of clients.

SOC 2 is voluntary. There’s no law requiring it. But it has become a de facto baseline in enterprise sales and vendor risk management. 

For finance and accounting teams within these organizations, SOC 2 often creates direct operational responsibilities. These teams are frequently involved in coordinating readiness efforts, maintaining documentation for controls that fall within their domain, and supporting the audit process from an evidence-collection standpoint.

SOC 2 vs. SOC 1: What Accounting Teams Need To Know

Both SOC 1 and SOC 2 are part of the AICPA’s SOC framework, but they serve different purposes and address different risks.

• SOC 1 evaluates a service organization’s internal controls over financial reporting (ICFR). It’s relevant when a service provider’s systems could directly affect a client’s financial statements. The audit focuses on controls around transaction processing, data accuracy, and the integrity of financial data flows. SOC 1 reports are typically requested by a client’s external financial statement auditors.
• SOC 2 evaluates controls related to information security and data protection, structured around the five Trust Services Criteria. It’s relevant when a provider handles sensitive data or operates IT systems that require security assurance.

SOC 3 is another report worth keeping in mind. SOC 3 is a public-facing summary version of a SOC 2 report. Unlike SOC 1 and SOC 2, which are restricted-use reports typically shared under NDA, a SOC 3 can be distributed freely and is sometimes posted on a company’s website. It provides a high-level overview without the detailed control descriptions and test results found in a full SOC 2 report.

SOC 2 And The Internal Audit Team’s Role

Internal audit teams often lead or support the gap assessment that happens before an external CPA firm begins the formal SOC 2 engagement. This readiness work identifies where controls are missing or insufficiently documented and gives the organization time to remediate before the auditor begins testing.

Supporting SOC 2 readiness

Control testing for SOC 2’s Trust Services Criteria aligns directly with standard internal audit workflows: defining control objectives, selecting samples, gathering evidence, and documenting findings. For internal audit teams already familiar with ICFR testing or operational audits, the methodology is similar. The difference is scope. SOC 2 readiness work maps controls to the TSC rather than to financial reporting objectives.

Early readiness work by internal audit reduces surprises during the formal engagement and can shorten the overall audit timeline.

Control testing as an ongoing function

SOC 2 compliance is not a one-time event. For a Type II report, controls need to operate effectively across the full observation period, not just during the weeks before the auditor shows up.

Internal audit teams that run continuous control testing programs are better positioned to maintain SOC 2 readiness year-round. This means regularly reviewing access logs, verifying that change management procedures are followed, confirming that backup and recovery tests are completed, and documenting findings as they occur. 

What external audit teams look for in SOC 2 reports

When reviewing a client’s or vendor’s SOC 2 report as part of a broader engagement, auditors evaluate several key elements:

• The observation period covered. A report that ended six months ago may not reflect the organization’s current control environment. 
• The scope of Trust Services Criteria included. A SOC 2 that only covers Security may not address availability or confidentiality risks relevant to your assessment. 
• Any qualified opinions or exceptions noted in the report. The CPA firm’s independence and reputation. An exception in a SOC 2 report is not automatically disqualifying. What matters is the nature of the exception, whether the organization has remediated it, and how it affects the controls relevant to your engagement. A clean opinion is preferable, but a qualified report with clear remediation steps can still provide meaningful assurance.

The SOC 2 Audit Process

While the details vary by organization and CPA firm, the SOC 2 audit generally follows a consistent sequence of stages.

• Readiness assessment. The organization conducts a gap analysis against the selected Trust Services Criteria. This is often done internally or with a consultant before engaging a CPA firm. The goal is to identify control gaps, missing documentation, and areas that need remediation before the formal audit begins.
• Scope definition. The organization and its auditor define which Trust Services Criteria will be included, which systems are in scope, and, for a Type II engagement, the observation period.
• Evidence collection. The organization gathers documentation of its policies, procedures, access logs, incident records, training records, change management tickets, and other artifacts that demonstrate how controls are designed and operating.
• Auditor testing. The independent CPA firm tests controls against the selected criteria. For a Type I engagement, testing focuses on control design at a point in time. For Type II, the auditor samples evidence across the observation period to verify that controls operated effectively and consistently. Auditors may request additional evidence or clarification during this phase.
• Report issuance. The CPA firm issues the final SOC 2 report, which includes a description of the system, the auditor’s tests and results, and an opinion. The opinion can be unqualified (clean), qualified (exceptions noted), adverse (controls not operating effectively), or a disclaimer (insufficient evidence to form an opinion).

How Trullion Supports SOC 2 Control Testing

Internal audit teams preparing for SOC 2 engagements need to document, test, and trace controls across the full observation period. That work often involves pulling together evidence from multiple systems, tracking testing status across control objectives, and maintaining a defensible record of what was tested, when, and by whom.

Trullion’s Audit Suite helps internal audit teams organize evidence, run structured control testing workflows, and maintain documentation that’s traceable and review-ready, so that audit preparation is continuous rather than a last-minute scramble. 

With Trullion’s Knowledge Room, teams can pull in the latest compliance guidelines directly into their control testing workflows to keep testing aligned with current standards.

Learn more about how Trullion supports internal audit teams.