Accountability for Data Governance in the Cloud

Part of the Lecture Notes in Computer Science book series (LNCS, volume 8937)


Cloud computing represents a major shift in the way Information and Communication Technology (ICT) is deployed and utilised across industries. Alongside the technological developments, organisations need to adapt to emerging operational needs associated with data governance, policy and responsibility, as well as compliance with regulatory regimes that may be multi-jurisdictional in nature. This paper is concerned with data governance in cloud ecosystems. It characterises the problem of data governance due to emerging challenges (and threats) in the cloud. It advocates an accountability-based approach for data stewardship. It defines accountability and introduces a model consisting of attributes, practices and mechanisms. The accountability model underpins an accountability framework supporting data governance. This paper also discusses emerging relationships between accountability, risk and trust. The overall objective of the proposed accountability-based approach to data governance is to support a transparent and trustworthy cloud.


Accountability Cloud computing Data protection Governance 

1 Introduction

Cloud computing is transforming the way Information and Communication Technology (ICT) is deployed and consumed across different application domains. Cloud computing is defined as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction” [1]. Different service and deployment models enable various customer-provider relationships depending on the types of cloud services procured (see [2] for examples of some generic cloud use cases). With the adoption of cloud computing and the transfer of data to the cloud, accountability has emerged as a critical concept related to data protection in cloud ecosystems Note that accountability is a notion that is used in slightly different senses in different contexts, and hence there is no uniformly accepted definition [3]. It is necessary to maintain chains of accountability across cloud ecosystems. This is to enhance the confidence in the trust that cloud actors have while operating in the cloud.

In the context of this paper, we focus on accountability for protection of data (e.g. personal and/or confidential data) [4], in which it is among the identified “technical and organisational measures of data protection and data security” [5]. Unfortunately, despite its relevance for supporting governance of privacy [6], data protection and security in the cloud, the concept of accountability is difficult to define and operationalize (that is, to put into practice) uniformly across cloud ecosystems because “defining what exactly accountability means in practice is complex” [4]. In the context of privacy and data protection, accountability is used in the sense (following the OECD, Organisation for Economic Co-operation and Development, guidelines on privacy and data protection [7]) of an “accountability principle” that “a data controller should be accountable for complying with measures which give effect to the” privacy principles (i.e. collection limitation, data quality, purpose specification, use limitation, security safeguards, openness and individual participation). Various elements have been identified as characterising a general accountability principle. The Article 29 Data Protection Working Party in [4] identifies various elements defining the general principle of accountability (namely, reinforcing obligations, appropriate measures implementing the Data Protection Directive, the role of data protection authorities, sanctions, and the development and regulation of certification schemes). In addition, the Galway Project has identified five essential elements of an accountable organisation [8]. Accountability might provide a means to unlock the potential of cloud computing by helping to address relevant problems of data protection emerging in cloud ecosystems [9, 10]. This approach has been further explored within the EU Cloud Accountability Project (A4Cloud). A4Cloud focuses on accountability for cloud (and other future internet services) as the most critical prerequisite for effective governance of personal and confidential data processed by cloud-based services. Accountability helps to align cloud ecosystems with relevant regulatory regimes [11] like the ones defined by the EU Data Protection Directive [12].

This paper presents a conceptual model, consisting of attributes, practices and mechanisms for accountability in the cloud [13]. The proposed model forms the basis for characterising accountability relationships between cloud actors, and hence chains of accountability in cloud ecosystems [13]. The accountability model enables a framework for supporting accountability in cloud ecosystems. This paper is structured as follows. Section 2 provides a rationale for an accountability-based approach to data governance in the cloud. It discusses the main drivers for accountability. Section 3 defines accountability. Section 4 contextualises and explains the main characteristics of an accountability-based approach. Section 5 defines cloud and data protection roles. It describes what being accountable means in cloud ecosystems. Section 6 introduces a conceptual model consisting of accountability attributes, practices and mechanisms. The accountability model underpins the framework presented in Sect. 7 that supports accountability in the cloud. Section 8 describes accountability governance in the cloud. Section 9 discusses emerging threats in cloud ecosystems and discusses relationships between accountability, risk and trust. This paper therefore provides an analysis of accountability for data governance in the cloud. The paper defines the concept of accountability tailored to the cloud, an accountability model and an accountability framework, which enable accountability governance. These provide the foundations for an accountability-based approach for data governance in the cloud.

2 Problem of Data Governance

Cloud computing is one of the most relevant recent shifts in the way Information and Communications Technology (ICT) is provided and utilised. This technological change concerns data governance, because large amounts of personal and confidential data are steadily transferred to the cloud. Stakeholder interactions and responsibilities vary across the entire cloud supply chain. This is manifested in different ways to the stakeholders. Data subjects are no longer co-located with their data, leading to uncertainty due to lack of transparency and loss of control. Cloud customers and providers may act as controller and/or processor of personal and confidential data (Article 29 Data Protection Working Party’s Opinion [14] clarifies the concepts of controller and processor, and provides some examples of organisations taking these roles, e.g. telecom operators, e-government portals, social networks). Such organisations have the responsibility of protecting data from privacy and security breaches, including due to unintended usage [12]. Governance in the cloud therefore requires understanding, moderating and regulating the relationships between cloud consumers (cloud customers) and providers. The NIST guidelines and recommendations (“on how organisations should consider the relative opportunities and risks of cloud computing”) highlight the relationship between cloud customers and providers as critical for security and privacy [15]. Clarifying the roles and responsibilities between customers and providers is important when considering moving to the cloud – “The partnership between providers and consumers in designing, building, deploying, and operating clouds presents new challenges in providing adequate security and privacy protection. It becomes a collaborative process between providers and consumers to share the responsibilities in implementing the necessary controls” [15]. Figure 1 shows a generic representation of the problem of data governance in a cloud ecosystem.
Fig. 1.

Problem of data governance in a cloud ecosystem

Different data protection requirements arise in the relationships between cloud customers and providers [5]. Accountability is among the identified “technical and organisational measures of data protection and data security” [5]. Unfortunately, despite its relevance for supporting governance of privacy, data protection and security in the cloud [6], the concept of accountability is difficult to define and operationalize (that is, put into practice) uniformly across cloud ecosystems as “defining what exactly accountability means in practice is complex” [4]. The remainder of this section discusses some drivers for an accountability-based approach to data governance in the cloud.

2.1 Regulatory Complexity

The collection and processing of personal information is subject to regulation in many countries across the world. There are many different national data protection legislations in place. For example, the United States (US) does not have a comprehensive regime of data protection but instead has a variety of laws targeted at the protection of particularly sensitive types of information that tend to be sector-based or enacted at the state level. This (sometimes inconsistent) matrix of national laws can make it really hard for businesses to ensure full compliance if they are operating in multiple jurisdictions. There is pressure from organisations for greater global interoperability to be achieved via development of a clear and consistent framework of data protection rules that can be applied, in order to reduce unnecessary administrative burdens and risks.

Transborder flow of personal information, including access to this information, is restricted by some of these laws. For example, the European Data Protection Directive 95/46/EC (DPD) is an important piece of privacy legislation that restricts the movement of data from EU to non-EU countries that do not meet the European adequacy standard for privacy protection [12]. Many other countries, e.g. Australia, New Zealand, Hong Kong and Japan, have enacted legislation similar to the EU DPD. In practice, contractual mechanisms like Binding Corporate Rules or Model Contracts might need to be put in place in order to allow data access. However, these arrangements typically take several months to set up, and hence are not well suited to dynamic environments.

The OECD revised guidelines [16] now recommend the practical implementation of privacy protection through an approach grounded in risk management and stress the need for improved global interoperability. With regard to security, it is a common requirement under data protection law that if a company outsources the handling of personal data to another company, it has some responsibility to make sure the outsourcer uses reasonable security to protect those data. This means that any organisation creating, maintaining, using or disseminating records of personal data must ensure that the records have not been tampered with, and must take precautions to prevent misuse of the information. Of course, in addition, organisations need to take into account the privacy-related expectations of their customers, which may be specified within private contracts, and this is likely to involve a combination of process-based and access control mechanisms. The legal obligations vary according to the regulatory context and indeed there are likely to be some quite significant changes in the near future. Once these changes are implemented, many service providers will gain a range of data security obligations including adopting risk management practices and reporting major security incidents to competent authorities and affected parties.

In order to harmonise data protection and to take into account new technologies including cloud computing, the European Commission (EC) has been working on a new General Data Protection Regulation (GDPR) [17], which will replace the DPD. In the proposed GDPR, which is currently being discussed and revised, accountability features and privacy by design take further precedence. Amongst other things, the proposed GDPR imposes new obligations and liabilities for data processors, new requirements on data breach notification and stricter rules on international data transfers. It also empowers National Regulatory authorities to impose significantly higher fines. In addition, a European Cloud Computing Strategy [18] has been launched aiming at more clarity and knowledge about the applicable legal framework and making it easier to verify compliance with the legal framework (e.g. through standards and certifications). Furthermore, the European Commission has also published a cybersecurity strategy [19] alongside a draft directive on a Network and Information Security (NIS) Platform [20]. Once the GDPR combined with the cybersecurity strategy will be implemented, many service providers will need to comply with a range of data security obligations including adopting risk management practices and reporting major security incidents.

The emerging regulatory complexity and the difficulty of compliance with different regulatory regimes represent barriers to migration to the cloud. A major reason for this is that data flows tend to be global and dynamic. As discussed above, the collection and processing of personal information is subject to regulation in many countries across the world and some national laws restrict transborder flow of personal information, including access to this information. This matrix of (sometimes inconsistent) national laws can make it difficult for businesses that wish to provide effective stewardship of the data that they handle to ensure full compliance when operating in multiple jurisdictions. It can be difficult even to determine which laws apply and which courts should preside. There is pressure from organisations for greater harmonisation to reduce unnecessary administrative burdens and risks. These two issues – trust and complexity – are closely linked. Both legal and ethical obligations arise to ensure privacy and protect data, and these need to be built upon to demonstrate the trustworthy nature of cloud services.

2.2 Challenges in Cloud Ecosystems

There are a variety of data protection concerns related to cloud computing that include ongoing questions of jurisdiction and exacerbation of privacy risk through sub-processing and de-localisation, as well as legal uncertainty. For example, the NIST guidelines on security and privacy in public cloud computing point out concerns for cloud adoption that include governance over data use and processing, the compliance to laws, regulations, standards and specifications, the management of risks to assess trust and trustworthiness along the cloud service chains and the effective implementation of incidence response mechanisms [21]. Table 1 lists key issues and links them to features characterising the cloud that can potentially increase data protection risks.
Table 1.

Cloud features and issues

For example, cloud vulnerabilities include the multi-tenancy of cloud applications, in which co-tenants may gain inappropriate access to the data of another application instance and the simplification of data access from multiple geographic locations, but with completely different legislative regimes. Also, data duplication and proliferation in the cloud create problems in terms of compliance, since the loss of control and transparency significantly affect the data lifecycle management across various involved providers in a service provisioning chain.

