Liability under EU Data Protection Law: From Directive 95/46 to the General Data Protection Regulation

To properly understand the liability exposure of controllers, it is necessary to first understand the nature of controller obligations. Directive 95/46 imposes a variety of obligations upon controllers. In certain instances, the obligations specify a result to be achieved (e.g., “personal data must be collected for legitimate purposes and not further processed in a way incompatible with those purposes”).  [13] In other instances, the obligations are specified as an obligation to make reasonable efforts to do something (“obligation of means”). For example, article 6(1)d provides that the controller must take “every reasonable step” to ensure that data which are inaccurate or incomplete shall be erased or rectified. Similarly, article 17(1) requires the controller to implement “appropriate” measures to ensure the confidentiality and security of processing. Finally, it should be noted that certain requirements necessitate a further assessment in light of the specific circumstances of the processing (e.g., whether or not personal data are “excessive” will depend inter alia on the purposes of the processing). The precise nature of the controller’s obligations must therefore always be determined in light to the specific wording of each provision.

Article 23(1) provides that the controller shall be liable towards data subjects for any damages suffered “as a result of an unlawful processing operation or of any act incompatible with the national provisions adopted pursuant to this Directive”. The liability rule of article 23 has been characterised as a form of “strict” (i.e. “no fault”) liability.  [14] The reason for this characterisation is the finding that the controller cannot escape liability simply by demonstrating the absence of a “personal fault”. Likewise, it is not necessary for data subjects to demonstrate that the unlawful act was personally committed by the controller.  [15] One should be careful however, to not overstate the “strict” nature of controller liability.  [16] Even though the data subject is not required to demonstrate a “personal fault” on the part of the controller, he or she must in principle still succeed in proving the performance of an “unlawful act”.  [17] Demonstration of an “unlawful act” generally amounts to a demonstration of “fault” for tort law purposes.  [18] Conversely, if the controller can establish that the processing complies with the requirements of the Directive, he will effectively exempt himself from liability on data protection grounds.  [19] The characterisation of controller liability as “strict” liability (i.e. the notion that a controller may be still be held liable in absence of a personal fault) is therefore mainly relevant in relation to (1) controller obligations which impose an obligation of result; and (2) the liability of a controller for acts committed by his processor.

Under Directive 95/46, the controller has a general duty to ensure compliance. Because the processor is seen as a “mere executor”, who simply acts in accordance with the instructions issued by the controller, the Directive maintains that the responsibility for ensuring compliance remains with the controller. The mere fact that the unlawful action was performed by the processor rather than the controller does not diminish the controller’s liability exposure.  [20] The controller shall in principle be liable for any violation of the Directive resulting from the operations carried out by a processor acting on its behalf (“as if they were performed by the controller”). In other words, Directive 95/46 imposes upon controllers a “non-delegable duty of care”: the duty of care that a controller owes data subjects cannot be transferred to an independent contractor.  [21]

A controller cannot escape liability for actions undertaken by its processors by demonstrating an absence of fault in either his choice or supervision of the processor.  [22] This is a consequence of the strict liability imposed upon controllers: a controller can only escape liability by demonstrating that the processing complies with the requirements of the Directive or by proving an “event beyond his control” (article 23[2]).  [23] The EU legislator chose to attach liability to the quality of a person as data controller (qualitate qua), without making any reference to possible exemptions other than the one mentioned in article 23(2).  [24]

The liability of the controller for the actions performed by its processor is similar to the vicarious liability of a principal for the actions undertaken by its auxiliaries, whereby “a person is liable for damage caused by his auxiliaries acting within the scope of their functions provided that they violated the required standard of conduct”.  [25] In case of processors, however, the relationship with the controller in principle is not hierarchical in nature. While the processor is legally prohibited from processing the data “except on the instructions of the controller”, he is not necessarily a “subordinate” of the controller.  [26] As a result, the processor will in principle not be formally considered as an “auxiliary” of the controller for tort law purposes, although the outcome may be similar in practice.  [27]

