## 2 The Framework
### Rationale and Summary
#### 2.1.5 The Inner Works  
This aspect of the framework is designed to control changes on the overall architecture of adopters. This is the reason why a change management perspective is adopted. In order to do so, the authors adopted the approach proposed by Information Technology Infrastructure Library (ITIL) [46]. This approach ensures that changes are registered, scheduled, and managed in an efficient way and with controlled risk. The main steps in the ITIL change process are illustrated in Figure 3:  
Figure 3: Change management process adapted from Information Technology Infrastructure Library (ITIL). From the generic process defined by ITIL [46], the authors added the following steps in the review, assessment, and evaluation. To do so, the following steps are defined:  
1. Identifying the significant information and procedures as main assets of the organization. 2. Identifying the secondary assets for the association along with metrics (inheritance). 3. Description of security requirements for reflected information in cloud computing as well as the definition of total risk according to the potential harm and possibility. 4. Present status: Measures that already existed. 5. Assessment of risk of current measures and of reflected alteration (total risk). 6. Steps remaining and new measures or controls. Once the process is defined, the next step is to define the protection requirements categories. The aim of these requirements is to decide for the affected data which protection requirements of the data presents in terms of availability, confidentiality, and integrity. Protection requirements are not easily quantifiable. Therefore, we divided the protection requirements into three qualitative categories as follows:  
* Low. The effect of possible damage or harm is partial and foreseeable. * Medium. The effect of possible damage or harm may be substantial. * High. The effect of possible damage or harm may be of disastrous extents, which could intimidate the very existence of the organization. The next step is the definition of damage areas to consider in each protection requirement:  
* Legal: Disruptions of rules, guidelines, or agreements. Damage of the right to informational self-determination. * Organizational/processual: Damaged ability to carry out the ongoing tasks, damage of business processes or activities, physical harm. * Technical: Removal of a certain technology from the accepted assets list due to compromised security. * Cultural: Negative external or internal impacts, cultural confusions. * Financial penalties. These categories (apart from the \"financial\" that can be considered as generic) correspond to the categories defined as subject field areas of the proposed framework. Table 1 presents a decision support tool to clarify the different damage areas combined with the different categories. \begin{table}
\begin{tabular}{c c c c} \hline \hline  & **Low** & **Medium** & **High** \\ \hline \multirow{4}{*}{Legal} & Disruptions of guidelines and rules with slight consequences (slight breaks of agreement which result in at most inconsiderable contractual consequences). & Disruptions of guidelines and rules with considerable consequences (major breaks of agreement with high contract with disastrous damage liabilities). \\  & Damage with no or few effects on business purposes, customers, or business partners. & Damage of the ability to carry out the tasks, so one or more business purposes will not succeed and there is a negative impact on customers and business partners. & Damage of the ability to carry out tasks was evaluated as unbearable and one or more major business purposes will not succeed and long term negative effects on customers and business partners. & Damage of the ability to carry out tasks was evaluated as unbearable and one or more major business purposes will not succeed and long term negative effects on customers and business partners. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Damage areas and categories: Examples.