A SOC 2 system description outlines the boundaries of a SOC report. It contains pertinent details regarding the people, processes, and technology that support your product, software, or service.
As a reminder, the SOC framework stands for System and Organization Controls. It is a broad architecture that organizations can use to audit the internal controls of vendors and business partners before entering a relationship with those firms, to assess whether those firms have a robust security posture.
SOC audits exist in several categories. A SOC 1 audit inspects the financial controls of a business; the SOC 2 audit inspects data security controls.
Moreover, SOC 2 audits have two types: Type I and Type II.
- A SOC 2 Type I audit assesses the design of internal controls at a specific time, creating a baseline for future audits.
- A SOC 2 Type II audit goes further, to determine whether those controls actually work as designed, across a prolonged period of time.
In this post we will specifically be referring to SOC 2 as we discuss the requirements for system descriptions.
During the audit itself, the auditor is looking to assure that you are faithfully fulfilling any of the Trust Services Criteria in a SOC 2 audit that might be applicable to your engagement. As a reminder, the Trust Services Principles are:
- Processing Integrity
Why Is the System Description Important?
The system description is important because the details included are vital to the auditor and facilitate the auditing process.
Gathering those details, however, can be challenging. Should they be incomplete, the service auditor will come back with feedback that must be gathered to complete the audit.
Thankfully, the American Institute of Certified Public Accountants (AICPA), which develops SOC 2 audit standards, has some guidance that can be helpful in compiling your system description.
In this guide, we’ll share what you need to include and the level of detail required, so you can get this cumbersome task finished and get back to focusing on other important tasks.
What Are the System Boundaries of a SOC 2 Report?
The System Boundaries section of your description criteria 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 objective 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 common criteria used to describe your components below.
In this section, you will detail the hardware, software, and SaaS components used in the infrastructure (both physical and virtual) of your systems. This could include computing hardware, internet servers, storage, connections between these elements, and your cybersecurity monitoring technology.
The documentation may incorporate lists, descriptions, and a diagram of your systems.
Product or Service
Next, you will define the product or service you market to customers. That includes the application itself (if relevant), system requirements, system processing guidelines, service level agreements, supporting databases, and your mobile and desktop applications.
This list shouldn’t include your operational technology. In other words, your payroll software, chat service, or project management tools — those can be omitted.
This section will likely take the form of an introductory section explaining, at a high level, how the application is used and a follow-up list of the components involved.
This next section will detail 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 main departments, followed by an organizational chart.
It should include third-party vendors or subservice organizations that support your offering.
While this is likely the toughest 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 its journey, is best. Be sure to 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 that specifically relate to safeguarding data against unauthorized access and risk management.
A service organization’s controls might include things like your training materials, access controls, and change management protocols. It should also include the control objectives and control activities that mitigate risk.
In addition to the effectiveness of controls, it’s also important to obtain the auditor’s opinion on the safety of your operations and protocols.
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 otherwise 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 which documentation and information you need to begin writing your system description.
Step 1: Understand the Purpose of the System Description
It’s important that those involved in preparing for the SOC report understand the purpose of the system description. We’ve touched on it before, but essentially, it’s to help your CPA or auditor assess whether or not your system components are organized to prevent a data breach.
Step 2: Define the Scope of Your SOC Report
Because service organizations may offer a variety of products or services, it’s vital to know upfront which are being 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 key elements of a service organizations system should include:
- 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 facilitate 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, what their objective is, how they are evaluated for effectiveness, and how they are monitored over time.
How Can ZenGRC Help to Prepare for a SOC 2 Audit?
At the enterprise level, implementing and managing a compliance program, including the auditing process, can quickly overwhelm a compliance function. Using spreadsheets alone is a sure-fire way for a critical element to slip through the cracks. This can be disastrous during an expensive audit — or, worse, if a data breach occurs.
ZenGRC takes the stress out of SOC 2 audits by allowing you to manage all of your compliance requirements, across frameworks like SOC, ISO, and HIPAA from a single, central platform.
This “single source of truth” dashboard acts similar 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, ZenGRC can save you time and money by providing all of your templated audit documentation in an easy-to-use format.
ZenGRC can also cross-check objectives from multiple frameworks at once, so you don’t have to do duplicate work while achieving all of your compliance, governance, and risk management requirements.
If you’d like to see ZenGRC in action, contact us today for a free demo.