To hold a controller liable, the data subject must succeed in demonstrating three elements: namely (1) the performance of an “unlawful act” (i.e. an unlawful processing operation or other act incompatible with the national provisions adopted pursuant to the Directive); (2) the existence of damages; and (3) a causal relationship between the unlawful act and the damages incurred.  [28] In addition, the data subject must also establish, as a preliminary matter, that the defendant is (or was) acting as the “controller” of the processing.  [29]

The burden of proof incumbent upon data subjects can be quite onerous. First, identifying the controller of the processing at issue may be a complicated exercise, especially where more than one party is involved in the processing. Second, demonstrating the performance of an “unlawful act” may also be a challenge, particularly in cases where the Directive specifies an obligation of means (rather than an obligation of result), or requires further interpretation (e.g., an assessment of proportionality).  [30] Demonstrating causality can also be difficult especially in cases where a particular outcome may be caused by different factors. For example, it may be difficult to prove that the unlawful collection of information (e.g., information regarding the ethnicity of a loan applicant) actually caused the damages to occur (e.g., the denial of a loan may be attributed to many different factors).  [31] Finally, demonstrating recoverable damages (e.g., loss of reputation, emotional distress) can also be a challenge.  [32]

A major difficulty for data subjects is that the evidence relevant to their case is often only accessible to the controller or its processor. Because personal data processing is generally conducted “behind closed doors”, it can be difficult for data subjects to obtain solid evidence substantiating their claims.  [33] Depending on the facts at hand however, the data subject may be able to invoke a presumption or other judicial construct with similar effect to help substantiate its claim. For example, in a case involving the unauthorised disclosure of personal data, the European Union Civil Service Tribunal has considered that the burden of proof incumbent upon the applicant may be relaxed:

“in cases where a harmful event may have been the result of a number of different causes and where the [defendant] has adduced no evidence enabling it to be established to which of those causes the event was imputable, although it was best placed to provide evidence in that respect, so that the uncertainty which remains must be construed against it”.  [34]

The reasoning of the Civil Service Tribunal can be seen as an application of the so-called “proof-proximity principle”, which allocates the evidential burden of proof on the party to whom the evidence is available, or whomever is better situated to furnish it easily and promptly.  [35] Another judicial construct which may benefit certain data subjects is the adage of “res ipsa loquitur” (“the thing speaks for itself”), pursuant to which negligence may be inferred in cases where the harm would not ordinarily have occurred in the absence of negligence.  [36] It should be noted however, that the ability for the data subject to avail him- or herself of a particular presumption or construct, may vary according to the domestic legal system of each Member State.

Article 23(2) stipulates that “the controller may be exempted from this liability, in whole or in part, if he proves that he is not responsible for the event giving rise to the damage”. The question inevitably arises as to the nature of the evidentiary burden of proof incumbent upon controllers. Which evidence must controllers offer to successfully exempt themselves from liability, either for their own actions or for the actions performed by their processors or auxiliaries?

In order to prove that he is “not responsible for the event giving rise to the damage”, the controller must demonstrate three things: (1) the occurrence of an event; (2) which caused the damage; and (3) which cannot be attributed to the controller.  [37] In principle, mere demonstration of an absence of fault on the part of the controller is not sufficient.  [38] Once it is established that the damage was caused by an unlawful processing operation, the controller can only escape liability by demonstrating that the damages occurred only as the result of an event that cannot be attributed to him.  [39]

The wording “not responsible for the event giving rise to the damage” recalls the concept of an “external cause” or “event beyond control”, which in many jurisdictions is accepted either (1) as a justification ground excluding fault, or (2) as a means to demonstrate the absence of a causal relationship.  [40] According to the Draft Common Frame of Reference, an event beyond control is “an abnormal occurrence which cannot be averted by any reasonable measure” and which does not constitute the realisation of a risk for which the person is strictly liable.  [41] The aim of the liability exemption is therefore not to reduce the “strict” liability of the controller. Rather, its aim is to keep the strict liability within the borders of the risk for which it exists.  [42] Recital (55) provides two examples of events for which the controller cannot be held responsible: namely, (1) an error on the part of the data subject;  [43] and (2) a case of force majeure.  [44]  [45]

