2.4 Flow of Accountability Information

As discussed in the previous section, control domains may be formed due to a combination of architectural, technical, organisational and economic reasons. A pragmatic approach to extending accountability beyond domain boundaries must reflect the way that clouds and cloud services are architected and operated, and thus focus on enabling the various domains to exchange the information necessary to establish, evaluate and exercise accountability while maintaining their structural separation.

At the highest level, the exchange of accountability-supporting information between two accountable ^[7] actors ^[8] in the cloud provisioning chain may be viewed as supporting one of two purposes: the communication of the service consumers objectives to the service provider as they pertain to the handling of data as part of the service provided and, in response, the provision of assurance that those objectives are appropriately met by the provider to the consumer. Figure 7 below illustrates this concept.

Figure 7: Exchange of accountability-supporting information between two actors.

The communication of objectives and provision of assurance encompass a number of different processes which result in the generation of various types of accountability-related information, called accountability artifacts. It is the exchange of these accountability artifacts over organisational boundaries at various phases of the service lifecycle that facilitates the establishment (and continuous evaluation) of accountability between actors. Figure 8 presents the full list of accountability artifacts.

Figure 8: Accountability artifacts.

Objectives describe the high-level goals an organisation wishes to achieve through the use of an IT service. These objectives express the business (i.e. functional) needs of the organisation as a prospective cloud customer and may also contain elicited preferences of the cloud subjects it represents. Before a particular service is procured from the cloud, the prospective cloud customer needs to refine and reformulate these objectives so that they clearly capture its privacy and security requirements for the service. These requirements will encompass any requirements stemming from law and regulation, such as limitations on how personal data are collected and handled. The formulation and compilation of these requirements is part of the "analyse and design" phase of the accountability process lifecycle described in section 3.2, and comprises the necessary first step towards defining the scope for accountability in the sought-after service relationship. These requirements are (implicitly or explicitly) communicated to the selected cloud provider ^[9] as part of the service procurement process.

The cloud provider has requirements of its own, stemming from how its business operates and the constraints it has itself from law and regulation. These requirements inform the providers service specification, which may be published in various forms ranging from documents outlining terms and conditions to machine-readable service description documents. In an accountability-based approach the process of publishing a cloud providers service specification takes a more prominent role. The cloud provider is expected to advertise the capabilities of the service it offers with regards to handling of data, including providing information about what security and privacy controls it offers, what mechanisms it has deployed internally to preserve the security and privacy characteristics of the data as well as any certifications or other documents supporting these assertions. The advertisement of these capabilities comprises the first accountability artifact to be produced, which supports the service procurement phase between a customer and a provider of cloud services.

Cloud providers are, like all organisations, required to comply with applicable laws and regulations. Accountable cloud providers additionally commit to moral obligations dictating responsible behaviour. Most, but not all, of these obligations can be, and to the extent possible should be, documented and provided to the cloud customers, under the form of the social and regulatory norms artifact.

Typically, if the procurement process deems that the cloud customers requirements are compatible to the cloud providers service description (capabilities), a contract is formed between the two parties describing the service agreement and responsibilities of each party to the other. Service and Privacy Level Agreements (SLAs and PLAs respectively) are particular forms of such contracts or may be produced to supplement a general contract to more precisely define particular aspects of the service. Contracts, SLAs and PLAs collectively comprise the third type of accountability artifact. In an accountability-based approach this step is particularly important because it is where the cloud providers obligations to the customer are defined and agreed upon with regards to the handling of data.

The agreed obligations at this stage may be expressed in a variety of forms, with natural language being the most common. These obligations need to be translated into specific policies to be enforced by the cloud provider. This necessitates a procedure for the translation of obligations into machine-readable policies that can be automatically monitored and enforced so that all handling of data is performed as per the agreed set of obligations. These (enforceable) policies comprise the fourth type of accountability artifact that must be generated. Machine-readable accountability policies may describe operations more verbosely or at a more granular level compared to obligations and their exact form may depend on the architecture and implementation specifics of the service provided.

