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.