A categorisation of risks from an EU perspective has been made according to lack of transparency or control by the Article 29 Working Party in their Opinion on Cloud Computing [5]. Similar risks were highlighted by the French data protection authority [22], with the addition of ineffective or non-secure destruction of data, or excessive data retention periods, and of takeover of the cloud provider by a third party. A detailed analysis of cloud computing risks has been provided by European Union Agency for Network and Information Security (ENISA) [23].

2.3 Drivers for Accountability

This section has discussed some of the drivers for accountability. Cloud computing represents the most significant shift in ICT deployments. The globalisation of businesses and the new technologies create global ecosystems that pose new challenges. Among the challenges is the regulatory complexity that is inherent in many cloud environments. Accountability potentially allows avoidance of the complex matrix of national laws and reduces unnecessary layers of complexity for cloud providers [10]. Additionally, cloud features expose, in particular, cloud customers and providers to new emerging challenges exacerbating data protection risks. Relationships among cloud stakeholders, e.g. customers, providers and regulators, are characterised by uncertainty resulting in a lack of trust in the cloud. In response to the seemingly insufficient reflection of EU data protection principles and obligations in concrete measures and practices used by organisations, the Article 29 Data Protection Working Party advocated in its opinion on the principle of accountability [4] that such a general principle could help move data protection from theory to practice, as well as provide a means for assisting data protection authorities in their supervision and assessment tasks: “EU data protection principles and obligations are often insufficiently reflected in concrete internal measures and practices. Unless data protection becomes part of the shared values and practices of an organisation, and responsibilities for it are expressly assigned, effective compliance will be at considerable risk, and data mishaps are likely to continue.” Therefore, a major driver for an accountability-based approach is to provide an incentive for organisations to do the right thing, in terms of providing appropriate and adequate data protection in the sense described above, by means of decreasing regulatory complexity, easing transborder data flow restrictions while avoiding increased privacy harm, encouraging best practice, using strong punishment as a deterrent and allowing organisations to choose what measures they will use, so long as they can show that these are effective and appropriate for the context.

3 Accountability Definitions

Accountability is becoming an important notion, defining the relations between various stakeholders and their behaviours towards data in the cloud. In cloud ecosystems, the accountors are cloud actors (organisations or individuals with certain responsibilities) acting as a data steward (for other people’s personal and/or confidential data). The accountees are other cloud actors, that may include private accountability agents, consumer organisations, the public at large and entities involved in governance. Building on our analysis of the problem of data governance (and an analysis of different understandings of accountability [3]), a definition of accountability that is applicable across different domains and that captures a shared multidisciplinary understanding is:
  • Definition of Accountability:Accountability consists of defining governance to comply in a responsible manner with internal and external criteria, ensuring implementation of appropriate actions, explaining and justifying those actions and remedying any failure to act properly.

Internal criteria are not necessarily visible to stakeholders external to that organisation, as they might for example reflect the risk appetite of that organisation or known security vulnerabilities; external criteria could include best practice on security, data protection and breach notification, as well as privacy regulatory and contractual requirements and societal expectations. However, given the scope of the project, we need to refine this definition to reflect our project focus. We look at accountability in the context of a cloud ecosystem, which is a business ecosystem of interacting organisations and individuals – the actors of the cloud ecosystem – who provide and consume cloud services. In other words, the main stakeholders in the cloud ecosystem are cloud providers and cloud users. In this ecosystem the stakeholders interact in a constant process of change. Moreover the stakeholders within the ecosystem are controlled not only by the internal factors of the system, such as codes of conduct and existing relations, but also by external factors such as regulations, the wider environment or even required skills.

Accountability, in general, is used prescriptively, that is, accountability of some agent to some other agent for some state of affairs. It reflects an institutional relation arrangement in which an actor can be held to account by a forum (for example, a customer organisation, business association or even the public at large). Accountability then focuses on the specific social relation or the mechanism that involves an obligation to explain and justify conduct. Subsequently, accountability is “a relationship between an actor and a forum, in which the actor has an obligation to explain and to justify his or her conduct, the forum can pose questions and pass judgement, and the actor can be sanctioned” [24]. In an accountability relationship thus two parties and an object can be distinguished: (a) the steward or accountor, (b) accountee or forum, and (c) the codes or norms on the basis of which the relationship is struck. The latter are the shared framework for explanation and justification that are negotiated between the accountor (to answer, explain and justify) and accountee (to question, assess and criticise). An accountability code then is a system of signals, meanings and customs, which binds the parties in a stewardship relation. There are different stages in accountability relations:
  • information in which explanation is given and one’s conduct is justified

  • debate, in which the adequacy of the information and /or the legitimacy of conduct is debated (answerability)

  • the forum must pass judgement and sanction whether formally (for example, via fines, disciplinary measures and unwritten rules leading to resignation) or informally (for example, having to render account in front of television cameras or via disintegration of public image and career).

Accountability as a mechanism thus can be used as a tool to induce reflection and learning. It provides external feedback on (un)intended effects of an organisation’s actions. However, accountability is also used in a more normative way – accountability as a virtue [25]. Accountability as a virtue is largely defined by bad governance: what is irresponsive, opaque, irresponsible, ineffective or even deviant behaviour. Accountability as a virtue, a normative concept, entails the promise of fair and equitable governance. Behaving in an accountable or responsible manner then is perceived as a desirable quality and laid down in norms for the behaviour and conduct of actors. Moreover, accountability then is not something imposed upon someone or an organisation by another actor, but an inherent feeling, the feeling of being morally obliged to be responsive, open, transparent and responsible. Hence, accountability as a virtue is a normative concept whereby a set of standards is provided for the evaluation of behaviour of public actors, and being accountable is seen as a positive quality in organisations or officials [25], while accountability as a mechanism is used in a narrower, descriptive sense, to describe an institutional relation or arrangement in which an actor can be held to account by a forum.

Our understanding of cloud accountability combines the notions introduced earlier of accountability as a mechanism and accountability as a virtue within the private sector of cloud computing and its cloud ecosystem. Our approach is to build on these notions to incorporate accountability in the cloud ecosystem by allowing for a mechanism that ensures the possibility of giving account ex post facto (via accountability tools) and steering accountability behaviour ex ante (via accountability as a virtue). Accountability as a virtue is extended to apply to cloud actors including cloud service providers, and accountability as a mechanism entails the social relation between the accountor and accountee that involves an obligation to explain and justify conduct. A definition of accountability within cloud ecosystems that we have produced, again through consideration of relevant interdisciplinary literature, is the following:
  • Definition of Accountability (for Cloud Ecosystems):Accountability for an organisation consists of accepting responsibility for data with which it is entrusted in a cloud environment, for its use of the data from the time it is collected until when the data is destroyed (including onward transfer to and from third parties). It involves the commitment to norms, explaining and demonstrating compliance to stakeholders and remedying any failure to act properly.

This definition differs slightly from the more generic one, for the following reasons. Security and privacy management is evolving into an information stewardship problem. In the cloud, it is harder to establish the risks and obligations, implement appropriate operational responses and deal with regulatory requirements. Notions of transparency and assurance receive more emphasis and it is necessary to ensure chains of accountability. Accountability places a responsibility upon an organisation that uses personal information to ensure that the contracted partners to whom it supplies the personal information are compliant, wherever in the world they may be. So, the communities responsible for data stewardship place responsibilities/constraints on other individuals or on the way systems operate, and these constraints are met along the chain of provision. Furthermore, we focus on governance of personal and/or confidential data in the cloud.

4 From Accountability to Being Accountable

Accountability complements the usage of appropriate privacy and security controls [26] in order to support democratically determined principles that reflect societal norms, regulations and stakeholder expectations (Fig. 2). Governance and oversight of this process is achieved via a combination of Data Protection Authorities, auditors and Data Protection Officers within organisations, the latter potentially supplemented by private accountability agents acting on their behalf. As shown in Fig. 2, accountability and good systems design (in particular, to meet privacy and security requirements) are complementary, in that the latter provides mechanisms and controls that allow implementation of principles and standards, whereas accountability makes organisations responsible for providing an appropriate implementation for their business context, and addresses what happens in case of failure (that is, if the account is not provided, is not adequate, if the organisation’s obligations are not met, e.g. there is a data breach).
Fig. 2.

Accountability framing

Although organisations can select from accountability mechanisms and tools in order to meet their context, the choice of such tools needs to be justified to external parties. A strong accountability approach would include moving beyond accountability of policies and procedures, to accountability of practice. There is an associated requirement for data controllers to be able to demonstrate compliance to supervisory authorities upon request. Hence, organisations are allowed increased control over aspects of compliance (i.e. which tools and mechanisms to use in order to achieve compliance), but at the expense of having to demonstrate on an ongoing basis that these mechanisms are appropriate for their business context, and operationally work as expected (Fig. 3). The legal and contractual context defines the norms applicable to actors in a given cloud ecosystem, and their associated obligations, responsibilities and liabilities.
Fig. 3.

Accountability context

Businesses need to meet these obligations, as well as obligations and requirements imposed by other stakeholders that include customers and data subjects. Accountability aims to entrust organisations with the practical aspects of complying with data protection obligations. This involves clarification of requirements of the different cloud actors within cloud ecosystems, as well as transparency and provisions of trustworthy accounts by organisations that collect or handle personal information. Cloud actors may select mechanisms and tools to support accountability practices, and thereby help them to comply with relevant regulatory regimes within specific application domains.

4.1 Accountability-Based Approach

