Third Party Risk Management: Attestations

Third Party Risk Management:  Attestations

Third party risk management is an area of increasing concern for most organizations today.  The growing adoption of IT services provided by third parties, combined with stricter regulatory and compliance requirements for managing third party risks, as well as the increasing publicity of attacks resulting from third party risks is causing most organizations to review their third party risk management programs.  There are many facets to managing third party risks, but one area that I will cover in this article is third party security attestations.  Some day, we will get to a point where service providers have implemented continuous monitoring, and are able to share the near real time information about the security of their service with customers.  However, we aren’t there yet, and organizations that need to assess the risk of using a third party will likely have to rely upon some type of attestation.

There are various types of attestations that an organization can provide to explain the information security program that protects the confidentiality, integrity and availability of the service (including the customer data stored, processed or transmitted) provided to customers.

In the simplest case, a service provider can make a simple statement “we have a strong security program”, however, as an attestation, this has very little value, and organizations would be wise to avoid accepting such statements.  To have credibility, the attestation should come from an independent third party rather than the service provider.  The need for this independent, third party attestation has resulted in several programs such as ISO-27001 certification, SAS-70, SSAE-16,  SOC-2, and SOC-3.  Some people include the PCI DSS Report on Compliance (ROC) as a form of attestation, but because of the tight focus and scoping on payment card data, the PCI DSS ROC may not be adequate for many organizations, unless they are solely focused on the security of payment card data.

Let’s dig into some of these attestations a bit:

ISO-27001 certification

The ISO 27000 family of standards is focused on information security.  The core of the family defines an “information security management system” ISMS as the program necessary to ensure the confidentiality, integrity and availability of an organization’s information assets.  An organization can seek certification under ISO-27001 in which an approved auditing organization will validate that the organization has an ISMS that is compliant with ISO-27001. 

It is important to understand that if you rely upon a service provider’s ISO-27001 certification, all you will see is a one page piece of paper that states that the organization was certified by the auditing firm.  You won’t learn anything about the specific security controls that the organization has in place.  Still, it is an attestation that the organization has an ISO-27001 certified ISMS.  Note that ISO-27001 certifications are typically valid for three years, which is quite a long time in the dynamic world of IT.

SAS-70 and SSAE-16

Prior to the adoption of the Statement on Standards for Attestation Engagements (SSAE-16) standard and the Service Organization Control (SOC) reports, many service organizations relied upon the Statement on Auditing Standards Number 70, also known as the SAS-70, to provide a description of controls in place, and a third party audit of the suitability of the design of the controls to achieve the specified control objectives.

In June of 2011, the SSAE-16 standard replaced the SAS-70 standard.  The SAS-70 is a retired standard, and as such, it should no longer be used.

The SSAE-16 standard, a US based standard created by the American Institute of Certified Public Accountants (AICPA), was designed to be compatible with the international standard ISAE 3402, which was released in December of 2009.

SOC Report Types

SOC reports can be either a type I or type II reports.  The simplest way to explain the difference between the type I and type II reports is to examine the time period for which the audit examined the controls.

Type I Report

Type I report:  a point in time report.  From the AICPA web site: “report on the fairness of the presentation of management’s description of the service organization’s system and the suitability of the design of the controls to achieve the related control objectives included in the description as of a specified date. “

Type II Report

Type II report:  a report covering a specific period of time, typically either six months or one year.  From the AICPA web site:  “report on the fairness of the presentation of management’s description of the service organization’s system and the suitability of the design and operating effectiveness of the controls to achieve the related control objectives included in the description throughout a specified period. “

Based upon these definitions, it should be clear why most organizations prefer a type II report from their service providers as opposed to a type I report.  Type II reports require that the audit team review evidence throughout the time period of the report to ensure the control’s implementation.  It would be much easier to complete a type I audit, as all you have to do is show that the control was in place on the day the auditor was present.

