AICPA and SOC 2: The Organization Behind the Framework

One of the most common knowledge gaps we see when working with clients is a misunderstanding of who actually owns and governs the SOC 2 framework. The American Institute of Certified Public Accountants (AICPA) is the professional organization that created, governs, and continues to evolve SOC 2 — the most widely adopted third-party security assurance standard for technology and service organizations. We find that understanding the AICPA's role provides essential context for any compliance program: the AICPA defines the Trust Service Criteria that form the basis of every SOC 2 evaluation, establishes the professional standards (AT-C Section 320) under which engagements are performed, and through its licensing requirements determines which CPA firms are qualified to conduct SOC 2 examinations. When a customer requests a SOC 2 report, the report's credibility derives directly from AICPA's standards, criteria, and oversight of the CPA profession.

This guide covers the AICPA's relationship to SOC 2: the history of SOC reporting from SAS 70 through the current framework, how the Trust Service Criteria were developed and are updated, the AICPA's role in CPA firm qualification, and what it means for your compliance program when the AICPA makes changes.

What Is the AICPA?

Overview

The American Institute of Certified Public Accountants is the national professional organization for Certified Public Accountants (CPAs) in the United States. Founded in 1887, the AICPA sets ethical standards, develops auditing and attestation standards, creates educational materials, and advocates for the CPA profession. While the AICPA is best known in the context of financial auditing and tax practice, its Assurance Services Executive Committee (ASEC) developed the SOC reporting framework that has become the dominant vendor security assurance mechanism in the technology industry.

AICPA Dimension	Description	Relevance to SOC 2
Professional standards	Develops auditing, attestation, and assurance standards for CPAs	SOC 2 engagements are performed under AT-C Section 320 (Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy)
Trust Service Criteria	Develops and maintains the criteria used to evaluate controls	The five Trust Service Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy) define what SOC 2 evaluates
Professional ethics	Establishes ethical requirements for CPAs	CPA firms conducting SOC 2 examinations must meet AICPA independence and ethics requirements
Quality standards	Sets quality control standards for CPA firms	CPA firms undergo peer review to verify their audit quality meets AICPA standards
Guidance and resources	Publishes implementation guidance and interpretive materials	SOC 2 guidance documents help both service organizations and auditors understand requirements

AICPA vs PCAOB vs State Boards

Organization	Role	SOC 2 Relevance
AICPA	Develops SOC 2 standards and Trust Service Criteria; sets professional standards for CPAs	Primary authority for SOC 2 framework design and criteria
PCAOB (Public Company Accounting Oversight Board)	Oversees auditors of public companies; sets auditing standards for SEC-registered firms	Not directly involved in SOC 2 (SOC 2 is not a PCAOB standard), but PCAOB-registered firms may also conduct SOC 2 engagements
State Boards of Accountancy	License CPAs in their respective states; enforce state accounting practice laws	CPA firms conducting SOC 2 must hold valid licenses in the states where they practice
ISACA	Professional organization for IT governance professionals	Not involved in SOC 2 standards, but ISACA frameworks (COBIT) influenced some SOC 2 control concepts

History: From SAS 70 to SOC 2

The Evolution of Service Organization Reporting

Era	Standard	What It Covered	Limitations
Pre-2011	SAS 70 (Statement on Auditing Standards No. 70)	Controls at service organizations relevant to user entities' financial statement audits	Only addressed financial reporting controls; no framework for security, availability, or privacy; was being misused as a general security assurance mechanism
2011	SOC 1 (SSAE 16, now SSAE 18)	Controls relevant to user entities' internal controls over financial reporting	Direct successor to SAS 70 for financial reporting purposes; narrower and more precisely scoped
2011	SOC 2 (AT-C 320, originally AT 101)	Controls relevant to security, availability, processing integrity, confidentiality, and privacy	Created specifically to address the security and operational control assurance gap that SAS 70 was improperly filling
2011	SOC 3	Same criteria as SOC 2 but designed for public distribution without detailed control descriptions	General-use report; less detailed than SOC 2; not widely adopted by enterprise buyers

Why SOC 2 Was Created