Article 23(2) of Directive 95/46 provides the only valid defence for controllers once the data subject has satisfied its burden of proof. In practice, controllers will not wait until the burden of proof shifts to them. Most controllers will try to ward off liability by arguing that the conditions of liability are simply not met, e.g. by demonstrating the absence of illegality in the processing. Again, the nature of the controller obligation at issue will be determinative here. Where an obligation of means is concerned, controllers can effectively avoid liability by demonstrating that they implemented every reasonable measure that might be expected of them. Even where an obligation of result is involved, controllers may seek to avoid liability by reference to the Google Spain ruling, where the Court of Justice indicated that there may also be practical considerations which limit the responsibilities of controllers.  [46] In particular, when qualifying search engine providers as “controllers”, the Court of Justice indicated that there may be practical limits to the scope their obligations:

“[…] the operator of the search engine as the person determining the purposes and means of that activity must ensure, within the framework of its responsibilities, powers and capabilities, that the activity meets the requirements of Directive 95/46 […]”.  [47]

By explicitly referring to the “powers and capabilities” of the search engine operator, the Court of Justice implicitly acknowledged that there may be practical limits to the ability of a search engine operator to meet all the obligations resulting from Directive 95/46.  [48] In particular, it can be argued that Google Spain does not oblige search engine providers to exercise preventative control over the information it refers to.  [49] In fact, the reasoning of the Court of Justice suggests that the obligations of search engine providers concerning third-party data is essentially only “reactive”; only after the provider has been made aware of the fact that the display of specific search results following a name search adversely impacts the data subject, must the provider assess whether or not delisting is necessary.  [50]

In principle, there is no restriction as to the type or amount of damages that data subjects may claim. Data subjects can claim both material (e.g., loss of a chance) and non-material damages (e.g. loss of reputation, distress).  [51] Of course, the general rules on damages shall also apply here (e.g. personal interest, actual loss, etc.).  [52]

In scenario A, the data subject shall in principle only be able to hold the processor liable on the basis of data protection law if this is provided by the national legislation implementing Directive 95/46.  [55] Article 49(3) of the Dutch Data Protection Act, for example, provides that the processor can be held liable by data subjects insofar as the damages resulted from his activities.  [56] In contrast, the Belgian Data Protection Act does not recognise a right for data subjects to hold processors liable as such. A data subject might nevertheless be able to hold a processor liable if he can demonstrate that the actions of the processor constituted “negligence” or violated another legal provision.  [57] The standard of care incumbent upon the processor may, however, be informed by the contract between controller and processor.  [58] In any event, the controller who has been held liable by the data subject, should be able to claim back the damages from the processor on the basis of the contract between them.  [59]

In scenario B, the processor does not merely fail to observe the instructions issued by the controller, but also decides to process the personal data for his own purposes. In such instances, the processor shall be considered to be acting as a controller in his own right, by virtue of determining his own “purposes and means” of the processing.  [60] As a result, the (former) processor can be held liable in any event on the basis of national legislation implementing article 23 of Directive 95/46.  [61] In principle, data subjects may also turn to the initial controller (who had entrusted the data to the (former) processor) for compensation. This is a result of the strict liability regime of article 23. The initial controller cannot escape liability by demonstrating an absence of fault in either his choice or supervision of the processor.  [62] In practice, this means that the data subject will typically have the choice whether or not to sue both parties and whether or not to do so simultaneously or consecutively (although national tort law may specify otherwise).  [63] Again, the initial controller should be able to claim back the awarded damages from the processor for disregarding his instructions on the basis of the contract between them.  [64]

