AICPA and SOC 2: The Organization Behind the Framework
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.
Key Takeaways
- •SOC 2 examinations can only be performed by licensed CPA firms — this is a fundamental requirement established by the AICPA's professional standards.
- •For the next operating decision, compare SOC 2 compliance for startups with policies needed for SOC 2.
- •The American Institute of Certified Public Accountants is the national professional organization for Certified Public Accountants (CPAs) in the United States.
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.
For the next operating decision, compare SOC 2 compliance for startups with policies needed for SOC 2. Confirm the work included, the evidence you need, and who will own implementation before committing to a provider.
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 |
How did SOC reporting develop after SAS 70?
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
| 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 |
AICPA & CIMA’s SOC overview describes CPA assurance services. It defines the assurance context; it does not establish vendor rankings, market prices, or a particular company’s readiness.
Frequently Asked Questions
Who owns and governs the SOC 2 framework?
Can a non-CPA firm perform a SOC 2 audit?
How did SOC 2 replace SAS 70?
Tyler Carbone
Managing Director and Cofounder
Tyler Carbone is a Managing Director and Cofounder of Agency and one of the industry's leading voices on governance, risk, and compliance. He holds degrees from Harvard and a JD/MBA from the University of Virginia, and previously worked in cybersecurity at Deloitte. Tyler has helped hundreds of companies operate SOC 2, ISO 27001, HIPAA, and GDPR programs.
LinkedIn
