Data Security in Light of the GDPR: Risk Analysis and Adequacy of Security Measures (Chapter 3, Section 1) — Guide to the GDPR

Pursuant to Article 32(1) GDPR:

Taking into account [1] the state of the art, [2] the costs of implementation and the [3.1] nature, [3.2] scope, [3.3] context and [3.4] purposes of processing as well as [4] the risk of [5] varying likelihood and [6] severity for the rights and freedoms of natural persons, the controller and the processor shall implement [7] appropriate technical and organisational measures to ensure a level of security [8] appropriate to the risk, including inter alia as appropriate:

Pursuant to Article 32(2) GDPR:

In assessing if the level of security is appropriate account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.

Article 32 GDPR is the fundamental, and in fact the only, provision that outlines the criteria to decide on the level of personal data security. Pursuant to this provision, both a controller and a data processor are obliged to ensure a degree of personal data security appropriate to the risk of a breach of the rights or freedoms of natural persons resulting from processing.

The requirement of employing appropriate (adequate) data protection is not new. Now, however, the General Data Protection Regulation (GDPR) puts much more weight on risk assessment. The requirement to adopt security measures adequate to the risk of processing does not set any material standard of data protection. It sets only a procedural standard of performing a risk analysis. That is deliberate as the GDPR intends to be ‘technology neutral’. In practice, though it lefts in the dark data controllers and data processors, especially small and medium enterprises (SMEs), as they have limited resources and capabilities to conduct such knowledgeable risk assessment.

A security analysis should start with a risk analysis.

Pursuant to Recital 83 GDPR:

In order to maintain security and to prevent processing in infringement of this Regulation, the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption.

This recital also indicates a need to weigh the costs of implementing protective measures against the risk and the nature of the data involved.

Those measures should ensure an appropriate level of security, including confidentiality, taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected.

Further on, the recital states how risk should be evaluated.

In assessing data security risk, consideration should be given to the risks that are presented by personal data processing, such as the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed, which may lead in particular to physical, material, or non-material damage.

The type of risk involved here is explained in Recital 75 GDPR, which specifies the following situations that threaten the rights or freedoms of data subjects:

harm – where the processing may give rise to discrimination, identity theft or fraud, financial loss, damage to the reputation, loss of confidentiality of personal data protected by professional secrecy, unauthorised reversal of pseudonymisation, or any other significant economic or social disadvantage;
a loss of rights or control – where data subjects might be deprived of their rights and freedoms or prevented from exercising control over their personal data;
sensitive data – where personal data are processed which reveal racial or ethnic origin, political opinions, religion or philosophical beliefs, trade union membership, and the processing of genetic data, data concerning health or data concerning sex life or criminal convictions and offences or related security measures;
profiling – where personal aspects are evaluated, in particular analysing or predicting aspects concerning performance at work, economic situation, health, personal preferences or interests, reliability or behaviour, location or movements, in order to create or use personal profiles; or
persons requiring special care – where personal data of vulnerable natural persons, in particular of children, are processed;
large-scale processing – where processing involves a large amount of personal data and affects a large number of data subjects.

The GDPR repeats the word ‘risk’ seventy-six times. Risk analysis is found on the inspection list of the supervising authorities. Whether a data protection impact assessment (DPIA) (a formalised risk analysis) should be run depends on the degree of risk entailed by the data processing. Undoubtedly, from the perspective of the GDPR, every controller and every processor should begin evaluating data security by analysing and estimating the risks posed to the rights and freedoms of data subjects.

It seems that a risk analysis should be conducted in respect of data processing activities but taking account of the data processing operations that generate risk. This conclusion results from combining a functional analysis of the GDPR pertaining to data processing, the wording of Article 32(1) GDPR, which requires different likelihoods and weights of threats to be accounted for, and Article 35(1) sentence 2 GDPR, where, in the context of a DPIA, the GDPR speaks of ‘processing operations’. We use here at once two terms that are not defined by the GDPR, but in our glossary, as well as when discussing the register of processing activities – we will try to clarify these. What is important is that every data processing activity should be preceded by a separate risk analysis.

The two basic dimensions of an analysis of risk are the likelihood of the risk and its impact, that is the (adverse) impact it can have on data subjects. An analysis is usually presented in the form of a two-dimensional, multilevelled grid. The CNIL proposes a grid having four levels (negligible, limited, significant, and maximal); PUODO (Polish supervisory authority) suggests five levels (of likelihood: rare, unlikely, possible, likely, and almost certain; impact: very low, low, average, high, and very high).

In practice, you have to anticipate what harm may result from processing data as part of a particular activity. Then you need to evaluate what the likelihood of each incident is, and to what extent it may adversely affect people’s lives, and how many lives. You enter the findings in the grid, multiply, and a risk weighting results. Next, you have to establish what level of risk is acceptable (including potential claims of compensation for harm caused) and then verify possible security measures and the costs involved. Do not forget that the GDPR does not permit a high risk of a breach of the rights or freedoms of natural persons; at the very least, these require consultation with the supervisory authority (Article 36(1) GDPR).

