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 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