This article is a part of three article series of Solving GDPR with Risk Analysis. Be sure to read the whole series, if you want to gain a full understanding of the relationship between GDPR and risk analysis.
Approaching Risk Analysis With A Cool Head
First of all, risk assessment or risk analysis is a huge topic of its own with trainings that could last for days, just to get the pure basics under your belt. We won’t expose you to that, nor will we require you to have such training.
What we will do, however, is to help you understand its basic concepts to the point that you will be able to use its abridged version as a basis for solving your GDPR compliance stress, and mess free, by getting your head in the game.
Just remember, this topic goes far deeper.
Angles Of Risk Assessment
If you’ve ever been in the position where you had to manage the risks, you already know that there are various processes that you can observe. The major one being information security risk management process under ISO 27005 or the general risk management framework in ISO 31000.
Yet GDPR introduces another point of view and is no longer concerned with the organization, but rather focuses on the data subject’s perspective. This means that all the risks are being evaluated using the question: How could it impact an individual? (e.g.visitor of web page or event participant).
Starting The Process By Identifying Risks
In an ideal world, your company should already have the most common risks documented and it’s a great start to use such a document as a basis to review the most commonly occurring risks.
What should follow is to approach the representative of each major department inside of your company for an interview about how their work affects data subjects.
Some questions could be following:
- Do you process any sensitive or private data?
- Is there any possibility for these data to leak during the processing?
- What was the source of the data?
With their help you should be able to write down answers and fill in a simple table which will help you out tremendously, down the line.
The table just summarizes your findings and will help you out with performing a deeper analysis. It’s made up of 4 distinct parts:
Cause: Describes what causes the risk
Condition: Details the effect of the root cause of the risk
Consequence: Specifies what is the outcome of the risk to the data subjects
Downstream effect: Defines how it further influences data subjects down the line
Example Identification Table:
|User login isn’t secure enough||Users’ accounts may be hacked||PII could be leaked||Loss of customer trust|
You are now aware of the most common risks that could take place and impact data subjects, brilliant, but now let’s dig slightly deeper into your assets and let’s map them. The previous step should make this analysis much easier.
We need to mention that asset assessment isn’t a part of GDPR requirements and it’s used predominantly in security risk management, but it serves for a basis of Data Protection Impact Assessment.
Again, the asset analysis is being done by filling out a simple table since it’s the easiest way to visualize it. So, what is it made up of?
Asset: Anything tangible and of value.
Threat: The perceived risk involved to an asset.
Likelihood: The chance that the threat occurs.
Impact: The effect of the threat on the asset.
Vulnerability: How vulnerable is the current asset to the threat.
Treatment option: A tactic outlining the necessary approach to solve the threat.
Solution: Your proposed solution to minimize the threat.
We’ve left out the financial details relating to an asset analysis on purpose because even though it’s very useful (and you should do it in the end), but it’s not necessary for plotting your way towards GDPR compliance and it would severely increase the difficulty.
Example Asset Analysis Table:
|Customer Database||Outside hack||Low||High||Medium||Reduce||Implement additional layers of encryption|
Deconstructing Likelihood, Impact and Treatment Option
Let’s talk about likelihood, impact and treatment option since you won’t be able to fill them out yourself if you didn’t do a risk analysis sometime in the past.
The following categorization is only one of the ways you can approach the assessment, it’s what we internally use, although it isn’t a part of any official methodology.
Likelihood defines how easy it is to identify data subjects based on the available data processed by the system.
Negligible: Identifying an individual using their personal data appears to be virtually impossible.
(e.g. searching through a JSON data format and cookies in events).
Limited: Identifying an individual using their personal data appears to be difficult but is possible in certain cases (e.g. searching a time series of events).
Significant: Identifying an individual using their personal data appears to be relatively easy (e.g. searching a dataset containing Personally Identifiable Information).
Impact is asking you how much damage would be caused to the data subjects.
Negligible: Individuals won’t be affected or may encounter only a few minor inconveniences (e.g. additional time spent re-entering information).
Limited: Individuals may be affected by inconveniences, which they will be able to overcome despite some difficulties (e.g. extra costs or denial of access to business services).
Significant: Individuals may encounter significant consequences, which they should be able to overcome, although with serious difficulties (e.g. blacklisting by banks).
Extreme: Individuals could encounter severe or even irreversible consequences, which they may not be able to overcome and an example could be to financial distress (e.g. substantial debt).
The treatment option is taking into consideration the likelihood and impact, so you can choose the best tactic available to solve the risk.
Risks with a high or very high impact and likelihood must absolutely be avoided or reduced by implementing security measures that reduce both their severity and their likelihood.
Ideally, the appropriate steps should be taken to ensure that these risks are treated by independent measures to prevent, protect and recover from them.
Risks with a high impact but a low likelihood must be avoided or reduced by implementing security measures that reduce either their severity or their likelihood. Emphasis must be placed on preventive measures.
Risks with a low impact but a high likelihood must be reduced by implementing security measures that reduce their likelihood. Emphasis must be placed on recovery measures.
Risks with a low impact and likelihood may be taken, especially since the treatment of other risks could also lead to their treatment.
Mapping The Results Onto The Business Processes
We are finally getting to the last piece of the puzzle. Mapping everything onto the business processes, campaigns and analyses.
It was a beneficial to perform previous analyses, since you are finally at the point where you are aware of the weak areas of your business and how do they impact individuals, who are most commonly your customers.
Process: An activity that you perform which operates with data subjects’ data.
Assets involved: Which assets are involved in the process.
Influence on data subjects: How impactful is the process on your data subjects.
Business impact: How impactful is the profess on your business.
Processing basis: Which processing basis do you choose to use?
Let’s map it!
|Process||Assets involved||Influence on data subjects||Business impact||Processing basis|
|Performing RFM Analysis||Customer Database||Medium||High||Consent|
What are you now holding in your hands?
- You are aware and have written down cross-departmental risks involving data subjects
- You know about risks to your assets and how to treat them
- You have specified your business processes with assets involved.