Further below we describe basic attributes of information security (confidentiality, integrity, availability) which should be taken into consideration in the risk analysis. We point out that usually measures taken to ensure confidentiality decrease availability. We also point out that performing a risk analysis according to existing ISO methodologies (ISO 27005, ISO 29134) is a time and resources consuming process. But we also give some hints on how to try to lower the required effort by taking some shortcuts.

Article 32(1) GDPR mentions a total of eleven elements for analysing the adequacy of data protection measures:

In times of changing threats and knowledge of how to protect against them, you need to employ modern solutions that incorporate current thinking about cyberspace. In practice, if you do not have sufficient knowledge in this area yourself, you need to call on the services of cybersecurity professionals.

However, at least from the experience of authors of this book, not only it is hard to find knowledgeable cybersecurity specialists, but they usually recommend solutions which are not easy to implement, consuming time, and other resources of a particular organisation. Often they offer solutions which are difficult or impossible to implement, resulting in a so-called shadow IT user behaviour – which is using publicly available free resources for professional use.

Why is that so? Mostly because there is no such thing as cybersecurity [deliberate overstatement]. Due to the current nature of the grid, basic assumptions of modern information technology (IT) (and in particular due to the fact it is based on trust), and due to the rules of the market, creating truly secure IT systems does not seem possible at the moment. As an example – Polish Prosecution claims they have secure email, as an internal email is ‘separated’ from the public network. Let us even believe it is truly physically separated. However, I once assisted in an interrogation which had to be stopped because a prosecutor needed to send a document to another prosecutor’s office. A fax machine was down, and the email quota was too low to accommodate a scan of that document (or the operators have not been trained to decrease a size of a scan). So what happened? Of course, eventually they sent that scan through a private email account of that prosecutor.

Another reason why achieving a state of cybersecurity is practically impossible is that cybersecurity experts usually do not offer complete solutions. The most common issue is requiring encryption and passwords for accessing specific resources. Why is it a problem? Because the market does not offer good solutions to devise and store those myriads of passwords. So, technically encrypting is good, but users are usually not offered with solutions allowing to manage all their digital credentials.

Finally, there will always be organisations ready to accept the risk (or not even carrying about it) and due to that being able to beat you on price. That is called unfair competition, and still security is mostly considered as a cost centre. For many reasons, supervisory authorities will not eliminate such organisations from the market, not even a small portion of them.

So, what to do? If you are small, look for ready to use solutions, rely on trustworthy cloud computing services and other out of the box solutions. If you are big, employ a competent team and see what happens.

However, there is hope. In February 2019, the German IT Security Association Germany (TeleTrusT) in association with ENISA issued guidelines on the notion of ‘State of the art’ in the meaning of the GDPR (as well as in the meaning of the German IT Security Act of 2015), relating to cybersecurity (and personal data security).^, The guidelines to a certain extent can be understood by non-technical persons including lawyers, though for sure they cannot be questioned by non-experts. We must however remember that the guidelines describe ‘state of the art’ in cybersecurity which not always needs to be attained though in any case needs to be taken into consideration according to ‘comply or explain’ principle.

Liability for a leak or destruction of data is one thing; the obligation to provide appropriate security is another. You must ensure that the security in place is appropriate to the threats, but this does not mean that no incidents will ever occur. If one does, you may, and in general will, be liable for how a particular person is affected. But this does not mean that you have breached the general obligation to provide an adequate level of security. The GDPR acknowledges the fact that there is never 100% security.

From this perspective, the cost of particular security measures and their effect on your activity can and should be taken into consideration when augmenting your level of security. It may not pay off to enhance security beyond a certain level; you accept a certain amount of risk along with the consequences (e.g., having to pay out compensation). The same is true in daily life where, for example, the risk of driving in traffic is high, but you are used to it. Of course, not every risk is acceptable, and apart from accepting risk or enhancing security, you can also cease processing that generates a high risk of a breach of the rights and freedoms of natural persons. Evaluating and deciding on how to deal with risk depends on who is doing the processing (whether as a controller or processor).

The logic of cost is a treacherous one, though. Even if you are a small organisation, you will not be able to rely on an argument that you could not have afforded a certain type of security measures if that led to a foreseeable severe adverse consequences for a particular person. Beware of relying directly on cost argumentation when resigning from certain TOMs (technical and organisational measures of data security). Neither supervisory authorities nor courts are very receptive to an argument that appropriate data security measures were too costly to implement.

Therefore, in reality, GDPR does not support the principle of proportionality as regards security measures. We may expect that proportionality will be manifested in practice by administrative (fines) and private (litigation) enforcement (focused on larger and wealthier entities) but purely due to practical reasons.

