Complementary User Entity Controls (CUECs) are an important component of SOC 2 reporting and are required to be disclosed in the description of the service organization’s system. The AICPA defines CUECs as follows: “CUECs are those controls that service organization management assumed, in the design of the system, would be implemented by user entities and are necessary , in combination with controls at the service organization, to provide reasonable assurance that the service organization’s service commitments and system requirements would be achieved.” An often overlooked part of the definition above is that CUECs are controls that are NECESSARY to achieve service commitments and system requirements. User entities have various responsibilities, but these may not be CUECs because they are not necessary to achieve the service organization’s commitments and requirements.
The AICPA’s SOC 2 Guide states that: “Usually, a service organization can achieve its service commitments and system requirements without depending on the implementation of CUECs at user entities because the service organization restricts its service commitments and system requirements to those matters that are its responsibility and that it can reasonably perform.” In other words, CUECs should be fairly uncommon in SOC 2 reports.
User Entity Responsibilities are another related concept in SOC 2 reports. They are different than CUECs because they are not necessary for the achievement of service commitments and system requirements, but may be necessary for other reasons. In the SOC 2 Guide, the AICPA states that “In addition to CUECs, user entities may have other responsibilities when using the system. Those responsibilities are necessary for the user entity to derive the intended benefits of using the services of the service organization.”
Trust services criterion CC 2.3 states: The entity communicates with external parties regarding matters affecting the functioning of internal control . This would include communication of user responsibilities. However, because user entity responsibilities can be voluminous, they are often communicated through other methods (for example, by describing them in user manuals). Consequently, disclosure of user entity responsibilities in the description is usually not practical. Instead, management ordinarily identifies in the description the types of communications it makes to external users about user entity responsibilities.
Let’s evaluate an example CUEC that appears in many SOC 2 reports: Controls provide reasonable assurance that user entities communicate a complete and accurate listing of authorized users to the service organization. This CUEC is commonly mapped to CC 6.2, which is as follows: Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized. Here is what the AICPA says about this example: “CC 6.2 limits the service organization’s responsibilities because the criterion requires only that the system register a user (identified by the user entity as an authorized user) and issue system credentials to that user after the user entity supplies the service organization with a list of authorized users. The user entity is responsible for identifying the users and supplying the service organization with a list of authorized users. If the user entity provides a list that inadvertently includes employees who are not authorized, the service organization has still met the criterion. Accordingly, identifying the authorized users and communicating that information to the service organization are not considered CUECs.”
Here is an example of a CUEC from the AICPA SOC 2 Guide relevant to trust services criteria CC6.4, The entity restricts physical access to facilities and protected information assets (for example, data center facilities, backup media storage, and other sensitive locations) to authorized personnel to achieve the entity’s objectives. “A service organization may install portions of its infrastructure at a user entity (for example, servers installed at user entity data centers to support the transmission of files between the user entity and the service organization). In these circumstances, the user entity needs to implement physical access controls at the user entity to protect the components of the service organization’s system located at the user entity.”
In conclusion, it is important for service organizations to determine if there are CUECs related to their service offerings and disclose them in SOC 2 reports if they exist. However, it is reasonable (and expected) that most service offerings and the related SOC 2 reports will have “user responsibilities” associated with them, but no CUECs.
The guidance above does not apply to SOC 1 reports that include one or more transaction processing control objectives for a variety of reasons. The AICPA’s SOC 1 guide indicates that CUECs will usually appear in SOC 1 reports and the example report in the SOC 1 guide includes CUECs. On the other hand, the example report in the AICPA’s SOC 2 guide does not include CUECs and there are implications throughout the SOC 2 guide that CUECs should generally not appear in SOC 2 reports.
In SOC 1 reports, CUECs are defined as “Controls that management of the service organization assumes, in the design of the service organization’s system, will be implemented by user entities and are necessary to achieve the control objectives stated in management’s description of the service organization’s system.” The AICPA SOC 1 guide provides the following examples of typical CUECs:
Some organizations that receive a SOC 2 report also receive an ITGC-only SOC 1 report over the same system. For these ITGC-only SOC 1 reports, CUECs (or lack thereof) should generally mirror the SOC 2 report. In other words, if there are no CUECs identified in the SOC 2 report, then there will not be CUECs in the SOC 1.