During the operation of the cloud service, various elements of it will access, process or otherwise handle personal data at some capacity. While regular operations may be expected to handle the data as prescribed by the relevant policies, an accountability-based approach requires the explicit provision of evidence to demonstrate compliance and meeting of obligations. Furthermore, information on the internal workings of the service, such as machine-generated logs, may need to be provided for the purposes of auditing or to support transparency reports. Both machine-generated logs and evidence records are thus important accountability artifacts that need to be generated and exchanged between different actors ^[10]. In addition, as discussed in section 4.2, the evidence collection process drives the development of the account, which is the principal means for supporting accountability at various phases of the accountability governance lifecycle in its own right.

While logs and evidence provide information about discrete actions and events that took place at specific instances during the operation of the service, the provider must also demonstrate how well it is meeting various accountability-related criteria during the continuous operation of the service, as these are determined by its stated obligations. The assessment of a providers performance with respect to such criteria is performed through the measurement of service-specific subjective and objective metrics over defined periods of time. The provision of metrics to enable the evaluation of how well a provider meets various accountability-related criteria thus comprises another important accountability artifact.

If during service provision an incident occurs or otherwise a failure to meet the agreed obligations is detected, the cloud provider must notify the affected parties, take steps to remedy the problem, and potentially offer redress. Thus, the construction of the notification report comprises an essential accountability artifact, containing besides a description of the incident, information on corrective actions or the proper remedial steps that have been taken.

When incidents occur or policy violations are detected, accountable service providers are expected to take steps to remedy their effects, and where appropriate offer redress. Affected parties must be given a mechanism to formulate claims in the form of artifacts and transmit them to the service provider for evaluation and processing in the context of the remediation and redress mechanisms.

There may be cases where remediation and redress cannot be fully handled by the particular service provider, either because the necessary process is such that it needs to be handled by third parties or because the liability involved is such that the provider cannot cover it on their own. In cases like these insurance can be a vital instrument to manage risk and offer additional assurance, even if it is not a compulsory requirement as it is in many industries and activities. Insurance is therefore another artifact that can be provided to establish and evaluate the accountability of a particular actor.

It is also important for the provider to demonstrate global compliance to best practice standards. This is typically achieved through an auditing process, which usually involves external auditors. The auditors produce detailed audit reports which are mostly used internally. The auditors also deliver more concise, summary-level assessments of the performance of the provider. The provider may also elect to be certified (or attested) against formal criteria defined in e.g. Cloud Security Alliance (CSA) Star Certification or Attestation [7]. These documents have historically been issued as paper reports, but are increasingly delivered as structured electronic documents protected against tampering.

Last but not least, the provider creates accounts to report on the state of what it is accountable for to stakeholders. In the case of interactions between the regulator and the data controller during an investigation, multiple accounts are created at the data controller level. Some accounts are oral ones (e.g. meetings with a data protection authority (DPA)) and others are written ones (e.g. document provision to the DPA or response to an investigation questionnaire). In cases of written accounts, they are produced by various teams (e.g. operations, public policy, security, engineering, advertising, platform etc.) and these are then aggregated by one senior (usually legal) officer to ensure that there are no inconsistencies between them and that all queries have been answered. These different accounts are then passed on to the DPA. The latter may come back with queries or requests for clarifications which are initially sent to the legal officer of the data controller who then passes it on to the relevant team who actions it.

In general, accounts can be in oral or written form, provided according to a schedule, on request or to answer specific questions, and are principally provided to customers, auditors, and regulators, at various phases of the lifecycle. Sections 4.1 to 4.5 present further details and an extensive analysis of the account.

Table 2 provides a summary of the various types of accountability artifacts discussed.

Table 2: Accountability artifacts.

[7] An organisation or actor defined as “accountable” hereafter is one that has implemented the accountability process described in section 3.

[8] For the list of actors and roles identified in the RA, see section 2.1.

[9] To avoid unnecessarily complicating this example, we describe a process between two parties, a single cloud customer and a single cloud provider, which results in a straightforward agreement. Obviously, while searching the market for the most appropriate service offering, the cloud customer may engage with multiple providers in parallel, expressing its requirements to each of them and evaluating all responses before selecting one. Additionally, it may engage in negotiation of terms, which will imply a number of out-of-band iterations before agreement is reached. These actions do not affect the ultimate outcome of this process, which is the acceptance of agreed obligations by the provider.

[10] Although in many cases evidence may include machine-generated logs, they can have different uses as well as different requirements for creation and handling. As such we consider them as two distinct classes of artifacts.