The European Union General Data Protection Regulation puts significant new responsibilities and liabilities on data controllers regarding their use of third-party processors. Data controllers will face increased requirements to understand and contractually stipulate the policies and procedures of their processors in accordance with the GDPR. In an effort to simplify procurement and review, controllers and processors alike are likely to look towards existing privacy and security certifications as evidence of processor practices. Although these certifications can function as signposts, providing an inside look into processors’ policies and procedures, they are likely to have significant gaps and require expert review.

Two of the most commonly sought after privacy and security frameworks are ISO 27001 and SOC 2. But what are these processes? What kinds of information and practices are reviewed, and how can these processes be used for procurement and vendor-management purposes? And, maybe more importantly, what are the risks?

ISO explained

The most recent IAPP-EY Privacy Governance Survey found that half of privacy professionals involved in procurement seek ISO 27001 compliance, up 11 percent since last year. ISO 27001 is an international security standard used to create information security management systems (ISMS) and measure their ongoing effectiveness. The primary focuses of the standard are the clear establishment of responsibility and the continual review and improvement of both security assets and policies. At its most fundamental level, an ISO 27001-certified ISMS identifies the scope of the organization’s processing activities, the risk associated with these activities, the organization’s risk tolerance, and the processes and procedures needed to meet these risk goals. A certified ISMS should also run scheduled tests and reviews of practices to ensure the continued maintenance and improvement of security measures. The standard also requires that “privacy and protection of personally identifiable information shall be ensured as required in relevant legislation and regulation.” As the GDPR is implemented and certifying bodies incorporate its requirements into their audits, this language is likely to be a major asset for controllers reviewing processor practices.

As ISO 27001 is an international standard with multiple certifying bodies, specific audit processes will vary. However, most audits will consist of an overarching review of an organization’s implemented policies and a testing of these policies against the requirements of the standard. In general, auditors will compare these results to interviews of stakeholders and subject-matter experts as well as the documentation of internal audits, incidents, and general reports to determine the extent to which the policies have been implemented and are being maintained. It is important to be aware that many organizations use ISO 27001 as a standard to guide the creation of their ISMS without ever having their system certified by an independent third party. When conducting due diligence, ensure that the processor has been certified by an accredited third party and that the certification is less than one year old: certifications must be updated annually.

As a recent IAPP One Trust white paper demonstrated, ISO 27001 standards can be mapped against much of the GDPR’s requirements. Of course, ISO certification does not equal GDPR compliance, as there are fundamental gaps between the two. While a compliant ISO 27001 ISMS provides much of the required infrastructure (such as data inventories, access limitation, and documentation), its standards are frequently less prescriptive than those of the GDPR, leading to potential gaps in compliance. Controllers will have to carefully review the processor’s policies and procedures to identify these gaps, which must be addressed in the drafting of required vendor contracts consistent with GDPR Article 28.

SSAE 16, otherwise known as SOC 2, explained

According to the 2017 governance report, 38 percent of privacy professionals involved in procurement required SOC 2 privacy credentials. SOC, which stands for Service Organization Controls, is part of the Statement on Standards for Attestation Engagements no.16 (SSAE 16) auditing framework, which replaced the Statement on Auditing Standards no. 70 (SAS 70).

A SOC report is not a certification, but rather an attestation made by a processor paired with an independent auditor’s comparison of the attestation to the company’s actual practices. While there are a number of SOC report variations, the SOC 2 report describes the “controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy,” primary topics of interest under the GDPR. SOC 2 reports will not always opine on all of the above categories and must be reviewed carefully for scope. There are two primary types of SOC 2 reports, type 1 and type 2, which also significantly affect the scope of a report.

A SOC 2 Type 1 report is an independent snapshot of an organization’s control landscape on a given day. A processor will attest to the controls they have implemented regarding security, availability, processing integrity, confidentiality, and/or privacy, and an auditor will compare this attestation to their independent audit of the organization’s controls. It is important to note that SOC 2 Type 1 reports do notinvestigate the actual day-to-day implementation of the organization’s controls; they simply focus on the quality and promulgation of policies outlining the creation and implementation of their controls. As the SOC 2 Type 1 report does not provide information on the daily practices of the processor, controllers are likely to find limited uses for it as a procurement or vendor oversight tool.

The SOC 2 Type 2 report, however, adds a historical element, showing how controls were managed over a minimum period of six months. In the Type 2 report, organizations attest to, and auditors review, the “operating effectiveness” of the organization’s controls in addition to the existence and quality of their policies. The Type 2 report provides significantly more insight into the organization’s actual actions as a processor and will contain descriptions of how the auditor tested the organization’s controls. The comparison of the processor’s attestation to that of the auditor may also provide interesting insight into the organization. In comparison to the Type 1 report, the SOC 2 Type 2 report will be much more useful for both procurement and vendor oversight.

The primary limitations of the SOC 2 report lie in its array of options and the specificity of its review. A processor can select which elements they want reviewed from the list of availability, processing integrity, confidentiality, and privacy. Controllers must therefore take note of the report’s scope and ensure that their requirements are included. When a processor forgoes SOC2 review of a specific section, that may draw the controller’s attention and potentially raise a red flag. Finally, the intricacy of the SOC2 report means that unpacking and understanding the findings is not necessarily a simple matter. Both privacy and security personnel will be required to invest significant time and effort in order to adequately understand the contents of a SOC2 report. In this regard, the depth of the report’s insight can be a bit of a double-edged sword.

Both ISO 27001 Certification and SOC2 reports can be incredibly useful tools for data controllers attempting to vet or manage data processors. However, they cannot simply be taken at face value to signify GDPR compliance. In order to meet GDPR’s requirements, controllers will need to dedicate the time and expertise of privacy and security professionals to the careful review of processor policies and contracts, and not simply assume that ISO 27001 certification and the existence of a SOC 2 report demonstrate a GDPR-compliant processor.

photo credit: CreditDebitPro via photopin