Moreover, despite the risk matrix is usually presented in the same units for likelihood and for severity, we believe that severity should be considered as a more important dimension than likelihood. We believe that risk of minor adverse consequences can be easier accepted even despite it may affect much more people than accepting injury or death of a single person.

Obviously, in order to evaluate risk, you have to know the purpose of the processing, what the data are, what the scope of processing is, and in general what the context is.

The context of processing is what are you processing data for and what consequences your processing has or may have on the data subjects.

Above we briefly discussed how to calculate risk, including how to anticipate any adverse consequences for natural persons. The CNIL provides sample adverse consequences (Table 3.1):

Levels	Generic description of impacts (direct and indirect)	Examples of physical impacts	Examples of material impacts	Examples of moral impacts
1. Negligible	Data subjects either will not be affected or may encounter a few inconveniences, which they will overcome without any problem	Lack of adequate care for a dependent person (minor, person under guardianship) Transient headaches	Loss of time in repeating formalities or waiting for them to be fulfilled Receipt of unsolicited mail (e.g., spams) Reuse of data published on websites for the purpose of targeted advertising (information to social networks, reuse for paper mailing) Targeted advertising for common consumer products	Mere annoyance caused by information received or requested Fear of losing control over one’s data Feeling of invasion of privacy without real or objective harm (e.g., commercial intrusion) Loss of time in configuring one’s data Lack of respect for the freedom of online movement due to the denial of access to a commercial site (e.g., alcohol because of the wrong age)
2. Limited	Data subjects may encounter significant inconveniences, which they will be able to overcome despite a few difficulties	Minor physical ailments (e.g., minor illness due to disregard of contraindications) Lack of care leading to a minor but real harm (e.g., disability) Defamation resulting in physical or psychological retaliation	Unanticipated payments (e.g., fines imposed erroneously), additional costs (e.g., bank charges, legal fees), payment defaults Denial of access to administrative services or commercial services Lost opportunities of comfort (i.e., cancellation of leisure, purchases, holiday, termination of an online account) Missed career promotion Blocked online services account (e.g., games, administration) Receipt of unsolicited targeted mailings likely to damage the reputation of data subjects Cost rise (e.g., increased insurance prices) Non-updated data (e.g., position held previously) Processing of incorrect data creating, for example accounts malfunctions (bank, customers, with social organisations, etc.) Targeted online advertising on a private aspect that the individual wanted to keep confidential (e.g., pregnancy advertising, drug treatment) Inaccurate or inappropriate profiling	Refusal to continue using information systems (whistle-blowing, social networks) Minor but objective psychological ailments (defamation, reputation) Relationship problems with personal or professional acquaintances (e.g., image, tarnished reputation, loss of recognition) Feeling of invasion of privacy without irreversible damage Intimidation on social networks
3. Significant	Data subjects may encounter significant consequences, which they should be able to overcome albeit with real and serious difficulties	Serious physical ailments causing long-term harm (e.g., worsening of health due to improper care or disregard of contraindications) Alteration of physical integrity, for example following an assault, an accident at home, work	Misappropriation of money not compensated Non-temporary financial difficulties (e.g., obligation to take a loan) Targeted, unique, and nonrecurring, lost opportunities (e.g., home loan, refusal of studies, internships or employment, examination ban) Prohibition on the holding of bank accounts Damage to property Loss of housing Loss of employment Separation or divorce Financial loss as a result of a fraud (e.g., after an attempted phishing) Blocked abroad Loss of customer data	Serious psychological ailments (e.g., depression, development of a phobia) Feeling of invasion of privacy with irreversible damage Feeling of vulnerability after a summons to court Feeling of violation of fundamental rights (e.g., discrimination, freedom of expression) Victim of blackmailing Cyberbullying and harassment
4. Maximum	Data subjects may encounter significant, or even irreversible, consequences, which they may not overcome	Long-term or permanent physical ailments (e.g., due to disregard of contraindications) Death (e.g., murder, suicide, fatal accident) Permanent impairment of physical integrity	Financial risk Substantial debts Inability to work Inability to relocate Loss of evidence in the context of litigation Loss of access to vital infrastructure (water, electricity)	Long-term or permanent psychological ailments Criminal penalty Abduction Loss of family ties Inability to sue Change of administrative status and/or loss of legal autonomy (guardianship)

Source: Privacy Impact Assessment (PIA) Knowledge Bases, CNIL, February 2018.

The ISO 27005 standard mentions the following typical threats to information security:

Fire,
Flooding,
Pollution,
Serious accident,
Damage to equipment or media,
Dust, corrosion, hypothermia.

Failure of an air conditioning system or water supply,
Loss of power supply,
Failure of telecommunications equipment.