Separate controllers exchange personal data with one another, but do so without making any joint decisions about the purposes and means of any specific processing operation.  [66] In such cases, each party is independently (yet fully) responsible for ensuring compliance of its own processing activities. In principle, the liability exposure of each party is also strictly limited to the processing activities under its own control. In exceptional cases however, liability may nevertheless be shared, particularly where failure to ensure compliance by one controller contributes to the same damages caused by the fault by another controller.

In the case of separate controllers, the starting point is that each controller is only responsible for ensuring compliance with its own activities (“separate control, separate responsibilities”). As Olsen and Mahler put it:

“In this type of multiple data controller relationship, the data controllers separately process personal data, but there is a data flow from one controller to the other. Each controller is responsible for his own processing, and the communication of personal data to the other data controllers is one example of such processing. One controller is not responsible for acts or omissions of the other data controller.”  [67]

Because each controller is separately responsible for his own processing activities, only one controller shall in principle be liable in case of an unlawful processing operation (scenario A).  [68] Liability may nevertheless be shared, however, if the fault of one controller brings about the same damage as the fault of another controller (scenario B).

In the case of joint control, several parties jointly determine the purposes and means of one or more processing activities. The distinction between “joint” and “separate” control may be difficult to draw in practice. The decisive factor is whether or not the different parties jointly determine the purposes and means of the processing at issue.  [74] If the parties do not pursue the same objectives (“purpose”), or do not rely upon the same means for achieving their respective objectives, their relationship is likely to be one of “separate controllers” rather than “joint controllers”. Conversely, if the actors in question do determine the purposes and means of a set of processing operations together, they will be considered to act as “joint controllers” or “co-controllers”.  [75]

Directive 95/46 EC is essentially silent on how responsibility and liability should be allocated in case of joint control. The only guidance that can be found in the legislative history of Directive 95/46 is the following statement made by the European Commission:

“each of the co-controllers must be considered as being constrained by the obligations imposed by the Directive so as to protect the natural persons about whom the data are processed”.  [76]

The cited passage suggests that each co-controller is individually responsible for ensuring compliance of the processing as a whole and should therefore in principle be liable for any damages resulting from non-compliance (“joint control, joint responsibilities”). The liability among joint controllers shall in principle be solidary in nature (i.e. the harmed data subject may bring a claim against any of them for the entire amount of the damage).  [77] Of course, the solidary liability of joint controllers only extends to those processing activities for which they in fact exercise joint control. In case of “partial joint control” (whereby certain processing operations are performed under the sole control of one controller),  [78] responsibility and liability will only be shared with regard to the common (i.e. jointly controlled) processing activities.  [79]

The solidary liability of joint controllers can be justified on the basis of the “common fault” committed by each controller. A “common fault” arises when multiple parties knowingly and willingly contribute to the same circumstance or event giving rise to the damage.  [80] Common faults typically induce solidary liability.  [81]

If the data subject decides to address only one of the joint controllers for the damages, that controller should be able to obtain redress from his fellow joint controllers for their contribution to the damages.  [82] In principle, nothing prevents joint controllers from deciding how to allocate responsibility and liability among each other (e.g., by way of a joint controller contract).  [83] The terms of such arrangements shall generally not however be opposable to data subjects, based on the principle of solidary liability for common faults.  [84]

It should be noted that the Article 29 Working Party has defended an alternative point of view. Specifically, it has argued that joint control should not necessarily entail solidary (“joint and several”) liability.  [85] Instead, joint and several liability:

“should only be considered as a means of eliminating uncertainties, and therefore assumed only insofar as an alternative, clear and equally effective allocation of obligations and responsibilities has not been established by the parties involved or does not clearly stem from factual circumstances”.  [86]

The approach of the Article 29 Working Party seems fair when it comes to the internal allocation of liability among joint controllers, but may potentially be unjust towards the harmed data subject. The approach suggests that a contract between joint controllers may be opposable to data subjects, and that a harmed data subject may carry the burden of deciding which of the joint controllers is “ultimately” responsible for the damages suffered. In my opinion, the viewpoint of the Article 29 Working Party does not find sufficient support in either the text or legislative history of Directive 95/46. In cases where joint control exists, each joint controller should in principle incur solidary liability for damages resulting from the “common” processing. Any arrangements between joint controllers, including those regarding liability, should not be opposable to data subjects, based on the principle of solidary liability for common faults.  [87]

