SOC 2: Definition and Use in Compliance

What is SOC 2?

SOC 2 is an attestation standard developed by the American Institute of Certified Public Accountants (AICPA) that evaluates a service organization's controls across five Trust Service Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only mandatory category. Most technology vendors serving regulated industries include Availability and Confidentiality as well. Privacy coverage is expected when handling personal data subject to regulations like GDPR or state privacy laws.

A cloud-storage vendor handling data from financial institutions, for instance, would typically cover Security, Availability, and Confidentiality to satisfy procurement requirements. A vendor managing consumer onboarding data would need Privacy coverage too. The scope is negotiated between the service organization and its auditor before fieldwork begins.

The standard produces two distinct report types. A Type I report answers one question: are the controls suitably designed as of a specific date? A Type II report asks something harder: did those controls actually operate effectively over a period of six to twelve months? For financial institutions, Type I is rarely sufficient. A vendor can design controls on paper in days. Demonstrating consistent operation over a full year is a different standard.

The AICPA updated the Trust Services Criteria in 2017, adding granular requirements around logical access controls, change management, and risk mitigation. The full 2017 Trust Services Criteria document is published by the AICPA and covers the specific criteria auditors apply in each category. The revision made the framework substantially more relevant to cloud infrastructure vendors, SaaS platforms, and data processors in regulated industries.

What SOC 2 doesn't do is equally worth stating. It's an attestation that an independent auditor examined specific controls and expressed an opinion. It doesn't certify architecture security the way ISO 27001 does. It doesn't guarantee zero breaches. A clean SOC 2 Type II with a strong control environment means those controls were present, tested, and working during the audit window. That's a meaningful signal, not an absolute guarantee.

The audit must be conducted by a licensed CPA firm, tying the standard's credibility to professional accounting liability. A vendor marketing a "SOC 2-equivalent" internal assessment as a substitute is not providing an equivalent artifact.

How is SOC 2 used in practice?

Financial institutions use SOC 2 reports as a primary input for Third-Party Risk Management (TPRM) decisions. Before signing a contract with a cloud provider, payment processor, or regtech vendor, procurement and compliance teams request the most recent SOC 2 Type II report. The review is more than a checkbox.

Analysts focus first on the auditor's opinion: qualified or unqualified? A qualified opinion means the auditor found exceptions material enough to call out. Then they read the description of controls the service organization provided and cross-reference it against what was actually tested. Scope determines relevance. If a vendor's report covers only their US datacenter and the buyer's data sits in EU infrastructure, the report doesn't address the actual exposure.

The exceptions table is where real risk concentrates. A vendor with five exceptions and weak management responses is a red flag. A vendor with two exceptions and documented remediation evidence may be acceptable if those exceptions don't touch systems handling sensitive data. The quality of management responses tells you whether control failures are addressed systematically or explained away.

On the vendor side, maintaining a clean Type II means running continuous evidence collection throughout the audit period. Access logs, change tickets, incident records, and backup test results all feed into the auditor's evidence package. The audit trail requirements are substantial: every user access event, every configuration change, every security incident must be captured and retrievable. Many vendors use automated compliance platforms to organize this evidence, though the final report must come from a licensed CPA firm.

For contract renewals, most enterprise agreements require annual SOC 2 reports. A gap of more than 12 months between report date and review date is typically flagged as a TPRM finding. Vendors in rapid growth phases, scaling headcount or migrating infrastructure, may present materially different risk environments than a year-old report reflects. In those cases, a bridge letter from the auditor covering the gap period is the standard remedy.

SOC 2 in regulatory context

SOC 2 isn't mandated by statute under most financial services laws. No clause in the Bank Secrecy Act requires a SOC 2 report specifically. But regulators treat it as the baseline standard for demonstrating third-party control assurance, and examiners ask for it.

The OCC's 2023 interagency guidance on third-party relationships, issued jointly with the FDIC and Federal Reserve, requires banks to assess the controls of critical third parties across the full relationship lifecycle. SOC 2 Type II reports are the most common mechanism vendors use to satisfy that requirement. FFIEC examiners routinely request third-party audit reports during BSA/AML examinations. A bank with a critical technology vendor that can't produce a current SOC 2 is likely to receive a finding.

The Federal Reserve's SR 23-4 letter, issued in January 2023, reinforced that financial institutions must manage third-party risk from vendor selection through contract termination. Technology vendors offering AI-driven compliance tools, transaction monitoring platforms, and analytics services are squarely within scope.

