3.4.3 Provisioning for Accountability - Analyse and Design

By its very nature, accountability identifies and addresses potential risks, harms and expectations there would be no need for accountability if one could provide a total and absolute guarantee that all these obligations would be met. Designing for accountability is therefore naturally associated with the lifecycle dealing with security, data protection, and risk. There are many variants for this lifecycle we will use the pragmatic model described in [16].

The main activities involved in this analysis and design phase are to:

• Understand the product or service and related assets
  • Have a description of the functionality and associated non-functional requirements
  • Inventory the (related) obligations for which the organisation will be accountable
  • Inventory the assets related to the functionality and obligations
  • Perform an impact assessment for these assets in order to qualify the risk
  • Keep and update a record of assets and impacts

• Perform a risk analysis
  • Identify the position of the board and executive management
  • Perform a risk analysis – in regards to accountability, this should focus on obligations and the contributing factors, as well as on the accountability support system. The nature of the obligations will influence this greatly. In the case of obligations regarding the handling of personal data, for example, the risk analysis must include an analysis of the potential harm to data subjects (which is not something usually included within a traditional organisational security risk analysis). The risk analysis must take in consideration all aspects impacting the organisation, including secondary impacts such as a loss of reputation, product or service implementation, slow down, regulator push back, and so on.
  • Keep and update the record of threats and vulnerabilities, qualified with probability and impact. Associate this record with the record of assets and impacts.

Risk analysis is a complex process for which many methodologies and software support exist for traditional security related domains. Risk analysis related to accountability is only a part of the overall risk analysis process but there are few existing tools and practices for that part. As mentioned above, extensions to this process are needed for the domain area (i.e. to consider data privacy, security, etc.), whereby tools and methodologies already developed for those areas (such as Privacy Impact Assessments) may be used, and ideally integrated at several points within the design lifecycle.

• Define the risk treatment
  • Define how risk will be handled as part of the investigation, design and engineering phases for the product or service
  • For each risk, identify if it will be reduced, mitigated, assigned, transferred, or accepted. The residual risk must be understood and treated in a recursive manner until the constraints associated with the obligations are met (typically, the residual risk in the last iteration will be transferred or accepted).
  • Define the controls which will be deployed to reduce or mitigate each risk, and define how the risk will be assigned or transferred, as appropriate. These controls can be based on a mixture of technology and processes^[14]. In this latter case, a link must be established with the inventory and operational programs defined at the global level for the organisation (see in particular sections 3.4.2 and 3.4.5).
  • Define the metrics and dashboard for continuous monitoring of the state and effectiveness of the risk treatment plan.
  • Augment the above record of threats and vulnerabilities with the record of risk treatment and associated measures. Include all steps in the recursive treatment of residual risk.
  • Validate that the risk analysis takes into consideration the selected implementation decisions. Update it as necessary.
  • Ensure that the accountability mechanisms are tested as part of the solution testing (in both regression and system tests). Validate the effectiveness of the measures.

This step is tightly integrated with the solution design and engineering phase, and is recursive by nature as each implementation alternative has an impact on risk. The information obtained in this process provides the foundation for signoff and the creation of the first account.

The result of this phase will be the definition of a technical solution to implement the solution or offering. The technical or procedural controls implemented correspond to a due-diligence and best effort coverage of the requirements. It is in general impossible to guarantee that the mechanisms and procedures effectively deployed guarantee that the obligations will be met. The accountability system must be able to handle the unexpected.

• Select 3^rd party providers

  Special attention must be given the selection of 3^rd party providers. We will focus on the selection of cloud services. This section leverages the recommendations made in [20] and [11], but those have been considerably modified to address accountability in general as opposed to just data protection regulation.

  When selecting a cloud provider, the accountable organisation must:

  • Identify assets which will be processed or stored in the cloud environment.
  • Identify the related obligations and associated accountability requirements.
  • Based on the initial risk analysis, identify the risk profile of the provider, the set of security (and other relevant attributes) that must be supported.
  • Identify the links between the third-party accountability provisions and the accountability system of the organisation – list the associated requirements.
  • Based on compliance obligations, identify the certifications and other levels of guarantees that must be offered by the provider (most often including local constraints relating to the data centre and the IT staff).
  • Check internal policies and procedures in terms of selection, registration, and tracking of third party service providers. Comply once the provider is selected.
  • Review and select the provider based on a review of the offerings matching the above requirements. Validate that the costs are in line with funding expectations. Review the risk appetite and risk treatment plans if there is a gap. The practice of increasing the levels of risk acceptance to meet the cost expectation should be banned.
  • Ensure that proper contractual clauses are in place, especially as in regards to compliance to the requirements and the associated accountability measures. The contracts must be handled as per organisational policies (see section 3.4.2).
  • Ensure the provider exploits the data only as intended and defined by the Data Controller.
  • Exploitation for the benefit of the provider should be avoided, but if envisaged it must be carefully defined by contract, and its consequences (including liabilities, the Data Controller role and relevant obligations) must be clearly understood by the organisation and be compliant with the allowable use of the data and legal requirements.
  • Identify the metrics that will be used during the lifetime of the relationship to continuously assess the compliance of the 3^rd party.
  • Track changes in the service provider operations.
  • Ensure there is an adequate link between the provider exception handling processes and those of the organisation (see section 3.4.5). The associated procedures must be tested regularly and readiness assessments must be performed.

• Provide documentation and signoff
• The solution must be fully documented and placed under change management. Any evolution must be assessed against the requirement, obligations, and risks, and necessary adjustments must be performed.
• The contracts associated with the solution must reflect what is actually implemented.
• An account reflecting the analysis linking obligations with actual controls must be produced and made available to stakeholders. This account is to demonstrate, through a static analysis, the effectiveness of the controls as due-diligence to meet the obligations.
• The solution must go through a signoff process that will validate that all internal requirements and obligations have been met.

[14] For example, the use of Privacy Enhancing Technologies (PETs) should be seriously considered as a way of mitigating privacy risks. Privacy by design is in general an important aspect of this accountability design process; the latter does not replace it, but augments it.