Before SOC 2, organizations that needed to demonstrate security and operational controls to their customers had limited options. SAS 70 was designed for financial reporting control assurance, but the technology industry began using it as a general security attestation — requesting SAS 70 reports from cloud providers, SaaS vendors, and data center operators even though the standard was not designed for that purpose. This misuse created problems: SAS 70 reports did not evaluate security controls comprehensively, they did not address availability or confidentiality, and the financial reporting focus made them a poor fit for technology vendor evaluation.

The AICPA recognized this gap and developed the SOC reporting framework in 2011, which separated service organization reporting into three distinct report types:

• SOC 1: Financial reporting controls (direct successor to SAS 70)
• SOC 2: Security, availability, processing integrity, confidentiality, and privacy controls (new framework addressing the misuse of SAS 70)
• SOC 3: General-use summary version of SOC 2 (new)

This separation allowed each report type to serve its intended purpose: SOC 1 for financial reporting assurance, and SOC 2 for the security and operational control assurance that the technology industry actually needed.

The Trust Service Criteria

How the Criteria Were Developed

The AICPA's Assurance Services Executive Committee (ASEC) developed the Trust Service Criteria as the evaluation framework for SOC 2 engagements. The criteria draw on established information security frameworks, risk management principles, and the AICPA's existing body of auditing standards.

Trust Service Criterion	AICPA Reference	What It Evaluates
Security (Common Criteria)	CC1 through CC9	The foundational criterion — evaluates controls protecting against unauthorized access, unauthorized disclosure, and damage to systems; required for every SOC 2 engagement
Availability	A1	Controls ensuring systems are available for operation and use as committed or agreed
Processing Integrity	PI1	Controls ensuring system processing is complete, valid, accurate, timely, and authorized
Confidentiality	C1	Controls protecting information designated as confidential
Privacy	P1	Controls protecting personal information collected, used, retained, disclosed, and disposed of in conformity with the entity's privacy notice

Criteria Structure

The Trust Service Criteria follow a hierarchical structure with criteria, points of focus, and implementation considerations.

Level	Description	Example
Criterion	Broad control objective that the organization must address	CC6.1 — The entity implements logical access security software, infrastructure, and architectures over protected information assets
Points of Focus	Specific considerations within each criterion that guide implementation and evaluation	Under CC6.1: identification and authentication of users, use of multi-factor authentication, managing credentials
Implementation Guidance	AICPA-published guidance on how organizations can implement controls to satisfy each criterion	Guidance documents describing common control implementations for different organization types

How the AICPA Updates the Criteria

The Trust Service Criteria are not static — the AICPA periodically updates them to reflect evolving technology environments, emerging threats, and changes in the security landscape.

Update Aspect	How It Works	Impact on Organizations
Revision process	ASEC reviews criteria periodically; solicits input from practitioners, service organizations, and user entities	We advise clients to track proposed revisions during exposure draft periods
Effective dates	Updates include an effective date after which all new engagements must use the updated criteria	Organizations may need to add or modify controls to meet updated criteria
Transition periods	The AICPA typically provides a transition period between the announcement and effective date of criteria changes	Time to evaluate impact and implement necessary changes
Points of focus updates	Points of focus may be updated more frequently than the criteria themselves	May refine what auditors evaluate within existing criteria without changing the criteria
Guidance updates	Implementation guidance and interpretive publications are updated as needed	Provides clarity on how criteria apply to emerging technologies and environments

AICPA's Role in SOC 2 Audits

Who Can Perform SOC 2 Examinations

SOC 2 examinations can only be performed by licensed CPA firms — this is a fundamental requirement established by the AICPA's professional standards. The CPA firm designation ensures that the auditor meets professional standards for independence, ethics, competence, and quality control.

Qualification Requirement	What It Means	Why It Matters
CPA firm license	The firm must be a licensed CPA firm in good standing with its state board of accountancy	Ensures the firm meets baseline professional competency and ethical standards
Practitioner competence	Individual practitioners performing SOC 2 work must have competence in information security controls and the Trust Service Criteria	Ensures auditors understand what they are evaluating
Independence	The CPA firm must be independent of the service organization being examined	Ensures objectivity; prevents conflicts of interest; underpins report credibility
Quality control	The firm must maintain a quality control system and undergo peer review	Ensures consistent audit quality across engagements
Adherence to AT-C Section 320	The examination must follow the attestation standard specific to SOC 2	Ensures standardized methodology and report format