We argue that an accountability-based approach should have a number of characteristics that include a notion of strong accountability. This term has recently been proposed in [27] to describe an approach that applies not only to policies and procedures, but also to practices, so that the effectiveness of the processing of personal data can be overseen (this stresses a distinction between reporting and demonstrating). This is supported by precise binding commitments enshrined in law and involves regular audits by independent entities. However, this should not be contradictory with the need for flexibility that is required by the industry. Similarly, in order to avoid charges of privacy whitewashing whereby apparent accountability encourages a false basis for trust in data controllers by data subjects, we argue that an accountability-based approach (such as the one of the Cloud Accountability Project) should have the following characteristics:
  • Supporting externally agreed data protection approach: Accountability should be viewed as a means to an end (i.e. that organisations should be accountable for the personal and confidential information that they collect, store, process and disseminate), not as an alternative to reframing basic privacy principles or legal requirements. Thus, the accountability elements in the GDPR provide a certain assurance of compliance with the data protection principles, but do not replace them.

  • Trust in the verification process: There needs to be a strong enough verification process to show the extent to which commitments have been fulfilled. Missing evidence can pose a problem, and guarantees are needed about the integrity and authenticity of evidence supporting verification. In addition, the actor carrying out the verification checks needs to be trusted by the data subject and to have the appropriate authority and resources to carry out spot checking and other ways of asking organisations to demonstrate compliance with regulatory and contractual obligation by providing accounts that may take various forms (e.g. certificates, seals and audit reports). This is why the data protection authorities will need to play a key role in the trust verification, for example in data protection certification. In terms of external governance mechanisms, strong enforcement strategies, not only in terms of verification, but also in terms of increasing the likelihood of detection of unlawful practices and strong penalties if caught, seem to be a necessary part of accountability. Data protection impact assessments, codes of conduct and certifications are proposed to increase trust in cloud providers who adhere to them. It is thus of the utmost importance that regulatory and supervisory bodies have a primary role in the verification of the level of compliance of these tools. Furthermore, to give data subjects give back some control it would be another level of interaction if the data subjects’ comments and needs receive a response and ideally even show some fundamental development in the application or organisational data processing. This form of feedback to the data subjects (in response to their feedback) is another form of verification. There are further related aspects supporting this approach in terms of responsibility and transparency, as listed below.

  • Clarity and acceptance of responsibility: The relationship between controllers and processors in cloud service provision chains can sometimes be complex. The commitments of the data controller need to be well defined – this is (part of) the aspect of responsibility, that is an element of accountability. The respective responsibility of cloud customers and cloud providers will need to be defined in contracts and the definition of standard clauses by the industry, as validated by regulators, will help cloud customers with lower negotiation capabilities. The commitments of the data controller should include all applicable legal obligations, together with any industry standards (forming part of the external criteria against which the organisation’s policies are defined) and any other commitment made by the data controller. Once again, the responsibilities of the entities along the cloud provider chain need to be clearly defined, including relative security responsibilities. On the other hand, certain tasks will need to be jointly carried out to be effective, such as risk assessment and security management. In this case there is a clear need for cooperation and coordination. Note that to what extent cloud providers should be considered as controllers or processors remains questionable [28].

  • Transparency: A main goal of accountability is to go beyond regulation through fostering transparency about actual practices and thus enabling promotion of good data handling practices, in a proactive sense. The commitments of the data controller(s) need to be expressed in an understandable language by the data subjects affected and other parties as appropriate – this is a key transparency aspect. In addition, the mechanisms used and relevant properties of the service providers in the provision chain need to be clarified as appropriate to cloud customers and regulators. It would also be beneficial to integrate social interaction between data subjects and the cloud infrastructure and service providers, for example via feedback mechanisms that enable comments on privacy policies and data usage reports [29]. Furthermore, data protection impact assessments and privacy impact assessments are forms of verification for accountability (that should be used in conjunction with others) that can be used to help provide transparency about the nature of the risks, including the criteria used in the risk assessment, how decisions are made to mitigate risk, and whether the mechanisms to be used and implemented are appropriate for the context. Comprehensive obligations for controllers to inform supervisory authorities and data subjects of personal data breaches would further increase transparency.

  • Avoidance of increased risk: Technical security measures (such as open strong cryptography) can help prevent falsification of logs, and privacy-enhancing techniques and adequate access control should be used to protect personal information in logs. Note however that data that is collected for accountability might be itself data that can be abused and hence needs to be protected as much as the processed data. The potential conflict of accountability with privacy is somewhat reduced as the focus in data protection is not on the accountability of data subjects but rather of data controllers, which need to be accountable towards data subjects and trusted intermediaries.

  • Avoidance of increased burden: Accountability must deliver effective solutions whilst avoiding where possible overly prescriptive or burdensome requirements.

  • Avoidance of social harm: Accountability should have democratic and ethical characteristics. Transparency should be as high as possible, in balance with other interests (as considered above while describing transparency). Mechanisms should also be developed to help regulators do their job, notably with respect to enhancement of the verification process as discussed above.

4.2 Accountability Evidence

Accountability evidence, as illustrated in Fig. 4, needs to be provided at a number of layers. At the policies level, this would involve provision of evidence that the policies are appropriate for the context, which is typically what is done when privacy seals are issued. But this alone is rather weak. In addition, evidence can be provided about the measures, mechanisms and controls that are deployed and their configuration, to show that these are appropriate for the context.
Fig. 4.

Accountability evidence

For example, evidence could be provided that Privacy Enhancing Technologies (PETs) have been used, to support anonymisation requirements expressed at the policy level. For higher risk situations continuous monitoring may be needed to provide evidence that what is claimed in the policies is actually being met in practice. Even if this is not sophisticated, some form of checking the operational running and feeding this back into the accountability management program in order to improve it is part of accountability practice, and hence evidence will need to be generated at this level too. In particular, technical measures should be deployed to enhance the integrity and authenticity of logs, and there should be enhanced reasoning about how these logs show whether or not data protection obligations have been fulfilled. The evidence from the above would be reflected in the account, and would serve as a basis for verification and certification by independent, trusted entities. Accountability is particularly hard to achieve in the cloud context, but that is actually a context where it is strongly needed. The main factors contributing to this difficulty are:
  • The complexity of technology offers.

  • The necessity to split responsibilities depending on the service delivery model.

  • Potential weak links in dynamically formed cloud provider chains, and

  • The current shallowness of transparency and verifiability in the cloud context.

If the data controller is ultimately made accountable for meeting obligations right along the service provision chain, they should try to obtain contractual assurances that lessen the risk of potential weak links in dynamically formed cloud provider chains. That is, contractual agreements between the series of actors taking part in the cloud chain should provide for the accountability obligations of data controllers owed to data subjects. Regarding the potential shallowness of transparency and verifiability, technical and organisational measures embedding transparency and verifiability by design are key for effective accountability. A model is proposed that includes such tools. Without this, accountability-based approaches in the cloud can only be relatively weak. Extending the accountability relationship between cloud providers and cloud customers to the provider’s responsibility to society at large provides a broader perspective on the need for accountability in the cloud.

Our approach is to integrate legal, regulatory, socio-economic and technical approaches into a framework to provide accountability pre-emptively, to assess risk and avoid privacy harm and reactively to provide transparency, auditing and corrective measures for redress. This enables us to implement chains of accountability, including interdisciplinary mechanisms to ensure that obligations to protect data are observed by all who process the data, irrespective of where that processing occurs. To achieve this for the cloud a chain of accountability needs to be built through the cloud service supply network starting from the cloud service users, which can be overseen by regulators, auditors and business governance. The Cloud Accountability Project provides a framework and technologies enabling accountability for how personal and confidential data is used in the cloud. Accountability is then the result of complying with a combination of public (external to ecosystems) and private (internal to ecosystems) criteria. Cloud actors use mechanisms to support accountability practices, and thereby help them to comply with relevant regulatory regimes within specific application domains.

5 Accountability in Cloud Ecosystems

There is a need to clarify actor roles in cloud ecosystems from an accountability perspective, using a terminology that is applicable both to data protection and business confidentiality domains. The cloud taxonomy defined by NIST [30], as most relevant for cloud computing terminology, has been extensively adopted by practitioners and researchers (both in Industry and Academia) to described cloud supply chains in terms of cloud computing roles (i.e. consumers, providers, brokers, auditors and carriers). In order to take into account accountability (and in particular, its emphasis on responsibility), it is necessary to extend and to refine the cloud computing roles. For example, end-users (one of the end points of cloud supply chains) who ultimately own the data or have some other interest or rights over its dissemination and usage are misrepresented (or undermined) by cloud computing roles. Another example of misrepresented role is the lack of representation for relevant supervisory authorities. Rather than creating a novel taxonomy, we extended and refined the existing NIST cloud computing terminology in [30] (maintaining an alignment with its mail roles) with roles that support a systematic analysis of accountability in the cloud ecosystems.

We extend the cloud computing roles (defined by NIST in [30]) creating a taxonomy of (seven) cloud actor roles tailored to accountability in the cloud (Table 2). We briefly examine some of the key reasons that motivated us to adopt the taxonomy in Table 2. The NIST cloud taxonomy defines a cloud customer as an entity that both (1) has a business relationship with, and (2) uses the services of, a cloud provider. We observe that in the data protection domain, the data subject does not always fit that definition: the data subject may not have a business relationship with a cloud provider directly (or through a broker), but rather with a cloud customer. In the business confidentiality domain, a similar situation may also materialise – e.g. a business will provide data to another business, which itself uses the service of a cloud provider. This has conducted us to add the cloud subject as a distinct actor to our extended taxonomy. All actors in the supply chain are ultimately accountable to the cloud subject. Once we add a cloud subject in our model, we need to also consider the role of the relevant supervisory authority. This is particularly clear in the data protection domain. Although Data Protection Authorities (DPAs) or telecom regulators (NRAs) may be seen as cloud auditors in the NIST model, they also have the distinct characteristic of holding enforcement powers. This has similarly conducted us to include the cloud supervisory authority in our extended taxonomy. In some cases, in order to facilitate the discussion, we found it useful to further distinguish both cloud subjects and cloud customers as individuals or organisations. Furthermore, some actors may endorse more than one role. For example, in the original NIST model, cloud customers may also act as cloud providers. This is also true in our taxonomy where additionally cloud subjects may act as cloud customers, and the supervisory entity may act also as an auditor in some situations. We also slightly refined the definition of cloud auditor proposed by NIST to better encompass accountability, which is also concerned with compliance.
Table 2.

Cloud actor roles

The revision of cloud actor roles allows us to structure the discussion of the chains of accountability enabling the comparison of different cloud ecosystems and identification of accountability relationships supported by different mechanisms. The analysis of any particular cloud ecosystem should identify specific accountability relationships among actors and how they relate to the elements of accountability in high level scenarios relating to the treatment of personal and of business sensitive information within service provision chains. The discussion of such roles in terms of accountability allows us to identify specific responsibilities. Moreover, the identified cloud computing roles extend the ones identified from technical considerations of cloud computing. The discussion of specific scenarios further points out roles and responsibilities in cloud ecosystems. We can then extend the analysis of accountability relationships by a data protection perspective, in terms of data protection roles [28]. Table 3 summarises the roles identified from both perspectives (i.e. cloud computing and data protection) and their possible mapping.
Table 3.

Data protection roles

According to the current European data protection directive, a data controller (DC) essentially determines the purposes for which and the manner in which personal data are processed. A data processor (DP) processes personal data upon the instructions of the data controller. The data subject is the living person that can be identified by personal data, and the data protection authority (DPA) is the supervisory body. In other regulatory contexts, different roles may apply to entities, such as data owner, in a similar manner. In the cloud context, cloud subjects may be data subjects, cloud customers and cloud providers would be Data Controllers (DCs) or Data Processors (DPs), and cloud carriers and cloud brokers may be DPs, or possibly DCs or else fall outside the controller/processor distinction, depending upon their function. The organisational cloud customer is in general considered to be the DC and is regulated by the DPA. Even though in most cases organisational cloud customers are not in a position to negotiate with cloud providers, they may still choose amongst offerings and hence are still considered a DC [5]. An individual cloud customer is likely to be considered to be a data subject, although there are situations where they would be considered as a DC, for example where they use a cloud service for professional purposes involving processing data of other data subjects. Cloud providers are nearly always a DP but could be a DC. They may need to assume co-controllership responsibilities, but may not know who the users are or what their services are being used for. If they process personal data which is not provided by a cloud customer, acting autonomously to define the means and the purpose of the processing, the cloud provider is a DC. The cloud provider is a DP if it processes personal data to provide a service requested by a cloud customer and does not further process the data for its own purposes. There are also cases where the cloud provider can be a joint DC, namely when it processes data to provide a service requested by a cloud customer but in addition further processes the data for its own purposes (e.g. advertising). In the proposed EU General Data Protection Regulation (GDPR), DPs who process data beyond the DC’s instructions would be considered as a joint DC. This case might include changing security measures or data handling practices.

