The compliance landscape is constantly evolving, and so are the standards that govern it. SOC 2®, a widely recognized framework for assessing service organizations’ controls, has recently undergone revisions. In this blog post, we’ll dive into the latest version of SOC 2® and explore the key changes to what are known as “points of focus,” designed to enhance the effectiveness and relevance of SOC 2® audits. Whether you’re a service provider or a practitioner, understanding these revisions is crucial for maintaining compliance and trust.
The evolution of SOC 2®
Before we explore the latest revisions, let’s briefly understand what SOC 2® is and why it matters. SOC 2®, short for Service Organization Control 2,® is an attestation standard developed by the American Institute of CPAs (AICPA) in 2010. It assesses the controls a service organization implements to protect customer data and other sensitive information. Before a SOC 2® report is issued, an independent CPA firm conducts an assessment of the scope, design, and (for Type 2 reports) the operating effectiveness of internal control processes. The scope of a SOC 2® report is determined by your organization and your SOC 2® assessor.
In the ever-expanding digital world, where data breaches and cyber threats are all too common, SOC 2® provides assurance to customers, partners, and stakeholders that your organization has taken necessary steps to safeguard their data. It has become a standard requirement for many service providers, including data centers, cloud service providers, and SaaS companies.
Understanding the SOC 2® Trust Services Criteria
Unlike other frameworks like ISO 27001 and NIST 800-53, SOC 2® does not have a universal requirements checklist. Instead, the AICPA has provided Trust Service Criteria (TSC) with five categories: security, availability, processing integrity, confidentiality, and privacy. Each criteria contains Points of Focus (PoFs) as well, which are examples of how organizations can satisfy requirements and guidance when designing and implementing their control environments. They can also help SOC 2® auditors understand whether controls were suitably designed and operated effectively to achieve a company’s objectives.
A successful SOC 2® report can test against all five criteria, which we will discuss in detail below.
Security criteria is the only required category for a SOC 2® audit. The security criteria enforces the protection of data and systems against unauthorized access. A company might implement a form of access control for SOC 2® security compliance, like using access control lists or identity management systems. Strengthening firewalls by introducing stricter outbound and incoming rules, introducing intrusion detection and recovery systems, and enforcing multi-factor authentication are also recommended ways to meet the security point of focus for SOC 2®.
Availability covers whether internal users and customers can use information and systems. It also examines your controls, ensuring that they support operation, monitoring, and maintenance. Your systems should meet availability SLAs at all times, which requires building inherently fault-tolerant systems that withstand stress tests. It also requires organizations to invest in performance and network monitoring systems, disaster recovery plans, and security incident handling.
3. Processing integrity
Processing integrity asks the key question: does the system work the way it needs to without delay, error, omission, or accidental manipulation? Customers — and their auditors — need to know whether systems operate as expected without impairments, delays, incorrect processing, or unauthorized or accidental manipulation. Auditors typically evaluate processing integrity for completeness, validity, accuracy, timeliness, and authorization. These evaluations focus on data inputs, the actual processing, outputs, and how the data is stored and protected.
Confidential data is defined as data that only a specific group of people should access, which could include application source code, usernames and passwords, credit card information, or business plans. SOC 2® requires that organizations encrypt this data, both at rest and during transit. Additionally, when providing access to confidential data, companies must adhere to the principle of leastprivilege, where they grant the bare-minimum permissions to the data so those who can access it can do their jobs but not receive more information than necessary.
The newest SOC 2® version: what’s changed?
So, now that we have a better understanding of the TSC, let’s talk about what exactly changed in the newest version of SOC 2®. The AICPA has updated and revised the PoFs for each criteria, which have undergone significant changes in this new revision, including:
- Additional clarity on the risk assessment process
- Outlining specific risks to consider
- New attestation standards
- Additional clarity on certain disclosure requirements
The SOC 2 revision provides clarity on:
- New points of focus and clarification of existing points of focus to better support the criteria
- How an auditor should proceed when a service organization is presenting controls related to another framework outside the SOC 2 Trust Services Criteria
- Key differences between the “Confidentiality” and “Privacy” categories and when it’s appropriate for a service organization to report on their respective controls
- Improving controls that support implementing all five categories to address the changing landscape of threat management
- Differentiating privacy points of focus as a “data controller” vs. a “data processor”
- Differences between the Confidentiality and Privacy categories and when to report on their controls
- How management and a service auditor should account for controls that may have operated outside the specified period, and how to consider the relevance of controls that operated prior to the specified period
- How to incorporate new changes to CPA attestation standards
- Clarity on objectives for service organizations and how they relate to the service commitments and system requirements
- Categorizing sub-service organizations vs. vendors and appropriate types of controls or disclosures related to the use of specialists by management
- Identifying the use of software and tools that help with detecting threats and vulnerabilities like firewalls, intrusion prevention, and detection systems
- How to address data storage, backup, and retention as it relates to confidentiality
Overall, the impact is minimal. If your organization has already identified and mitigated your primary risks, many of the controls affected are already in place. The new points of focus should only result in new or revised controls if you and your auditor determine that your existing controls do not adequately address the criteria. Organizations operating on the previous version of SOC 2® are not required to update to this new version. As per the AICPA:
These updates to PoFs provide additional clarity for each category and modernize them to include new and emerging technologies, threats, vulnerabilities, and mitigation tactics. In case you’re curious about what revisions the AICPA made, we’ve broken down the highlights and most significant revisions below.
Information and communication
The revisions provide additional guidance on how to manage and identify threats to data recovery, how to create more effective mitigation strategies, and how to better align with other privacy best practices, like those outlined in the COSO framework.
Here are a few specifics:
CC2.1: addresses management, classification, completeness and accuracy (C&A), and asset storage.
CC2.2: addresses communication concerns relating to privacy knowledge and awareness and reporting of incidents related to privacy (*when Privacy TSC is applicable).
CC2.3: addresses communicating about privacy-related incidents (*when Privacy TSC is applicable)
The revisions provide additional clarity on information relevant to internal control systems, like:
- Asset inventory and location
- How to classify information
- Clarity on data flow
- C&A of information used in a system
Here is the most notable change in this revision:
CC1.3 and CC1.5: these two items address newly identified privacy concerns for reporting lines and disciplinary actions.
The revisions of the Risk Assessments PoFs outline a more detailed approach to evaluating risks by defining the components of a risk assessment as:
- Identifying threats and vulnerabilities
- Evaluating the likelihood and impact of a threat intersecting with a vulnerability
Here are the most notable changes in this revision:
CC3.2: addresses the identification of system component vulnerabilities and provides more guidance on assessing the significance of risks for the sub-service organization.
CC3.4: assesses changes in internal and external threats and vulnerabilities an organization may encounter.
Logical and physical access
Updated points of focus for logical and physical access encourage program participants to evaluate all logical access controls across an organization, including:
- Types of access (employee, contractor, vendor, or partner)
- Device recovery (laptops, work phones)
- IT tools
- System and service accounts
Here are the most notable changes in this revision:
CC6.1: addresses accessing and using confidential information for identified purposes when Confidential TSC is applicable.
CC6.4: addresses recovering physical devices.
System operations and monitoring
The revisions for system operations and monitoring encourage program participants to consider activities performed by the first and second lines of defense in addition to internal audit functions and other IT assessments historically identified in SOC 2® reports.
Here are the most notable changes in this revision:
CC7.3: addresses the impact on, use, or disclosure of confidential information in the case of a security event when Confidential TSC is applicable.
CC7.4: addresses the definition of and execution of breach response procedures when the Privacy TSC is applicable.
Previously, identification, testing, and implementation of software patches and resilience requirements were not included in the Change Management category, and these have been added as PoFs to provide more clarity.
Here’s the most notable update:
CC8.1: addresses the process for managing patch changes and the design and testing phases for system resilience when the Availability TSC is applicable and privacy requirements in the design phase when the Privacy TSC is applicable.
The updated points of focus for risk mitigation provide guidance on residual risks that remain after internal controls are in place and management has evaluated whether to accept, reduce, or share risks.
Here is the most notable change from the revision:
CC9.2: addresses identifying and evaluating vendor risks and vulnerabilities that arise from business partnerships.
What’s changing in Hyperproof?
The short answer: not much!
The changes outlined above are updated guidance for organizations and auditors alike. For many organizations, these changes will only have a minor impact on audit engagements. Organizations may be asked to tailor existing controls to cover these changes or provide revised evidence. In other cases, your auditor may determine that new controls are needed to address the new points of focus.
Organizations operating on the previous version of SOC 2® are not required to update to this new version. However, these new and revised points of focus have been added to the existing requirements and are available for those who would like to update to the newest version of SOC 2® in Hyperproof.
If you would like to update to the new version of SOC 2® in Hyperproof, you’re in luck! It’s simple: because this program shares the same requirement IDs as the previous version, you can simply download your existing controls from your original SOC 2® program and re-upload them to the revised program.
You might be wondering: does this affect any of my existing controls?
Nope! All of the existing functionality for SOC 2® still exists, including Trust Category selection and crosswalks. Nothing has changed about these functionalities.
How are controls impacted?
To ensure that all points of focus are covered, we’ve added over 50 new illustrative controls to the SOC 2® framework in Hyperproof and revised close to 100 existing controls. These new controls use language from AICPA sources, including the AICPA illustrative controls report and the points of focus themselves. We made minor modifications to control names to improve readability and reduce redundancy, including the following:
Updated naming conventions
We have updated the naming convention to reference the primary point of focus each control originates from to reduce confusion.
We’ve reduced redundant controls.
Example: “CC1.3-PO2” now covers points of focus in CC4.1 as well as CC1.3
And just a quick note from our experts: if you’re just getting started with SOC 2®, you can use illustrative controls from a second, more prescriptive program like NIST CSF or CIS Security Controls to jumpstart your program and provide a more robust control language from the start.
Are you ready for your next SOC 2® audit? Hyperproof can help!
As technology and security threats evolve, so must our standards and practices. The latest version of SOC 2® reflects these changes by introducing new points of focus and refining existing ones. Staying informed and adapting to these revisions is essential for maintaining trust and compliance in an ever-changing cybersecurity landscape. Hyperproof’s out-of-the-box SOC 2® program template can get you started in minutes. You can even automate evidence collection for your next SOC 2® audit, easily assign tasks to collaborators, communicate with your SOC 2® auditor within the platform, reuse your SOC 2® work to satisfy other frameworks, and so much more. Get in touch for a demo today!