Note that because the Type II report is an attestation of the implementation of controls over a period of time, it is always a “look back” report, meaning that the report covers a period of time in the past.  It’s not possible to report on the presence of a control for a future time period.  Keep that in mind if someone asks “Why is this report for last year?” or “This is good but where is the report for this year?”.

SOC 1, SOC 2, SOC 3

As described above, there are type I reports and type II reports, but there are also three different kinds of SOC reports:  SOC 1, SOC 2 and SOC 3.

SOC 1

SOC 1 reports are based upon the SSAE-16/ISAE-3402 standards.  The SOC 1 report replaces the SAS-70, and is intended to evaluate controls over an organization’s IT systems that are material for financial statements.  It is not intended to attest to the controls related to general security, integrity, availability or privacy.

SOC 1 Reports are intended for a very limited distribution.  The report includes details about the controls that management has decided to report.  The report is typically classified as a confidential document and is not shared with external parties unless under terms of non-disclosure.

Because of the very limited focus of a SOC 1 report to IT systems that are material for financial statements, they are not generally speaking well suited for most organizations seeking attestation of a service provider's security for a given service.

SOC 2

SOC 2 reports are based on the AT-101 Trust Service Principals.  There are five TSPs:  Security, Availability, Confidentiality, Processing Integrity, and Privacy.  An organization determines which of the 5 TSPs are appropriate for its SOC 2 audit.  Some service provider organizations may include all five TSPs, while others may use a sub set of the TSPs.  Service provider organizations select the TSPs that they believe are most appropriate for the services they provide.  As a customer, or potential customer of the service provider, you should evaluate if the selected TSPs are appropriate for your use of the service.

In a SOC 1 report, the organization determines which the controls it feels are appropriate, and the accounting firm checks to see if the controls were in place over the reporting period.  The auditing firm does not issue an opinion about the appropriateness of the controls.  The SOC 2’s TSPs have defined criteria, and the audit checks to ensure that the control activities implemented by the service provider are adequate to meet the requirements of the Trust Service Principle criteria. 

Because the SOC 2 audit focuses on defined Trust Service Principle criteria, many people believe it is more appropriate for cloud service providers as an attestation of the service provider’s controls over their systems.  For example, in the Security TSP, one of the criteria is “1.0 Policies:  The entity defines and documents its polices for the security of its system.”  While not likely, it is possible to have a SOC 1 report that doesn’t include anything about security policies.

Like the SOC 1 report, a SOC 2 report is not intended for public distribution.  The report includes details about the controls in place to meet the principles and criteria of the Trust Service Principle(s).  The report is typically classified as a confidential document and is not shared with external parties unless under terms of non-disclosure.

The SOC 2 is widely understood to be the attestation of choice for cloud service providers.  The Cloud Security Alliance released a paper in February of 2013 stating that the SOC 2 is likely the best attestation for most users of cloud services.

SOC 3

The SOC 3 report is a short report that is intended for wide distribution.  It provides an attestation that the service provider’s controls meet the requirements to satisfy the stated Trust Service Principles.

In addition to a report, the SOC 3 seal is often displayed on the service provider’s web site, as a public statement of the provider’s achievement in meeting the requirements of the stated Trust Service.

The SOC 3 report does not provide information about the controls the service provider implemented to meet the requirements of the stated Trust Service Principles.

Summary

I hope this summary has been helpful.  Here are some short takeaways to remember:

• SAS-70 is a retired standard that has been replaced by the SSAE-16 standard.  Let’s stop using the SAS-70 standard in contracts and other documents.  It’s been over three years, time to let it go.
• ISO-27001 certification is a good indicator that an organization has an information security program, but you won’t learn much about the specific security controls that are used, and since the certifications are valid for three years, it isn’t very timely.
• SOC-2 reports are most likely the most appropriate attestation report for a service provider at this time, although adoption by service providers is still lagging.  Part of the reason for this is that the switch from a SOC 1 to SOC 2 is often a multi-year process.
• If your service provider hasn’t yet adopted the SOC-2, you should ask them when they expect to move to it.  It could take some time, but they should be moving toward the SOC-2.