ZenGRC

SOC 2 System Description: Key Elements and Preparation Steps

A SOC 2 system description is a crucial component of a SOC report that defines the scope and details of the people, processes, and technology supporting a service, enabling independent auditors to assess cybersecurity controls and provide assurance to customers about the vendor's trustworthiness, with SOC audits varying by focus (financial or cybersecurity) and type (design assessment or operational effectiveness over time).

A SOC 2 system description is an important part of a SOC report. It outlines the boundaries of the report and contains important details regarding the people, processes, and technology that support your product, software, or service. One cannot complete a SOC 2 audit without a clear, comprehensive system description.

As a reminder, “SOC” stands for System and Organization Controls. SOC audits assess the internal controls of service providers, to provide assurance to corporate customers that the vendors are trustworthy business partners.

What Is a SOC Report?

A SOC report is the final result of a SOC audit. A SOC audit assesses whether a service provider is adhering to certain best practices for financial reporting or cybersecurity. The audits, undertaken by independent auditors, are designed to give assurance and to assist potential customers in understanding any possible risks associated with dealing with the examined vendor.

When Do You Need a SOC Report?

SOC reports are not required by law. However, some corporations require prospective vendors to undergo a SOC audit before doing business with that vendor. Vendors might also volunteer to undergo a SOC audit to demonstrate their commitment to sound financial reporting or cybersecurity and make themselves more attractive to their customer base.

Types of SOC Audits

SOC audits come in several forms:

  • SOC 1: Assesses the financial controls of a service provider, in case that vendor helps its customers with their own financial reporting.
  • SOC 2: Assesses cybersecurity controls, so customers know whether they can entrust confidential data to the vendor.

SOC audits also come in two types:

  • Type I: Assesses the design of internal controls at a specific time, creating a baseline for future audits.
  • Type II: Determines whether those controls actually work as designed over a prolonged period (usually six or 12 months).

This post specifically refers to SOC 2 as it discusses the requirements for system descriptions.

During the audit, the auditor assesses various “Trust Services Criteria” (TSC) that might be in scope for the audit:

  • Security
  • Availability
  • Confidentiality
  • Processing Integrity
  • Privacy

Not every SOC audit will include all five TSCs, although many audits will. All SOC audits will include at least one, depending on the exact relationship you and your customer are considering.

What Is a SOC Report System Description?

The system description, part of Section III of a SOC 2 report, contains critical information about the people, processes, and technology that support your product or service. The system description is a synopsis of your organization and its system(s). It helps any reader to understand the internal control systems you have in place.

Why Is the System Description Important?

The system description is essential because the details included are vital to the auditor; they facilitate the auditing process.

Gathering those details can take time and effort. If they are incomplete, the auditor will come back with feedback that must be collected to complete the audit. The American Institute of Certified Public Accountants (AICPA), which develops SOC 2 audit standards, provides guidance to help compile your system description.

What Are the System Boundaries of a SOC 2 Report?

The System Boundaries section of your description is divided into five sub-sections. These detail the components of the system a service organization uses to fulfill its service commitments. The goal is to give enough detail to satisfy SOC audit requirements without divulging trade secrets.

System Components to Cover in Your SOC 2 System Description

Infrastructure

This section details the hardware, software, and SaaS components used in your systems’ infrastructure (both physical and virtual). This could include computing hardware, internet servers, storage, connections among these elements, and your cybersecurity monitoring technology. The documentation may incorporate lists, descriptions, and a diagram of your systems.

Product or Service

Define the product or service you market to customers. That includes the application (if relevant), system requirements, system processing guidelines, service level agreements, supporting databases, and mobile and desktop applications.

This list shouldn’t include your operational technology (e.g., payroll software, chat service, or project management tools).

This section will likely take the form of an introductory paragraph explaining, at a high level, how the application is used and a follow-up list of the components involved.

People

This section details the departments, teams, and functions that play a role in anything related to your product or service. It will likely be a list of your central departments, followed by an organizational chart. It should include third-party vendors or subcontractor organizations that support your offering.

Customer Data

You must describe the kinds of data that come into and move out of your product or service systems. A high-level chart or table that lists the data types used, plus a diagram highlighting the journey, is best. Include data present in your files, internal databases, and external storage.

Additionally, you will need to detail how your control environment protects your data. This includes internal controls for safeguarding data against unauthorized access and risk management. Controls might include training materials, access controls, and change management protocols, as well as control objectives and control activities that mitigate risk.

Operations

Detail the key processes, both manual and automated, involved in managing the use of your product or service. This includes how service activities are commenced, your authorization system, activities performed, or how your services are delivered.

What Are the Steps to Writing a System Description for a SOC Report?

The following steps will help you determine the documentation and information you need to write your system description.

Step 1: Understand the Purpose of the System Description

Those involved in preparing for the SOC report must understand the purpose of the system description: to help your auditor assess whether your system components are organized to prevent a data breach.

Step 2: Define the Scope of Your SOC Report

Because service organizations may offer various products or services, it’s vital to know upfront which ones are covered under the SOC audit and which are not. Specify all of that in the scope.

Step 3: Document the Key Elements of Your System

The critical elements of a service organization's system should include:

  • Personnel involved in the operation of your service or product
  • Third-party vendors that facilitate the product or service (including how you evaluate vendor controls to assure they meet compliance guidelines)
  • Procedures that enable the product or service
  • The technical components of your system
  • Your reporting processes
  • How elements were designed and implemented

Step 4: Document Your Control Components

Your internal controls should all be documented so that they can be easily procured, if required, during an audit. This includes how the controls are implemented, their objective, how they are evaluated for effectiveness, and how they are monitored over time.