The American Institute of Certified Public Accountants (AICPA) oversees several audit protocols to ensure trust in organizations. Many of these concern financial operations exclusively; others touch on information technology and cybersecurity components. Two of AICPA’s most widely applicable assessments are SOC 2 and SOC for Cybersecurity. Read on for a comparative look at SOC for Cybersecurity vs SOC 2 to determine if one or both may be apt for your organization.
What Are SOC 2 and SOC for Cybersecurity Assessments?
SOC for Cybersecurity and SOC 2 are both reporting protocols that assessors, such as CPAs or managed security service providers (MSSPs), can use to document an organization’s security for legal, business, or other reasons. To help you understand each comprehensively, we’ll provide:
- A quick look at the significant differences and similarities between both assessments
- A full breakdown of the SOC 2 and Trust Services Criteria (TSC) frameworks
- A deep dive into SOC for Cybersecurity assessments and possible applications
- An overview of other SOC reports to consider—and their specific variations
For most organizations, the kind and frequency of SOC reports generated depends on the nature of your business, your clients’ demands, and industry requirements or best practices.
Download Our SOC 2 Compliance Checklist
SOC for Cybersecurity vs SOC 2: Assessments at-a-glance
Both SOC for Cybersecurity and SOC 2 fall within the System and Organization Controls suite of audit and attestation protocols overseen by AICPA. All the protocols within this suite provide guidance and uniformity for CPAs and other auditors assessing service and other organizations.
In particular, some SOC assessments apply to specific kinds of organizations, or individual branches or systems within given organizations. Therein lies one of the biggest differences between SOC for Cybersecurity and SOC 2 applicability: the former can be performed on any entity, whereas the latter is intended for service organizations (e.g., SaaS providers) specifically.
SOC for Cybersecurity reports tend to be entity-wide in scope but can focus on any particular part of the organization. SOC 2 reports, on the other hand, focus specifically on the parts of a service organization that house, process, or otherwise contact user data.
The most significant evaluation difference is that SOC 2 utilizes a specific set of controls for assessments, whereas SOC for Cybersecurity reports can use any criteria (with restrictions—see below).
See also: AICPA’s whitepaper on SOC 2 and SOC for Cybersecurity for more critical differences and use cases.
SOC 2 and Trust Services Criteria for Service Organizations
The SOC 2 attestation is one of three mainline SOC frameworks. Its full title is SOC For Service Organizations: Trust Services Criteria. The reports generated from a SOC 2 audit are intended for a specialized audience, such as other assessors interested in the organization or B2B clients. The process of attestation differs depending on which type of attestation is requested:
- SOC 2 Type 1 – A short-term analysis of security controls, as designed
- SOC 2 Type 2 – A long-term analysis of security controls, in practice
In both cases, the specific metrics used are enumerated in AICPA’s TSP Section 100: Trust Services Criteria (TSC). The TSC prescribes various criteria by which an entity should be assessed, according to five general categories (i.e., The Trust Services Principles (TSP)):
- Security – Prevention of unauthorized access to information and systems, unauthorized use or disclosure of information, and compromises to the other Trust Services Principles
- Availability – Assurance that all information and systems are available for use by those parties who are authorized and entitled to access them (i.e., first, second, and third parties)
- Processing Integrity – Full functionality of all system processing, including timeliness, completeness, accuracy, authorization, and adherence to organizational objectives
- Confidentiality – Adherence to all protections applicable to any kind of information
- Privacy – Adherence to protections applicable to personally identifiable information
Critically, SOC 2 attestations always use the TSC framework—specifically, they always use the Common Criteria, which pertain to Security. They may also assess criteria for the other TSP.
Measuring Effectiveness of Security Through Common Criteria
The TSC framework breaks down into various Series of criteria. The most critical of these are the Common Criteria, which apply across all Trust Services Principles and reflect (or build on) COSO Principles. The first five CC Series house criteria that directly reflect COSO Principles:
- Control Environment (CC1 Series) –
- CC1.1 – Entity-wide commitment to integrity and defined ethical values
- CC1.2 – Board independence from management and program oversight
- CC1.3 – Management’s establishment of reporting lines and infrastructure
- CC1.4 – Entity-wide commitment to attracting and retaining quality staff
- CC1.5 – Entity-wide commitment to accountability pertaining to controls
- Communication / Information (CC2 Series) –
- CC2.1 – Entity-wide gathering of quality data to support internal controls
- CC2.2 – Internal communication of information required for internal controls
- CC2.3 – External communication of information required for internal controls
- Risk Assessment (CC3 Series) –
- CC3.1 – Clear establishment of objectives, enabling efficient risk mitigation
- CC3.2 – Entity-wide risk identification and analysis-informed risk mitigation
- CC3.3 – Entity-wide prioritization of fraud and related activities in risk mitigation
- CC3.4 – Entity-wide identification and analysis of changes that impact controls
- Control Monitoring (CC4 Series) –
- CC4.1 – Regular evaluation to determine controls’ presence and effectiveness
- CC4.2 – Identification and communication of control deficiencies for correction
- Control Activities (CC5 Series) –
- CC5.1 – Selection and establishment of control activities for risk mitigation
- CC5.2 – Selection and establishment of control activities for general security
- CC5.3 – Deployment of control practices per clearly defined institutional policy
Beyond these, there are also four Common Criteria unique to the TSC that build upon COSO Principle 12, which calls for specific controls relative to a particular service engagement:
- Logical and Physical Access Controls (CC6 Series) – Eight criteria restricting and controlling physical, proximal, and logical (i.e., virtual) access to protected information
- System Operations (CC7 Series) – Five criteria governing system-wide monitoring to ensure security systems are functioning properly and addressing anomalous incidents
- Change Management (CC8 Series) – One criterion ensuring that all security-relevant changes are accounted for, including authorization, implementation, and adjustment
- Risk Mitigation (CC9 Series) – Two criteria specifying requirements for risk mitigation, both for internal risks related to objectives and external risks arising from third parties
And, aside from the Common Criteria, each Trust Service Principle besides Security has a set of supplemental criteria applicable to it (e.g., A Series, PI Series). These may or may not come into play in an individual SOC 2 assessment, depending on the goals of the target organization.
SOC for Cybersecurity: Applicability and Considerations
The SOC for Cybersecurity is a standalone SOC framework, apart from the mainline SOC 1, SOC 2, and SOC 3 attestation standards. It applies to cybersecurity concerns across a broad range of organizations, including both service organizations and any other businesses. Unlike SOC 2 attestations, the purpose of a SOC for Cybersecurity report is to describe the nature and status of an organization’s cybersecurity programs. These reports are intended for a general audience rather than strictly for specialists. Therefore, they are lower stakes and generally not required.
Like SOC 2, SOC for Cybersecurity is also guided by a specific framework of criteria. However, unlike SOC 2, these criteria are meant as descriptors rather than measurements. And, unlike SOC 2, they are not required—assessors are free to use any set of controls deemed most applicable to the organization. For example, a healthcare organization may defer to HIPAA or HITRUST CSF requirements rather than the baseline SOC for Cybersecurity framework. Or an organization that requires PCI compliance may use the DSS framework. SOC for Cybersecurity is flexible.
SOC for Cybersecurity Categories of Description Criteria
The primary SOC Cybersecurity framework is AICPA’s Description Criteria for Management’s Description of the Entity’s Cybersecurity Risk Management Program. The Description Criteria (DC) proper are distributed across nine categories, analogous to the TSC’s Common Criteria:
- Nature of Business and Operations –
- DC1 – Describe the nature of the entity’s business model and operations, including all products sold and services rendered, along with methods used
- Nature of the Information at Risk –
- DC2 – Describe the primary forms of sensitive information the entity creates, collects, transmits, processes, stores, or otherwise comes into contact with
- Cybersecurity Program Objectives –
- DC3 – Describe the entity’s risk management program objectives with respect to data availability, data confidentiality, data integrity, and data processing integrity
- DC4 – Describe the process(es) by which the entity approves, develops or acquires, deploys, maintains, and adjusts its cybersecurity objectives
- Factors Impacting Cybersecurity Risks –
- DC5 – Describe all factors that can or do impact cybersecurity risks, including technologies used, connections between them, third parties, delivery channels, characteristics of users, and environmental or other changes impacting the entity
- DC6 – Describe security incidents that impacted the entity’s security objectives, including the incident’s nature, timing, duration, extent, and impacts on the entity
- Cybersecurity Risk Governance Structure –
- DC7 – Describe the process for managing and communicating integrity and ethics to support the full functionality of the cybersecurity program, per objectives
- DC8 – Describe the process(es) by which the board executes oversight of the entity’s various cybersecurity and risk management programs, per objectives
- DC9 – Describe the reporting lines established for cybersecurity accountability
- DC10 – Describe the process(es) by which the entity recruits, hires, develops, and retains competent individuals—and holds them accountable, when needed
- Cybersecurity Risk Assessment Process –
- DC11 – Describe the process(es) by which the entity identifies and assesses all cybersecurity risks and changes that could indicate challenges to risk mitigation
- DC12 – Describe the process(s) by which the entity identifies and assesses all vulnerabilities specific to its vendors, business partners, and other third parties
- Communications and Information –
- DC13 – Describe the process(es) for internal communication regarding security events and responsibilities, including thresholds for triggering communications
- DC14 – Describe the process(es) for external communication regarding security events and responsibilities, including thresholds for triggering communications
- Risk Management Program Monitoring –
- DC15 – Describe the process(es) by which the entity conducts regular, periodic evaluations to ensure operational effectiveness for all cybersecurity measures
- DC16 – Describe the process(es) for swiftly evaluating and communicating risk mitigation responsibilities to all parties responsible for taking corrective actions
- Cybersecurity Control Processes –
- DC17 – Describe the process(es) for developing and implementing risk response
- DC18 – Describe the entity’s IT infrastructure and network architecture in detail
- DC19 – Describe all critical security policies and procedures implemented by the entity to address risks, including prevention of security events, detection and immediate response to incidents, management of capacity, and data protection
These criteria offer general guidance on how an organization’s cybersecurity programs ought to be described, irrespective of any other framework that is used. The only requirement is that any controls or descriptions used meet or exceed their equivalents or analogs in the DC above.
Other Applicable SOC Frameworks and Assessments
SOC 2 and SOC for Cybersecurity are not the only SOC attestation frameworks. There are also SOC 1 and SOC 3 reports within the mainline SOC suite. A SOC 1 report differs from SOC 2 in that it targets financial services organizations and assesses their controls of internal reporting. A SOC 3 report is much more similar to a SOC 2 report, but it is intended for a general audience.
On another level altogether, there is another specialized SOC attestation: SOC for Supply Chain. Similar to SOC for Cybersecurity, it abandons the TSC in favor of a tailored framework, the Description Criteria for a Description of an Entity’s Production, Manufacturing, or Distribution System in a SOC for Supply Chain Report (DC Section 300). And, like SOC for Cybersecurity, a SOC for Supply Chain report comprises descriptions rather than prescriptive requirements.
For these reasons, SOC 2 is the optimal SOC attestation for most service organizations.
RSI Security: Comprehensive SOC Assessment Advisory
To recap, the biggest differences in SOC for Cybersecurity vs SOC 2 mostly concern the open endedness of the former, contrasting with strict definitions in the latter. Both are audit protocols within the System and Organizations Controls suite, overseen by the AICPA. In addition, both require an organization to work with a third-party auditor to generate a SOC report.
But, whereas SOC for Cybersecurity can use any framework as a baseline, SOC 2 requires the use of the TSC. This makes for added trust assurance, if also a more challenging assessment.