Organizations currently subject to a SOC 2 Examination or that intend to be subject to a SOC 2 Examination, along with their auditors, must use guidance issued by the American Institute of Certified Public Accountants (AICPA), as the “rule-book” for these reports.  In October 2022, the AICPA issued updates to this SOC 2 guidance that address:

• Criteria organizations and auditors use to evaluate SOC 2 report controls,
• Criteria organizations use to describe their systems in the SOC 2 report, and
• SOC 2 Audit Guide that auditors use when performing SOC 2 Examinations.

Organizations planning to issue a SOC 2 report to customers in 2023 may need to make changes to their controls and their system description from prior SOC 2 reports as a result of this guidance.

KEY POINT: The 2022 guidance changes are intended to help organizations better meet the information needs of their customers and business partners who use their SOC 2 reports.  It will be well worth the effort to absorb and embrace this new guidance for 2023 reports, but organizations should start now.

The remainder of this article focuses on two elements of the 2022 guidance: expanded guidance on how to evaluate SOC 2 report controls, and expanded guidance on the system description.

What’s Changing in SOC 2 Control Guidance and Why?

AICPA Trust Service Criteria (TSC) is the guidance organizations and auditors use to develop and audit SOC 2 controls. The TSC are supported by points of focus (POF) that are used to evaluate if the controls are designed and operating effectively to meet the SOC 2 criteria.  Think of the POFs as the suggestions and examples of how and what an organization’s controls should include to meet the intent of the TSCs.

KEY POINT:  The official TSC list is not changing; however, new & clarified POFs have been developed in support of the TSCs.

Per the AICPA, the revised POFs are intended to “better support application of the TSC”, with four reasons provided:

• Ever-changing technologies, threats and vulnerabilities, and other matters that may create additional risks to organizations.
• Addressing changing legal and regulatory requirements and related cultural expectations regarding privacy.
• Addressing data management (for example, data storage, backup, and retention), particularly when related to confidentiality.
• Differentiating which points of focus related to privacy may apply only to an organization that is a data controller or only to an organization that is a data processor (as defined)

Here is an example of how the TSCs and POFs interact and one of the expanded elements of this 2022 guidance:

• TSC (1, unchanged from the past): The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity’s objectives.
  • One (of several) POFs in support of TSC CC6.1: Identifies and Authenticates Users

Other expansions of the POFs in the 2022 revised guidance include:

• Risk assessment — Expanded POFs detail evaluating risks by understanding the underlying components of risk assessment: threat and vulnerability identification and the evaluation of the likelihood and magnitude of a threat event intersecting with a vulnerability.
• Logical access (in addition to the example above)— ensuring all types of types of access are addressed, including employees, contractors, vendors, and business partners; describing the periodic user access review including how inappropriate system or service accounts are reviewed.
• Monitoring activities —The POF regarding whether the organization “considers different types of ongoing and separate evaluations” was expanded to encourage organizations to think broadly in terms of what constitutes monitoring and includes examples of penetration testing, independent certification against established specifications (e.g., ISO certifications), first- and second-line monitoring and control testing, internal audit assessments, compliance assessments, penetration testing, and third party assessments.
• Change management — The existing POF on “deploying system changes” has been expanded to address consideration of segregation of responsibilities (for example, restricting unilateral code development or testing and implementation by a single user) to prevent or detect unauthorized changes. And a new POF addresses process in place to identify, evaluate, test, approve, and implement patches in a timely manner on infrastructure and software.
• Availability — New POF regarding identification of threats to data recoverability and mitigation procedures.
• Privacy — POFs were updated for typical practices. Example: Disciplinary Actions — A sanctions process is defined, and applied as needed, when an employee violates the entity’s privacy policies or when an employee’s negligent behavior causes a privacy incident.

KEY POINT: The guidance does not require every POF to be met, but organizations should consider the applicability of each POF. The applicability of each POF depends on the facts and circumstances of the organization. 

What’s Changing in SOC 2 System Description Guidance?

The AICPA Description Criteria (DC) guidance outlines what is to be included in the organization’s system description, often the most lengthy section of a SOC 2 report.   As a reminder, the system description is your organization’s opportunity to present who your organization is, what services you provide, and how you provide the service (e.g., people, process & technology).

KEY POINT: The official description criteria have not changed.  New guidance serves to expand on the existing DC and provides useful clarifications and examples.

Key clarifications and examples provided in the expanded DC guidance includes:

• Emphasizing the importance of providing sufficient detail about the organization’s principal “service commitments and system requirements (SC/SR)”, including:
  • Not all SC/SR require disclosure, just “principal” SC/SR which are those that support understanding the services, system, and controls which apply to a broad range of SOC 2 report users.
  • SC/SR made by the service organization influence the scope of the SOC 2. For example, cloud service providers may choose availability as a category for their SOC 2 scope because of its importance to a broad range of users who expect a commitment of consistent availability.
  • Clarifying when disclosure of a control framework makes sense. For example, since many organizations have adopted the NIST Cybersecurity Framework (CSF), the guidance gives an example of mentioning adoption of the CSF in the service commitments section.

• Emphasizing that tools should be included when describing the software components of the system description. Examples of tools that would be appropriate to list in the report are firewalls, IPS systems, monitoring tools, tools that automate controls, and security information & event management (SIEM) systems

• Clarifying the thought process as to when to disclose a security incident in the system description. Organizations are encouraged to determine whether the incident resulted from ineffective controls shared among all the organization’s systems. If so, challenge whether controls such as segmentation between systems would prevent a similar breach from occurring in the system in the report. If there are no such controls to prevent a similar breach in the system being described, organizations should disclose the incident
• Emphasizing the need to disclose the organization’s risk assessment process with examples such as:
  • Risks that may have a significant effect on the organization’s ability to achieve its SC/SR,
  • Whether any aspect of risk assessment is performed by third parties, and
  • Process for addressing risks introduced by use of subservice organizations or other third parties, including those that have access to customer and employee data

AARC-360 is here to help!

Contact the AARC-360 team to understand how the new guidance specifically relates to your organization.  We will work with you to:

• Review your principal SC/SR disclosures for sufficiency.
• Review the process and control frameworks you have adopted, and whether disclosure of those frameworks in their system description makes sense.
• Review the new/expanded POFs for the relevant controls in your report (including risk assessment, monitoring and the other areas above) to ensure the controls are broad enough to meet the new guidance.