Interception of signals as a result of interference phenomena,
Remote espionage,
Wiretapping,
Theft of media or documents,
Theft of equipment,
Access from reused or discarded media,
Disclosure,
Data from unreliable sources,
Manipulation of devices,
Falsification of software,
Detection of location.

Failure of equipment,
Improper functioning of equipment,
IT system overload,
Improper functioning of software,
Breach of capacity to maintain IT system (lack of organisational and technical resources guaranteeing the proper functioning of the system).

Unauthorised use of equipment,
Unauthorised copying of software,
Use of false or copied software,
Deformation of data.

Unlawful data processing,
User error,
Breach of entitlements,
Falsification of entitlements,
Refusal to act,
Breach of personnel access.

Hacker (break-in to the system),
Computer crime (cybernetic persecution, impersonation, data hijacking),
Terrorism,
Industrial espionage,
Internal staff (badly trained, dissatisfied, angry, careless, dishonest, conducting themselves unethically or contrary to the law, dismissed employees).

Appropriate organisational and technical measures. Your palette of information and personal data protection measures can vary. It may consist of legal tools (e.g., confidentiality undertakings, provisions, agreements), organisational tools (procedures, levels of authorisation), physical tools (e.g., keys, safe envelopes, access control), and IT tools (e.g., levels of authorisation, firewalls, shared access, intrusion detection systems, antivirus tools, real-time cloud-based cybersecurity services). You should choose what best fits the risk determined.

Appropriate level of security. An organisation should manage its security through security levels. Of course, in theory you could just apply the highest level and forget about lower levels. But in practice it is usually more convenient to distinguish a number of levels so as not to hinder activity excessively. Further, when determining the most appropriate security level, attention should be also be paid to accessibility. Requirements that are too strict can hinder access to data, both within the organisation and among its customers.

Article 32(1) GDPR mentions the following categories of security measures:

In an organisation, the personal data security system, which can be documented in a data security policy, should take account of at least the following control points:

When developing personal data security rules, you might wish to refer to a local implementation of the NIS Directive (European Union (EU) Network and Information Security Directive) – often called ‘cybersecurity acts’. Though primarily NIS Directive applies to large entities (operators of essential services), NIS cybersecurity systems standards will undoubtedly become best standards for evaluating data protection security (at a procedural level), especially that the GDPR in reality says nothing about data security (maybe except for something like this ‘consider encryption and pseudonymisation, remember about backups and in general about business continuity, though we do not use words “backups” and “business continuity”, because it would be too easy, so even Americans would know’). At the same time a relation between the NIS Directive (implementations) and the GDPR will become symbiotic; as though the NIS Directive does not provide for fines, breaching NIS’ cybersecurity standards is easily penalised under the GDPR as violation of data protection security rules (not so easy applicable to operational technology, though).

Of course, if you intend to be EU-wide compliant, you need to develop a more holistic approach than relying on a local ‘cybersecurity act’. That is where the TeleTrust and ENISA’s guidelines on the state of the art in IT security might come in handy. Still, extracting a common denominator from all EU implementations of the NIS Directive seems to be the best approach.

The CNIL (Commission nationale de l’informatique et des libertés), the French supervisory authority, has published an application on how to conduct a DPIA. The application includes a predefined set of typical security measures. Using the CNIL’s method in order to evaluate impact, you can conduct a risk analysis of your own data processing activities. Combined with security procedures, this should result in a data protection system that will stand up before the supervisory authority. The catch in using CNIL’s PIA app is that it adopts a per-data processing activity approach, requiring an organisation to run it separately for each of their data processing activities (which one may have from several dozens to a couple hundred).

Other DPIA or PIA apps are being released to the market right now in different EU countries.

You may also employ a little less developed tools such as predefined spreadsheets which are less fancy than CNILs PIA, but they allow for a two or even threedimensional perspective on an organisation, its resources, and risks associated.

Small organisations may try to approach risk analysis in a simplified manner, starting from defining their minimum security level set of ‘TOMs’ (technical and organisational (security) measures), from an increased security level TOMs up to maximum level TOMs (mostly moderated by an organisation’s budget). Then within such defined range, an organisation may define its native level of risk in a few simple steps.

#1.1 Security Appropriate to Risk

#1.1.1 Risk

#1.1.2 Risk of a Breach of Rights or Freedoms

#1.1.3 Data Processing Risk Analysis

#1.2 Elements of Evaluating the Adequacy of Data Protection Measures

#1.2.1 The State of the Art

#1.2.2 Cost

#1.2.3 Features of Processing Itself

#1.2.4 Risk of a Breach of Rights or Freedoms

#Table 3.1 Severity of Feared Events by CNIL

Physical damage:

Loss of basic services:

Breach of information security:

Technical failure:

Unauthorised activity:

Breach of functional security:

Personal breaches:

#1.3 Security Measures

#1.4 Shortcuts?