What’s the System Description of a SOC 2 Report?

A SOC 2 system description is an important part of a SOC report. It outlines the boundaries of that 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 of those vendors 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, in turn, assesses whether a service provider is or is not 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. That said, 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. A SOC 1 audit assesses the financial controls of a service provider, in case that vendor helps its customers with their own financial reporting. A SOC 2 audit assesses cybersecurity controls, so customers know whether they can entrust confidential data to the vendor.

Moreover, SOC audits come in two types: Type I and Type II.

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

This post will specifically refer to SOC 2 as we discuss the requirements for system descriptions.

During the audit itself, the auditor assesses various “Trust Services Criteria” that might be in scope for the audit. As a reminder, those criteria are:

• 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, however, can take time and effort. Should they be 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, has some guidance that can 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. Those subsections detail the components of the system a service organization uses to fulfill its service commitments.

When describing a service organization’s system, 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

To help you prepare these boundaries, we’ve compiled the standard criteria to describe your components below.

• 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

  Next, 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. In other words, your payroll software, chat service, or project management tools can all be omitted.

  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 next 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

  While this is likely the most challenging section to get through, it can also be the most important. 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 will include internal controls for safeguarding data against unauthorized access and risk management.

  A service organization’s controls might include your training materials, access controls, and change management protocols. It should also include the control objectives and control activities that mitigate risk.

• Operations

  This may look slightly different depending on the nature of your product or service. The goal, however, is to detail the key processes, both manual and automated, involved in managing the use of your product or service. It will also include 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. It’s 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 organizations system should include the following:

  • Personnel involved in the operation of your service or product
  • Third-party vendors that facilitate the product or service (you should also include 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.

Let ZenComply Help you Prepare for Your SOC 2 Audit

Implementing and managing a SOC compliance program, including the auditing process, can quickly overwhelm a compliance function. Relying on spreadsheets is a surefire way for critical elements to slip through the cracks. This can be disastrous during an expensive audit, and worse if a data breach later occurs.

ZenComply takes the stress out of SOC 2 audits by allowing you to manage your compliance requirements across frameworks like SOC, the International Organization for Standardization (ISO) certifications, and Health Insurance Portability and Accountability Act (HIPAA), all from a single, central platform.

This “single source of truth” dashboard acts similarly to an internal audit, showing you where your compliance gaps are and what must be done to fill them. And when it’s time for your SOC audit, ZenComply can save you time and money by providing all of your templated audit documentation in an easy-to-use format.

ZenComply can also cross-check objectives from multiple frameworks, so you don’t have to duplicate work while achieving all of your compliance, governance, and risk management requirements.

Contact us today for a free demo to see ZenComply in action.