Jump to Navigation


4.2.2 Legal Influence on Properties of Accounts

In this section we examine what an account should contain from a practical perspective, beginning with the obligations arising from legal and regulatory norms, contractual obligations and the opinions of legal or academic commentators about the content of an account. From these sources, we identify what could or should be the content of an account in more detail than already considered in 4.1.1 .

Legal or regulatory norms about the content of the account

There is no formal legal standard on the content of an account. Guidance about the content of the account given by regulatory bodies is typically very high level with little specificity provided by regulators as to what accounts must contain. For example, very little direction is provided in the Data Protection Directive, or even the proposed General Data Protection Regulation on this point.

The Article 29 Working Party (Article 29 WP) has published its own opinion highlighting the importance of the notion of accountability in the field of personal data protection [26]. In its Opinion 3/2010 on the principle of accountability, the Article 29 Data Protection Working Party highlighted the importance of a concrete proposal for a general accountability principle. Specifically, the Article 29 Working Party found that accountability should focus on two main elements: (i) the need for a controller to take appropriate and effective measures to implement data protection principles; and (ii) the need to demonstrate upon request that appropriate and effective measures have been taken. Thus the controller shall provide evidence of (i) above. ( [26] at 28) From a data protection point of view, the account is the method of presenting such evidence and demonstrating such measures. The Article 29 Working Party also explained how the use of accounts will lead to greater enforcement by data protection authorities, and perhaps even increased accountability:

Furthermore, putting the accountability principle into effect will provide useful information to data protection authorities to monitor compliance levels. Indeed, because data controllers will have to be able to demonstrate to the authorities whether and how they have implemented the measures, very relevant compliance related information would be available to authorities. They will then be able to use this information in the context of their enforcement actions. Moreover, if such information is not provided upon request, data protection authorities will have an immediate cause of action against data controllers, independently of the alleged violation of other underlying data protection principles. [26]

A similar approach is taken in the non-binding 2009 Madrid international privacy standard, which also addresses the need for organisations to provide an account:

The Responsible person shall: a) Take all the necessary measures to observe the principles and obligations set out in this Document and in the applicable national legislation, and b) Have the necessary internal mechanisms in place for demonstrating such observance both to data subjects and to the supervisory authorities in the exercise of their powers, as established in section 23 (Monitoring).

These documents are important to the process of devising accountability mechanisms in that they indicate how accounts could be used by data protection authorities, for example, to monitor compliance and to demonstrate to the relevant authorities that such measures are in place in the organisation. Therefore they implicitly indicate what types of information an account should contain: evidence of compliance with legal norms and information that demonstrates to authorities that relevant compliance has taken place. Nevertheless, these statements do not give a template of what exactly an account should contain. Rather, they are good practice guidance for accountability at quite a high level.

Contracts in the cloud and practical accountability

Contracts between data controllers and cloud users, and, to a lesser degree, contracts between data controllers and data processors, do not shed much light on the notion of the account. Contractual obligations essentially take regulatory obligations, which may be at a high level, and translate them into specific binding obligations between the parties. It is also important to note that contractual obligations are not only based on regulatory obligations. Non-legislative obligations such as industry standards and certifications or even accepted industry norms can be included into agreements, which turn such obligations into legal contractual obligations. And even then, data controllers largely try to further limit their obligations, particularly their liability, in their contracts and/or terms of service. [27]

As between data controllers and data processors, Article 17 of the Data Protection Directive requires data controllers to impose on data processors the same obligations regarding the implementation of security measures as those imposed on data controllers. The relationship between data controllers and data processors will normally be established via the prior conclusion of a contractual agreement (or other legal act) [23].The initial draft of the Proposed Regulation stipulated in Article 26(2) that such a contract or legal act should be obligatory and should require the processor to make available to the controller and the supervisory authority all information necessary to control compliance with the obligations laid down in this Article, or in other words to provide at least a partial account.

Finally, the one area where one would most expect an account to be provided would be where there has been a security breach, yet, even in negotiated contracts, as opposed to the standard, non-negotiated contracts which currently dominate the cloud computing landscape, many providers standard terms did not require reporting of security incidents and so on to users. [28]

It is noteworthy that even where accounts are imposed by law through legislation and contracts, there is mostly little to no express provision as to what the account must specifically include. If accountability is to be built into the cloud, an important element will be the inclusion of terms in contracts which require a proper account to be given.

It is not possible to draft model contract clauses for this purpose because what is proper in an account will vary substantially depending on the nature of the relationship between the giver and the recipient of the account. It is, however, possible to suggest some overriding principles which might guide the drafting of such clauses:

  • The recipient of the account should be entitled to appropriate information about how its data will be stored and processed, updated as storage and processing methods change. The level of detail will depend on the nature of the relationship and the data. Thus a consumer user of a free cloud service should be content with quite general information, whereas a financial institution will require far more detail.
  • There should be a suitable mechanism for checking that the actual operations on data match the information given under (a). Mechanisms might range from tools that allow customers to generate their own reports, through independent audit reports, to a right to inspect and audit a providers systems.
  • There should be an appropriate mechanism for reporting breaches to those whose interests are engaged, primarily customers, data subjects and regulators. What level of reporting, at what seriousness of breach, and to whom, again will depend on the nature of the relationships.
  • The account should include explanations of the reasons for any failings, and the measures which will be taken to prevent future failure. The frequency, granularity and addressees of this part of the account are also relationship-dependent.

The content of an account

Since we have no clear stipulation from legal or regulatory sources about the content of the account, we therefore have to turn to statements by academic commentators who have studied or assessed the notion of the account or accountability and analyse what they suggest an account should contain.

As Prof. Charles Raab noted:

To 'give an account' - rendre des comptes - is to tell a story, and there are three levels that can be distinguished. First, on a weak definition, it means the obligation of an organisation to report back, to give an account of its actions. Second, on a stronger definition, it means that, plus the implication that the audience can interrogate the account and produce other accounts on their own account. Third, on the strongest definition, it means the previous two plus the implication that sanctions can be brought to bear where there is a general agreement that the organisation has given a bad account of itself, either (a) through its inactions, or (b) through its own unsatisfactory production of an account. The audience, which may be the public, can thus hold the organisation to account, and that might have real consequences. [29]

And, as Raab further noted:

But the account must also, and essentially, include descriptions and explanations of the actions, for two reasons. First, so that we can better understand the organisations intentions and its understanding, or theory, of its own situation or how it might act in it. Second, because most of a stewards actions are invisible to the principal, and therefore have to be re-presented, through stories or accounts, explanations, and justifications. [29]

Importantly, especially for an organisation to be accountable, an account is not provided only when something has gone wrong, but rather can be presented at any time upon request. As one commentator opined:

Accountability does not wait for a system failure; rather, it requires that organisations be prepared to demonstrate upon request by the proper authorities that it is securing and protecting data in accordance with the essential elements. [30]

[23] Data Protection Directive Article 17.3 The carrying out of processing by way of a processor must be governed by a contract or legal act binding the processor to the controller and stipulating in particular that: the processor shall act only on instructions from the controller