Complete SOC 2 Glossary: Every Term Defined

One of the first things we do when onboarding a new compliance client is make sure everyone on the team speaks the same language. SOC 2 has its own vocabulary, and misunderstanding a single term can derail scoping conversations, audit prep, or vendor evaluations. We built this glossary from the questions our clients actually ask us — the terms that cause confusion in real compliance programs.

SOC 2 compliance involves specialized terminology spanning auditing standards, security frameworks, technical controls, and regulatory concepts that can be confusing for organizations pursuing compliance for the first time. This glossary defines the essential terms encountered throughout the SOC 2 process — from the initial scoping conversation through audit fieldwork and report delivery. Each definition includes context for where and how the term appears in the SOC 2 lifecycle, making this a practical reference for compliance teams, engineering teams, and leadership involved in the audit process. Whether you are reading a SOC 2 report for the first time, preparing for your initial audit, or evaluating a vendor's compliance posture, this glossary provides clear, concise definitions for every term you are likely to encounter.

This glossary covers SOC 2 and compliance terminology including audit concepts, Trust Service Criteria, control terms, technical security terms, and regulatory framework definitions.

Core SOC 2 Terms

SOC 2 (System and Organization Controls 2) — An auditing framework developed by the AICPA that evaluates an organization's information systems based on five Trust Service Criteria: Security, Availability, Confidentiality, Processing Integrity, and Privacy. SOC 2 reports provide assurance to customers that the organization maintains adequate controls over their data and systems.

AICPA (American Institute of Certified Public Accountants) — The professional organization that developed the SOC 2 framework and the Trust Service Criteria. The AICPA sets the standards that CPA firms follow when performing SOC 2 audits. SOC 2 is a registered trademark of the AICPA.

Trust Service Criteria (TSC) — The five categories against which SOC 2 evaluates an organization's controls: Security (required), Availability, Confidentiality, Processing Integrity, and Privacy. Organizations choose which criteria to include in their audit scope based on their services and customer expectations.

Common Criteria (CC) — The Security criteria within the Trust Service Criteria, organized into nine categories (CC1 through CC9) covering control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. Security (Common Criteria) is required for all SOC 2 audits.

SOC 2 Type I — An audit report that evaluates the design of an organization's controls at a specific point in time. Type I confirms that controls are designed appropriately but does not test whether they operated effectively over a period. Often used as a first step toward Type II.

SOC 2 Type II — An audit report that evaluates both the design and operating effectiveness of controls over a period of time (typically 3-12 months, with 12 months being standard for mature programs). Type II is the report most enterprise buyers require because it demonstrates that controls actually worked consistently.

Observation Period — The time period covered by a SOC 2 Type II audit, during which the auditor evaluates whether controls operated effectively. Common observation periods are 3, 6, or 12 months. A 12-month observation period aligned with the fiscal or calendar year is standard for mature organizations.

Bridge Letter — A document provided by the audited organization or its auditor covering the gap between the end of the SOC 2 observation period and the current date. Bridge letters affirm that no material changes to controls have occurred since the report date. Used when a SOC 2 report is not yet renewed.

Audit Process Terms

Service Auditor — The CPA firm that performs the SOC 2 audit. The service auditor is independent from the organization being audited and issues the SOC 2 report with their professional opinion on the controls.

Service Organization — The company being audited — the entity whose controls are evaluated in the SOC 2 report. If you are pursuing SOC 2, your company is the service organization.

User Entity — The customer of the service organization — the company that relies on the service organization's systems and uses the SOC 2 report to evaluate the service organization's controls. User entities are the intended audience for SOC 2 reports.

Subservice Organization — A third-party vendor used by the service organization that is part of the system being audited. Cloud providers (AWS, GCP, Azure) are the most common subservice organizations. Their controls are either included in the audit (inclusive method) or excluded with reference to their own SOC 2 report (carve-out method).