In the EU, the Digital Operational Resilience Act (DORA), in effect from January 2025, explicitly requires financial entities to include security audit requirements in ICT third-party contracts under Articles 28-30. SOC 2 doesn't satisfy DORA on its own. DORA requires specific contractual provisions, mandatory exit strategies, and concentration risk assessments. A SOC 2 Type II is supporting evidence for ICT risk assessments, not a complete substitute for DORA compliance obligations.

For vendors serving both US and EU clients, maintaining SOC 2 alongside ISO 27001 covers the main bases. A vendor selling KYC automation to a US bank and a European financial institution, for instance, would typically need both to pass procurement in each market. The frameworks share substantial control overlap; firms that achieve one typically find the second audit is faster and less expensive.

Common challenges and how to address them

Scope drift is the most common problem. A vendor earns a SOC 2 Type II for a subset of their infrastructure, then markets the report as covering everything. Compliance teams need to map systems in scope against systems that actually handle their data. If there's a gap, the report doesn't answer the relevant question. It's worth building a scope verification step into the standard TPRM intake process, not leaving it to the vendor to flag voluntarily.

Report staleness is the second issue. A SOC 2 Type II covers a historical period. A report from February 2024 describes controls that may no longer look the same. Fast-moving vendors scaling headcount or migrating to new cloud infrastructure can have materially different control environments six months after an audit closes. Most banks require reports within 12 months; for high-risk vendors, a bridge letter covering the period since the last report is standard. Without it, you're assessing yesterday's controls against today's risk.

Auditor quality varies substantially. Some firms run deep tests, pulling real samples of access logs and change records. Others accept screenshots and brief descriptions. The AICPA publishes quality guidance, but enforcement across thousands of CPA firms is inconsistent. Audit price is often a signal: a $15,000 SOC 2 engagement and a $150,000 one are rarely testing to the same depth. Compliance teams should ask vendors how many samples were tested per control and which testing procedures the auditor used.

Maintaining the continuous evidence collection required for a clean Type II adds real operational overhead. Access reviews, quarterly vulnerability scans, annual penetration tests, and complete audit trail coverage for all in-scope systems are standard requirements. The common mistake is treating SOC 2 as an annual project. Controls that lapse mid-year still surface as exceptions if the auditor's sample period catches them.

Finally, SOC 2 and operational resilience requirements address different questions. SOC 2 is about control assurance; operational resilience is about service continuity under stress. A vendor can hold a clean SOC 2 and still have inadequate recovery time objectives for the systems financial institutions depend on. The two assessments need to run in parallel, not be treated as substitutes.

Related terms and concepts

SOC 2 sits within a cluster of frameworks that compliance and security teams use together when assessing organizational risk.

ISO 27001 is the most direct comparator. It's a certifiable information security management standard maintained by the International Organization for Standardization. Unlike SOC 2, ISO 27001 requires surveillance audits between three-year certification cycles. European clients and regulators often require it alongside SOC 2. The frameworks share substantial control overlap in access management, incident response, and change management. Firms that achieve one typically find the second audit covers familiar ground.

SOC 1 reports, also from the AICPA, cover controls relevant to financial reporting rather than operational security. They're the successor to SAS 70 and are used by payroll processors, transfer agents, and loan servicers. When evaluating technology security, SOC 2 is the relevant report. Confusing the two is a common onboarding mistake in vendor procurement.

Third-Party Risk Management (TPRM) programs use SOC 2 as one signal among many. A complete TPRM review includes financial stability assessments, penetration test results, business continuity documentation, and contractual right-to-audit clauses. SOC 2 is necessary for critical vendor classifications, not sufficient on its own.

Operational resilience frameworks from the Bank of England, FCA, and DORA focus on continuity of critical services under stress. A vendor's Availability Trust Service criteria from their SOC 2 is relevant input to a resilience assessment, but the two frameworks address different questions. Availability in SOC 2 means the system met its uptime commitments during the audit period. Resilience frameworks ask whether the service can stay available through cyberattacks, third-party failures, and operational crises.

Control environment is the aggregate of policies, procedures, and organizational culture that shapes how controls operate. SOC 2 auditors assess both design and operating effectiveness within that environment. A strong control environment shows up in reports through low exception rates and substantive management responses to any exceptions found. It's one of the clearer signals of whether a vendor's compliance posture is genuine or performative.