If you’ve been involved in preparing your organization’s SOC report, you likely have come across the section that discusses “subservice organizations” and “complementary subservice organization controls” (auditors call these “CSOCS” for short). You may have even been tasked with the responsibility to figure out whether your organization uses subservice organizations, and to draft the CSOCS section. If so, congratulations! You were selected to work on one of the most challenging areas in SOC reporting.
Below is a breakdown of the four steps to help make the process more manageable, and effective.
Subservice organizations represent a special class of vendor and are formally defined as “a service organization used by another service organization to perform some of the services provided to user entities that are likely to be relevant to those user entities' internal control over financial reporting” — (or to the trust services criteria in a SOC 2).
That’s clear, isn’t it? Essentially, subservice organizations can exist in SOC 1 or SOC 2 reports, and apply whether the report is a Type 1 or Type 2. Typical examples of subservice organizations include:
As a service organization, if you use a data center to host your infrastructure, at a minimum, you have outsourced the responsibility for physical and environmental security over that infrastructure to the data center. If you have a managed services company, you may have outsourced the responsibility for backups, patching, network monitoring or other IT general control activities. While these subservice organization activities are fairly easy to identify and understand, other vendor relationships are not as obvious or easy to identify as subservice organizations.
Once you’ve identified the subservice organization(s) your service organization uses, your work has just begun. For your report, you will also need to determine whether the “carve-out” or “inclusive” method is used.
The carve-out method is where CSOCS come into play. Under this method, the actual controls performed by the subservice organization are not included in your report — only a description of what the subservice organization does for your service organization, how it interacts with your system, and the types of controls you expect it to have in place so that you can achieve your control objectives or trust services criteria (the CSOCS).
So, for our data center subservice organization, you would identify:
Taking the same example above, if you use the inclusive method, the relevant aspects of the subservice organization’s operations along with related controls in place at the subservice organization are fully included in your report.
Think of the inclusive method as merging the separate SOC reports of two entities. The same level of work that is performed on your service organization must also be performed on the subservice organization’s activities. Needless to say, this can be daunting, which is why use of the inclusive method is rarely seen in practice. Brother/sister type entities, such as an operating unit that is supported by a separate IT division, both of the same parent, is an example of when inclusive might be used. Another example would be where the subservice organization performs nearly all of its business with an unrelated service organization.
Now you’ve identified all of your subservice organizations, decided on the appropriate reporting method, and identified the CSOCS (if you selected the carve-out method). You’re all done, right? Not quite yet.
The last bit of work when carved-out subservice organizations exist is to insure that you adequately document how you manage them. With subservice organizations, a typical vendor management program where you evaluate the vendor’s service delivery, quality, policies and procedures (IT security for example) and insurance coverage isn’t quite enough. Remember those CSOCS? With a subservice organization, you as the service organization must take steps to determine if the types of CSOCS you expect the subservice organization to have in place are actually in place. How do you do that? One of the easiest ways is to obtain the subservice organization’s SOC report, assuming they have one. Requiring the subservice organization to have a SOC report may have been part of your vendor due diligence — kudos to you! If no SOC report is available, make detailed inquiries of the subservice organization management, read other internal reports the subservice organization may produce, and/or conduct site visits to evaluate your required CSOCS.
You’re almost done! Most service organizations, and likely yours as well, have expectations of their user entities that auditors call CUECs, which stands for “Complementary User Entity Controls.” Your subservice organization also expects you as its user entity to engage in certain types of controls. Your last step is to understand these and determine how you comply, and if you don’t, the impact on the subservice organization’s services to you. Oh, of course, all of this analysis you’re performing is in writing, correct (just say yes!)?
Subservice organizations are a special class of vendor and are a critical part of properly reporting your system as a service organization. With subservice organizations, you must expand your regular vendor management practices to insure subservice organizations are meeting your control expectations, and that you are living up to the controls they expect from you. This enables user entities to properly evaluate the impact that subservice organizations have on their internal controls and/or operations.
Contact Steve Guarini at sguarini@cohencpa.com or a member of your service team to discuss this topic further.
Cohen & Company is not rendering legal, accounting or other professional advice. Information contained in this post is considered accurate as of the date of publishing. Any action taken based on information in this blog should be taken only after a detailed review of the specific facts, circumstances and current law.