Inclusive Method — An approach where the subservice organization's controls are included within the service organization's SOC 2 audit and tested directly by the service auditor. Less common due to the complexity of auditing a third party's controls.

Carve-Out Method — The most common approach for handling subservice organizations, where the subservice organization's controls are excluded from the service organization's SOC 2 audit. The service organization references the subservice organization's own SOC 2 report. Most organizations use the carve-out method for cloud providers.

Complementary User Entity Controls (CUECs) — Controls that the service organization expects user entities (customers) to implement on their end for the overall control environment to be effective. For example, a SaaS provider may expect customers to use strong passwords and enable MFA. CUECs are listed in the SOC 2 report.

Complementary Subservice Organization Controls (CSOCs) — Controls that the service organization relies on the subservice organization (e.g., AWS) to perform. These are documented in the SOC 2 report when using the carve-out method.

System Description — A detailed description of the service organization's system included in Section III of the SOC 2 report. It covers the services provided, system components, data types, system boundaries, and the control environment. Auditors verify the accuracy of the system description.

Management Assertion — A formal statement by the service organization's management (Section II of the SOC 2 report) asserting that the system description is fairly presented and that controls are suitably designed and operating effectively.

Auditor's Opinion — The service auditor's professional conclusion about the controls, presented in Section I of the SOC 2 report. Opinions can be unqualified (clean — no issues), qualified (issues found in specific areas), adverse (significant failures), or disclaimer of opinion (unable to conclude).

Qualified Opinion — An auditor's opinion indicating that the controls were generally effective but specific exceptions or issues were identified. A qualified opinion is not a failure but signals areas that did not meet the criteria during the observation period.

Unqualified Opinion — A clean auditor's opinion stating that the controls met the Trust Service Criteria without exception. This is the ideal outcome and what most organizations aim for.

Exception — A specific instance where a control did not operate as designed during the observation period. Exceptions are documented in the SOC 2 report. Minor exceptions do not necessarily lead to a qualified opinion; the auditor evaluates the overall impact.

Readiness Assessment — A pre-audit evaluation that identifies gaps between an organization's current controls and SOC 2 requirements. Readiness assessments are performed before the formal audit to identify and remediate issues. Also called a gap assessment.

Fieldwork — The phase of the SOC 2 audit where the auditor tests controls, collects evidence, and evaluates the operating effectiveness of the control environment. Fieldwork typically takes 3-6 weeks.

Trust Service Criteria Definitions

Security (Common Criteria) — The required criteria for all SOC 2 audits. Evaluates whether the system is protected against unauthorized access, both physical and logical. Covers access controls, encryption, monitoring, incident response, change management, and risk assessment.

Availability — Evaluates whether the system is available for operation and use as committed or agreed. Covers uptime, disaster recovery, business continuity, backup procedures, and environmental protections. Recommended for SaaS companies whose customers depend on system uptime.

Confidentiality — Evaluates whether information designated as confidential is protected as committed or agreed. Covers data classification, encryption, access controls for confidential information, and data disposal. Recommended for organizations handling customer business data.

Processing Integrity — Evaluates whether system processing is complete, valid, accurate, timely, and authorized. Relevant for organizations where data processing accuracy is critical (financial calculations, data transformations, automated workflows).

Privacy — Evaluates whether personal information is collected, used, retained, disclosed, and disposed of in conformity with the entity's privacy notice and privacy-related criteria. Relevant for organizations handling significant consumer personal data.

Control and Evidence Terms

Control — A specific procedure, process, or technical measure designed to mitigate a risk. In SOC 2, controls map to Trust Service Criteria and are tested during the audit. Examples include MFA enforcement, quarterly access reviews, and encryption in transit.

Control Activity — The action or process that implements a control. For example, if the control is "access is reviewed quarterly," the control activity is the actual quarterly access review performed by the IT team.

Control Objective — The goal that a control is designed to achieve. Control objectives are derived from the Trust Service Criteria. For example, CC6.1's objective is that logical and physical access to the system is restricted to authorized users.

