Menu

Filter by
content
PONT Data&Privacy

0

Risk analysis and the DPIA

On several occasions, I have heard that it is unclear to some organizations exactly how to handle questions surrounding personal data security during a Data Protection Impact Assessment (DPIA). Often I hear that during a DPIA substantive questions about security are addressed. Is authorization properly managed? What is being done to counter malware and hackers? Is the data properly encrypted? While these are good questions, in my opinion they do not belong in a DPIA. They belong in an information security risk analysis (henceforth "risk analysis"), which is something quite different from a DPIA. Only the result of such a risk analysis do you include in a DPIA to answer the question of whether personal data are adequately secured.

February 12, 2020

Author: Hugo Leisink

Differences

There are several reasons to keep a risk analysis and a DPIA separate. One important reason is that a good risk analysis already takes more than enough time. By discussing security questions substantively during a DPIA, Article 32 is likely to get disproportionately more attention than the other AVG articles, which are just as important. In addition, security is usually designed for information in a broad sense and not specifically for personal data. This makes a risk analysis specifically for personal data security ineffective.

The other main reasons are the difference in thinking and way of assessment required in a risk analysis and a DPIA. For example, during a DPIA, you assess the current or planned situation, while in a risk analysis you estimate a possible situation in the future. A risk analysis is about the security of business information, while a DPIA is about the rights and freedoms of those involved. So in both cases you are thinking and working from a completely different perspective. In my opinion, it would be good to be able to summarize personal data security in such a way that it can be assessed in the same way as the other topics covered during a DPIA. The way to do that properly is to take the risk analysis out of the DPIA and conduct it separately.

It would go too far for this article to explain all the differences in terms of content, but for the sake of completeness, below is an overview of the main points in which personal data protection (from now on "data protection") and information security, and therefore also the DPIA and risk analysis, differ.

Data Protection

Information Security

Standards Framework:

AVG, UAVG

ISO 27k, NEN 7510, BIO

Compliance:

mandatory

comply or explain, choice

Subject:

rights and freedoms

security of business information

Target audience:

involved

own organization

Assessment:

respect for privacy/law

estimate probability x impact of incident

Moment:

now or as planned

possible situation in the future

Risk acceptance:

as low as possible

proper balance

Risk communication:

transparency

confidential

The right approach

To properly address risk assessments and DPIAs, the order in which you conduct them is important.

The first step is to get a good overview of your own information management. Article 30 of the AVG requires having an overview of all processing of personal data. Why limit yourself to personal data? Why not an overview of all company information? Why a personnel administration, a financial overview, but no information overview, while organizations are just as dependent on business information as they are on personnel and money. So get to work on information management. Create an overview of all business information, indicating for each information item whether it is personal data and what the classification of that information is in terms of availability, integrity and confidentiality.

The next step is to conduct a risk analysis. Choose the scope of the risk analysis, request from information management the metadata (classification of the information, name of manager responsible, name of systems involved, et cetera) about the information in question, and perform the analysis. The content of the data is irrelevant here. Personal data is then simply "confidential data. If a risk analysis has already been performed recently, the results of which are still useful, then of course you use them. So what I am not saying is that a DPIA requires a new risk analysis.

Only after the risk analysis is it the turn of the DPIA. It is important here that there is a balance between the topics to be discussed. Personal data security is only one of the topics. Use the results from the risk analysis for this purpose. Realize that a data breach is basically a security breach and not necessarily a data protection breach. The latter depends on the level of security, which is independent of whether an incident has occurred or not.

A common approach is that risk assessments are conducted only if there is a high risk. Also, Article 35 of the AVG states that a DPIA is only required if a processing operation is "likely to present a high risk. Personally, I believe it is always wise to think carefully before doing anything. So always conduct a risk analysis and a DPIA, regardless of the risk. The time it takes will probably catch up with the incidents it prevents.

Beyond borders

Information security professionals are not about information privacy, and the AVG and privacy professionals are not about information security. However, the fields of data protection and information security, as well as information management, are not completely isolated fields. They have mutual interfaces. For that reason, in this article I have gone beyond the boundaries of my own field. This is because I am convinced that what we need to focus on in the future in order for the individual disciplines to be successful is better collaboration. So, if you haven't already, information security professionals, privacy professionals and information managers, sit down with each other on a regular basis.

This article can also be found in the files AVG and Accountability

source: NCSC

Share article

Comments

Leave a comment

You must be logged in to post a comment.