TOTAL: {[ getCartTotalCost() | currencyFilter ]} Update cart for total shopping_basket Checkout

The Privacy Advisor | Using NIST's risk management framework to conduct GDPR-compliant DPIAs Related reading: A view from Brussels: EDPS sends signal on data transfers 

rss_feed

""

""

What information is readily available about DPIAs?

Data protection impact assessments are obviously one of the key issues of the GDPR. Implementing a process for performing and adequately documenting state-of-art DPIAs is a necessary building block for a risk-based approach to privacy and to insure accountability in accordance with the GDPR principles.

Up to now, guidelines from WP29 (endorsed by EDPB) have been published, which provide a lot of insight on what are the DPIA triggers and how to assess the risk. Other WP29 guidelines, including ones about data protection officers, data breach notifications, or about individual decision making and profiling, significantly contribute to the discussion about how to assess the risk. Recently, a number of lists of operations where DPIAs are mandatory, and also some lists of operations where no DPIAs are needed, have been submitted by country supervisory authorities and have been evaluated by the EDPB, which should result in more or less similar approach across EU to privacy risks. 

All in all, there are many official resources to augment organizations and to educate them when it comes to formal requirements and the legal side of the process.

What information is not readily available or difficult to establish?

Well, after reading the WP29 guidelines it is pretty obvious, that although they provide a lot of information and some practical advice, you receive no recipe for how to design and develop your DPIA process and what methodology should be used when conducting DPIAs.

The DPIA process, as it has been perceived and as it is described in all available guidelines and resources, require strict and close interaction between privacy and security functions and controls. It means that having a privacy assessment on top of your security assessment is not enough as the whole process and analysis need to be driven from the very beginning by security and privacy considerations, security and privacy risks, and allow for the necessary controls being implemented to mitigate such risks.

Whereas WP29 guidelines and other available opinions and publications provide a lot of input for creating, e.g., checklists or forms to assess different types of risks and possible DPIA triggers, it is difficult to establish what should the process look like in practice and what methodology is needed to properly analyze privacy and security concerns. Such concerns and risks must at the end guide you through a process of choosing integrated privacy and security solutions commensurate with the level of risk. 

What solutions are available?

It seems that the most popular and widely available solution, which is, by the way, kind of officially recognized as it comes from the French supervisory authority, is the CNIL's privacy impact assessment software tool and CNIL's methodology behind it. The tool seems to be user friendly and easy to use, and the methodology looks to be well developed and explained.

Most importantly privacy and security are integrated into the process so that the outcome of the risk evaluation and risk mitigation analysis takes into consideration the real threats which may arise when using specific technologies and information systems. Different templates or forms can also be used together with or instead of the software tool as they also have the same methodology behind them.

For all of these reasons, any many more, organizations, especially smaller ones, tend to use the CNIL's solution, as it comes for free and is open source. However, there is also a catch or potential issue here.

The CNIL methodology uses EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité - Expression of Needs and Identification of Security Objectives), a method for analysis, evaluation and action on risks relating to information systems developed by the French government in 1995 and now supported by a club of experts. It is not to say that there is something wrong with this method, but still there are many global organizations who prefer to use other frameworks, as the Risk Management Framework from NIST. Naturally many methods and solutions could be used at the same time or interchangeably, but it will significantly add to the complexity of what is already very complicated.

How to use NIST's framework to support the GDPR DPIA process?

The RMF provides a process for managing security and privacy risk that includes information security categorization; control selection, implementation, and assessment; system and common control authorizations; and continuous monitoring. The RMF includes also activities to prepare organizations to execute the framework at appropriate risk management levels.

The process, as such, is flexible and should allow, with some adjustments, both for consideration of risk factors, as provided in The Working Party 29 guidelines, as well as to implement privacy controls in line with GDPR requirements instead of controls prescribed by U.S. federal laws which might be very different (e.g. when it comes to notice).

The seven steps in the RMF: prepare, categorize, select, implement, assess, authorize, monitor all support continuous risk management. This is in line with DPIA requirements, which must be considered under the GDPR not simply as a one-time activity but more as a lasting process where even the main reports and deliveries are not entirely final, as they need to be constantly monitored and updated throughout the project life-cycle.

Prudent advice would be to follow the criteria for an acceptable DPIA, provided at the end of the Article 29 guidelines on DPIAs, at all stages of the risk management process whenever one or more DPIA triggers have occurred (or reoccured as a result of changes to the project or its environment). It can take a form of checklists or forms, unless some software solution would be preferred. 

It is very difficult, if not impossible, to say that one or the other method or framework is perfect for conducting GDPR DPIAs. First of all, no such method or solution is provided directly by the EU authorities or has been officially recognized by relevant certifications (which by the way are also not available). Secondly, EU authorities tend to be not just technology neutral when it comes to the GDPR, but also when it comes to all sort of methods, operational solutions, routines or plans, which may be used for practical GDPR implementation efforts.

Having said that, it still worth noting that the most recent NIST Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy could be used by GDPR-aware security and privacy specialists in order to support the DPIA process and to implement privacy and security controls which would be in line with the GDPR principles and requirements. 

photo credit: mikecohen1872 risk via photopin (license)

Comments

If you want to comment on this post, you need to login.