Part 2 of 2 in our deep dive into the AICPA’s proposed Description Criteria for its new SOC Suite of Services, SOC for Supply Chain

This is our final blog post in the 2-part series detailing the recent AICPA’s SOC for Supply Chain Description Criteria. For a shorter read, check out our previous blog summarizing the Criteria, or read part 1 before continuing here.

In part 2, we look at Description Criteria #6-10, which dives deeper into control activities and the environment at the supply chain company.

AdobeStock_93816857

 Description Criteria

DC 6: Describe applicable Trust Services Criteria and related controls designed to show that the Company’s System objectives were achieved.

The Trust Services Principles (utilized for the SOC 2 report) describe the criteria for each services area. A SOC for Supply Chain report must should address these criteria, specifically, the controls in place at the Company. This includes the risk assessment process, the information and communication of governance at the company, and the control environment and monitoring.

DC 7: If a customer’s controls are necessary when combined with Company controls to achieve System objectives, the Company must describe those complementary customer controls.

Sometimes, customers have a role to play in the input of the supply chain, and fulfilling those responsibilities is necessary for the customer to meet its own goals. A simple example is that a customer must provide the correct shipping address information for packages to be delivered successfully.

Because these responsibilities are usually lengthy, they are not typically presented in the Description but instead communicated through product documentation or user manuals. However, management should disclose the types of communications it makes to customers about their responsibilities.

Most of the time, customer responsibilities are not necessary for the company to meet its System objectives. However, in some situations a customer must have reasonable evidence that controls are in place for the entity to meet the System objectives. These are referred to as Complementary Customer Controls (‘CCCs’).

Let’s break it down with an example. Consider a company is installing a server at a customer’s data center to support that customer’s access to the company’s production management system. The customer should implement physical access controls at its site to protect the components (e.g. software or data stored on that server) of the company’s System in order for the company to achieve its System objectives based. In this case, the criteria which requires that “physical access be limited to authorized personnel.”

When CCCs are necessary, these are listed at the end of the Description in a separate section.

DC 8: If a supplier’s controls are necessary when combined with Company controls to achieve System objectives, the Company must either use the carve-out method or inclusive method when describing the System objectives.

Typically, a company has effective controls in place over the quality of raw materials. For example: a company has change management controls in place over a system used by a supplier to produce new software, which the company then uses in its own production. In that case, the company’s monitoring of the supplier’s system and controls is sufficient for the entity to meet its System objectives.

In some situations, however, the entity may not have controls in place. For example, the company may source subassemblies containing embedded software and thus may be unable to directly assess the quality and security of that software. In that case, the entity would delegate certain responsibilities to the supplier and expect the supplier to perform specific controls over the processes used to produce or deliver the subassemblies. As a result, effective supplier controls may be necessary for the entity to meet its System objectives.

There are two ways to describe these processes: Carve-out method and Inclusive method.

The carve-out method is used when the controls performed by the supplier are necessary (combined with the entity’s controls) to meet the System objectives, such controls are referred to as complementary supplier controls (CSCs) and disclosed in the Description. When using the carve-out method, the Description identifies the types of CSCs that the supplier is expected to implement and the trust service criteria affected by them (e.g. CC6 related to logical security). CSCs are usually presented in a table format at the end of the Description, mapped to the trust service criteria to which each relates.

The inclusive method is used when Company management presents its suppliers processes and controls because: a) users require this information, or b) the supplier plays a significant role in the process. Relevant pieces of a suppliers infrastructure, software, people, procedures, and data are considered part of the system, and therefore, are disclosed in the Description and are subject to the SOC examination procedures. The Description would separately identify controls at the company and controls at the supplier. Because this method adds to the complexity of the audit, both managements should agree on its use before the audit starts.

Regardless of the method used, the Description should disclose controls that the entity uses to monitor the services provided by the supplier, such as reviewing output reports, making onsite visits, and monitoring customer complaints.

DC 9: Describe any specific applicable trust services criteria not relevant to the System and the reasons it is not relevant.

If one or more of the applicable trust services criteria are not relevant to the System, entity management should include an explanation of why in its Description.

For example, a seller of a medical device uses an entity to implement specific software configuration of its devices for each patient. The medical information for each patient is provided by the patient’s physician to the seller, who then forwards the information to the entity for the configuration data to be created and implemented on the device. When the Description addresses controls over Privacy, entity management would not disclose the customers’ controls over collection; however, the reason for that omission would be disclosed.

However, the existence of a policy prohibiting certain activities is not sufficient to render criteria as “not applicable.” For example, if the Description addresses controls over privacy, it would be inappropriate for a company to state it forbids disclosure of personal information to third-parties based only on the fact that its policies forbid it. Instead, the Description should describe the policies and controls for preventing or detecting such disclosures.

DC 10: Describe significant changes to the System and Company’s controls necessary for the success of the System objectives.

Companies must disclose significant changes that are likely to be relevant to a broad range of report users. Disclosures should include details, such as the date the changes occurred and how the System was impacted before and after.

Some examples of a significant change include changes to production processes, changes to security personnel, changes to IT architecture, and changes to legal and regulatory requirements that could affect System requirements.

Disclosures about significant changes to the System are only made to the extent that they relate to the trust services addressed by the Description.

Conclusion

This concludes our blog series exploring the finer points of the SOC for Supply Chain Description Criteria. The comment period for this exposure draft ended February 28, 2019.

Currently, there is no date for the release of the SOC for Supply Chain Guide, which will provide a framework and standard approach for testing and reporting on the criteria.

We hope that your are able to understand the importance of describing the inputs, outputs, and the controls related to the System for SOC for Supply Chain.

COMMENTS

THIS POST WAS WRITTEN BY Ryan Wallace

Ryan Wallace is a Cyber Risk Supervisor at HORNE Cyber where he works to provide IT-focused assurance to clients both public and private.