How to Prepare and Document for SSAE18 Changes including Vendor Oversight

Mary Beth Marchione

Systems Manager

May 9, 2017

By now it is safe to say that you are aware of the SSAE18 change. This is a clarified standard to SSAE16 along with the AT 801 and AT 101 attestation standards. Below we’ll focus on the changes that will require the most action or additional documentation from service organizations.

Emphasis on Risk Assessment and Responsibility

Service organizations are now responsible for completing a risk assessment as it relates to the subject matter (a.k.a. your system and its control objectives and controls) defined in the SOC report. The risk described is called “risk of material misstatement,” meaning the risk that the subject matter and/or management’s assertion of the subject matter is not fairly presented.

In the past, it has always been the responsibility of the service auditor to conduct a risk assessment – now it’s in the hands of the service organization. Because the control objectives and controls are the service organization’s responsibility, it makes sense for the party designing the controls to have an understanding of the associated risk of material misstatement.

Many service organizations already have a risk assessment process in place. If your management team needs to develop an approach, below are questions to help get you started:

  1. Who is your audience? (user entities, independent auditors of financial statements, those auditors who audit and report on internal controls over financial reporting)
  2. What are your users concerned about?
  3. What action(s) could result in financial loss?
  4. What action(s) could result in inaccurate reporting?
  5. What action(s) could result in the disclosure of sensitive information?
  6. What action(s) could result in a disruption to operations? Prolonged disruption?

Once you have thought through the risks, you can make sure the appropriate controls are in place.

For those that have already thought through the risks informally and formed controls, it may be helpful to work backwards. Look at the control objectives and controls identified and think about the risk(s) if a control did not work. After going through the controls in place, think about any additional risks and control objectives/controls that may need to be added to the subject matter. At the end of the day, you may also learn that some of the controls noted are not key and do not need to be included in your testing.

Vendors vs. Subservice Organizations

There is nothing new about subservice organizations, but it is important to understand the difference between a “vendor” and “subservice organization,” as the level of scrutiny relating to your vendor management program may be impacted by this determination.

A subservice organization is defined as an entity used by another service organization to aid in providing the service(s) described in the report. Subservice organizations provide services that are likely to be relevant to user entities (your customers). Meaning, they have a direct impact on the controls defined within your SOC report. Your vendors obviously provide a service or a product, but it may not be directly related to providing the service described in your SOC report. As it relates to SOC1, determine if the vendor is providing a service or product directly related to your user’s internal controls over financial reporting. To determine if a vendor should be noted as a subservice organization, here are some things to think about:

  1. When describing the system, are the vendor(s) services and controls part of the description?
  2. Are the services provided by the vendor required for the controls stated to operate effectively?

If you answered yes to these questions, you most likely have determined your vendor is a subservice organization. Once you have determined the subservice organizations used to deliver the service, it will be important to determine relevant Complementary Subservice Organization Controls (CSOCs). CSOCs are those controls that are expected to be in place at the subservice organization. As part of the SSAE18 changes, service organizations will need to go through the exercise of documenting the CSOCs within management’s system description.

SSAE18 also notes that where a subservice organization uses the service(s) of another organization that are relevant to user entities, the downstream sub-servicer(s) should also be reflected as subservice organizations. In that case, you will need to include these organizations in your system description and also apply vendor management controls/monitoring as necessary.

Vendors vs. Subservice Organizations

The clarified standard notes that monitoring activities may include:

  • reviewing and reconciling output reports,
  • holding periodic discussions with the subservice organization,
  • making regular visits to the subservice organization,
  • testing controls at the subservice organization by members of the service organization’s internal audit function,
  • reviewing type 1 or type 2 reports, and
  • monitoring external communications, such as customer complaints relevant to the services by the service organization.

There is not a strict rule as it relates to monitoring, so consider the following when forming a monitoring program:

  1. Focus on risk. What are the risks related to the service provided? Higher risk will equate to more oversight.
  2. What controls are expected to be in place?

An approach to documenting oversight could be to look at the CSOCs identified and ensure that they are covered by one or more of the monitoring activities listed above. For example, the subservice organization in question provides data storage, backup, and replication services. They also provide you with a SOC2 report covering security. You define the following CSOCs and note how each is monitored:

  • Physical access to the storage servers is restricted – SOC Report
  • Logical access to storage servers is restricted – SOC Report
  • Help desk tickets are closed timely – periodic review of closed help desk tickets to determine they are in line with SLAs (output report).

The SOC report will be helpful when reviewing the physical and logical security CSOCs. In this example the CSOC related to timely resolution of help desk tickets is not included within the SOC report controls and testing, so management reviews the available output report.

It is important to note that SSAE18 went into effect as of May 1, 2017. While the standards are clarified, some things may still seem unclear. Over time, the industry will adopt and adapt to the new standards, so stay tuned.

For more information, or help with preparing and documenting the new changes, please feel free to reach out to me or comment below to get the conversation started. We are eager to hear your feedback about how the new changes will impact you and how we can help you prepare.

Stay Up-to-date