• Mr. ByteChek

SOC for Supply Chain System Description

Updated: Mar 25

When thinking of SOC 2 or other SOC reports, most people think about the auditor’s opinion and the controls (in section 4). But there is another vitally important section of SOC reports, and that is the System Description (section 3). This is no different in the SOC for Supply Chain report. The reason this is so important is that, ultimately, it is what your SOC report opinion is on.

This blog post is going to let you know more about what to expect in your SOC for Supply Chain system description, what it is, what needs to be included in it, and some tips on how to make it easier when developing your SOC for Supply Chain report.

What is the System Description and why is it important?

The system description is exactly what it says. It’s a description of the system that is being reported on in your SOC for Supply Chain report. It is important because it gives your report users an overall understanding of your production, manufacturing, or distribution processes in place.

Before we get into the AICPA Description Criteria for the SOC for Supply Chain Section 3, let’s lay out five things to consider when determining if the description is being presented in accordance with the below description criteria:

  1. The description includes the significant components of the system that the entity has designed and implemented (placed into operation) to produce, manufacture, or distribute the products.

  2. The description does not inadvertently or intentionally omit or distort information that is likely to be relevant to intended users decisions.

  3. The description includes information about each description criterion, to the extent that it is relevant to the system being described, without using language that omits or distorts the information.

  4. The description is prepared at a level of detail likely to be meaningful to intended users.

  5. The characteristics of the presentation, such as the format, are appropriate, given that the description criteria allow for variations in presentation.

OK, so what’s in the system description?

The AICPA has provided a benchmark of 10 description criteria (DC) for system descriptions of SOC for Supply Chain reports. They are as follows:

DC1: The types of goods produced, manufactured, or distributed by an entity – The description should include disclosures about the type of products the company produces, manufactures, or distributes and the system or systems that produce, manufacture, or distribute the products. The types of products discussed in this section will depend on the nature of the company undergoing the SOC for Supply chain examination. This section should be objective and not include any marketing language that cannot be evaluated by a service auditor or practitioner.

DC2: The principal product performance specifications, commitments, and requirements and production, manufacturing or distribution components and requirements (principal system objectives) – This section is where management outlines the specific processes and procedures to achieve system objectives related to the goods produced or distributed by the company. These objectives tie directly into the trust services category or categories addressed by the SOC for Supply Chain report. These objectives help the users understand the objectives that drive the operation of the system and how the applicable trust services criteria were used to evaluate whether controls were effective. A few examples from the AICPA:

  • Commitments regarding protection of the system from cybersecurity risks

  • The product meeting the product performance specifications that have been communicated to or agreed upon with customers

  • The product’s availability in the quantities and at the times agreed upon with customers

  • The achievement of delivery commitments made to customers, including the timing of delivery, storage and transportation commitments, and the system requirements necessary to achieve those commitments.

In order to determine that your principal system objectives are, management should consider the following categories:

  • Product Performance Specifications

  • Production, Manufacturing, or Distribution Specifications

  • Product Requirements

  • Production, Manufacturing, or Distribution Requirements

  • Other commitments related to the TSCs in scope.

DC3 System incidents – If there were identified incidents that were the result of controls not effective then those incidents should be disclosed. Judgment should be used when determining whether to disclose a system incident and the following matters should be disclosed:

  • Whether the incident resulted from one or more controls, including controls at carved-out suppliers, that did not provide reasonable assurance that the company achieved its principal system objectives

  • Whether the incident resulted in a significant failure in the achievement of one or more of the entity's system objectives

  • Whether the public disclosure of the incident was required (or is likely to be required) by laws or regulations

  • Whether the incident resulted in sanctions by any legal or regulatory agency

DC4 Risks that may have a significant effect on the company’s ability to achieve its principal objectives - In this section, you would disclose risks that may have a significant impact on the company’s ability to achieve its principal system objectives that relate to the trust services category or categories in scope for the production, manufacturing, or distribution equipment and system being evaluated. These risks should cover risks related to:

  • Information systems, suppliers, and delivery channels used by the company

  • Organizational and customer characteristics such as locations, size, structure, etc.

  • Physical, environmental, technological, organizational, and other changes.

DC5 Relevant information about the system that produces, manufactures, or distributes the products - This section should include the following areas:

  • Components of the system:

  1. Infrastructure

  2. Software

  3. People

  4. Procedures, and

  5. Data

  • Significant inputs used by the system (raw materials and other inputs)

  • Boundaries of the system, when necessary to prevent users from misunderstanding the system being described

DC6 The applicable trust services criteria and the related controls designed to provide reasonable assurance that the entity’s principal system objectives were achieved - In this section, management will describe the controls that relate to the trust service category or categories addressed by the description which includes controls relate to the control environment, risk assessment process, information and communication, monitoring activities, logical access, and much more. If the company includes Availability in-scope then they would describe the availability controls in scope to address the availability criteria.

DC7 Complementary Customer Controls (CCCs) - This section would describe the role customers play in production, manufacturing, or distribution processes. For example, maybe your customers need to have their own logical access controls in place so that only authorized users access your service, otherwise, unauthorized access may cause you to fail to meet your security commitments. The important thing to remember with this section is that it should not be a “laundry list” of things that you want customers to do in order for you to be covered in case something happens. That is what your contracts and agreements are for. This is purely just meant for controls they need to have in place otherwise your system doesn’t work to meet its objectives.

DC8 Complementary Supplier Controls (CSCs) - This section is where you will discuss the suppliers that support the production, manufacturing, or distribution processes. Suppliers are a bit more involved than your vendors (or sometimes even critical vendors). Think of suppliers as a vendor that you cannot meet your principal system objectives without. For most SaaS companies a common example is your cloud hosting provider (AWS, GCP, Azure, etc.). For example, you cannot meet the physical controls in CC6.4 or CC6.5 without them. So, you would list them here and what criteria they help you meet.

DC9 Specific trust services criterion that is not relevant to the system and the reason why it is not relevant - This is where you would describe any criterion that does not apply to the production, manufacturing, or distribution services provided by the company. An example could be where you have privacy in scope for your SOC 2, but you are not a data controller. Therefore things like the notice, choice, and consent criteria in privacy would be not applicable.

DC10 Significant changes to the system during the period (Type 2 reports only) – In a type 2 report, if you had any significant changes (how the control environment operates, control changes in how they meet criteria, key personnel changes, mergers/acquisitions, etc.) during the period, you would state those here and their effect on the report.

Your SOC for Supply Chain report is based on this description and it’s clear to see why. The description contains detailed information on the processes in place that your customers care about. Getting this document right is critical to make the SOC for Supply Chain report as useful as possible. Reach out to a ByteChek team member today if you’d like to get started on your SOC for Supply Chain report!