As under Directive 95/46, the actual liability exposure of controllers depends on the nature of the obligation in question. Many controller obligations under the GDPR are formulated as an obligation of means. For example, article 17(2) of the GDPR requires controllers who are obliged to erase data pursuant to the right to erasure, to take “reasonable steps” to inform other controllers that the data subject has requested the erasure. Moreover, it is worth noting that many controller obligations make reference to the notion of “risk” (e.g., data protection by design (article 25(1) GDPR), implying that the evaluation of risk may be a determinative factor in liability disputes. Only few controller obligations contained in the GDPR can be qualified as obligations of result. An interesting example is provided by article 13(3) of the GDPR, which concerns the duty to provide information to the data subject in case a controller who collected information from the data subject intends to further process data for a purpose other than that for which the data were collected.  [88]

The liability regime for controllers has remained “strict” under the GDPR: once an infringement has been established, the controller cannot escape liability simply by demonstrating the absence of personal fault.  [89] The controller shall therefore remain liable for unlawful processing activities undertaken by the processor on its behalf, even if the controller were to demonstrate an absence of fault in either his choice or supervision of the processor. Under the GDPR, a controller may in principle be exempted from liability (in whole or in part) in only two situations: (1) if the controller can prove it is not in any way responsible for the event giving rise to the damage (article 82[3]); and (2) if the controller satisfies the conditions for liability exemption for intermediary service providers contained in Directive 2000/31 (article 2[4]).  [90]

According to article 5(2) of the GDPR, controllers are under a general obligation to be able to demonstrate their compliance with the basic principles of data protection (“accountability”). Moreover, a number of other provisions additionally stipulate that the controller must be able to demonstrate compliance, such as the provisions regarding the conditions for consent (article 7), processing which does not allow identification (articles 11 and 12[2]), and the general obligation to adopt appropriate technical and organisational measures to ensure compliance (article 24).

Strictly speaking, the requirement that the controller should “be able” to demonstrate compliance does not alter the burden of proof incumbent upon data subjects. After all, requiring the ability to demonstrate is not the same as requiring actual demonstration.  [91] Such a formalistic reading would, however, run contrary to the principle of accountability which the GDPR seeks to promote.  [92] The EU legislature did not introduce these provisions merely to promote better organisational practices, but also to require controllers to stand ready to demonstrate compliance when called upon to do so. As a result, one could argue that the data subject no longer carries the burden of proof of demonstrating exactly where the processing went wrong.  [93] At the very least, the argument can be made that the provisions of the GDPR regarding accountability (which require controllers to “be able to demonstrate compliance”) reinforce the notion that the controller is in fact “best placed” to proffer evidence of the measures it has taken to ensure compliance. Even if the legal burden of proof is still borne by the data subject, the evidential burden of proof should de facto shift to the controller as soon as the data subject has offered prima facie evidence of an unlawful processing activity.  [94]

Article 82(3) GDPR provides that a controller or processor shall be exempt from liability if it proves that it is “not in any way” responsible for the event giving rise to the damage. Article 82(3) GDPR clearly echoes the escape clause of article 23(2) of Directive 95/46.  [95] Interestingly, the GDPR does not contain a recital similar to recital (55) of Directive 95/46, which provides two examples of how a controller might prove that it is “not responsible for the event giving rise to the damage” (i.e., force majeure or error on the part of the data subject). Nevertheless, it is reasonable to assume that the words “not responsible for the event giving rise to the damage” should still be interpreted in the same way. As a result, the escape clause of article 82(3) still refers exclusively to “events beyond control”, i.e. an abnormal occurrence which cannot be averted by any reasonable measures and which does not constitute the realisation of the risk for which the person is strictly liable.  [96] If anything, the addition of the words “in any way” (in comparison to article 23[2] of Directive 95/46), suggests a desire to tighten the scope of the escape clause even further.  [97]

A more significant development has been the formal recognition of the liability exemptions for internet intermediaries contained in the E-Commerce Directive. Article 2(4) GDPR specifies that the Regulation “shall be without prejudice to the application of Directive 2000/31/EC, in particular of the liability rules of intermediary service providers in Articles 12 to 15 of that Directive”. The clarification provided by article 2(4) GDPR is most welcome, given the uncertain status of these liability exemptions under Directive 95/46. Article 1(5)b of the E-Commerce Directive provides that it does not apply to “questions relating to information society services covered by Directive 95/46 […]”. A literal reading would suggest that the liability exemptions provided in the E-Commerce Directive should not be applied in cases concerning the liability of “controllers”, as this is a matter regulated by Directive 95/46.  [98]

The practical importance of article 2(4) of the GDPR should not be overstated. A reasonable interpretation of controller obligations shall generally not result in the imposition of liability in absence of both knowledge and control. The decision of the Court of Justice in Google Spain  [99] , as well as the decision of the Italian Supreme Court in Google Video  [100] , clearly support this proposition. Nevertheless, the incorporation of the liability exemptions for internet intermediaries is likely to yield certain benefits. First, it should further the development of a more horizontal and uniform approach to the issue of intermediary liability.  [101] In addition, article 15 of the E-Commerce Directive clearly provides that Member States may not impose general monitoring obligations upon internet intermediaries. While most would agree that internet intermediaries should not be expected to proactively monitor whether the personal data disseminated through their platform is being processed lawfully, the formal applicability of article 15 of Directive 2000/31 would offer certain providers greater legal certainty. But article 2(4) of the GDPR is by no means a panacea: the concepts of “hosting, “mere conduit”, and “caching” contained in Directive 2000/31 are subjects of continuous debate and have themselves given rise to a fair degree of legal uncertainty.  [102] Moreover, the liability exemptions of Directive 2000/31 would only affect the liability exposure of controllers in relation to mere distribution or storage activities. An absence of liability for mere distribution or storage does not however, imply an absence of responsibility with regard to other operations performed on that content. Many service providers perform additional operations which go beyond a purely “intermediary”, “passive”, or “neutral” capacity.  [103] As a result, it may still be necessary to interpret the obligations of internet intermediaries as controllers in light of their “responsibilities, powers and capabilities”, as suggested by the Court of Justice in Google Spain.  [104]

Article 82(1) GDPR explicitly recognises that data subjects may seek compensation for both material and non-material damages. The EU legislature has thereby clarified that the right to compensation extends to “non-pecuniary damages”. While this was arguably already the case under Directive 95/46, the clarification is nevertheless welcome with a view of removing doubt and ensuring a harmonised approach among EU Member States.

As is the case for controller liability, the liability exposure of processors depends on the nature of the obligation concerned. Many obligations incumbent upon processors are formulated as obligations of means rather than as obligations of result. For example, the obligation to secure the processing of personal data (article 32) is clearly an obligation of means. On the other hand, the obligation not to process personal data except on the instructions of the controller (article 29), has been formulated as an obligation of result. The precise nature of a processor’s liability exposure must therefore also be determined in light of the specific wording of each obligation.

It should be noted that the GDPR has added considerable detail as regards to the legal binding of processors towards controllers (article 28[3]). Processors must comply not only with requirements that are directly applicable, but also with requirements imposed by way of contract. For example, article 28(3) foresees that the contract or other legal act between the controller and processor shall stipulate that the processor shall assist the controller in the fulfilment of its obligation to respond to requests for exercising the data subject's rights - insofar as this is possible and taking into account the nature of the processing.

Other obligations that are directly relevant to processors are the obligation to maintain a record of processing activities (article 30[2]), the obligation to notify data breaches to the controller (article 33[2]), the obligation to appoint a data protection officer (article 37), the adherence to codes of conduct and requirements of certification (articles 41 and 42), and restrictions regarding international transfers (article 44 et seq.).

Despite the increased number of obligations incumbent upon processors, the relationship between controllers and processors has remained largely the same. Like before, the processor is essentially conceived of as an “agent” or “delegate” of the controller, who may only process personal data in accordance with the instructions of the controller (articles 29 and 28[10]). As a result, the liability exposure of processors remains more limited in scope than the liability exposure of controllers. Whereas controllers can in principle be held liable for damages arising from any infringement of the GDPR, processors can in principle only be held liable in case of failure to comply with obligations of the GDPR specifically directed to processors or where it has acted outside or contrary to lawful instructions of the controller (article 82[2]). This is essentially a “proportional” liability model, as the processor can in theory only be held liable in relation “for his segment” in the processing.  [105] The processor will be liable for the entire damage however, insofar as it is - at least partially - responsible for the harm suffered (article 82[4]). To properly understand the meaning of article 82(4), it is worth elaborating upon its legislative history.

In the initial proposal for the GDPR, the Commission provided that processors would be jointly and severally liable, together with any controller involved in the processing, for the entire amount of the damage.  [106] Mere “involvement” in the processing would be sufficient to render the processor liable, unless the processor could prove it was not responsible for the event giving rise to the damage. The Council revised the text to differentiate between the liability exposure of controllers and processors more clearly.  [107] The changes introduced by the Council, which were retained in the final version of the GDPR, made clear that a processor would only be liable in case of failure to comply with those obligations of the Regulation which are specifically directed to processors, or if it acted contrary to or outside of the lawful instructions of the controller. As a result, mere “involvement” in the processing is not sufficient to give rise to liability: the liability of the processor is conditional upon a prior finding of responsibility in causing the damage. Only in cases where the processor can be deemed responsible in accordance with paragraphs 2 and 3 of article 82 GDPR can it be held liable for the entire damage. It is important to note however, that there is no threshold regarding the degree of responsibility of the processor in contributing to the damage. Even if the processor is only partially responsible, the processor can be held liable for the entire amount of the damage.  [108]

From the perspective of the data subject, article 82(4) of the GDPR results in a “cumulative” liability regime.  [109] The controller carries a general responsibility for the processing and can be held liable for damages in the event of an unlawful processing activity. The data subject additionally has the possibility to sue the processor directly in case he or she has reasons to believe that the processor and not (only) the controller is in fact responsible for the damage.  [110] In such cases, the data subject will effectively have a choice whether to sue the controller, the processor, or both.  [111] In cases where a controller and processor have been bound to the same judicial proceedings, compensation may be apportioned according to the responsibility of each controller or processor for the damage caused by the processing, provided that full and effective compensation of the data subject who suffered the damage is ensured.  [112] In cases where the processor is not joined to the same proceeding, the controller is entitled to claim back any compensation from the processor that was paid for in damages for which the processor was responsible (article 82[5] GDPR).

The cumulative liability regime of article 82(4) of the GDPR reflects the Principles of European Tort Law (PETL) regarding multiple tortfeasors. According to article 9:101 of the PETL, liability is solidary “where the whole or a distinct part of the damage suffered by the victim is attributable to two or more persons”.  [113] The same provision also stipulates that where persons are subject to solidary liability, the victim may claim full compensation from any one or more of them, provided that the victim may not recover more than the full amount of the damage suffered by him.  [114] The main innovation of the GDPR in comparison to Directive 95/46 therefore does not relate to the imposition of cumulative or solidary liability as such (as the GDPR merely codifies general tort law principles), but rather to the fact that the GDPR also imposes an increasing number of obligations directly upon processors.

Finally, it is worth noting that article 28(10) explicitly states that if a processor infringes the GDPR by determining the purposes and means of processing, it shall be considered to be a controller in respect of that processing. The rule of article 28(10) applies “without prejudice to articles 82, 83 and 84”, meaning that a failure to abide by the controller’s instructions could still give rise to liability, even if the processing might theoretically have been legitimate if the processor had obtained the data through other means. It also implies that the initial controller remains liable towards the data subject even in cases where the processor re-purposes the data.  [115]

To hold a processor liable, the data subject must succeed in demonstrating three elements: namely, (1) the performance of an “unlawful act” (i.e. failure to comply with those obligations of the GDPR which are specifically directly to processors or an act contrary to or outside of the lawful instructions of the controller); (2) the existence of damages; and (3) a causal relationship between the unlawful act and the damages incurred.

As indicated earlier, the data subject may be able to invoke one or more presumptions in order to help substantiate its claims.  [116] While the GDPR does not impose upon processors a general obligation to “be able to demonstrate” compliance, processors will often still be “best placed” to provide evidence of their efforts to comply with the obligations applicable to processors. As a result, the evidential burden of proof may also shift to the processor as soon as the data subject offers prima facie evidence of a failure to comply with those obligations of the GDPR, which are incumbent upon processors.  [117] Again, it should be noted that the ability for the data subject to avail him- or herself of such a presumption may vary according to the domestic legal system of each Member State.

Processors can in principle benefit from the same liability exemptions as controllers. A processor who is considered (at least partly) responsible for the damage may be exempted from liability - in whole or in part - if it proves that it is not in any way responsible for the event giving rise to the damage (article 82[3]).  [118] In addition, processors acting as internet intermediaries within the meaning of article 12 to 15 of the E-Commerce Directive, may also be exempted from liability provided the conditions listed in these articles are met.

An interesting issue to consider is the liability of processors in the case of sub-processing. Article 28(4) of the GDPR provides that in the case of subprocessing, the initial processor remains fully liable towards the controller for the performance of the relevant obligations by the subprocessor. The GDPR does not however explicitly state that the initial processor also remains liable towards the data subject. Nevertheless, the argument can easily be made that this should be the case. After all, the GDPR imposes obligations directly upon processors. Every processor involved in the processing must therefore accept personal responsibility for those requirements directed towards processors, even in the case of outsourcing. The formulation of the escape clause of article 82(3) makes clear that the GDPR also imposes a non-delegable duty of care upon processors.

Under the GDPR, data subjects can claim both material and non-material damages from processors (article 82[1]).

Pursuant to article 82(2) GDPR, any controller involved in the processing can in principle be held liable for the damages suffered. Read in isolation, one might assume that both joint and separate controllers face equal liability exposure. This is not the case however. While joint controllers can theoretically always be held liable for damages caused by processing activities under their joint control, separate controllers can only be held liable if the damage was caused by a processing activity which was under the control of that particular controller (or may otherwise be attributed to him). After all, article 82(4) provides that every controller involved in the processing may only be held liable “for the entire damage” insofar that they can be held responsible in accordance with paragraphs 2 and 3. As a result, separate controllers shall in principle only be liable for the entire damage if they acted as a controller towards the processing activity which gave rise to the damage or in case of “concurring faults”.  [119]

The GDPR introduced a new provision dedicated specifically to situations of joint control. Article 26(1) provides that joint controllers must determine their respective responsibilities for compliance with the GDPR, in particular as regards to the exercise of data subject rights and their respective duties to provide information by means of an “arrangement” between them.  [120] The arrangement must duly reflect the respective roles and relationships of the joint controllers vis-à-vis the data subjects (article 26[2]).

For the most part, article 26 of the GDPR can be seen as a codification of the earlier guidance provided by the Article 29 Working Party regarding the legal implications of joint control.  [121] A notable difference however, is that every joint controller in principle remains liable towards data subjects for the entire damage even if there exists an appropriate arrangement between them (article 82[4]).  [122] A joint controller can only escape liability if it succeeds in demonstrating that is not in any way responsible for the event giving rise to the damage (article 82[3]), or that it satisfies the conditions for liability exemption for intermediary service providers contained in Directive 2000/31 (article 2[4]).