6 Accountability Model

Building on the concept of accountability, we introduce a model of accountability for data stewardship. The model expands upon the definition of accountability by introducing accountability practices, attributes and mechanisms. Accountability attributes encompass the numerous elements and properties of accountability at the conceptual level. Accountability practices characterise organisational behaviour, and hence define what it means to be an accountable organisation. Diverse mechanisms are used in order to support such practices. Accountability is interpreted in terms of accountability attributes. These accountability attributes are operationalised (that is, put into practices) by organisational accountability practices. Accountability practices need to comply with and mediate between external (drawn from relevant regulatory regimes and ethical attitudes) and internal criteria (characterising organisational culture). In order to implement such practices, organisations use different accountability mechanisms tailored to their domains. Organisations adopt mechanisms and shape (that is, adapt or modify) them in order to address their needs as well as embed organisational knowledge derived from experience. These mechanisms therefore constrain and support accountability practices, and the operational interpretation of the accountability attributes. Figure 5 illustrates how attributes, practices and mechanisms form a model of accountability for cloud ecosystems. The accountability model consists of:
Fig. 5.

Accountability attributes, practices and mechanisms

  • Accountability attributes – conceptual elements of accountability applicable across different domains (i.e. the conceptual basis for our definition, and related taxonomic analysis)

  • Accountability practices – emergent behaviour characterising accountable organisations (that is, how organisations operationalise accountability or put accountability into practices)

  • Accountability mechanisms – diverse processes, non-technical mechanisms and tools that support accountability practices (that is, accountability practices use them).

The emerging relationships between accountability attributes, practices and mechanisms give rise to an operational interpretation of accountability. This characterisation explains how organisations may attain accountability in different ways (that is, instantiate this accountability model differently according to their particular contexts).

6.1 Accountability Attributes

Accountability attributes capture concepts that are strongly related to and support the principle of accountability. We propose a number of attributes, coming from our analysis at the topmost layer, i.e. from our definition and related literature. The core (key) attributes are: transparency, responsiveness, responsibility and remediability. In addition, as we shall see, verifiability is a key property of an object of accountability, and accountability indicators about the measures used by an organisation include the key attributes of appropriateness and effectiveness. We now consider these notions in more detail. We shall distinguish between attributes that we consider to be key to the concept of accountability, in the sense that they are most associated with our definition of accountability and related notions in the literature, and those that we consider to be of secondary relevance, in the sense that they are not necessary elements of accountability or have a strongly overlapping meaning to a key attribute. We identify the objects that a cloud actor is accountable for within a cloud ecosystem to be [31]:
  • Norms:the obligations and permissions that define data practices; these can be expressed in policies and they derive from law, contracts and ethics.

  • Behaviour:the actual data processing behaviour of an organisation.

  • Compliance:entails the comparison of an organisation’s actual behaviour with the norms.

From our definition of accountability, the core attributes are suggested in a direct way: “commitment to norms” and “demonstrating compliance” suggest that transparency is an important element; “explaining to stakeholders” suggests responsiveness; “accepting responsibility” suggests responsibility; “remedying failure to act properly” suggests remediability. More specifically, these key attributes refer to:
  • Transparency:the property of a system, organisation or individual of providing visibility of its governing norms, behaviour and compliance of behaviour to the norms.

  • Responsiveness:the property of a system, organisation or individual to take into account input from external stakeholders and respond to queries of these stakeholders.

  • Responsibility:the property of an organisation or individual in relation to an object, process or system of being assigned to take action to be in compliance with the norms.

  • Remediability:the property of a system, organisation or individual to take corrective action and/or provide a remedy for any party harmed in case of failure to comply with its governing norms.

By system here we mean (parts of) the accountable cloud ecosystem, which could for example be a chain of cloud providers or an IT process, which should be accountable to humans. However, since in a legal sense the entities further down the chain are not accountable to cloud customers, but rather to the entity one step up the chain, often in our domain of interest the accountability property will relate to a single cloud provider.

Being transparent is required not only with respect to the identified objects of the cloud ecosystem (i.e. norms, behaviour and compliance) but also with respect to remediation. Transparency can be argued to be the most important attribute of accountability. A stronger definition would require demonstration of the governing norms, behaviour and compliance of behaviour as part of the definition of transparency. However, we hold that it is more natural for this aspect of demonstration to be captured mainly within the verification attribute given below. A weaker definition of transparency would only require visibility of the governing norms, but we consider this interpretation of the notion of transparency in the context of accountability to be too weak.

Responsiveness is a key element of the notion of accountability in the relation between government and electorate because ultimately, it is the electorate that mandates what happens (for example, via a social contract). In the context of cloud computing the providers are private entities that determine their own actions, between the boundaries set by regulation, and if users do not like this, they can refuse to use the service. However, responsiveness is required even in the relation between cloud providers and their users. It refers to the two-way communication relation between cloud providers and external stakeholders (such as individual cloud customers and regulators) needed within the cloud ecosystem to define part of the governing norms. Generally speaking, the audience for an organisation’s account should somehow be involved with the process by which the account is produced, and not only with the product.

Responsibility is revealed through being an attribute of the accountability objects, so is slightly different from the other attributes listed here, in that for each object, process or system within an accountable ecosystem a responsible entity (i.e. cloud actor that here would be the accountor) should be provided.

The remediability attribute provides assurance that being responsible, etc. is not sufficient and further action is required in order to be accountable; although legal responsibility, namely liability, leads to remedies, accountability equally puts emphasis not only on whom to blame but how to heal. An attribute that is a property of the objects of accountability (i.e. norm, behaviour, compliance) is:
  • Verifiability:the extent to which it is possible to assess norm compliance.

This is a property of the behaviour of a system, service or process that it can be checked against norms. We consider this to be a core attribute because of our explanation of accountability in terms of defining and displaying relevant norms, behaviour and compliance to the norms. Other attributes that are properties of accountability objects but are of secondary relevance are:
  • Attributability:the possibility to trace a given action back to a specific entity.

This is a property of behaviour or of a norm violation. Attributability is considered of secondary relevance as it is not explicit in our definition of accountability, but is implied in the notions of responsibility and transparency. For responsibility to materialise in a meaningful way, actions have to be attributable to those responsible for them. Furthermore demonstration of this responsibility through transparency allows for accountability.
  • Observability:the extent to which the behaviour of the system is externally viewable.

This is a property of behaviour of a system, service or process which describes how well the internal behaviour of a system, service or process can be described by observing the external outputs of the system, service or process. Observability is considered of secondary relevance as it is not necessary for accountability (as observability implies transparency and verifiability but the opposite is not true), even though if organisations know that they are likely to be observed then they may be more likely to behave in a responsible manner. While transparency requires an actor taking actions to be transparent, observability is more passive and the actor may not even be aware of it. It is possible to be transparent (and accountable) and non-observable, by the intervention of a third party that can observe a party instead and transfer the element of transparency.

Accountability is not a binary state, but often has many factors indicating the extent of accountability of an organisation. If accountability is seen as a process in which an organisation can mature, accountability indicators can assess the maturity of the organisation, with a focus on the mechanisms used and resultant behaviour. Accountability attributes may be defined to capture the important aspect of deployment of ‘appropriate and effective measures’ that meet technical, legal and ethical compliance requirements, and act as this type of indicator:
  • Appropriateness:the extent to which the technical and organisational measures used have the capability of contributing to accountability.

  • Effectiveness:the extent to which the technical and organisational measures used actually contribute to accountability.

By contribute to accountability, we mean (in the light of the analysis above) contribute to defining and displaying relevant norms, behaviour and compliance to the norms. We believe that it is acceptable to refer to accountability within these definitions since they are accountability indicators (properties of the measures used to support organisational accountability).

The cloud ecosystem not only has internal factors steering accountability, there are also some external factors that have the ability or are needed to keep the process of accountability in motion. These external factors often relate to governance mechanisms that, for example, sanction when compliance is not met. Hence there are accountability attributes that relate to the process by which the accountee holds the accountor to account. One of these is punishability, which is achieved through sanctions. Another attribute relevant to this process is verifiability, which, as already considered above, allows for the provision of evidence that compliance to the norms is (or is not) met. A further relevant attribute is liability. When an actor becomes liable for his actions, one could perceive this as a form of sanctioning. Liability is the legal obligation (either financially or with some other penalty) in connection with failure to apply the norms. It is closely related to legal responsibility (although being held liable does not necessarily mean that the same entity is actually responsible, for example, according to the DPD, data controllers are always held liable towards data subjects, even in connection with a damage actually caused by data processors), and is not referred to directly in our definition, and so could be considered to be a secondary attribute.
  • Liability:the state (of an organisation or individual) of being legally obligated or responsible in connection with failure to apply the norms.

There exist emerging relationships (e.g. implication and inclusion) among the concepts described above dependent on different viewpoints of analysis (related to societal, legal and ethical aspects of accountability). For example, from a legal perspective, responsibilities imply obligations, which consequently may involve sanctions; liability is based upon the establishment of norms, allowing the request for remedies and the imposition of sanctions should these norms not be met. If the norms are not met it is not necessarily the case that all related failures can be entirely remedied (e.g. in case of a data breach the harm resulting from the disclosure of information is done and that cannot be entirely corrected). Table 4 summarises the core accountability attributes.
Table 4.

Core accountability attributes

6.2 Accountability Practices

Accountability practices, derived directly from the given definitions, characterise emerging behaviour (highlighting operational and organisational objectives to be met) manifested in accountable organisations. Specifically, an accountable organisation:
  • Defines governance to responsibly comply with internal and external criteria, particularly relating to treatment of personal data and/or confidential data.

  • Ensures implementation of appropriate actions.

  • Explains and justifies those actions, namely, demonstrates regulatory compliance that stakeholders’ expectations have been met and that organisational policies have been followed.

  • Remedies any failure to act properly, for example, notifies the affected data subjects or organisations, and/or provides redress to affected data subjects or organisations, even in global situations where multiple cloud service providers are involved.

6.3 Accountability Mechanisms

The accountability model highlights ‘what’ needs to be implemented. Within the model, accountability mechanisms (cf. the ‘how’) are instances of tools and techniques supporting accountability practices (that is, high level objectives that accountable organisations need to achieve). Organisations can adopt different available accountability mechanisms as appropriate for their contexts. They will use what is best suited to their particular processes, demonstrating at the same time that the appropriate mechanisms have been selected. Accountability mechanisms focus on the core aspects of accountability (e.g. remediation, notification and risk assessment) and are expected to be used in conjunction with separate privacy and security mechanisms [26].

