SOC 2 Common Criteria Explained

Share:

In 2017, the American Institute of Certified Public Accountants (AICPA) announced major changes to its Trust Services Criteria (TSC). AICPA’s changes to TSC affected the controls included in SOC 2 reports. The new SOC 2 common criteria are similar to the existing framework, but there are some major changes of which you should be aware.
This post breaks down what the SOC 2 Common Criteria are and what they mean for your business.

What Are the SOC 2 Common Criteria?

There are nine SOC 2 common criteria:

  • CC1 – Control Environment
  • CC2 – Communication and Information
  • CC3 – Risk Assessment
  • CC4 – Monitoring Activities
  • CC5 – Control Activities
  • CC6 – Logical and Physical Access Controls
  • CC7 – System Operations
  • CC8 – Change Management
  • CC9 – Risk Mitigation

Each of these criteria fall into a framework and have a particular goal. Here’s a quick snapshot of what it looks like laid out:

CC Framework

Now we will go into detail about each one:

CC1 – Control Environment

CC1 is part of the management and communications framework in the SOC 2 Common Criteria. Its goal is to enable the organization’s management and its board to value integrity and security.

Under CC1, the management commits to security and considers it carefully during hiring decisions (as well as during the evaluation and reporting processes). The board has independent oversight over the management.

The key SOC 2 deliverables or activities are ensuring the management understands SOC 2 common criteria and security, and operates accordingly. To guarantee these deliverables, you’ll need HR information systems, which includes a handbook, an org chart, and other crucial components. You’ll also need a solution that manages SaaS vendors to keep your company safe and reduce risk.

CC2 – Communication and Information

CC2 also falls under the management and communications framework. The goal of CC2 is to create quality policies and procedures that safeguard the firm, as well as to communicate clearly internally and externally. When CC2 is in place, the company should generate and use high-caliber information and documentation so it operates smoothly. Moreover, the firm shares this data inside and outside of its walls.

Key deliverables include high-quality, complete procedures, documentation, and tools that ensure and validate internal and external communication. A good way to store those documents would be in Notion, Google Docs, or another word-processing application.
The ideal software for this control would be something with audit capabilities, although email would work, too.

CC3 – Risk Assessment

CC3 falls into the risk assessment, monitoring, and control category. Its goal is to establish clear objectives, analyze risks to achieve those, and monitor how changes impact risk.

Objectives should be clear enough to assess existing and potential risks, address those risks and update risk assessments with changes to the system. The deliverables for this control are risk assessment processes (including regular updates), with robust documentation on risk assessment procedures and assessment outcomes.

An essential document is a risk assessment tracker, which can be stored in one of the word-processing applications mentioned above.

CC4 – Monitoring Activities

CC4 also falls into the risk assessment, monitoring, and control category. Its aim is to continually monitor, evaluate, and communicate the effectiveness of internal controls. These evaluations are ongoing. The communication component shares news internally and externally of deficiencies, as appropriate.

Deliverables for this control include policies and procedures to monitor compliance and evidence of ongoing compliance and monitoring activities. Storing these documents in some kind of word-processing application makes them easily accessible.

In terms of software to support this control, it helps to have something for department-specific workflows to easily export evidence.

CC5 – Control Activities

CC5 is the last of the controls in the risk assessment, monitoring, and control category. Its objective is to develop clear controls for processes and technology to mitigate risks and achieve objectives. There are clear policies to establish expectations and procedures to ensure compliance.

Key deliverables include evidence showing risk control activities and risk management procedures. You’ll need documentation of risk management procedures; storing them in word-processing apps makes them accessible.

In terms of software, a technology-management solution as well as an HRIS or employee tracking system (to ensure training during onboarding) will help.

CC6 – Logical and Physical Access Controls

The best way to think of CC6 is that it’s all about security. This control has three goals: ensure only the right people have access to key data, secure/encrypt data at all times, and physically protect servers and data. The key deliverables are robust security practices for physical, servers, work stations, employees, etc., and proof they are working.

Three types of software support this control: employee access control that includes onboarding and off-boarding capabilities, technical infrastructure security, and engineering access.

CC7 – Systems Operations

The seventh of the SOC 2 Common Criteria falls into the robust servers and infrastructure framework. Its aim is to ensure the system is working and robust, which includes ongoing monitoring, incidents response and evaluation, and disaster recovery.

Key deliverables for this control include business continuity and disaster recovery plans and incident reporting, as well as verification they work. As such, documentation consists of those plans and reports.

Your cloud services provider can offer technical infrastructure planning and redundancy evaluations to satisfy these requirements.

CC8 – Change Management

CC8 falls into the infrastructure change management category of the SOC 2 Common Criteria. The eighth of the SOC 2 Common Criteria is about authorizing, designing, developing/acquiring, configuring, documenting, testing, approving, and implementing changes to infrastructure, data, software, and procedures to meet organizational goals.

Your deliverables for this control will be clear controls for how technical infrastructure changes and proof these changes have taken place. Github pull requests and engineering workflows support those deliverables.

CC9 – Risk Mitigation

The final control in the SOC 2 Common Criteria is risk mitigation, which is part of the risk mitigation and vendor management framework. Its goal is to mitigate risk through business processes and vendor management.

To fulfill this control, your deliverables will be business continuity, business insurance, and sound vendor management practices such as vendor due diligence and management (especially for primary cloud vendors). You’ll need vendor processes, assessments, and approvals.

Meet SOC 2 Common Criteria with Robust SaaS Management

Now that you understand the SOC 2 Common Criteria, use our SOC 2 Compliance Playbook to guide you through your first audit.