3.6 Implementing Accountability across the Cloud Provisioning Chain

Our report on the Cloud Accountability Conceptual Framework [1] and section 2.5 in this document discuss the complex service provisioning chains which are increasingly frequent in cloud ecosystems. This does not mean, however, that all actors along the provisioning chain have to be strongly accountable organisations and adopt the control objectives and best practices defined in this section. Some cloud providers along the chain may implement mitigating measures which remove (or reduce) the dependency on 3 ^rd-parties' high-grade quality of service (QoS) and ability to render account. For example, an intermediate SaaS service provider may use several IaaS 3 ^rd-party providers for redundancy and workload balancing, effectively removing the dependency on the continuity of any one of these service providers. This means that the SaaS provider can source cheaper IaaS services, from providers with lower quality of service (QoS) commitments and lesser-grade accountability standards. This is however only true to a degree we are in the domain of greater tolerance to risks, not of acceptance of careless behaviour; likewise we are referring to lesser-grade accountability, not elimination of accountability altogether. Furthermore, we cannot assume that the QoS requirements and level of accountability will become progressively lower across all branches of the provisioning chain the tolerance for lower-grade services can only be determined through a thorough analysis of the dependencies.

Long and complex provisioning chains pose another challenge for QoS and accountability: the numerous customer-provider interfaces in the chain correspond each to a separate service contract, often pre-existing, with its own set of obligations and reporting requirements. Seamless integration does not exist in this regard. This poses a challenge with regard to the true realisation of each of the four main attributes of accountability:

• Transparency: transparency is never absolute. Even if an organisation intends to be genuinely transparent, the processes used to put transparency in motion have limitations, in particular as insiders will have a good knowledge of the situation but have an (involuntarily) biased view, while outsiders equally have a bias, of another nature, and only a limited ability to obtain a true understanding of the situation. Cost, resource, time, and contractual constraints compound these issues.
• Responsiveness: input and queries from external stakeholders may not always be received directly by the party which it relates to, and have to be propagated through the provisioning chain, with a transformation at each step according to the context of the customer-provider relationship. This will slow down or ultimately decontextualize the input or query.
• Responsibility: responsibility is to be considered in the context of the norms, which are not uniform across the provisioning chain. This means that an agreement relating to responsibility may not keep its nature along the whole provisioning chain.
• Remediability: remediability, like responsibility, is defined in the context of the governing norms (to which an accountor is supposed to be compliant), which vary across the whole provisioning chain. While the main service provider (data controller) can provide remedy to affected parties, corrective actions are subject to the customer-provider interfaces along the provisioning chain.

One way to deal with the challenges induced by the provisioning chain is to take a holistic approach, which addresses globally all actors. One of these approaches is Service Integration and Management (SIAM), which finds its sources in ITIL® ^[19] and its community. The intent of SIAM corresponds to "the ability to manage the challenge of cross-functional, cross-process, cross-provider integration while finding an effective method for controlling this delivery environment and assuring value based outcomes for the customer" [21]. SIAM starts with understanding and enumerating the boundaries and dependencies between each of the services; and does not require the documentation of end-to-end transparent processes. SIAM is based on a three layer structure as depicted in Figure 13.

Figure 13: SIAM organisational layers and service modules (source: [21]).

While SIAM itself may be outsourced, this model presumes that all service providers integrate into SIAM. This means that service providers party to the clumps described above integrate with SIAM. As SIAM is based on the ITIL model, it means that each provider needs to operate in a manner compatible with an ITIL-based IT Service Management, and use a standardised approach to key processes, such as the exchange of service management information. The SIAM model recognises that some providers, most notably large commodity service providers, may not comply, and requires that the SIAM provider maps (translates) provider-specific information into the structure adopted by SIAM.

The SIAM approach provides a methodology for dealing with accountability in cloud provisioning chains. In an accountability-enabled SIAM, the analysis of boundaries and dependencies between services corresponds to the identification and distribution of responsibilities, which is the starting point of the accountability relationship between an accountor and its accountees. In this approach, each organisation must be accountable, and adopt the organisation-level control objectives and best practices (cf. sections 3.3 and 3.4).

SIAM is however not the ultimate solution as it requires that all all service providers integrate into the framework, something that can be mandated only by very large, institutional level actors like governments or similar entities. Only a few actors in the private sector have the purchasing power and competitive positioning to impose such a framework on all providers while remaining competitive. It seems likely that a solution based solely on regulations would not be adequate either due to the inherent dynamism and multi-jurisdictional nature of supply chains and long adaptation cycles of the regulation. A more promising approach could be in the adoption of industry-regulated sectorial compliance frameworks, which would practically translate into a requirement to only select providers which have adopted the compliance framework and been certified for it.