Mechanisms (e.g. security controls, policies, tools, standards, legal mechanisms, penalties), from a social science viewpoint, are accountability objects (“that both inhabit several communities of practice and satisfy the information requirements of each of them” [32]). Accountability mechanisms (developed by A4Cloud) complement others that are available from third parties. They may be used individually or in combination. Organisations may select from different alternatives. For example, they may choose to use the Privacy Level Agreement format specified by the Cloud Security Alliance (CSA) to express privacy-related obligations [33] or the Cloud Trust protocol [34] to ask for and receive information from cloud service providers about the elements of transparency, or they may take another approach to do so.

7 Accountability Framework

This section presents an accountability framework for the cloud. It describes our high level approach and how a combination of legal, governance and technical measures are used to enable chains of accountability to be built along cloud service provision chains. This section highlights that the emerging accountability framework enables cloud ecosystems to comply with relevant regulatory regimes within specific application domains. This section also explains how the emerging accountability framework supports the analysis of cloud ecosystems and emerging issues (e.g. data protection issues). The aim in particular is to strengthen the accountability of organisations that use cloud services and organisations that provide cloud services to data subjects and regulators. This section introduces an accountability framework that is based upon the defined accountability model. The accountability framework supports:
  • assessment of potential co-design of mechanisms from different disciplines (i.e. legal, regulatory, procedural and/or technical)

  • provision of flexibility in our approach, including ‘intelligent accountability’ in complex environments and incorporation of varying degrees of accountability according to the context

  • assessment of accountability in different cloud delivery and deployment models; possibly, this could include identification of patterns and capabilities that are suitable for specific cloud computing contexts (e.g. private cloud vs. public cloud, storage-based cloud vs. flexible computing ones, etc.)

  • contribution towards high-level design and architecture– mapping across to requirements for functional components within systems that provide accountability and starting to build a high-level, logical design structure and explaining how the component parts work together.

Accountability promotes implementation of practical mechanisms whereby legal requirements and guidance are translated into effective protection for data. Legislation and policies tend to apply at the data level, but the mechanisms can be at various levels, including the system level and data level. A toolbox of measures could be provided for data controllers, to allow construction of custom-built solutions, whereby the controllers might tailor measures to their context (e.g. taking into account consideration of the systems involved, type of data and data flows). We can co-design legal mechanisms, procedures and technical measures to support this approach. We may integrate design elements to support: prospective (and proactive) accountability, using preventive controls, and retrospective (and reactive) accountability, using detective controls.
  • Preventive Controls – These can be used to mitigate the occurrence of an action for continuing or taking place at all (e.g. an access list that governs who may read or modify a file or database, or network and host firewalls that block all but allowable activity). The cloud is a special example of how businesses need to assess and manage risk better [35]. Preventive controls for cloud include risk analysis and decision support tools (for example, Privacy Impact Assessments), policy enforcement (for example, machine readable policies, privacy-enhanced access control and obligations), trust assessment, obfuscation techniques and identity management.

  • Detective Controls – These are used to identify the occurrence of a privacy or security risk that goes against the privacy or security policies and procedures (for example, intrusion detection systems, policy-aware transaction logs, language frameworks and reasoning tools). Detective controls for the cloud include audit, tracking, reporting, and monitoring.

  • Corrective Controls – These (e.g. an incident management plan, dispute resolution) are used to fix an undesired result that has already occurred.

Preventive, detective and corrective controls complement each other: a combination of these would ideally be required in order to provide accountability. Provision of accountability would not just be via procedural means, especially for cloud, which is such an automated and dynamic environment. Technology can play an important role in enhancing the solution (e.g. by enforcing policies). Procedural measures for accountability include determining the capabilities of Cloud Service Providers (CSPs) before selection, negotiating contracts and Service Level Agreements (SLAs), restricting the transfer of confidential data to CSPs and buying insurance. Organisations should also appoint a Data Protection Officer, regularly perform privacy impact assessments on new products and services, and put mechanisms in place to allow quick response to data subject access and deletion requests. Technical measures for accountability can include encryption for data security mitigation, privacy infomediaries and agents to help increase trust. We also need to be able to rely on infrastructure to maintain appropriate separations, enforce policy and report information accurately. It could be argued that the current regulatory structure places too much emphasis on remediation of problems (e.g. privacy breaches), and not enough on trying to get organisations to do the right thing for data protection in the first place.

Our approach involves the provision of hybrid accountability mechanisms via a combination of policies, regulatory and technical means. It is a co-regulation strategy based on a corporate responsibility model underpinned primarily by contract. This approach places the onus upon the data controller to take a more proactive approach to ensuring compliance, and encourages cloud service vendors and subcontractors to compete in providing services on the basis of evolving better privacy and security enhancing mechanisms and processes. We build upon the accountability definitions and model discussed and extend these to include prospective effects, that is to say, proactive rather than just reactive measures. This is because the policies by which we are judging our actors are constantly changing, the context and technological environment is changing and privacy-related harms to individuals are not equal. It is necessary to provide mechanisms to determine liability in the event of a breach, but we also (from the point of view of the data controller) build in processes and reinforce good practices such that the liability does not arise in the first place. We suggest ways in which an organisation might take an accountability approach further in order to develop a reflexive privacy process that is not simply a static compliance mechanism but rather that involves an on-going process of data protection monitoring and review and improvement throughout the contractual chain. Figure 6 shows examples of services supporting accountability. The identified services map to the trusted services supporting accountability that are developed by the Cloud Accountability Project or that relate directly to those. Other services could be provided and would fit into this framework, such as incident management, identity management services and certification. We provide benefits and tools for a range of different stakeholders (Fig. 6).
Fig. 6.

Accountability framework

This model would vary according to context and depend on relevant parameters. Related questions include investigating: To what extent do the same mechanisms apply for personal data, confidential data, sensitive info, location info, and other sensitive information? How can we put intelligence into accountability? What should underlie all scenarios? What should vary, in terms of accountability? What guidance can be given in terms of appropriate levels of external assessment and certification for different contextual types? The functional aspects of accountability may be achieved by mechanisms in the following way:
  • Proper allocation of responsibilities – via management support, allocation of responsibilities for data protection within an organisation and clarification of responsibilities across supply chains.

  • Definition of the contextual obligations to be followed (carried out by organisations and reflecting stakeholder and regulatory requirements) – via formation of appropriate organisational policies, contracts, stakeholder engagement.

  • Risk and trust assessment to decide which mechanisms to use in the given context to meet the policies – via risk identification/assessment, trust assessment, appropriate choice of business partners.

  • Deployment of appropriate privacy and security controls (these are the mechanisms determined above and include means to make uses transparent to individuals and to assure that their rights are respected) – via security and privacy best practice, including transparency tools.

  • Monitoring data practices (by organisations and by regulatory oversight) – via tracking tools.

  • Detection of policy violations – via audit and violation detection tools (e.g. evidence collection).

  • Correction of policy violations – via remediation and/or compensation.

  • Reporting of policy violations – via breach notification and transparency tools.

  • Demonstration of policy compliance (including that policies defined by organisations are appropriate, the mechanisms used are appropriate for the context and that the operational environment is satisfying the policies) – via provision of trustworthy account, verification (about appropriate use of privacy and security controls), certification, provision of evidence about satisfaction of obligations along service provision chains, transparency tools.

Not only are mechanisms to achieve this run within different types of organisation, but others are kinds of meta-mechanisms that can bridge across organisations, for example helping with clarifying responsibilities, or with the verification process.

8 Accountability Governance

Accountable organisations need to define and implement appropriate governance mechanisms relating to treatment of personal and/or confidential data in cloud environments. “Cloud governance encompasses two main areas: internal governance focuses on a provider’s technical working of cloud services, its business operations, and the ways it manages its relationship with customers and other external stakeholders; and external governance consists of norms, rules, and regulations which define the relationships between members of the cloud community and attempt to solve disputes between them” [36]. All actors involved in the cloud – customers, service providers, and supervisory authorities (whether individual cloud customers, businesses, public organisations and even other cloud service providers) – and those directly involved in governance have a role to play in making cloud services accountable for how data is used and managed in the cloud. Inspired by the NIST definition of Information Security Governance [37], accountability governance can be defined as the process of establishing and maintaining a framework and supporting management structure and processes, as well as accepting and providing assignment of responsibility to:
  • provide stewardship of personal and confidential data with which the organisation is entrusted,

  • processing, sharing, storing and otherwise using said data according to contractual and legal requirements, from the time it is collected until when the data is destroyed (including onward transfer to and from third parties),

  • comply with legal, ethical and moral obligations, policies, procedures and mechanisms,

  • explain and demonstrate ethical implementation to internal and external stakeholders and remedy any failure to act properly.

In essence, accountability governance consists in accepting responsibility for accountability objectives, and in establishing and sponsoring the operational structure and process to meet these objectives. The board (or equivalent executive leadership) of the organisation is responsible for governance. It can (and usually does) create management structures to assign authority in the implementation of the oversight and processes identified. However, it ultimately remains responsible and accountable for meeting these objectives [38]. Nothing in this definition is dependent on the mechanisms used to store or process the data. The accountability governance objectives do not depend on whether data processing uses cloud computing. However, cloud has a strong impact on how governance is implemented. In a simplified view, accountability is modelled as a relationship between two parties: the first party (the application provider) is accountable to another party (the customer) for something (in this case, handling data in a defined manner). These roles bear a strong relationship to the roles defined in data protection legislation; the first party might be a data controller and the second a data subject. This relationship can be defined across multiple dimensions:
  • Legal: laws and regulations assign responsibilities and obligations to both parties.

  • Contractual: the use of cloud services is done in the context of an agreement between the cloud customer and the cloud provider. This agreement can take many forms, for example, a negotiated contract or terms and conditions applicable to all cloud users.

  • Technical: the cloud service offers a set of functionalities, which are accessed through a defined interface. This interface is provided by the cloud provider and is invoked by the cloud customer, hence creating the relationship.

  • Administrative: operators and administrators can only manage the resources placed under their administrative control. Administrative domains define which resources are in the control of which party.

Figure 7 shows the interaction between two organisations (as a continuous process) driven by accountability governance (constrained by external criteria and regulatory regimes but orchestrated independently by organisations). Organisation A could be part of a service provision chain that involves cloud service providers and Organisation B is actually an oversight and enforcement actor (e.g. regulator) in the chain. Organisation A defines and implements appropriate governance mechanisms, which enable demonstration of governance. Organisation B, in holding to account Organisation A, can ask for further clarification, engage in discussions and also (request to) apply sanctions. As a result, Organisation A may modify its own organisational governance. In summary, accountability governance consists of taking responsibilities for specific accountability criteria, ensuring them by deploying suitable mechanisms and demonstrating their appropriateness and effectiveness by evidence.
Fig. 7.

