4.1.1 General Concepts

The form and content of accounts are contextually dependent. In this section, the varying properties of accounts are considered.

4.1.1.1 What is an account?

An account is a report or description that may be written and/or oral, of an event or process. It serves to report what happened, what has happened, or what might happen. An account generally contains answers to the reporters questions, i.e. who, what, where, when and why. It may also include measures taken to remedy prior failures. An account of the same event or process might be provided several times and vary in its format and information depending on the recipient.

4.1.1.2 Example

An example where accounts are needed is data breach notification. In this case, the following information should be provided:

• To explain who committed the breach (or if unknown, how investigation to discover perpetrator)
• What the breach consisted of
• When the breach occurred (and was discovered if different dates)
• How and why it occurred, extent of breach
• What measures are being taken to prevent any further such breaches in future
• Contact information for a department or person to respond to further questions (and maybe link to web page for updates)

4.1.1.3 Forms of account

There are two main forms of account: proactive or retrospective accounts.

Proactive accounts relate to r eports before making services available. Provision of an account could be proactive, in the sense that the choice of accountability mechanisms and tools needs to be justified to external parties, and this could happen before any processing takes place (perhaps as part of a third party assurance review), when processing is particularly risky (e.g. before such processing, with documentation generated via Data Protection Impact Assessments), or using ongoing certification to provide flexibility (for example, as is the case with Binding Corporate Rules).

Retrospective accounts are reactive and can either describe a l egitimate event - in which case they can be either periodic or produced upon request (e.g. triggered by a spot check by a regulator) or an unexpected event, such as a data protection breach.

Furthermore, an interesting distinction can be made between what may be regarded as static accounts, as opposed to dynamic accounts. The former do not vary over time, whereas the latter take into account parameters that may change over time. For instance, an example of a dynamic account would be a CSA Open Certification Framework (OCF) level 3 ^[20] account, which is an example of a dynamic certification. Indeed, it could be argued that yearly or monthly audits are irrelevant in an environment that changes completely on a daily or hourly basis, as is often the case with cloud computing. Continuous compliance monitoring is essential to securely delivering cloud services and ensuring compliance. Cloud services are inherently dynamic, because the dynamic provisioning and de-provisioning of resources is a key part of the cloud value proposition and business model. Hence, automation for operations and asset management are essential in this dynamic environment and verification of compliance with policy and legislation, such as the EU Data Protection Directive1995 (Directive 95/46/EC), Gramm-Leach-Bliley Act (GLBA) ^[21] , US federal Health Insurance Portability and Accountability Act (HIPAA) 1996, and export compliance controls like the International Traffic in Arms Regulations (ITAR) ^[22], requires continuously running automation. Accounts can be also regarded as a process, for example a process of storytelling and explanation, and further detail about that is given below, later in this section.

4.1.1.4 Attributes of the account

Although the description of the event or process is an essential element, the account should also carry the following attributes:

• Recipient: This is the actor who receives the account. Depending on the recipient, the level of detail in the description of the event may change.
• Event/Process description
• Evidence: Relevant information to support explanation and justification about assertions (for further discussion see section 5.2.4).
• Measures for remediation (if incident)
• Timestamp and signature: The accountable organisation is of course responsible for producing the account and therefore should sign the entire report including the date. Accounts of legitimate events may be periodic and could sometimes be used as evidence for prior events whenever an incident happens in the future. A timestamp in the report hence becomes mandatory.