4.1.4 Summary of Core Properties

From the analysis above, we can identify what an account should include. An account can perhaps best be defined, though simply, as a report or description of an event. This means that an account should have a story or narrative that can be easily understood. This account or report can be presented at any time, not just when there has been a system failure. The report or description should sometimes include reasons or explanations, for example, if the event should not have occurred. It should sometimes also explain consequences, for example, what action will be taken to remedy a situation or what action will be taken in the future. It may also include justifications for actions taken or for omissions.

In light of the foregoing, an account, when required and/or provided, usually consists of the accountable actor providing a report or description of an event or process. The account should generally include the answers to what are traditionally referred to as the reporters questions, i.e. who, what, where, when, why and how. Often, an account will also include the measures being taken to remedy a breach or failure. Still, the form and content of the account are contextually dependent and may be specifically dictated under the specific circumstances. Forms of the account may include Data Protection Impact Assessments, notifications to supervisory authorities, notifications to data subjects, contractual compliance verifications, audit reports, and even certifications and seals obtained by data controllers and/or data processors from third party certification agencies such as Cloud Security Alliance.

Applying these principles in practice perhaps best demonstrates the notion of the account and what would be encompassed in an actual account. In sections 4.3 and 4.4, examples of giving an account are considered further.