Accountability Governance

Organisations need to provide transparency of those actions taken in order to show that stakeholders’ expectations have been met and that organisational policies have been followed. They also need to remedy any failure to act properly (e.g. by notifications, remedies, sanctions) even in cloud-supply chains involving multiple service providers. Accountability governance redefines interactions between providers and regulators as well as between providers themselves. The ethical nature of an accountability-based approach and the organisational obligations that result from taking this approach represent a shift from reactive to proactive governance of personal and/or confidential data. Organisations commit to the stewardship of personal and/or confidential data by addressing legal, contractual and ethical obligations. Organisations deploy and use different mechanisms (e.g. policies), take into account social norms, provide evidence to internal and external stakeholders, and remedy any failure to act properly. While accountability may not typically be composed; i.e. it is primarily a bilateral relationship, the ability to behave in an accountable manner in the context of the cloud depends on cloud services supporting accountability attributes, such as transparency.

9 Dealing with Emerging Threats in Cloud Ecosystems

Let us now consider the accountability relationships between the various actors in a cloud ecosystem (such as those illustrated by Fig. 8). Every party of the cloud service is called to be accountable to other parties. Figure 8 shows some examples of threats (e.g. loss of governance, lock in hazard, incomplete data deletion) in cloud ecosystems. The threats are drawn from existing risk analyses of cloud computing [23, 39, 40, 41]. ENISA further reviewed emerging threats in order to point out potential risks and highlight areas for mitigations [42].
Fig. 8.

Emerging threats in cloud ecosystems

Cloud customers and providers are exposed to various problems. For instance, from a resource viewpoint, an increasing amount of data and resources may require new mechanisms enabling cost-effective management while guaranteeing critical features like security and privacy. From the viewpoint of security, privacy or trustworthiness, some of the issues that consumers and regulators are mostly concerned about are things like lack of transparency and control in cloud service provision [39], as well as worries about increased unwanted access to their data by third parties, including governments. The compliance with multiple jurisdictional requirements may also exacerbate complexities from a legal perspective [11]. Such challenges are perceived as barriers to the adoption of cloud computing.

There are different obligations according to the roles that apply in a given scenario. The DC is accountable for applicable data protection measures. The cloud providers as DPs must provide security measures, and their responsibilities will vary according to the combination of cloud service and deployment models. For example, Platform as a Service (PaaS) providers are responsible for the security of the platform software stack and Software as a Service (SaaS) providers are responsible for security applications delivered to end users. The lower down the stack the cloud provider stops, the more security the consumer is tactically responsible for implementing and managing. The liabilities involved are expressed within contracts as there can be ramifications of failure within cloud ecosystems, affecting other parties. The DPs are accountable for co-operation with the DC to meet data subjects’ rights, assist the DC in providing security measures, and should act only on the DC’s behalf. Thus, there are chains of accountability through the cloud service supply chains to the cloud customer.

In addition, cloud providers and customers are accountable to the actors involved in governance and enforcement (as shown on the left hand side of Fig. 8). These include regulators, stakeholders and society, as well as auditors and business governance. These are especially interested in monitoring and measuring non-functional aspects, leaving it to the service providers to determine how they actually want to achieve those. The organisational cloud customer is in general accountable to these governance entities for applicable data protection measures. All actors in the supply chain are ultimately accountable to the cloud subject. Extending the accountability relationship between cloud providers and cloud consumers to the provider’s responsibility to society at large provides a broader perspective on the need for accountability in the cloud. Hence, most of the data protection risks associated with cloud should be reduced by contractual provisions that can include penalties for the service provider, and by technical and organisational measures for the customer and the service provider. If the DC is ultimately made accountable for meeting obligations right along the service provision chain, it should try to obtain contractual assurances that lessen the risk of potential weak links in dynamically formed cloud provider chains. That is, contractual agreements between the series of actors taking part in the cloud chain should provide for the accountability obligations of DCs ultimately owed to data subjects.

Accountability can be achieved via a combination of public accountability – derived from transparent interaction (between subjects of personal data, supervisory authorities, regulatory bodies and DCs), legislation, soft regulation, on-going Privacy Impact Assessments (PIAs), certification, audit and public policy – and private accountability –derived from interactions between DCs and data processors (premised on contract law, technological processes and practical internal compliance requirements) [10]. Furthermore, we advocate the combination of a strong and soft approach to support accountability provision. The soft approach relates to addressing how accountability can be achieved in a socially beneficial way, including ethical governance and the democratic aspect. The strong approach involves supporting accountability of practice, provision and analysis of trusted evidence to show whether or not data protection obligations have been fulfilled, verification by independent, trusted entities and certification based on such verification.

9.1 Risk Assessment

Accountability, as articulated by the Article 29 Working Party [4], begins to shift our thinking from only having an obligation to comply with a principle, to an obligation to prove that you can put those principles into effect. Risk assessment is therefore particularly important for accountability, because it is a central part of the process used to determine and demonstrate that the policies (whether reflected in corporate privacy and security policies or in contractual obligations) that are signed up to and the corresponding practices that are implemented by an organisation (adopting an accountability-based approach) are effective and appropriate to the context [43, 44]. On-going risk assessment and mitigation relating to new products or processes, as well as regular risk assessment and validation of the accountability program, are captured within the core elements of implementing an accountability project within an organisation specified within the Galway Project [8]. These core elements of implementing an accountability project within an organisation [8], are very similar to the guidance provided by the Privacy Commissioners of Canada, Alberta and British Columbia [45], which also emphasises the need for risk assessment, as does the revised OECD guidelines [16], which now recommend the practical implementation of privacy protection through an approach grounded in risk management and stress the need for improved global interoperability. The type of procedures and mechanisms employed by an organisation could vary according to the risks represented by the processing and the nature of the data [22, 23, 26, 46, 47]. Automation can enhance this process [9]. Data impact assessment may also become an obligation for some high risk contexts within the GDPR [17].

Risk assessment within an organisation can potentially be extended to encompass both pre-emptive approaches (to assess risk and avoid privacy harm) and reactive approaches that provide transparency and audit. Furthermore, the privacy policies and mechanisms need to take into account the entire life cycle. Companies need to think about what data they will collect and how they plan to use it, but also what the potential harms are for individuals. It is the data subject that is in a sense the real owner of data, who ultimately is harmed in case of failure and who should be empowered and supported. For example, if you are tracking someone online then under an accountability approach you might include clear notice that tracking is happening, how the tracking data will be used, as a mechanism for individuals to choose not to be tracked and to request previous tracking data to be deleted.

The Privacy Impact Assessment (PIA) process (incorporating privacy by design to help organisations assess the impact of their operations on personal privacy) assesses the privacy requirements of new and existing systems. It is primarily intended for use in public sector risk management, but is increasingly seen to be of value to private sector businesses that process personal data. Similar methodologies exist and can have legal status in Australia, Canada and the US [48]. The methodology aims to combat the slow take-up to design in privacy protections from first principles at the enterprise level. Usage is increasingly being encouraged and even mandated in certain circumstances by regulators [48].

PIAs are regarded as an essential tool for implementing the accountability principle and demonstrating compliance [4, 17], where PIAs based on self-verification by or on behalf of data controllers are proposed for higher risk data processing operations. The Article 29 WP Opinion 3/2010 on the Principle of Accountability states that [4]: “As a complement to the principle, specific additional requirements aiming at putting into effect data protection safeguards or at ensuring their effectiveness could be set up. One example would be a provision requiring the performance of a privacy impact assessment for higher risk data processing operations”. In addition to this, data impact assessment may also become an obligation for some high risk contexts within the forthcoming GDPR [17]. The proposed GDPR [17] introduces a risk-based approach to PIAs (namely, Data Protection Impact Assessments, or DPIAs). Prior to processing of personal data, a DPIA is required if the processing is likely to present specific risks for the rights and freedoms of data subjects, taking into account the nature, scope and purpose of the data processing.

However, there is still no consensus on the final legal provisions. Existing organisational risk assessment processes need to be enhanced to meet the requirements above, or else supplemented with separate privacy-specific risk assessment [48]. The UK Information Commissioners’ Office (ICO) – an organisation responsible for regulating and enforcing access to and use of personal information – have already rolled out a process to encourage privacy by design guidelines on privacy impact assessments [49], and a number of standards and tools related to PIAs exist [50].

Risk assessment must be extended right along the service provision chain: in order to implement a chain of accountability for the non-functional attributes of an ICT system, it must be possible to measure those attributes in a meaningful way. However, this is non-trivial. For example, liability assignment is currently particularly difficult in an international context where business relations are negotiated and regulated by contracts, and there are differences among the countries with respect to legal framework and regulations. Furthermore, it is very difficult and resource-demanding to detect and then prove that electronic data has been compromised and to identify the perpetrator. What is reported to the police is just a small percentage of all violations detected. In addition, risk allocation is (for large deals) negotiated individually in contracts, so that a single provider will have a different risk allocation scheme with each of its major customers. Law and regulation differs between countries, so that there is no single scheme of risks to be addressed, or single view on liability if those risks eventuate (note that there are also worries about how exactly privacy impacts would be measured and taken into account, even if a PIA were carried out).

Current risk assessment methods have not been designed for use in a cloud computing setting, and there is at the moment no methodology or tool developed for assessing and predicting risks related to accountability of cloud services. Even in a non-cloud environment, automation of privacy impact assessment is not yet mature [51]. Practical challenges include whether objective or subjective harm (e.g. material tangible harm to individuals, moral non-tangible harm to individuals, and harm to democratic and societal values of a free society) can be used as a basis for evaluation, and how this could be encoded. An additional challenge relates to what the evidence looks like that is provided by DPIAs to external parties, and how important organisational criteria and choices in this decision making process can get exposed to other parties. Related to this issue, self-verification through PIAs could involve a transparency duty with regard to the outcome of the PIAs (e.g. public PIA registers), but this is not even specified from the regulatory side and the situation is unclear.

A further challenge relates to the way in which verification is provided that the measures used (potentially across a supply chain network) are appropriate for the context. The intention of using risk management is to mitigate risks and to identify operational trade-offs, that is, what it is reasonably feasible to achieve in terms of protections with respect to emerging security and privacy threats [39]. Within organisational risk management processes, security and privacy policies are translated into implementable solutions that make use of specific mechanisms (e.g. security controls) in order to monitor and enforce operationally the implementation of such policies. Detected policy violations are then assessed as part of the risk management. Gathering evidence is central for organisational risk management processes [45]. On the one hand, evidence provides valuable information to risk management. On the other hand, evidence would support assurance – “Assurance is about providing confidence to stakeholders that the qualities of service and stewardship with which they are concerned are being managed and maintained appropriately” [35]. This is also particularly important when dealing with emergent digital risk [52] due (to a certain extent) to the shift required while deploying new technological paradigms like cloud computing. This is also relevant in the case of supply chain risk management [53].

Risk assessment is a preventative accountability measure that helps prevent risky actions happening. It is also used to demonstrate how the security and privacy mechanisms used are appropriate for the context. Cloud Service Provider (CSP) chains should be taken into account within the analysis. Accountability functionality must also be part of the solution, so accountability requirements should be part of the output of the risk assessment process – “can we predict how risky it is to provide our personal data to an entity or organisation?” [54]. Among the main challenges of risk assessment are: risk assessment across CSP chains [53], assessment of social harms (different “types of harm may directly or indirectly affect individuals” [54]), output as part of a design process and output as part of the account/verification process. Risk assessment is also concerned with the problem of lack of trust in the cloud, as discussed in the next section.

9.2 Accountability, Risk and Trust

The relationship between risk and trust has been considered (in particular, from social and policy perspectives) to underpin the governance of privacy [55]. Both risk (management) and trust (promotion) provide alternative viewpoints of analysis. Having recognized that “the problem of privacy is socially and politically constructed” [55], it is necessary to balance objective evidence with subjective perceptions while dealing with policy governance. Objective evidence is derived from mechanisms that can be implemented and monitored in the cloud [56]. For instance, the work in [57] provides an example of a mechanism that may be implemented by cloud providers and used by cloud customers in order to gather objective evidence and obtain assurance about running services (e.g. assurance that cloud services comply with relevant national jurisdictions). Other similar mechanisms can be utilized to provide further transparency, which is part of accountability, to cloud customers. Approaches (like risk assessment) promoting transparency (of information) would support “better understanding of exposures to privacy dangers, the distribution of risks, and the patterning of trusting [that] may be worth seeking” [55]. In this respect, accountability (as promoting transparency) is critical for supporting governance of privacy, data protection and security in the cloud [6]. In general, accountability needs to mitigate risk, hence suggesting trust or mistrust depending on the supported accountability in practice. The problem then is to understand how accountability mechanisms mitigate specific risks – How does accountability address emerging threats?

In particular, we need to make explicit the relationships between the different aspects of the accountability model (and the associated framework) mitigating the emerging threats in the cloud. For instance, the CSA Cloud Control Matrix [58] identifies specific controls (e.g. Governance and Risk Management, Legal & Standards Compliance, Supply Chain Management, Transparency and Accountability) that relate directly to aspects of accountability. Mapping accountability to specific mechanisms (and explaining how they mitigate risks) highlights how accountability (if successfully supported) contributes to mitigate a broad range of risks, encompassing privacy and security. Accountability mechanisms complement privacy and security controls. Therefore, a combination of accountability, privacy and security controls are necessary in order to mitigate and address emerging risks. An accountability assessment with respect to risk then consists in assessing whether or not relationships between assets and accountability are successfully supported. If accountability is successfully supported, the result would be to mitigate risks and to enhance trustworthiness and transparency.

We have collected and analysed stakeholders’ feedback in order to gather accountability requirements for cloud services [31]. The analysis of the accountability requirements points out emerging relationships between accountability, risk and trust and the way in which they underpin accountability governance. Stakeholders, attending dedicated workshops, involved organisational cloud customers, cloud providers, data protection authorizes and researchers [59]. Stakeholders agree that trust facilitates interactions between cloud actors. They additionally point out that trust is related to the context of the interaction (that is, the actors in a cloud supply chain, cloud ecosystem), whereas risk is context free (that is, risks are perceived to be independent from the specific cloud ecosystem, not necessarily the likelihood and or the impact of such risks). High risk levels would affect trustworthiness. The relationship between accountability and risk stimulated interesting discussions too.

Stakeholders affirmed that accountability will enhance trustworthiness and change risk perception [59] – “responding to perceived risk can lead to less secure solutions, instead of optimal controls”, hence “reduced perceived risk will increase cloud adoption, increased transparency will mean increased usage”. On the relationship between accountability and trust, stakeholders agreed that accountability supports trust decisions and enhances cloud trustworthiness. They also highlighted that “accountability is a good starting point to trust but not the answer”, that is, being accountable for specific actions is essential but not sufficient for being trusted. Stakeholders confirmed that “accountability is very important” and influences trust in cloud services. Enhancing trustworthiness will have also an effect on risk due to trust decisions. In summary, stakeholders articulated accountability, risk and trust as follows:
  • Accountability – The term accountability is understood differently by stakeholders. There is not yet a shared understanding of the accountability concept itself. Stakeholders recognize different attributes (or elements) such as responsibility and liability contributing to accountability. However, they understand the contributions of such attributes toward accountability in different ways. This depends on their background and expertise. There were no major objections about the presented accountability model. A structured representation of accountability would support discussions on accountability and building a shared understanding of the concept itself. Other comments were concerned with the relationship between accountability, risk and trust. There was a convergent understanding that the relationships between accountability and risk and accountability and trust are different (in the sense of having a different nature).

  • Accountability and Risk – Although accountability addresses risk, it is as yet unclear how. The relationship between accountability and risk is a generalized one. That is, it is believed that accountability addresses emergent risks affecting security and privacy in cloud ecosystems. However, stakeholders had difficulties in figuring out in which way. This is probably due to the fact that the concepts were presented in general terms and in the context of an accountability-based approach to risk and trust. Future work would need to identify clear examples of the effect of accountability on risk. Stakeholders questioned whether accountability addresses risk (by modifying risk profiles in terms of likelihood of occurrence or severity of impact) or changes risk perception of emerging threats in cloud ecosystems. This is another interesting aspect of the relationship between accountability and risk that requires further investigation.

  • Accountability and Trust – The relationship between accountability and trust seems to be more context-dependent than the one with risk. Accountability helps to make trust decisions. However, accountability itself seems to be necessary but not sufficient for trust (or to imply trust unconditionally). This agrees with research on the data protection implications of accountable surveillance practices – “Accountability is however only part of the solution and only contributes to generate trust in institutions and market players engaged in surveillance to the extent that these are compelled to give an account of their practices.” [60]. A critical aspect of trust seems to be related to the evidence provided to stakeholders. Such accountability evidence is often associated to the implementation of privacy by design principles and the adoption of specific mechanisms [61]. Therefore, accountability (in particular transparency) plays an important role in trust decisions and can support trustworthiness (in particular based on accountability evidence).

The emerging relationships between accountability, risk and trust underpin the accountability-based approach to data governance in the cloud.

10 Concluding Remarks

This paper has discussed various drivers for accountability in the cloud. Adopting the cloud involves transfers of personal and/or confidential data, hence a loss of governance over the way data is managed and controlled in the cloud. Different regulatory regimes at the national and international level combined with potential threats affecting the cloud represent barriers to cloud adoption. Accountability has emerged as a critical aspect of data governance in the cloud. This paper introduces the foundations of an accountability-based approach to data governance in the cloud. Based on our accountability definitions, one independent from the application domain and another tailored to the cloud, the paper introduces an accountability model consisting of accountability attributes, practices and mechanisms. The model provides the basis for an accountability framework supporting cloud actors by different means across cloud supply chains and hence supporting accountability chains. The analysis of accountability provided across cloud supply chains points out various aspects concerned with the different cloud roles and data protection roles of cloud actors.

The discussion of emergent threats in cloud ecosystems highlights the role of risk assessment within an accountability-based approach. It also points out insights about how accountability, risk and trust relate to each other. In order to be accountable, organisations need to deploy mechanisms (e.g. tools and controls) that are suitable for cloud ecosystems and proportionate to the threats. The deployment of such mechanisms intends to mitigate the risks, and to enhance transparency of data stewardship in the cloud. Risk assessment has a critical role in identifying suitable mechanisms. In addition, certification involves scrutiny by third parties that the identified mechanisms are implemented and that organisational practices comply with regulatory regimes [62]. For instance, the CSA STAR (Security, Trust & Assurance Registry) relies on a three-level Open Certification Framework [63], which assesses and documents how organisations implement security controls identified by the Cloud Control Matrix [58]. However, in order to maintain continuous monitoring as well as to enhance transparency and assurance, specific mechanisms supporting automation and evidence gathering are necessary [64]. An accountability-based approach, such as the one introduced in this paper, is necessary in order to support data stewardship in the cloud. In summary, this paper introduces and discusses an accountability-based approach to data governance in the cloud. The proposed approach is based on an accountability model and framework enabling accountability in cloud ecosystems.



This work has been partly funded from the European Commission’s Seventh Framework Programme (FP7/2007-2013), grant agreement 317550, Cloud Accountability Project – – (A4Cloud). We would like to thank our project partners and colleagues who contributed to the accountability-based approach presented in this paper, in particular, we acknowledge the contributions of Brian Dziminski, Carmen Fernandez Gago, Simone Fischer-Hübner, Frederic Gittler, Martin Jaatun, Theo Koulouris, Ronald Leenes, Jesus Luna, Maartje Niezen, David Nuñez, Alain Pannetrat, Jenni Reuben Shanthamoorthy, Jean-Claude Royer, Anderson Santana de Oliviera, Dimitra Stefanatou and Vasilis Tountopoulos.


  1. 1.
    Mell, P., Grance, T.: The NIST Definition of Cloud Computing. National Institute of Standards and Technology, NIST Special Publication 800-145 (2011)Google Scholar
  2. 2.
    Cloud Computing Use Case Discussion Group: Cloud Computing Use Cases White Paper, Version 4.0 (2010)Google Scholar
  3. 3.
    Papanikolaou, N., Pearson, S.: A cross-disciplinary review of the concept of accountability: a survey of the literature. In: International Workshop on Trustworthiness, Accountability and Forensics in the Cloud (TAFC), Malaga (2013)Google Scholar
  4. 4.
    Article 29 Data Protection Working Party: Opinion 3/2010 on the Principle of Accountability, 00062/10/EN WP 173 (2010)Google Scholar
  5. 5.
    Article 29 Data Protection Working Party: Opinion 05/2012 on Cloud Computing, 05/12/EN WP 196 (2012)Google Scholar
  6. 6.
    Guagnin, D., et al. (eds.): Managing Privacy Through Accountability. Palgrave Macmillan (2012)Google Scholar
  7. 7.
    Organisation for Economic Co-operation and Development (OECD): OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data (1980)Google Scholar
  8. 8.
    Galway Project: Accountability: A Compendium for Stakeholders. The Centre for Information Policy Leadership LLP (2011)Google Scholar
  9. 9.
    Pearson, S.: Toward accountability in the cloud. IEEE Internet Comput. 15(4), 64–69 (2011). IEEECrossRefGoogle Scholar
  10. 10.
    Charlesworth, A., Pearson, S.: Developing accountability-based solutions for data privacy in the cloud. Innovation, Spec. Issue Priv. Technol. Eur. J Soc. Sci. Res. 26(1), 7–35 (2013). Taylor & FrancisCrossRefGoogle Scholar
  11. 11.
    Felici, M., Jaatun, M.G., Kosta, E., Wainwright, N.: Bringing Accountability to the Cloud: Addressing Emerging Threats and Legal Perspectives. In: Felici, M. (ed.) CSP EU FORUM 2013. CCIS, vol. 182, pp. 28–40. Springer, Heidelberg (2013)CrossRefGoogle Scholar
  12. 12.
    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. Official Journal L 281, 23 Nov 1995, pp. 0031–0050 (1995)Google Scholar
  13. 13.
    Felici, M., Koulouris, T., Pearson, S.: Accountability for data governance in cloud ecosystems. In: 2013 IEEE 5th International Conference on Cloud Computing Technology and Science (CloudCom 2013), vol. 2, pp. 327–332. IEEE (2013)Google Scholar
  14. 14.
    Article 29 Data Protection Working Party: Opinion 1/2010 on the concepts of “controller” and “processor”, 00264/10/EN (2010)Google Scholar
  15. 15.
    Badger, L., et al.: Cloud Computing Synopsis and Recommendations. NIST Special Publication 800-146 (2012)Google Scholar
  16. 16.
    OECD: The OECD Privacy Framework. Organisation for Economic Co-operation and Development (2013)Google Scholar
  17. 17.
    European Commission: Proposal for a directive of the European Parliament and of the council on the protection of individuals with regard to the processing of personal data by competent authorities for the purposes of prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, and the free movement of such data (2012)Google Scholar
  18. 18.
    European Commission: Unleashing the Potential of Cloud Computing in Europe (2012)Google Scholar
  19. 19.
    European Commission: Cybersecurity Strategy of the European Union: An Open, Safe and Secure Cyberspace (2013)Google Scholar
  20. 20.
    European Commission: Directive on Network and Information Security (2013)Google Scholar
  21. 21.
    Jansen, W., Grance, T.: Guidelines on Security and Privacy in Public Cloud Computing, NIST SP 800–144 (2011)Google Scholar
  22. 22.
    CNIL: Recommendations for Companies Planning to Use Cloud Computing Services, Commission nationale de l’informatique et des libertés (2012)Google Scholar
  23. 23.
    Catteddu, D., Hogben, G. (eds.): Cloud Computing: Benefits, Risks and Recommendations for Information Security. ENISA Report (2009)Google Scholar
  24. 24.
    Bovens, M.: Analysing and assessing accountability: A conceptual framework. Eur. Law J. 13(4), 447–468 (2007)CrossRefMathSciNetGoogle Scholar
  25. 25.
    Bovens, M.: Two concepts of accountability: accountability as a virtue and as a mechanism. Spec. Issue Account. Eur. Gov. West Eur. Politics 33(5), 946–967 (2010)CrossRefGoogle Scholar
  26. 26.
    Pearson, S.: On the relationship between the different methods to address privacy issues in the cloud. In: Meersman, R., Panetto, H., Dillon, T., Eder, J., Bellahsene, Z., Ritter, N., De Leenheer, P., Dou, D. (eds.) ODBASE 2013. LNCS, vol. 8185, pp. 414–433. Springer, Heidelberg (2013)CrossRefGoogle Scholar
  27. 27.
    Butin, D., Chicote, M., Le Métayer, D.: Strong accountability: beyond vague promises. In: Gutwirth, S., Leenes, R., De Hert, P. (eds.) Reloading Data Protection: Multidisciplinary In-sights and Contemporary Challenges, pp. 343–369. Springer, Netherlands (2014)CrossRefGoogle Scholar
  28. 28.
    Van Alsenoy, B.: Allocating responsibility among controllers, processors, and “everything in between”: the definition of actors and roles in Directive 95/46/EC. Comput. Law Secur. Rev. 28(1), 25–43 (2012)CrossRefGoogle Scholar
  29. 29.
    Guagnin, D., Hempel, L., Ilten, C.: Bridging the gap: We need to get together. In: Guagnin, D., et al. (eds.) Managing Privacy through Accountability, pp. 102–124. Palgrave (2012)Google Scholar
  30. 30.
    Liu, F., et al.: NIST Cloud Computing Reference Architecture. National Institute of Standards and Technology, NIST Special Publication 500-292 (2011)Google Scholar
  31. 31.
    Jaatun, M.G., Pearson, S., Gittler, F., Leenes, R.: Towards strong accountability for cloud service providers. In: 2014 IEEE 6th International Conference on Cloud Computing Technology and Science (CloudCom 2014). IEEE (2014)Google Scholar
  32. 32.
    Bowker, G.C., Star, S.L.: Sorting Things Out: Classification and Its Consequences. The MIT Press, Cambridge (1999)Google Scholar
  33. 33.
    CSA: Privacy Level Agreement Outline for the Sale of Cloud Services in the European Union. Cloud Security Alliance, Privacy Level Agreement Working Group (2013)Google Scholar
  34. 34.
    Knode, R., Egan, D.: Digital Trust in the Cloud: A Precis for the CloudTrust Protocol, v2.0. Computer Science Corporation (2010)Google Scholar
  35. 35.
    Baldwin, A., Pym, D., Shiu, S.: Enterprise information risk management: Dealing with cloud computing. In: Pearson, S., Yee, G. (eds.) Privacy and Security for Cloud Computing. Springer, Heidelberg (2013)Google Scholar
  36. 36.
    Reed, C.: Cloud Governance: The Way Forward. In: Millard, C. (ed.) Cloud Computing Law. Oxford University Press, Oxford (2013)Google Scholar
  37. 37.
    Bowen, P., Hash, J., Wilson, M.: Information Security Handbook: A Guide for Managers. National Institute of Standards and Technology, NIST Special Publication 800–100 (2006)Google Scholar
  38. 38.
    De Clercq, J., et al.: The HP Security Handbook. HP publication 4AA1-7729EEW (2008)Google Scholar
  39. 39.
    CSA: The Notorious Nine: Cloud Computing Top Threats in 2013. Cloud Security Alliance, Top Threats Working Group (2013)Google Scholar
  40. 40.
    CSA: Top Ten Big Data Security and Privacy Challenges. Cloud Security Alliance (2012)Google Scholar
  41. 41.
    CSA: Security Guidance for Critical Areas of Focus in Cloud Computing V3.0, Cloud Security Alliance (2011)Google Scholar
  42. 42.
    ENISA: ENISA Threat Landscape 2013 – Overview of current and emerging cyber-threats. European Network and Information Security Agency (2013)Google Scholar
  43. 43.
    Article 29 Data Protection Working Party: Statement on the role of a risk-based approach in data protection legal frameworks, 14/EN WP 218 (2014)Google Scholar
  44. 44.
    CIPL: A Risk-based Approach to Privacy: Improving Effectiveness in Practice. Centre for Information Policy Leadership (2014)Google Scholar
  45. 45.
    Office of the Information and Privacy Commissioner of Alberta, Office of the Privacy Commissioner of Canada, Office of the Information and Privacy Commissioner for British Colombia: Getting Accountability Right with a Privacy Management Program (2012)Google Scholar
  46. 46.
    ENISA: Privacy, Accountability and Trust – Challenges and Opportunities. European Network and Information Security Agency (2011)Google Scholar
  47. 47.
    Pearson, S.: Privacy management in global organisations. In: De Decker, B., Chadwick, D.W. (eds.) CMS 2012. LNCS, vol. 7394, pp. 217–237. Springer, Heidelberg (2012)CrossRefGoogle Scholar
  48. 48.
    Tancock, D., Pearson, S., Charlesworth, A.: Analysis of privacy impact assessments within major jurisdictions. In: Proceedings of the 2010 Eighth Annual International Conference on Privacy Security and Trust (PST), pp. 118–125. IEEE (2010)Google Scholar
  49. 49.
    Trilateral Research & Consulting: Privacy Impact Assessment and Risk Management. UK Information Commissioner’s Office (ICO) (2013)Google Scholar
  50. 50.
    ICO: Data Protection Act – Conducting privacy impact assessments code of practice. UK Information Commissioner’s Office (ICO) (2013)Google Scholar
  51. 51.
    Pearson, S., Sander, T.: A decision support system for privacy compliance. In: Gupta, M., Walp, J., Sharman, R. (eds.) Data Mining: Concepts, Methodologies, Tools, and Applications, pp. 1496–1518. IGI Global, New York (2013)CrossRefGoogle Scholar
  52. 52.
    Lloyd’s: Lloyd’s 360° Risk Insight Managing Digital Risk: Trends, Issues and Implications for Business (2010)Google Scholar
  53. 53.
    Boyens, J., et al.: Supply Chain Risk Management: Practices for Federal Information Systems and Organizations, pp. 800–161. NIST Special Publication (2013)Google Scholar
  54. 54.
    Robinson, N., et al.: Review of the European Data Protection Directive. RAND Europe, Cambridge (2009)Google Scholar
  55. 55.
    Bennett, C.J., Raab, C.D.: The Governance of Privacy: Policy Instruments in Global Perspective. The MIT Press, Cambridge (2006)Google Scholar
  56. 56.
    Pearson, S.: Privacy, security and trust in cloud computing. In: Pearson, S., Yee, G. (eds.) Privacy and Security for Cloud Computing, Computer Communications and Networks, pp. 3–42. Springer, Heidelberg (2013)Google Scholar
  57. 57.
    Schiffman, J., et al.: Cloud Verifier: Verifiable Auditing Service for IaaS Clouds. In: IEEE Ninth World Congress on Services (SERVICES 2013), pp. 239–246, IEEE Computer Society (2013)Google Scholar
  58. 58.
    CSA: Cloud Control Matrix. Cloud Security Alliance, CSA CCM v3.0 (2013)Google Scholar
  59. 59.
    Felici, M., Pearson, S.: Accountability, risk, and trust in cloud services: Towards an accountability-based approach to risk and trust governance. In: 2014 IEEE World Congress on Services (SERVICES), pp. 105–112. IEEE (2014)Google Scholar
  60. 60.
    Coudert, F.: Accountable surveillance practices: Is the EU moving in the right direction? In: Preneel, B., Ikonomou, D. (eds.) APF 2014. LNCS, vol. 8450, pp. 70–85. Springer, Heidelberg (2014)CrossRefGoogle Scholar
  61. 61.
    Antignac, T., Le Métayer, D.: Privacy by design: From technologies to architectures. In: Preneel, B., Ikonomou, D. (eds.) APF 2014. LNCS, vol. 8450, pp. 1–17. Springer, Heidelberg (2014)CrossRefGoogle Scholar
  62. 62.
    Sunyaev, A., Schneider, S.: Cloud services certification. Commun. ACM 56(2), 33–36 (2013). ACMCrossRefGoogle Scholar
  63. 63.
    CSA: CSA STAR – Security, Trust and Assurance Registry (STAR) Overview. Cloud Security Alliance (2014)Google Scholar
  64. 64.
    Anisetti, M., et al.: A test-based security certification scheme for web services. ACM Trans. Web (TWEB) 7(2), 1–41 (2013). Article 5, ACMCrossRefGoogle Scholar

Copyright information

© Springer International Publishing Switzerland 2015

Authors and Affiliations

  1. 1.Security and Cloud LabHewlett-Packard LaboratoriesBristolUK

Personalised recommendations