What the AICPA Does Not Do

We frequently clarify these misconceptions for our clients:

Common Misconception	Reality
The AICPA certifies or accredits SOC 2 audit firms	The AICPA sets standards, but CPA firms are licensed by state boards; the AICPA does not maintain a list of "approved" SOC 2 auditors
The AICPA reviews or approves individual SOC 2 reports	SOC 2 reports are issued by the CPA firm; the AICPA does not review, approve, or endorse individual reports
The AICPA certifies service organizations as "SOC 2 compliant"	SOC 2 is an audit report, not a certification; the AICPA does not issue compliance certificates to service organizations
The AICPA mandates specific technical controls	The Trust Service Criteria are principle-based, not prescriptive; the AICPA does not mandate specific technologies or configurations
Organizations can "register" their SOC 2 with the AICPA	There is no AICPA registry of SOC 2 reports or compliant organizations

AICPA Standards Governing SOC 2

Key Standards and Publications

Standard/Publication	Reference	What It Covers
AT-C Section 320	Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy	The attestation standard governing how SOC 2 examinations are performed and reported
Trust Service Criteria (TSC)	AICPA Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy	The criteria against which controls are evaluated; includes common criteria (CC1-CC9) and supplemental criteria
SOC 2 Guide	AICPA Guide: SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy	Comprehensive implementation guidance for practitioners performing SOC 2 engagements
SSAE 18	Statement on Standards for Attestation Engagements No. 18	The overarching attestation standards framework under which AT-C 320 operates
System and Organization Controls guidance	Various AICPA publications	Interpretive guidance on specific SOC 2 topics, emerging issues, and implementation questions

Principle-Based vs Rule-Based Criteria

The AICPA designed the Trust Service Criteria as principle-based standards rather than prescriptive rule-based requirements. This is a fundamental design choice that affects how organizations implement and auditors evaluate SOC 2 controls. We often explain this distinction to clients because it directly impacts how much flexibility they have in their control design.

Characteristic	Principle-Based (SOC 2)	Rule-Based (Comparison)
Prescriptiveness	States the objective; does not mandate specific implementation	Specifies exact controls, configurations, or technologies required
Flexibility	Organizations choose controls appropriate to their environment	Limited flexibility; same requirements regardless of environment
Scalability	Scales from startups to enterprises; adaptable to any technology stack	May not fit all environments without exceptions or compensating controls
Auditor judgment	Auditors exercise professional judgment in evaluating whether controls satisfy criteria	Auditors verify compliance against specific checklists
Example	CC6.1 requires logical access security but does not mandate a specific IdP or MFA technology	PCI DSS 8.3.1 specifies MFA for all non-console administrative access

What AICPA Updates Mean for Your Compliance Program

Monitoring and Responding to Changes

What we tell clients about staying current with AICPA changes:

Activity	Frequency	How to Stay Informed
Monitor AICPA announcements	Ongoing	Subscribe to AICPA's assurance and advisory services communications; follow SOC-related publications
Review exposure drafts	When published	Review proposed criteria changes during comment periods; assess impact on your control environment
Assess impact of finalized changes	When criteria updates are finalized	Evaluate which controls may need to be added, modified, or documented differently
Update control documentation	Before the effective date of criteria changes	Revise control descriptions, policies, and evidence collection to align with updated criteria
Coordinate with your auditor	During planning for each engagement	Discuss any criteria changes affecting the upcoming audit; align on interpretation of new or modified criteria

Historical Criteria Updates

Year	Update	Impact
2011	SOC 2 framework created (SOC 1, SOC 2, SOC 3 replacing SAS 70)	Fundamental framework creation; organizations migrated from SAS 70 to SOC 1/SOC 2
2017	Trust Service Criteria revised (2017 TSC) — aligned with COSO 2013 framework	Significant restructuring; common criteria (CC1-CC9) replaced previous criteria numbering; enhanced risk assessment and monitoring requirements
2018	SSAE 18 replaced SSAE 16 as the overarching attestation standard	Updated professional standards for practitioners; refined reporting requirements
Ongoing	Points of focus refinements and guidance updates	Incremental clarifications affecting auditor evaluation approach

