In less than a year’s time, the General Data Protection Regulation will succeed the EU’s Data Protection Directive. But many organizations striving to align with the new framework’s requirements are not properly weighing the gravity of its nuanced “controller accommodation” provision, or are avoiding it out of distress.

Controller accommodation is the concept of processors accepting the burdens of the GDPR on behalf of controllers when systematic or procedural boundaries necessitate it. Generally, this is put into the context of employing security measures and facilitating requests from data subjects to exercise their rights. The condition should eliminate finger pointing between controllers and processors, something that vague privacy doctrines of the past have allowed, but it seems as though companies are having trouble determining and formally spelling out when business relationships and technology interplay demand accommodation.

Straight from the text

Serving as the guard rails for this topic, Article 28 of the GDPR’s “Controller and Processor” chapter is chiefly the section that outlines the responsibilities of controllers when engaging processors. Part 1 of the article sets the tone for the remaining parts to come, establishing that controllers interested in delegating to processors (i.e. service providers) functions of their product or service that involve personal data processing must only engage organizations willing and able to uphold whatever the inherited obligations of the GDPR would be. Subsequently, part 3 dictates what must be documented in contracts between controllers and processors, particularly including details like the nature of the relationship with the processor (what the processor’s service or product is), what the processor will actually be doing (as in, what is the functional interaction between the controller and processor) as part of their service or product, the types of personal data that will be handled by the processor, and what general or specific GDPR obligations will be imposed on the processor. That part segues into the following section of the article, which most explicitly drives the concept of controller accommodation:

“…(e) taking into account the nature of the processing, [a processor] assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller’s obligation to respond to requests for exercising the data subject’s rights laid down in Chapter III;

(f) [a processor] assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor;

(g) at the choice of the controller, [a processor] deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data…”

There are some very actionable takeaways here.  Simply put: controllers can only work with processors that will abide by the precepts of the GDPR, controllers and processors must agree on accommodation requisites, and this all must be formally articulated in writing.

Many organizations serving in the role of processor when the GDPR is effective next year are disbelieving or apprehensive of what controller accommodation will really involve. For example, when exploring provisions like the right to erasure (the right to be forgotten), a common refrain is, “How are we supposed to do that?” The idea of assisting controllers with data purging or masking seems to be a bit abstract. Consider a cloud service provider who offers distributed storage-as-a-service and is helping a customer of theirs (the controller) facilitate a data subject’s request for personal data erasure when the controller does not have the system access to fulfill it themselves.  This could involve an incredible degree of diligence when data that needs to be deleted is stored on more than one node in a replicated fashion.

Or, worse: consider the IT service provider that backs up customer (controller) data onto shared backup tapes and has to destroy the personal data of a European resident exercising their right to erasure. Some organizations have thousands of backup tapes. Helping with a request like this would require the service provider to identify the backup image or images that contain the target file or files, find the tape or tapes with the related backup images, then duplicate all other backup images on the tapes before destroying the tapes. And if the backup image also contains other files that must be kept, then the service provider would first need to restore that backup image, delete the file, and then backup the rest again. 

Another common hang up for IT service providers is, “how am I supposed to know where European personal data is stored?”

Consider a simple software-as-a-service provider whose product ingests customer data through file uploading and open text fields. Any kind of information can be inputted into the solution. If the SaaS’ customers (controllers) are not systematically able to purge data housed by the SaaS, then the SaaS provider is going to have to own part of the erasure process, and it’ll be a blind exercise without a knowledge of where the targeted data resides.

Examples like these solidify the point that accommodation may prove to be extremely challenging and will most likely require a great deal of infrastructure reengineering and procedural evolution for some companies. Controllers and processors are going to have to extensively map where personal data resides in a processor’s environment, determine who is able to manage the various harbors of personal data identified and, lastly, establish who is obligated to carry out certain tasks to fulfill data subject requests. As noted earlier, contracts between controllers and processors must be drafted to outline processor obligations, and they should be as unambiguous as possible so agreed upon accommodation expectations are crystal clear.

For future processors, the GDPR’s controller accommodation provision is no light switch that can be easily flicked on come May 28, 2018. Preparing for the new privacy doctrine will require organizations to dive deep into hypothetical situations that would require accommodation and will demand an honest look at what technology and process adaptations might be necessary. The GDPR may really show itself to be a catalyst of change and reface enterprise IT architecture and operations indefinitely.