Evidence — Documentation, logs, screenshots, or records that demonstrate a control is operating effectively. Auditors collect evidence during fieldwork to support their opinion. Evidence can be automated (system-generated logs) or manual (screenshots, attestation documents).

Population — The complete set of items from which the auditor selects a sample for testing. For example, the population for access review testing is all access reviews that should have been performed during the observation period.

Sample — A subset of the population selected by the auditor for detailed testing. Auditors use sampling because testing every item in a population is impractical. Sample sizes follow AICPA guidance based on population size and control frequency.

GRC Platform (Governance, Risk, and Compliance) — Software platforms that automate SOC 2 compliance activities including evidence collection, control monitoring, policy management, and audit preparation. Examples include Vanta, Drata, Secureframe, and Sprinto.

Technical Security Terms

MFA (Multi-Factor Authentication) — An authentication method requiring two or more verification factors (something you know, something you have, something you are). MFA is a fundamental SOC 2 control under CC6.1 and is expected for all production system access.

RBAC (Role-Based Access Control) — An access control model where permissions are assigned to roles rather than individual users. Users inherit permissions by being assigned to roles. RBAC supports the principle of least privilege under CC6.1 and CC6.3.

SSO (Single Sign-On) — An authentication mechanism allowing users to access multiple systems with one set of credentials. SSO simplifies access management and improves security by centralizing authentication. Commonly implemented through SAML or OIDC protocols.

Encryption at Rest — Encryption of data stored on disk, in databases, or in storage services. SOC 2 expects AES-256 encryption for sensitive data at rest under CC6.7.

Encryption in Transit — Encryption of data being transmitted between systems, typically using TLS (Transport Layer Security). SOC 2 expects TLS 1.2 or higher for all data transmission under CC6.7.

IDS/IPS (Intrusion Detection/Prevention System) — Systems that monitor network traffic for malicious activity. IDS detects and alerts; IPS detects and blocks. Relevant to CC7.1 monitoring requirements.

SIEM (Security Information and Event Management) — A platform that aggregates, correlates, and analyzes security event data from multiple sources. SIEMs support CC7.1 and CC7.2 monitoring and detection requirements.

WAF (Web Application Firewall) — A firewall that monitors and filters HTTP traffic between the internet and a web application. WAFs protect against common web exploits (SQL injection, XSS) and support CC6.6 external access controls.

RPO (Recovery Point Objective) — The maximum acceptable amount of data loss measured in time. An RPO of 1 hour means the organization can tolerate losing up to 1 hour of data. RPO determines backup frequency under A1.2.

RTO (Recovery Time Objective) — The maximum acceptable time to restore system operations after a disruption. An RTO of 4 hours means the system must be operational within 4 hours of an outage. RTO drives disaster recovery architecture under A1.3.

Vulnerability Scanning — Automated testing that identifies known security vulnerabilities in systems, applications, and configurations. Regular vulnerability scanning supports CC7.1 and is expected by most SOC 2 auditors.

Penetration Testing — Manual security testing performed by a qualified tester who attempts to exploit vulnerabilities in an organization's systems. Annual penetration testing is a standard expectation for SOC 2 under CC4.1 and CC7.1.

Regulatory and Framework Terms

HIPAA (Health Insurance Portability and Accountability Act) — US federal law establishing standards for protecting health information. Healthtech companies often pursue SOC 2 alongside HIPAA compliance.

PCI DSS (Payment Card Industry Data Security Standard) — Security standard for organizations that handle credit card data. Fintech companies may need both SOC 2 and PCI DSS compliance.

GDPR (General Data Protection Regulation) — EU regulation governing the processing of personal data of EU residents. SOC 2 and GDPR have significant control overlap.

ISO 27001 — An international standard for information security management systems (ISMS). Some organizations pursue both SOC 2 and ISO 27001 because they serve different markets (SOC 2 is primarily US; ISO 27001 is international).

