Selection criteria for privacy controls
The selection of appropriate privacy controls is an unstructured process that has to balance several factors. Controls are different in their risk treatment, in the cost they impose, in their compatibility with administrative procedures and in many other parameters. The privacy officer, the risk manager, the business process owner and the technical experts should choose, evaluate and device upon the appropriate controls for risks.
Figure 1 below shows the seven factors that the selection of controls has to take into consideration.
Figure 1: Selection criteria for controls.
The following sections will describe those factors.
Risk treatment
Privacy controls will vary in their particular approach to risk treatment. Some may deploy PETs, others may minimize the collection of risky personal data, yet others may install safety procedures. A clear understanding of how the risk is mitigated by the control, and how the overall impact of a data breach will be reduced by the control should get assessed under control evaluation.
Availability in particular context
Privacy controls may not be available in certain contexts. Technological solutions may be restricted from being used in certain countries due to export control regimes. Location may restrict remote access to data. Other situations may require certified and security-cleared systems and staff - which may or may not be available for a particular control. When evaluating candidate controls, a thorough understanding of the application contexts of the control is necessary. You should, in addition, consider the consequences of changes to the business model that may change the context and use environment of the control in the near and medium future.
Budget limitations
Controls come at different cost. Besides direct licensing, controls have a cost of operation, a cost of maintenance and possible additional cost for more complex overall system handling. The total cost of ownership of deploying and maintaining particular privacy controls should be assessed.
Goal conflicts
Controls may cause goal conflicts with other important features or requirements of the system or the processes they get applied to. Controls for data minimization, anonymization or encryption may, for example, violate archiving requirements, public transparency laws or other internal requirements. Therefore, the conflicts that a control may cause with respect to other system goals than data protection should get analyzed before deployment.
Effectivity and efficiency
Controls will be of different effectiveness in mitigating risks, while at the same time mitigating the risk with varying degrees of efficiency. Proven controls should provide information about both the effect and the efficiency. However, as shown in this chapter, those parameters are widely unknown as of today.
Technical feasibility
Technical privacy controls may or may not be available for particular technical contexts. Operating system variations, programming languages, availability of portable source code in suitable programming languages and system demands may make particular controls unusable for a particular component. The technical managers, operators and developers should inspect such controls before decisions are made about these.
Procedural feasibility
Some controls are by their structure not compatible with the existing administrative processes of the application, of the IT department or of other units involved in processes with identified risks. Risk managers will therefore, in collaboration with the business process owner and possibly other managers, discuss the aligment of privacy controls with the existing procedures and processes the control will get deployed into.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.