TY - JOUR AU1 - Lindqvist, Jenna AB - Abstract The increasingly complex data-processing reality created by new technologies, such as the ‘Internet of Things’ (IoT) underline the need for stakeholders to be clear about issues relating to responsibility for the personal data they process and/or control. The European General Data Protection Regulation (GDPR) expands the obligations of data processors and brings changes to the relationships between IoT stakeholders. To understand how the law operates in an IoT context, we need to analyse the complexity of the current legal state and map out grey areas. The focus of this article lies mainly on the contractual relationship between controllers and processors dealing with new technology, and changes to data controllers’ and data processors’ rights and obligations brought by the GDPR. The main aim is to investigate whether the GDPR is fit to deal with new technologies such as the IoT. INTRODUCTION Organizations often outsource parts of their routine activities, such as payroll administration or data storage to third parties. If the arrangement includes personal data processing, data protection legislation applies. In this scenario, the outsourcing company is a data controller, whereas the supplier of processing services is a data processor.1 The Data Protection Directive 95/46/EC (DPD) states that the controller will be held liable for data protection compliance.2 In other words, the DPD does not impose statutory obligations on processors, directly deriving from law. Instead processors can be subject to obligations that the controller imposes on them by contract to protect the controller against compliance risks.3 In fact, it is required by law that there is a contract between the controller and the processor, obliging the processor to comply with certain security and other requirements regarding personal data processed on behalf of the controller.4 However, the relationships between data stakeholders have become quite complicated because of rapid technological development and some parts of the DPD do not reflect the practical situations and relationships that data processors and data controllers face in the modern online-world. The increasingly complex data-processing reality created by new technologies, such as the ‘Internet of Things’ (IoT), underline the stakeholders’ need to be clear about issues relating to responsibility for the data they process and/or control.5 On the IoT, multiple actors often share the responsibility for personal data management and it is also likely that the status of an IoT service provider could vary (between processor and controller) in different circumstances.6 Sometimes it is hard to determine which party is accountable or liable if a device or a service encounters problems or faults. To address uncertainties and new challenges in the application of EU data protection rules, a comprehensive reform of the DPD and other EU data protection rules has been taking place since 2012, resulting in a new General Data Protection Regulation (GDPR).7 The DPD was drafted in an era before smart devices, Google and Facebook. It was impossible for the legislator at the time to foresee how rapidly the technology would outrun the law, which makes the reform overdue and very welcome. The new Regulation came into force in May 2016 and will be directly applicable in EU member states from 25 May 2018.8 The GDPR expands the obligations of data processors by introducing direct statutory obligations on processors as well as severe sanctions for non-compliance,9 forming an important change for the both contractual and non-contractual relationship between data processors and data controllers.10 A better understanding of the interaction between the concept of data controller and data processor plays an essential role in the application of the GDPR, as the specific roles condition the responsibilities for compliance and determine which stakeholders involved in the personal data processing are responsible for the data of data subjects.11 Furthermore, to understand how the law operates in an IoT context, we need to analyse the contractual requirements closely. To shed some light on the unclear existing legislation and especially the upcoming changes brought by the new regulation, this article aims at investigating the complexity of the current legal state. Focus will lie mainly on the contractual relationship between controllers and processors dealing with new technology, and changes to data controllers’ and data processors’ rights and obligations brought by the GDPR. The article maps out changes, points out unclarities and contributes to the discussion about the possible effects of the GDPR. The article examines the distribution of responsibility between the parties, with the main aim of investigating whether the GDPR is fit to deal with new technologies such as the IoT. Most of the observations in this article apply to personal data in general. However, special focus has been placed on legal issues that present themselves within the IoT. The main focus is on the GDPR, but to explain the changes in a period of potential confusion, parallels are drawn to the existing and currently applicable legislation (DPD). SETTING THE SCENE This section of the article describes the new technological landscape and the contractual relations between controllers, processors and sub-processors, continuing with a brief overview of the different contracts in a ‘smart world’. Furthermore, the section reflects on how the new challenges affect data subjects. IoT The Article 29 Data Protection Party (‘WP 29’) has identified the IoT as: [A]n infrastructure in which billions of sensors embedded in common, everyday devices – ‘things’ as such, or things linked to other objects or individuals – are designed to record, process, store and transfer data and, as they are associated with unique identifiers, interact with other devices or systems using networking capabilities.12Examples of the so-called ‘Smart Things’ or smart devices are smart TVs, running trackers, sleep monitors and smart watches. The key character of Smart Things is that they connect with other smart devices, building a kind of smart device ‘ecosystem’. Google’s smart ‘Nest’ learning thermostat is a good example of such a connected smart device. It is a thermostat designed to save energy in homes (also called ‘home automation’). It uses sensors and algorithms to control heating and hot water automatically and adapts to the user’s needs by creating personalized schedules.13 The thermostat is further interconnected with a growing collection of other IoT devices (‘Works with Nest’), such as ‘smart light bulbs’, smoke detectors, washing machines and door locks.14 The so-called ‘IoT stakeholders’ offer the applications that people download to use these Smart Things and the data gathered by them. Stakeholders can include application developers, social platforms, device manufacturers or other data recipients.15 Different stakeholders may be involved in the IoT process for various reasons. The question of whether the stakeholders are legally responsible for complying with EU law depends on whether they take the role of processors or controllers. Controller and processor Both under the DPD and the GDPR, a controller is defined as a ‘natural or legal person, public authority, agency or any other body which alone or jointly with others determines the purposes and means of the processing of personal data …’.16 Usually, the individual circumstance of each case, where personal data are being processed, determines who the controller is; the key is to define who determines why the specific processing operations are taking place and who has initiated them.17 A processor, in turn, is ‘a natural or legal person, public authority, agency or any other body which processes personal data on behalf of the controller’.18 A processor can become a controller if it uses data for its own purposes, such as for example in marketing of its own services and/or without following instructions from a controller.19 The WP 29 has set out two basic conditions for an entity to qualify as a data processor, these being a ‘separate legal entity with respect to the controller’ and ‘processing personal data on his (the controller’s) behalf’.20 Processing personal data is defined in the DPD and the GDPR as: Any operation or set of operations which is performed uponon personal data or on sets of personal data, whether or not by automatic means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blockingrestriction, erasure or destruction.21 The WP 29 has offered some advice on criteria that may be helpful in determining the qualification of controllers and processors: Level of prior instructions given by the data controller, which determines the margin of manoeuvre left to the data processor; Monitoring by the data controller of the execution of the service …; Visibility/image given by the controller to the data subject, and expectations of the data subjects on the basis of this visibility; Expertise of the parties: in certain cases, the traditional role and professional expertise of the service provider play a predominant role, which may entail its qualification as data controller.22 Defining which party is the controller and which is the processor is just the first step in distributing obligations and liability on the IoT. To a certain extent, the parties can also influence the responsibility distribution with contracts and other documentation. Contracts in a smart world Since the supply chain of the IoT is multi-layered and complex, and space is limited, this article focuses mainly on contracts between data processors and data controllers at a relatively general level with the aim of exemplifying and demonstrating the complexity of the current legal state. Drawing upon an analysis of IoT contracting by Ian Walden and Guido Noto La Diega, this section presents examples of different contracts relating to home automation with the aim of illustrating the different layers in IoT contracting.23 Before the Smart Thing is taken into use, the main stakeholders involved are the manufacturers providing the actual hardware device. Various manufacturers can contribute to this process, providing components and facilities for the manufacturing (manufacturing agreements).24 After the manufacturing, the device needs to be placed on the market. At this stage, retailers, distributors and installers step into the process (reselling agreements). The following step in the life of the smart device is the actual initialization of the products. The communication between the Smart Things requires a lot of storage space, memory and power, which is why the networking is usually administered with cloud services (cloud contracts).25 In addition, analytics tools are needed to analyse and exploit the data that are collected. Other stakeholders that come into play at this point include card processing service providers and advertising services. The structure also includes the ‘app stores’ from which the end users can buy services. Website developers, software providers and network operators are also part of the supply chain (third-party agreements). 26 Facing and protecting the data subjects Data subjects, or in an IoT context, ‘end-users’, are the focus of most IoT devices, since the smart applications are meant to be of benefit to them and they are also the ones directly or indirectly feeding the devices with data. When consumers buy smart devices, they do not just buy the object, but also by implication they acquire many services and data from multiple stakeholders. The payment usually happens both in forms of money when buying the device or application and in addition with user-generated data being fed into the device to be used by the controllers.27 Data protection is a primary concern when discussing consumer contracts in the IoT context, hence an introduction will be given describing the role of the data subjects in the contractual relationships brought up by the IoT. The data subjects (consumers or end users) are in general seen as the ‘weaker party’ in IoT contracts. The user terms of Smart Things are often written in a ‘take it or leave it’ form, and if the user does not agree, he or she must not use the device or the applications.28 This setup can be viewed through the lens of general consumer law. If, for example, a smart TV’s smart functions are turned off, there is not much you can do with the static TV, in practice leaving the user ‘locked-in’ with the user terms provided. In the eyes of consumer laws, such device could be seen as defective, as the consumer cannot use the device for its purpose. In addition, the imbalance between the IoT stakeholders such as smart device producers and consumers, leads to a conclusion that, in many cases, the contract terms are deemed unfair.29 At the same time, arguments have been presented that the technology that smart devices provide, increases the opportunities for users to stay informed about their options. When the users have comprehensive information about the alternatives at their fingertips, it has been suggested that the freedom of contract is in fact strengthened.30 The supply of smart devices does not always fit well in the current sales and consumer contracts, as we know them. When Smart Things combine the offline and online worlds, the physical features of goods are connected to digital content. Also, the supply of smart devices and applications combine sale of goods and services needed for the use of the goods.31 Instead of two different contractual ‘spheres’ divided into the contracts made in the physical world and the ones happening digitally online, the IoT technology unifies the two.32 The case of John Deere tractors identifies how a non-digital ‘traditional’ product has become ‘embedded with more and more software’ and thus ‘evolved to take on a different character’.33 John Deere is a leading American manufacturer of agricultural machinery. The machines, such as tractors, have parts that are controlled with software. In the case at hand the software was protected, which means that the owners were not able to change or repair the machine without the manufacturer’s approval. This meant that the owners of the machines did not hold the complete usufructuary right to the devices. Previously, the purchaser of a tractor owned the product ‘completely’. Now ‘farmers receive an implied license for the life of the vehicle to operate the vehicle’.34 The case ended up in a recommendation to grant ‘an exemption to the anti-circumvention rules’35 based on a ‘fair-use’ argument.36 The continuous access to online services and the supply thereof calls for an approach in which the different relationships are taken into account, namely the relationship between the buyer and the seller, the relationship between the end-user and the producer, as well as the relationship between the end user and the suppliers of digital infrastructure.37 Appointing processors and sub-processors In businesses selling or providing IoT solutions, data sets can become overwhelmingly big and scattered. As a result, personal data controllers often outsource the processing to several data processors specialized in processing masses of data. For the same reason, it is common that the initial processors further delegate parts of the processing to sub-contractors (sub-processors). Under Article 17(2) of the DPD the controller must ‘choose a processor providing sufficient guarantees in respect of the technical security measures and organizational measures governing the processing to be carried out’ when choosing a data processor. This means that the currently applicable legislation requires ‘pre-contractual checks’ on the processors.38 However, the DPD does not give any guidance as to how the checks should be performed.39 In the data processing chain, responsibilities of parties are rarely clearly determined, and the plurality of actors involved in processing can easily decrease the control and responsibility for data processing.40 The DPD does not include any specific provisions regarding sub-processing situations, but sub-processing is acknowledged in Article 28(2) of the GDPR, stating that ‘the processor shall not engage another processor without prior specific or general written authorization of the controller …’. Simply put, the Article obliges data processors to keep detailed documentation about the processing chain and requires processors to obtain authorization from the data controller when engaging sub-processors, thus adding a further control mechanism to protect data subjects’ rights.41 The reasons why transparency in sub-processor contracting relationships is important are twofold. First, it is important from a contractual point of view for the data subjects’ legal security to be able to identify which party is liable to him or her in the event of damage or loss. Secondly, it is important for the data controllers to be aware of all possible processors and sub-processors, to be able to ensure compliance with the legal (accountability) requirements provided by the GDPR.42 Also, under the DPD the sub-processors are required to comply with instructions given by the data controller. However, the requirement of a written authorization is a new specification brought in by the GDPR.43 THE CONTRACTUAL REQUIREMENTS OF ARTICLE 28 OF THE GDPR In this section, the contractual requirements brought by the GDPR are discussed in more detail. The aim of the GDPR is to bring more certainty and clarity to the interpretation of EU data protection law. However, when the rules are analysed in an IoT context, it becomes clear that the drafters of the GDPR have not been successful on reconciling the updated legislation with all new technologies, leading to possible confusion and uncertainty for those applying the law. Article 28 of the GDPR—a complicated litany of confusing rules? The GDPR builds on the DPD, but it brings more legal certainty to data subjects and hence more data protection considerations for stakeholders. Many of the new data processor obligations are included in Article 28 of the GDPR. It is a long and detailed article with many cross-references to other parts of the Regulation, creating possible confusion about the correct application of the Article. Even the explanatory memorandum of the Commission’s first proposal for the GDPR, given in 2012, does not provide much clarification as to the exact meaning of the underlying principles that have guided those drafting Article 28. The detailed explanation of the proposal states ‘Article 28 introduces the obligation for controllers and processors to maintain documentation of the processing operations under their responsibility, instead of a general notification to the supervisory authority required by Articles 18(1) and 19 of Directive 95/46/EC.’44 In other words, the explanation does not really elucidate the underlying aim of the article, especially in relation to contractual requirements. Since the article is not yet applicable, there is also limited analysis in the literature and arguably no case law regarding it yet. This section of the article will therefore cover some of the relevant points of Article 28 of the GDPR with the aim of mapping and clarifying the new contractual requirements laid out by the article.45 Governing the content of contracts with law The amount of legislation governing contracts between stakeholders on the IoT has grown in recent years, the newest addition being the GDPR. Although contract and law often work together, many situations have risen when there is tension between the law or the norms and the contracting parties’ contractual freedom.46 To avoid freedom of contact from posing a ‘threat’ to public interests, legislation decreases contractual freedom when it is needed.47 Such public interests might be protection of the weaker party or fair distribution of obligations and liability. In the context of this article, contractual freedom refers to ‘the ability of contracting parties to determine freely the terms and conditions of their contractual arrangement’.48 According to the principle of contractual freedom, contracting parties can freely determine: ‘whether or not to enter into a contract’; ‘with whom they will enter into a contract’; and ‘the terms of the contract’.49 According to Article 17 of the DPD, the processing should be governed by a contract ‘in writing or in another equivalent form’. Further, the contract must include the following two obligations: ‘The processor shall act only on instructions from the controller’; and The processor shall be bound by equivalent data security obligations as the controller. The change brought by the GDPR is a new set of more detailed requirements for the elements of the processing the contract should set out, those being: Subject matter and duration of the processing Nature and purpose of the processing Type of personal data being processed Categories of data subjects, who’s data is processed Obligations and rights of the controller50 Article 28(3) of the GDPR goes on with a list of requirements for exactly what the contract between the controller and processor should stipulate, some of those requirements being elaborated in the following sections of the article. The requirements of Article 28 of the GDPR especially affect the freedom to terminate the terms of the contract, setting limits and requirements to the terms of the contract between controllers and processors. In the IoT context, where multi-layered contracts exist both online and offline, and where contracts regulate terms regarding goods as well as services and digital content, which often change over time, freedom of contract takes on a different meaning, demanding more research into the consequences of contract law.51 The validity of contracts is a necessary principle for a meaningful contractual system, whilst contractual freedom is value-based and founded on multiple contractual systems.52 As has been identified by Pöyhönen, sometimes limiting contractual freedom clarifies and simplifies contracting mechanisms, reducing later disagreements and cases.53 The requirements of Article 28(3) GDPR can ‘clarify contracting mechanisms’ in a way that it states clearly what the contracts should entail. It will also probably ‘reduce later disagreements’ because it demands detailed contracts that are well documented, justifying the moderate limitations of contractual freedom in the processing contracting. Documented instructions from the controller The GDPR follows the DPD in assuming that the data controller is almost omnicompetent and always the stronger party, able to take responsibility for, and make the decisions about, the collection and processing of personal data. However, in the IoT supply chain, the processor company usually acts as processor for many controllers at the same time, which means that the data processor often drafts the processing contracts and presents them to the controller to sign, and not vice versa. In this outsourcing scenario, the controller is in fact the client buying a (processing) service from the processor. Imagine, for example, Google as a cloud service provider, processing personal data on behalf of thousands of clients (controllers), receiving separate individual processing instructions from every single client. In reality, the ‘instructions process’ is often turned on its head and the cloud provider (processor) has drafted standard terms that it presents to its clients (controllers) with a clause stating something like ‘These are your instructions to us. Is this ok? Good, then sign here!’ These special circumstances are quite common when handling new technologies in a digitized society, but it seems that the GDPR has not properly taken them into account; hence it is not really helping the stakeholders who really want to (and have to) apply the rules on this point. The main thing to keep in mind is that in the end, it is the controllers’ responsibility to ensure secure compliance with the GDPR. This means that the controller cannot rely on standard contractual terms drafted by the processor. However, many processor agreements presumably include the mandatory data protection provisions by now.54 The paradox of the EU data protection legislation’s focus on controllers, while in practice contractual terms are often imposed by the processors on the controller as a client, is well described in a decision from 2013 by the Swedish Data Protection Authority (‘Data Protection Authority’ or ‘Authority’). In the case, the Swedish municipality of Salem had used Google Apps cloud services for its e-mail and calendar functions. After reviewing the facts of the case, the Data Protection Authority concluded that the sub-processing agreements between the parties lacked mandatory controller instructions required by the applicable data protection legislation. The Authority also determined that the controller did not have sufficient control and insight into the data processing chain (accountability).55 The following agreements were applicable between the parties56: Google Apps Enterprise via Reseller Agreement Data Processing Addendum Appendix: Security Measures Commission Decision of 5 February 2010 on standard contractual clauses for the transfer of personal data to processors established in third countries under the DPD Google Privacy Policy In accordance with the Data Processing Addendum, the data processor ‘will process Customer Personal Data for the purposes of providing, maintaining and improving the services’.57 Furthermore, The Google Apps Enterprise via Reseller Agreement stated58 … either party may sub-contract its obligations under this Agreement, in whole or in part, without the prior written consent of the other, provided that the subcontracting party remains fully liable for all such sub-contracted obligations and accepts full liability as between the parties for the actions and/or inactions of its sub-contractors as if such actions and/or inactions were its own.The Data Protection Authority found these instructions too wide. The controller also did not have the necessary information about exactly which sub-processors had access to the data and therefore had not fulfilled its accountability requirements.59 The core of the matter in the case is that the processor (Google) is the party that has specified the ‘controller instructions’ in the agreements, leading to a result where the processor has the upper hand and it is possible for Google to process personal data for its own purposes.60 The decision shows that a controller should not accept standard processing contract provisions without assessing the individual situation. Saying the same things twice One of the main objectives with the data protection reform is to give better protection to the data subjects. The EU legislator has indicated this in adding some obligations twice over in the GDPR. Some of the required elements of the processing agreements are derived straight from law, but regardless of this, they need to be documented in the actual processing contracts as well. Article 28(3)(c) of the GDPR, for example, requires that the contract between the processor and controller must stipulate, in particular, that ‘the processor shall take all measures required pursuant to Article 32’. Article 32 of the GDPR, in turn, regulates that both the processor and the controller shall ‘implement appropriate measures to ensure a level of security …’. This means that both controllers and processors are obliged directly by law to ensure the security of personal data processing. It is therefore unclear what surplus value it brings to include this direct obligation under law into the already complicated agreement between the controller and the processor. Presumably it is meant to increase the legal certainty of data subjects by reminding the parties of their already existing obligations. A similar situation in which the GDPR is indirectly repeating itself can be found in article 28(3)(d), according to which the contract between the controller and processor must stipulate that “The processor respects the conditions referred to in paragraphs 2 (‘the processor shall not engage another processor without prior … authorisation of the controller’) and 4 (‘where a processor engages another processor for … the same data protection obligations as set out in the contract … between the controller and the processor shall be imposed on that other processor …’) for engaging another processor. Article 28(2) and (4) directly binds processors (and controllers) already, but still the requirements must also be documented in a contract. Assistance requirements The GDPR gives data subjects more control over their data and hence more rights to be properly aware of how companies use their data in their business. The other side of the coin is of course having more accountability obligations for controllers. In order for the controllers to be able to fulfil their obligations, they need assistance from the processors, who often are better equipped to provide the necessary information needed to enable the data subjects to exercise their rights under the GDPR. According to Article 28(3)(e) of the GDPR, the processing contract must stipulate: The processor shall, taking into account the nature of the processing, assist 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.Chapter III of the GDPR regulates ‘the rights of the data subjects’. The chapter includes provisions regarding transparency and modalities, information and access to personal data, rectification and erasure, right to object and automated individual decision-making and restrictions. This is a welcome amount of precision, since the processors are often more competent to analyse and provide data hands-on as opposed to controllers, who are simply determining the purposes and means of the processing by a contract, and are not necessarily able to access detailed data sets easily. However, the requirement is written in quite vague terminology: It includes wording such as ‘taking into account the nature of the processing’, ‘by appropriate technical and organisational measures’ and ‘insofar as this is possible’. In an actual situation when the assisting obligation stated in the contract between the controller and processor would be (con)tested, the result could probably swing in either direction, depending on the interpretation of the article and the argumentation. Further assistance requirements are stated in Article 28(3)(f): The processor shall assist 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.This assisting obligation refers to security of processing (Article 32 of the GDPR), notification of a personal data breach to the supervisory authority (Article 33 of the GDPR), communication of a personal data breach to the data subject (Article 34 of the GDPR), data protection impact assessment (Article 35 of the GDPR) and prior consultation with a supervisory authority (Article 36 of the GDPR). Article 35 becomes especially relevant when dealing with IoT technology; paragraph 3(a) of Article 35 demands that a data protection impact assessment shall in particular be required in a case of a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person.Most IoT devices create a profile of the data subject, and more and more decisions are based on these profiles. Therefore, a conclusion could be drawn that an impact assessment is always required when gathering data with smart devices, if this is done through automated processing. ACCOUNTABILITY In this section, the accountability principle is analysed and discussed. The underlining of the accountability principle is one of the changes brought by the GDPR and it highlights the changing relationship between data controllers and data processors as well as the importance of well-drafted processing contracts. The accountability principle One of the biggest changes provided by the GDPR is the emphasis on accountability. The accountability principle was not expressly included in the DPD. Nevertheless, it could be indirectly identified in the articles regarding judicial remedies, liability and sanctions (Articles 22–24 of the DPD). In addition, one can interpret that Article 6 of the DPD (data quality principles) includes the accountability principle by implication, because it states that ‘it shall be for the controller to ensure that paragraph 1 (data quality principles) is complied with’.61 The principle was however explicitly included into the GDPR in Article 5, which refers to the principles relating to the processing of personal data, those being principles of lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation and integrity and confidentiality.62 According to Article 5(2) of the GDPR, ‘[t]he controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (the data quality principles) (“Accountability”).’ Demonstrating compliance The growing importance of the accountability principle requires that a controller must be able to demonstrate in a measurable way that it has complied with the EU data protection obligations. In accordance with Article 28(3)(h) of the GDPR, the processing contract must stipulate that ‘The processor shall make available to the controller all information necessary to demonstrate compliance with the obligations laid down in this article and allow for and contribute to audits …’. For the accountability obligation to be properly fulfilled, there must be a link between the controller’s accountability obligation and the measurability of the processing.63 The measuring can be performed with processor audits, for example. The right to audit can include64: ‘the right to audit the location of the servers where data are processed and stored’; ‘the right to audit the logic (the algorithms) which are used throughout the various steps envisaged for the whole processing’; and ‘the right to audit the security measures put in place by the processor’. In the end, it is up to the contracting parties to decide how detailed they want to describe the auditing rights in their contract. The right to conduct an audit can, however, be complicated to realize if the processor processes personal data on behalf of many controllers. When (personal) data from different stakeholders are being stored in the same location, it can form a serious security risk to allow an audit.65 The processor’s accountability obligation Accountability, as enshrined in the GDPR, requires accountability only from a data controller even if it uses the services of a processor for the actual data processing, leading to the conclusion that accountability is not an obligation ‘specifically directed to processors’.66 Therefore, if it comes to liability, processors cannot be liable for failure to apply the accountability principle, unless it is included in the processing instructions from the controller. This again highlights the importance of well-thought-through contracts between data processors and controllers. The accountability principle is visible in the processing contract requirements of Article 28: Article 28(3)(h) states that the processing contract should stipulate that ‘the processor shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other Union or Member State data protection provisions’. Currently, the DPD does not include such provisions regarding possible conflicting requirements between the controller’s instructions and the law, namely the DPD. The GDPR now presumably aims to clarify this issue by requiring the processor to inform the controller if the processor presumes that the controller’s instructions are in conflict with the GDPR. However, there is no clear guidance on what the consequences are if in fact the processor has already acted in breach of applicable legislation when carrying out the controller’s instructions, adding a further layer on the contractual negotiations between the parties. LIABILITY The complexity of contractual relationships between IoT stakeholders is furthermore identified in this section of the article. The section describes the changes in liability distribution and adds to the analysis of the compatibility of the GDPR in an IoT context. Distributing liability There is confusion about both contractual and extra-contractual distribution of liability when it comes to IoT scenarios. If, for example, a self-driving car was to cause damage to another car, the liability could fall on the producer of the car, the designer of the car, the seller, the stakeholder providing the infrastructure for the automated car or even ‘the driver’.67 Google’s NEST smart home system has for example encountered issues with unreliable functioning of its thermostat. In an example case there was ‘a miscommunication between partner services’ in the Nest, which lead to the system interpreting the closing of the garage door as an indication of the homeowner ‘leaving the house for a long period’ and the heating was turned off.68 This failure in the system ‘could be the fault of an ISP (Internet Service Provider), payment facilitator or intermediary or the product itself’ and it is very complex to identify which one it in the end is.69 Consequently, questions have been raised whether it is even possible to have a ‘fault-based liability approach’ if in fact autonomous software or an algorithm is the reason for the damage, especially if a causality link to a human cannot be established.70 However, the GDPR has put a lot of emphasis on strengthening the enforceability of the regulation.71 Following the GDPR, the liable companies can now have heavy administrative fines imposed on them in cases of infringement. At the contractual level, the liability for damages can to a certain extent be distributed between the stakeholders. Article 28(4) of the GDPR states that: … Where that other processor (sub-processor) fails to fulfil its data protection obligations, the initial processor shall remain fully liable to the controller for the performance of that other processor's obligations.If a liability situation arises from breach of contract by the sub-processor, the initial processor has a legal responsibility to the controller. The initial processor can later seek compensation from the sub-processor with reference to their contract. In practice, the complexity of contractual relationships between IoT stakeholders can act as a ‘disclaimer of responsibility’; if a smart device is faulty or if it is found that data protection regulations have been breached, it is possible that the hardware manufacturer could try to shift the blame to the software developer. The software developer in turn may say that it is actually the service provider who is the guilty one.72 Liability for potential damages Under the DPD liability for damages is regulated in Article 23, according to which, the Member States shall ‘provide that any person who has suffered damage as a result of an unlawful processing operation … is entitled to receive compensation from the controller for the damage suffered’.73 This means that under the DPD, the controller is the only party who is liable for damages directly deriving from the personal data protection law. In practice, the controller has been able to spread the risk by adding indemnification clauses to the processing agreements. Article 82 of the GDPR brings changes to the liability distribution stating that ‘any person who has suffered material or non-material damage as a result of an infringement of this Regulation shall have the right to receive compensation from the controller or processor for the damage suffered’.74 According to Article 82(2) of the GDPR, a controller is liable for damage caused by processing which infringes the regulation, whilst a processor ‘shall be liable for the damage caused by processing only where it has not complied with obligations of this Regulation specifically directed to processors or where it has acted outside or contrary to lawful instructions of the controller’.75 As identified in Recital 85 of the GDPR, the damages can, for example, include: [l]oss of control over personal data or limitation of rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, loss of confidentiality of personal data protected by professional secrecy or any other significant economic or social disadvantage to the natural person concerned. Article 82(3) of the GDPR states that both the controller and the processor can be exempted from liability if they prove that they are ‘not in any way responsible for the event giving rise to the damage’. In cases of joint controllership or ‘processorship’, each controller or processor can be held liable for the entire damage.76 Any controller or processor which has paid full compensation ‘may subsequently institute recourse proceedings against other controllers or processors involved in the same processing’77 and claim back a part of the compensation corresponding their part of the responsibility.78 The underlying aim is to assure full and effective compensation for damages for data subjects.79 According to the WP 29, the first and foremost role of the controller is to allocate responsibility and to determine who is responsible for compliance rules, and how data subjects can exercise their rights in practice.80 The first objective, and the heart of the DPD, is to protect individuals with regard to the processing of personal data. This objective can only be realized if the data controllers and processors can be sufficiently stimulated by legal (and other) means to take the measures that are necessary to ensure that this protection is provided in practice.81 CONCLUSIONS It is problematic to analyse legislation that has not yet been applied. The lack of existing case law and proper guidelines makes it difficult to draw reliable conclusions about the correct interpretation and effect of the GDPR norms. At the same time, this is also the reason why research in this field is so important. The GDPR will come into effect from May 2018 and data processers and data controllers in the EU must be prepared and compliant by then. Taking into account that the DPD only has 34 articles, whilst the GDPR has 99 articles, there is a lot of work to do for many. The situation is especially critical for many small businesses with limited resources and funds. Recital 15 of the GDPR notes, ‘in order to prevent creating a serious risk of circumvention, the protection of natural persons should be technologically neutral and should not depend on the techniques used’. However, as has been identified in this article, many of the obligations in Article 28 of the GDPR are difficult to implement in the IoT context: The GDPR brings with it many comprehensive requirements to processing contracts, such as highlighted accountability, detailed processing instructions, assistance requirements such as audits, but yet it fails to present clarification of underlying principles that have guided the drafters of the regulation. Furthermore, the regulation does not effectively demonstrate the fact that the supply of smart devices does not always fit well in the current sales and consumer contracts, as we know them. Not enough scrutiny has been given to the new relationship between processors and controllers, or to the relationship between stakeholders and consumers. The IoT technology links different technologies, smart objects and branches of law to each other and this should be better understood to be able to realize data protection rights in the EU. In fact one of the biggest challenges imposed on data protection and contractual legislation by the IoT is the confusing new concept of goods. It has been suggested that we need a new definition of ‘products’ when talking about Smart Things.82 Products consisting of hardware, software and services, existing at the same time in an offline and an online world and constantly developing and changing are difficult to define and therefore also difficult to draft contracts about, leading to a lot of confusion among stakeholders. In places, the GDPR is written in vague terminology such as ‘insofar as this is possible’ leaving the actual implementation of the legislation quite open for interpretation and consequently not changing the status quo considerably enough. In addition, some processor obligations in the GDPR, such as requirements for security measures and sub-processing mechanisms, are stated twice over, which adds to the confusion experienced by legal scholars trying to understand the underlying principles of the GDPR. One can ask why some obligations are stated twice while others are not. Surely all articles are as binding as each other. As identified in section ‘The Contractual Requirements of Article 28 of the General Data Protection Regulation’, data protection legislation is difficult to reconcile with IoT services as the law assumes that it is the data controller who is the strong, decisive player, who can instruct and control what the data processors do. In IoT services, the reality is different. In such cases, it is usually the data processor that is offering a service and it is the processor who in reality decides the rules of the processing, usually through standard agreements and policies.83 The fact that the GDPR leaves so much room for in casu interpretation means that the importance of well thought-through contracts between data processors and controllers are crucial. Currently, it seems that the EU legislator places its bets on data controller conduct. As has been discussed in this article, the opportunities for data controllers to formulate individual processing instructions and to specify in casu security measures are limited in the technological reality in which we operate today.84 Even though the GDPR brings with it new statutory responsibilities for data processors, bad or unclear contractual clauses in data processing agreements are likely to cause legal problems especially for data controllers in the future. This problem can of course increase significantly if the initial processor engages sub-processors to assist with the processing. Therefore, a thorough control of their existing and upcoming processing contracts may be a good idea for most IoT stakeholders. It is however safe to assume that more guidance and clarity is on its way: the WP 29 has designed an action plan for the implementation of the GDPR, preparing the transition into the new legal framework. One of the priorities of the action plan is issuing guidance for controllers and processors: the aim of the plan is to provide guidelines to help controllers and processors get prepared for the application of the GDPR.85 During the preparation and transition period, one of the priorities of the EU legislators ought to be issuing reliable and intelligible guidance for controllers and processors. The WP 29 will be replaced by ‘The European Data Protection Board’ (Board) established by the GDPR.86 Article 70 of the GDPR identifies some of the Board’s tasks, mainly consisting of issuing guidelines, recommendations and best practices on the application of the GDPR.87 The transition time will, however, pass quickly and it is vital for the stakeholders of the IoT to receive guidance now and not later when the Board has been properly established and started its work. Footnotes 1 P Carey, Data Protection: A Practical Guide to UK and EU Law (OUP 2015) 261. 2 Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data, OJ 1995 L 281/31 (DPD) see eg art 23. 3 H Grant, A Lambert and K Pickering, ‘Data Protection Day—Data Processors and the GDPR’ (2016) fieldfisher accessed 17 May 2017. 4 DPD, arts 16–17; art 28 of the Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (GDPR) OJ 2016 L 119/1; See also Carey (n 1) 262. 5 art 29 Working Party, ‘Opinion 8/2014 on the on Recent Developments on the Internet of Things’ (WP 223, 16 September 2014) 11. 6 ibid. 7 Regulation (EU) 2016/679. 8 GDPR, Introduction and art 99. 9 See eg GDPR, art 28. 10 Grant and others (n 3). 11 art 29 Working Party, ‘Opinion 1/2010 on the concepts of “controller” and “processor”’ (WP 169, 16 February 2010) 2. 12 WP29, Opinion 8/2014 (n 5) 4. 13 See Nest.com web page accessed 21 March 2017. 14 ibid. 15 WP29, Opinion 8/2014 (n 5) 4. 16 DPD, art 2(d); GDPR, art 4(7). 17 WP29, Opinion 1/2010 (n 11) 8. 18 DPD, art 2(e); GDPR, art 4(8). 19 See GDPR, art 28(10) stating that if a processor infringes the GDPR by determining the purposes and means of processing, the processor becomes a controller in respect of that processing. 20 WP29, Opinion 1/2010 (n 11) 1. 21 DPD, art 2(b); GDPR, art 4(2). Strikethrough and italics by author. Strikethrough refers to wording in DPD that has been erased/replaced by the GDPR. Italics means addition in the GDPR. 22 WP29, Opinion 1/2010 (n 11) 28. 23 G Noto La Diega and I Walden ‘Contracting for the “Internet of Things”: Looking into the Nest’ (2016) 7(2) EJLT s 3, accessed 2 June 2017. 24 ibid. 25 Noto La Diega and Walden (n 23) s 3; ‘Third party’ means ‘a natural or legal person, public authority, agency or body other than the data subject, controller, processor and persons who, under the direct authority of the controller or processor, are authorised to process personal data’ GDPR, art 4(10). 26 Noto La Diega and Walden (n 23) s 3. 27 C Wendehorst ‘Consumer Contracts and the Internet of Things’ in R Schulze and D Staudenmayer (eds), Digital Revolution: Challenges for Contract Law in Practice (Nomos Verlagsgesellschaft 2016) 191. 28 Noto La Diega and Walden (n 23) s 3. 29 ibid, s 6; for further reading about consumer contract terms, see SR Peppet, ‘Freedom of Contract in an Augmented Reality: The Case of Consumer Contracts’ (2012) 59 UCLA L Rev 676, 689. The page numbering used in this article is following University of Colorado Law Legal Studies Research Paper No 11–14 accessed 24 March 2017. 30 Peppet (n 29) 10 and 22. 31 Wendehorst (n 27) 222. 32 Peppet (n 29) 33. 33 L Coll and R Simpson, ‘Connection and Protection in the Digital Age: The Internet of Things and Challenges for Consumer Protection’ (Consumers International, April 2016) 34 accessed 21 August 2017. 34 ibid. 35 Anti-circumvention rules forbid the circumvention of technical measures preventing access to copyrighted material. 36 Coll and Simpson (n 33). 37 Wendehorst (n 27) 222. 38 Carey (n 1) 264. 39 ibid. 40 WP29, Opinion 1/2010 (n 11) 27–28. 41 ibid. 42 Noto La Diega and Walden (n 23) s 3. 43 DPD, arts 16–17. 44 Commission, ‘Proposal for a Regulation of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)’ COM (2012) 11 final. 45 Space does not permit a detailed examination of each section. That is why the most relevant points to the specific topic of this article have been highlighted. 46 LA Bygrave, Internet Governance by Contract (OUP 2015) 104. 47 ibid. 48 ibid. 49 ibid 114. 50 GDPR, art 28(3). 51 Peppet (n 29) 1. 52 J Pöyhönen, Sopimusoikeuden järjestelmä ja sopimusten sovittelu (Suomalaisen Lakimiesyhdistyksen julkaisuja 1988) 88. 53 ibid 94. 54 Carey (n 1) 265. 55 The Swedish Data Protection Authority, ‘Tillsyn enligt personuppgiftslagen (1998:204)—Uppföljning av beslut i ärende 263-2011’ (31 May 2013) accessed 16 November 2016, 1. 56 ibid 2–3. 57 The Swedish Data Protection Authority (n 55) 5. 58 ibid 10. 59 ibid 11. 60 ibid 6. 61 DPD, art 6; G Zanfir, ‘Forgetting about Consent: Why the Focus Should Be on “Suitable Safeguards” in Data Protection Law’ in S Gutwirth, R Leenes and P De Hert (eds), Reloading Data Protection (Springer 2014) 252. 62 GDPR, art 5(1). 63 art 29 Working Party, ‘Opinion 02/2015 on C-SIG Code of Conduct on Cloud Computing’ (WP 232, 22 September 2015) 11. 64 ibid. 65 The Swedish Data Protection Authority (n 55) 16. 66 GDPR, art 82; GDPR, art 5(2). 67 R Schulze and D Staudenmayer, ‘Digital Revolution—Challenges for Contract Law’ in R Schulze and D Staudenmayer (eds), Digital Revolution: Challenges for Contract Law in Practice (Nomos Verlagsgesellschaft 2016) 28. 68 Coll and Simpson (n 33) 29. 69 Schulze and Staudenmayer (n 67) 29. 70 ibid. 71 See eg GDPR, recital 148; GDPR, art 83. 72 Noto La Diega and Walden (n 23) s 5. 73 DPD, art 23 (emphasis added). 74 GDPR, art 82(1) (emphasis added). 75 GDPR, art 82(2) (emphasis added). 76 GDPR, art 82(4). 77 GDPR, recital 146. 78 GDPR, art 82(5). 79 GDPR, recital 146. 80 WP29, Opinion 1/2010 (n 11) 4. 81 ibid; DPD, art 17. 82 Noto La Diega and Walden (n 23) 4. 83 The Swedish Data Protection Authority (n 55) 10. 84 ibid. 85 art 29 Working Party, ‘Statement on the 2016 action plan for the implementation of the General Data Protection Regulation (GDPR)’ (WP 236, 2 February 2016) 2. 86 GDPR, recitals 77 and 139–40. 87 GDPR, art 70; For further information about the tasks of the Board, see GDPR, Chapter VII s 3. © The Author(s) (2017). Published by Oxford University Press. All rights reserved. For Permissions, please email: journals.permissions@oup.com. TI - New challenges to personal data processing agreements: is the GDPR fit to deal with contract, accountability and liability in a world of the Internet of Things? JF - International Journal of Law and Information Technology DO - 10.1093/ijlit/eax024 DA - 2017-12-20 UR - https://www.deepdyve.com/lp/oxford-university-press/new-challenges-to-personal-data-processing-agreements-is-the-gdpr-fit-yifKjUcpPt SP - 45 EP - 63 VL - 26 IS - 1 DP - DeepDyve ER -