SOC 1 — A related AICPA framework that evaluates controls relevant to financial reporting. SOC 1 is used by service organizations whose services affect their customers' financial statements (payroll processors, financial data providers). SOC 1 and SOC 2 are separate audits.

SOC 3 — A publicly available summary version of a SOC 2 report. SOC 3 reports contain the auditor's opinion without the detailed control testing results. Used for general marketing purposes rather than detailed vendor evaluation.

NIST (National Institute of Standards and Technology) — US government agency that publishes cybersecurity frameworks and standards. NIST SP 800-53 and the NIST Cybersecurity Framework are frequently referenced alongside SOC 2.

CIS Controls (Center for Internet Security Controls) — A set of prioritized cybersecurity best practices. CIS Controls provide specific implementation guidance that maps to SOC 2 requirements.

CCPA (California Consumer Privacy Act) — California state law governing the collection and use of personal information of California residents. Relevant to SOC 2 Privacy criteria for organizations handling California consumer data.

BAA (Business Associate Agreement) — A HIPAA-required contract between a covered entity and a business associate that establishes permitted uses and disclosures of protected health information. Healthtech vendors typically execute BAAs with healthcare customers.

Key Takeaways

• We consistently see that SOC 2 Type II is the report enterprise buyers require — it demonstrates that controls operated effectively over a period of time, not just that they were designed properly; most organizations we work with start with Type I and progress to Type II
• We advise clients to use the carve-out method as the standard approach for cloud provider subservice organizations — your cloud provider's own SOC 2 report covers their controls, and you reference it in your system description; make sure you understand the Complementary User Entity Controls (CUECs) that you are expected to implement
• In our experience, an unqualified opinion is the goal but exceptions do not necessarily mean failure — minor exceptions are common and do not automatically result in a qualified opinion; the auditor evaluates the overall control environment and whether exceptions are material
• We recommend leveraging GRC platforms to automate much of the evidence collection and control monitoring process — platforms like Vanta, Drata, Secureframe, and Sprinto connect to your systems and continuously collect evidence that would otherwise require manual screenshots and log exports
• What we tell clients early on is that understanding the difference between SOC 1, SOC 2, and SOC 3 prevents confusion — SOC 1 relates to financial reporting controls, SOC 2 evaluates security and operational controls, and SOC 3 is a public summary; most SaaS companies need SOC 2
• We help our clients navigate SOC 2 terminology and the audit process — from initial education and readiness assessment through audit preparation and report interpretation, ensuring teams understand the process and requirements before, during, and after the audit

Frequently Asked Questions

What is the difference between a control and a policy?

What we tell clients is that a policy is a documented statement of intent — it describes what the organization will do (e.g., "All employees must use multi-factor authentication"). A control is the actual implementation that enforces the policy (e.g., MFA configured and enforced through the identity provider for all production access). Auditors evaluate both: policies must exist and be communicated, and controls must operate effectively to enforce those policies. In our experience, a policy without an implementing control is a gap, and a control without a documenting policy is an audit risk.

What does "operating effectiveness" mean?

Based on what we see across our client engagements, operating effectiveness means that a control not only exists and is designed properly (design effectiveness) but also functioned consistently throughout the observation period. A control has operating effectiveness if it was performed by the right people, at the right frequency, with the right results, consistently over time. Type I audits evaluate design only; Type II audits evaluate both design and operating effectiveness.

What is the difference between SOC 2 and ISO 27001?

What we advise clients evaluating both frameworks is this: SOC 2 is an attestation report issued by a CPA firm evaluating specific Trust Service Criteria; it is primarily required by US enterprise buyers. ISO 27001 is an international certification standard for information security management systems; it is more commonly required by European and international buyers. Many organizations we work with pursue both to serve global markets. The frameworks overlap significantly in technical controls but differ in structure, assessment methodology, and market applicability.