The AICPA released an updated SOC 2® Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy (guide) to system and organization control (SOC) examinations, sometimes referred to as SOC audits. The guide provides updates to trust services criteria points of interest and additional clarity related to disclosure requirements, among other things.
This article covers updates within the following areas:
- Description criteria
- Trust Services Criteria points of focus
- Objectives, service commitments, and system requirements
- Select the Trust Services Category or Categories to be addressed by the SOC 2 audit
- Distinction between the confidentiality category and the privacy category
- Meeting the requirements of a process or control framework and SOC 2+
- Considerations related to subservice organizations and use of specialists
- IT services
- Management review controls
- Relevancy of controls that operated prior to an examination period
Description Criteria
The new publication offers updated guidance related to various topics within the Description Criteria. See the topics below for a brief description of what has changed.
Report Format
The guide provides increased clarity around report format and subject grouping within the system description in Section III, emphasizing there’s no prescribed format and that subjects could be grouped by control families or objectives as long as description criteria are met.
It also provides increased guidance for disclosing how controls meet the requirements of a process or control framework as outlined in a SOC 2+ report.
Mapped Controls
While not required, it’s good practice to have the controls mapped back to the relevant criteria in each of the trust services categories to more clearly show how the organization achieved the service organization’s commitments and system requirements.
Presentation of the Description and Level of Information
The guide is updated to clarify that refined language can help with describing the system without divulging too much information where that could present a security risk to the service organization.
Updated considerations around the level of detail include:
- The needs of report users to understand the nature of the risks faced by the service organization
- The impact of the realization of those risks
- The potential of a hostile party using the information provided to expose vulnerabilities in the service organization’s system
Deficiencies or Misstatements
The guide provides clarity that wording used to make disclosures shouldn’t omit or distort important facts and details that would be relevant to the user.
Other related updates include:
- Updates to materiality and disclosures related to deficiencies
- Misstatements that affect compliance with laws or regulations
- Effect of a misstatement or potential misstatement on the description as a whole
Disclosure of System Incidents and Control Deficiencies Considerations
Information related to disclosure of system incidents and determining disclosure requirements has been updated.
If a system incident occurred that didn’t affect the system in scope, there should be consideration given if the incident occurred due to a control failure that also applies to the system in scope if there could be a vulnerability or ineffective control affecting the in-scope system.
Infrastructure Description
There are more examples describing infrastructure used by the service organization to provide services, and the guide suggests including technical terms that describe the architecture and operation of the system.
Disclosures of Risk Assessment Process
The updated guide addresses disclosure of information related to the risk assessment process and specific risks. There is increased clarity on what should be disclosed about the service organization’s risk assessment process, namely disclosure of:
- Risks that may have a significant effect on the service organization’s ability to achieve service commitments
- Any aspects of the risk assessment performed by third parties
- Mitigation and assessment of risks related to subservice organizations or other third parties
Criterion Carried Out by Third Parties
Criterion relevancy, even if all components of the system used to meet a specific criterion are carried out by a third party, has been clarified.
The updated guide states that these criteria are still relevant and shouldn’t be described as not applicable but should be described in terms of how the service organization still meets the criterion through use of a third party or subservice organization.
Trust Services Criteria Points of Focus
The guide addresses several issues, including that not every point of focus needs to be addressed by a service organization’s controls. Instead, the service organization and auditor should determine if the criteria are materially met by the controls of the service organization. There are also several specific updates to the points of focus.
Definition of Board of Directors
The definition of board of directors used in the criteria has been clarified, and the guide recognizes that smaller, less complex organizations may meet governance and oversight objectives with a simplified organizational structure.
Common Criteria and Privacy
The document offers additional guidance for which common criteria have additional points of focus when the Privacy Category is in scope for SOC 2 audit.
Obtaining or Generating and Using Relevant, Quality Information
Additional points of focus add clarity for meeting common criteria 2.1, which reads, “The entity obtains or generates and uses relevant, quality information to support the functioning of internal control.”
These points of focus are:
- Documented data flow diagrams
- Manages assets through identification, documentation, and maintenance of records
- Classifies information by relevant characteristics
- Use of information in performing controls is complete and accurate
- Manages location of devices especially for those outside the physical security control of the service organization, such as software and data stored on vendor devices or employee bring your own device (BYOD)
Assess Changes in Threats
An additional point of focus is offered on assessing changes in threats and vulnerabilities through the risk assessment process.
Logical Access
There’s a new point of focus in logical access in considering new or significantly updated architectures and assessing their impact on security prior to implementation.
Physical Devices
A new point of focus was added to recover physical devices when access to those devices is no longer required by an authorized user.
Change Management
Clarified guidance was added related to the change management points of focus including segregation of duties, testing of system changes, and managing patch changes.
Identify and Assess Vulnerabilities
A point of focus was added on identifying and assessing vulnerabilities associated with the use of vendors, business partners, and other third parties.
Data Recoverability
A point of focus was added for the service organization to consider data recoverability and threats like ransomware.
Data Retention
An added point of focus deals with data retention of confidential information and that data shouldn’t be retained for longer than is necessary to fulfill the identified purpose.
Privacy Notices
Further guidance is offered regarding using clear language in privacy notices.
This includes:
- Making notices easily accessible and available
- Reviewing the notice on a periodic basis
- Communicating any changes to the notice
- Retaining prior notices
Data Controllers Versus Data Processors
Clear identifiers were added in the privacy criterion of each point of focus and its applicability to data controllers versus data processors.
Objectives, Service Commitments, and System Requirements
The updated guide provides more information around disclosure of service commitments and system requirements. Several topics were added for consideration by the service organization to include in the system description when presenting their objectives, service commitments, and system requirements.
Mission and Vision
Guidance has been provided on the service organization’s adoption of a mission and vision. There’s guidance for setting strategies and establishing objectives to help achieve these, including the relation of internal controls and risk mitigation strategies.
Understand Service Commitments and System Requirements
The guide clarifies that report users generally need an understanding of the nature of the service organization’s service commitments and system requirements to comprehend the services provided, the system, and design and operation of controls within that system.
Principal Service Commitments and System Requirements
The guide clarifies that service commitments and system requirements should be disclosed and presented that are useful to a broad range of SOC 2 report users. The list isn’t intended to be exhaustive but should be applicable to a broad range of SOC 2 report users.
Understand Objectives
Disclosure of the principal service commitments and system requirements provides SOC 2 report users with an understanding of the objectives that drive the operation of the system and how the applicable trust services criteria were used to evaluate whether controls were suitably designed and operated effectively.
Select the Trust Services Category or Categories to Be Addressed by the SOC 2 Audit
The updated guide offers points to consider in determining which categories a service organization should include for presentation.
Selection of Trust Services Categories
An added section provides guidance on how the Trust Services Category or Categories should be selected for examination by the service organization.
Needs of the Intended Users
Generally, the service organization should select the category or categories that would best meet the information needs of intended users.
This is also determined by considering the risks that the use of the service organization presents to user entities and the principal service commitments made to them.
Applicability of Trust Services Categories
Examples were added of when certain Trust Services Categories apply to service organizations based on the service commitments and system requirements.
Reports could be misleading if they only examine a single Trust Services Category. The service organization should consider the information most relevant and pertinent to user entities. For example, a report that only addresses availability may be misleading if user entities are also concerned about cybersecurity risks with using the system.
Distinction Between the Confidentiality Category and the Privacy Category
This update presents key differences between these two categories, when appropriate for a service organization to report on controls included in them, and differences for data controllers versus data processors in addressing privacy.
Define Categories
Another key update within the guide further expounds on the distinction between privacy and confidentiality categories.
The guide defines confidentiality as pertaining to sensitive information, distinct from privacy, which relates to personal information.
Personal information is also further clarified as nonpublic information that relates to an identifiable individual. Sensitive information may consist of a variety of different types of nonpublic information including proprietary information, and personal information.
Protecting Personal Information
In addition to existing guidance when including the Privacy Trust Services Criteria, the AICPA now suggests considering processes that address protecting personal information from unauthorized or inappropriate use or disclosure as part of the examination when selecting the Privacy Trust Services Criteria.
Details About Privacy
Continuing its refinement of the Points of Focus, the AICPA acknowledges and addresses the distinct application of the privacy category based on the role played by the service organization.
When it comes to handling personal information, service organizations fall into one of two classifications:
- A data controller determines the purposes and means of the processing of personal data
- A data processor processes personal data on behalf of the data controller
The updated guide adds identifiers for both data controllers and data processors to the Points of Focus relevant to the Privacy Trust Services Criteria.
This is intended to help the service organization and the service auditor identify where certain Points of Focus may be relevant based on the role they serve in handling personal data.
Meeting the Requirements of a Process or Control Framework and SOC 2+
This update includes greater detail when a service organization presents controls related to frameworks or requirements outside of the SOC 2 Trust Services Categories.
Process or Control Frameworks
The service organization may find the implementation of security, privacy, or regulatory process or controls frameworks appropriate or beneficial.
The guide dives deeper into the treatment of management establishing service commitments and system requirements regarding the requirements of a process or control framework such as HIPAA, NIST CSF, ISO 27001, or similar.
Presenting the process or controls frameworks within the SOC 2 report can be achieved either as a disclosure within unaudited Section V of the SOC 2 report or through the inclusion of additional points of focus when the evaluation of control design, suitability, and operating effectiveness is required.
SOC 2+
A SOC 2 audit that includes an additional opinion about matters that aren’t normally in-scope for a SOC 2 audit is known as a SOC 2+.
In instances where the users of the report want assurance about service commitments and system requirements regarding implementing a process or control framework, management may engage the SOC auditor to perform a SOC 2+ audit.
The service auditor will evaluate the implemented controls and form an opinion on the additional criteria selected for the SOC 2+ audit.
Considerations Related to Subservice Organizations and Use of Specialists
This update provides guidance on identifying vendors versus subservice organizations, and appropriate controls and disclosures related to the use of specialists by management.
Identify Subservice Organizations
Many service organizations rely on one or more vendors for outsourced functions, and the guide offers a deeper understanding of the considerations for identifying subservice organizations.
To be considered a subservice provider both the services provided by the vendor and internal controls at the vendor should be relevant and necessary to the report users’ understanding of the service organization’s system, its service commitments, and system requirements.
In instances where either the service provider’s controls or their monitoring of the vendor’s controls alone can provide reasonable assurance, the vendor’s controls over its services aren’t likely relevant to the SOC 2.
Oversight of Specialists
When management engages specialists such as security specialists or disaster recovery simulation providers, one must fully understand the frequency and significance of the specialist services to determine whether they qualify as a subservice provider or not.
Management retains responsibility for oversight of the specialist’s work.
This could lead to conversations about subservice providers and specialists with the examiner and the appropriate treatment for each of those within SOC 2.
IT Services
This update clarifies independence responsibilities for CPAs providing services such as the design, implementation, or integration of governance, risk, and compliance (GRC) or SOC 2 tools, monitoring services, and the threat of self-review.
The new guidance cautions that if a service organization’s auditor provides assistance with the design, implementation, or integration of the GRC or SOC 2 tool, the auditor needs to assess if that work impairs their independence.
How Can GRC Tool Guidance Impact a SOC 2 Audit?
Understand the auditor likely won’t be able to help with implementation or setup of the GRC or SOC 2 tool or anything that may affect their independence.
Management should do these tasks with the assistance of the GRC or SOC 2 tool vendor.
Management Review Controls
This update includes additional information related to how management should perform review controls and the various considerations associated with that type of control.
Updated guidance regarding review controls —such as user access reviews, admin tool, and activity logs—and how auditors evaluate these controls require the auditors to understand how management performs the review control, including specific steps for performing the review, criteria, or thresholds that would require follow-up and what steps are taken when investigating any follow-ups.
The auditor will assess if the review control was performed consistently each time, that the review identified appropriate follow-ups, and that those follow-ups were addressed timely.
If review controls aren’t identifying appropriate follow-ups, the auditor may not have sufficient evidence to conclude that the control operated effectively during the examination period—as this may indicate that the review wasn’t robust enough or at an appropriate level of precision to identify items that need further follow-up.
The auditor may find it necessary to test the control by performing it again.
How Does a Management Review Control Affect a SOC 2 Audit?
When performing a review control, use a consistent approach, retain any documentation used, such as user access lists from the application in the case of a user access review, and resolve and document any follow-ups.
This will help the auditor assess the design and operating effectiveness of review controls.
Relevancy of Controls that Operated Prior to a SOC 2 Examination Period
This update gives recommendations and guidance on how management and a CPA should consider accounting for controls that may have operated outside a specific examination period.
When planning a SOC 2 audit, determine the period of time the audit will cover. Typically, this will be a 12-month period; for a first SOC 2 Type 2, it’s possible to opt for a shorter period, such as three, six, or nine months.
In those cases, consider the period controls were in place and operating to have enough evidence for the auditor to perform their testing.
Align Examination Period and Controls
This is particularly true for controls that operate on a periodic frequency such as semi-annually or annually.
If unable to align the examination period to semi-annual and annual controls, understand it could affect the SOC 2 report and the achievement of relative service commitments and system requirements.
Some things for management to consider are:
- If the control impacts other controls
- The period between when the control was performed
- The examination period
- The importance of the control in mitigating one or more risks relevant to service commitments and system requirements
If these controls are relevant to the achievement of service commitments and system requirements, and it’s not possible to shift the examination period to include those controls, the auditor might be able to determine the controls continued to be suitably designed—or note in the report that the controls operated outside of the examination period.
If the periodic control isn’t relevant or necessary to show that you’re achieving service commitments and system requirements, the control could be excluded from the audit.
Be sure to discuss this with the auditor prior to determining the examination period.
We’re Here to Help
If you have questions about the SOC 2 Guide, contact your Moss Adams professional.
Learn More: