Executive Summary and Reading Guide

The goal of the Cloud Accountability Reference Architecture is to provide an abstract but powerful model for designing accountability in modern cloud and future Internet ecosystems. It is an essential step towards addressing the requirements of target stakeholders by defining the architectural vision and capabilities and delivering a roadmap to implement such requirements in specific cases, aligned with selected business goals.

The context of our work is the cloud, with its associated ecosystem of customers, providers, auditors and regulators. Whilst we often refer to accountability in the context of data protection, our aim is to design an architecture which is agnostic of the particular domain of accountability.

Hence, we adopt a definition of accountability which can be applied to most enterprise operations, and most notably to information technology (IT)-supported functions, namely that:

accountability is the state of

• accepting allocated responsibilities,
• explaining and demonstrating compliance to stakeholders and
• remedying any failure to act properly;

where these responsibilities may be derived from

• law,
• social norms,
• agreements,
• organisational values and
• ethical obligations.

This document builds on the concepts and models developed in the Cloud Accountability Conceptual Framework ^[1], and most notably develops the mechanisms which provide the means to implement and deploy the practices specified in the accountability model shown in Figure 1 below (which provides an overview of the concept of accountability at different levels of abstraction):

Figure 1: The A4Cloud accountability model.

We have identified six key groups of practices which must be addressed by accountable organisations, shown in Figure 2, where these are mapped onto an Accountability Lifecycle.

Figure 2: Accountability Lifecycle and Practices.

This lifecycle, presented in more detail in section 3, addresses both the governance programme of the organisation (Govern and Program Office elements), as well as the lifecycle for the services or applications to be developed (which comprises Analyse and Design, Operate, Handle Exceptions, and Audit and Validate phases).

We provide a Reference Framework that clarifies the functional elements and mechanisms of accountability. Figure 3 shows this information captured in an integrated diagram.

Figure 3: The accountability reference framework

We discuss the elements of this framework throughout the document, building progressively towards the full picture.  We start in section 2, by addressing how accountability applies to the cloud, focusing our analysis on the actors and how they interact. In section 2.4 we identify the various accountability artifacts which are exchanged between actors across the cloud provisioning chain.

In section 3, we shift our focus to the organisations that will be accountable to other stakeholders. After defining the lifecycle, we identify a series of process groups that map to this lifecycle. We are offering practical guidance to organisations that want to behave in an accountable manner at three different levels of abstraction:

• A set of principles for accountable behaviour, which we have designed specifically for use by small and medium sized organisations (SMEs) which do not have the organisational structure to adopt the more detailed recommendations
• A simplified control framework specific to accountable organisations, which leverages existing control frameworks to specifically address accountability
• A series of best practices which provide practical guidance about the governance and processes that accountable organisations need to deploy. This list can also be used in case of questions in the interpretation of the control framework

In section 4, we focus our attention on the various aspects of demonstrating accountability. We provide an in-depth analysis of the account, which is the core instrument to demonstrate accountability. An account is a report or description, which may be written and/or oral, of an event or process. It serves to report what happened, what has happened, or what might happen. It is produced on a schedule, on request, or as an answer to specific questions. Accounts are produced at various points of the service lifecycle: as a companion to service descriptions for the prospective customer, to communicate audit results and system state to existing customers, and to report on the handling of failures to continuously meet obligations. Accounts are primarily intended for customers and for auditors mandated by regulators, depending on the situation.

We also address other methods to complement the account when demonstrating accountability, either in a very dynamic context (section 4.6 on Metrics and Evidence) or being more effective in the use of resources (section 4.7 on Certifications and Continuous Compliance). The Accountability Maturity Model we present in section 4.8 focuses on capturing both the maturity of individual organisations in terms of accountability practices, as well as a measurement of the appropriateness of the measures used across the whole cloud provisioning chains, as a way to aid organisations (in particular, SMEs) to quantitatively assess their accountability practices as a first step to improving them.

Finally, in section 5, we propose a set of cloud accountability support services that are designed to offer an automated accountability interface to process the artifacts identified above.

Note to the Reader

We have structured the Cloud Accountability Reference Architecture document so that it offers two reading levels:

• CORE: central material that provides enough detail to obtain a general understanding of the Reference Architecture

• DETAILS: additional information that allows a deeper understanding of the selected topics

The Cloud Accountability Reference Architecture is structured to be accessed through a web interface, the PDF version being offered as a convenient option for those who prefer this medium.