Key Takeaways

• The AICPA created, governs, and evolves the SOC 2 framework through its Trust Service Criteria and attestation standards (AT-C Section 320) — understanding the AICPA's role provides essential context for why SOC 2 reports carry the credibility they do with enterprise buyers
• SOC 2 was created in 2011 to address the technology industry's misuse of SAS 70 (a financial reporting standard) as a general security assurance mechanism — the SOC framework separated financial reporting controls (SOC 1) from security and operational controls (SOC 2) to serve each purpose properly
• The Trust Service Criteria are principle-based, not prescriptive — the AICPA defines control objectives (what to achieve) rather than mandating specific technologies or configurations (how to achieve it), which allows SOC 2 to scale from startups to enterprises across any technology stack
• Only licensed CPA firms can perform SOC 2 examinations — the AICPA does not maintain an approved auditor list, does not review individual reports, and does not certify service organizations as "SOC 2 compliant," but its professional standards ensure auditor independence, competence, and quality
• We advise our clients to monitor AICPA announcements and coordinate with their auditors whenever criteria updates are published — staying ahead of changes prevents surprises during audit fieldwork and demonstrates proactive compliance management
• We help our clients understand how AICPA standards and Trust Service Criteria apply to their specific environment — from criteria selection and control design through documentation alignment and auditor coordination, ensuring the compliance program meets current requirements

Frequently Asked Questions

Is SOC 2 a certification?

What we tell clients is that SOC 2 is not a certification — it is an attestation report, and this distinction matters. Certifications like ISO 27001 are issued by a certifying body that declares the organization meets a specific standard, while SOC 2 is an auditor's report describing the service organization's controls and the auditor's opinion on whether those controls meet the Trust Service Criteria. The SOC 2 report is issued by the CPA firm, not by the AICPA. There is no "SOC 2 certificate" to display, no AICPA seal of approval, and no registry of SOC 2-compliant organizations. When organizations say they are "SOC 2 certified," they mean they have received a SOC 2 report with an unqualified opinion — but we advise clients to use precise language because it demonstrates compliance maturity to enterprise buyers.

Can non-CPA firms perform SOC 2 audits?

No, and this is something we emphasize in every client engagement. SOC 2 examinations must be performed by licensed CPA firms under AICPA attestation standards. Non-CPA security assessment firms, penetration testing companies, and consulting firms cannot issue SOC 2 reports. This requirement ensures that SOC 2 reports carry the professional standards, independence requirements, and quality control oversight that gives them credibility. Some non-CPA firms offer "SOC 2 readiness assessments" or "SOC 2 preparation" services — these are legitimate advisory services that help organizations prepare for the actual examination, but they are not SOC 2 reports.

How does the AICPA ensure SOC 2 audit quality?

Based on what we see across our client base, audit quality is maintained through multiple mechanisms rather than a single quality control process. CPA firms must maintain quality control systems meeting AICPA quality management standards. Firms undergo peer review — a periodic evaluation by another CPA firm assessing whether the quality control system is suitably designed and operating effectively. Individual practitioners must meet continuing professional education requirements and maintain competence in their practice areas. The AICPA publishes guidance and interpretive materials that help practitioners apply the Trust Service Criteria consistently. While no quality assurance system is perfect, the combination of peer review, professional standards, state licensing, and ethical requirements creates a framework that supports consistent SOC 2 report quality across the profession.

Does the AICPA have a role in SOC 2 for non-US organizations?

The advice we give most often here is to recognize that the AICPA is a US-based professional organization, and SOC 2 is fundamentally a US standard performed under US attestation standards. However, SOC 2 has become globally recognized, and non-US organizations regularly obtain SOC 2 reports to serve US and international customers. For non-US organizations, the SOC 2 examination is still performed by a CPA firm (either a US-based firm or a firm affiliated with a US CPA practice that can issue reports under US attestation standards). Many non-US organizations we work with pursue both SOC 2 and ISO 27001 to address US and international market expectations simultaneously.