4.3 [DETAILS] Accounts Relating to Compliance
While an account is usually expected and more useful in the event of security breach or policy violation, an accountor, i.e. the organisation acting as a data steward, may report on events or operations that have taken place in accordance with pre-defined rules. For example, the process for providing information on the use of third parties in the cloud service chain is not adequately addressed in current practices, resulting in the bulk of end users not being aware of the complete cloud service delivery chain and their rights over data handling processes. In DB3.2 [31], several different obligations on informing different actors (Data Subjects or DPAs) about data processing practices have been enumerated (O1-O4, O13, O16).
Therefore, an account relating to compliance should demonstrate that the accountor fulfils the expected requirements regarding data processing practices usually defined through the obligations expressed in policies or in law. Such a report should generally describe the event in question and include the following information:
- involved actor(s): the account should list all relevant actors who were involved in the event;
- list of actions with time and location information: the report should describe all relevant actions taken with respect to the event to be reported. Such a description should include information about time and location.
- justification of the event: the account should describe the reason of the event. This usually refers to the identification of the policy rule or obligation for which the accountor should comply with,
- contact details of the person or group who is responsible for the event in case further information is needed or an unexpected problem occurs.
The description of the event should further be completed with some additional evidence in order to achieve a certain level of confidence, indeed, as also stated in [13], it is more difficult to fully demonstrate compliance than to report on a security breach. Therefore an account of compliance should regroup all appropriate evidence.
In [13], Nymity divides their proposed privacy compliance attestation methodology, into two main steps: identification of the rules that require appropriate evidence and further demonstration of accountability. We propose to follow the same approach and to enrich this methodology by providing examples of forms of account by regrouping a list of potential evidence with respect to specific obligations derived from D23.2 [31]. We will consider in particular three different types of account, relating to secure data deletion, correct data storage and data location.
Download the preliminary release of the Cloud Accountability Reference Architecture and the relevant A4Cloud Toolkit.