Swiss insurance companies show growing interest in genetic data

A lawmaker’s current initiative in Switzerland on the required disclosure of genetics tests to insurance companies is raising a number of moral, legal and philosophical issues. If passed, the law would give a green light for insurance companies to receive genetic data of natural persons who wish to enter into a life insurance contract and who have previously had a genetics test.

Under currently applicable Swiss laws, insurance companies have no access to such data.

Under the draft law which is currently pending before the federal parliament, an applicant for an insurance policy would be required to inform the insurance company of the results of a completed genetics test if that person wishes to conclude a life insurance contract.

Nowadays, it is becoming more and more easy as well as cheaper to have a genetics test carried out and quite a few individuals take advantage of this possibility. For such individuals, these tests will often serve the purpose of knowing the risk of any inherited diseases and whether they are otherwise predisposed to certain illnesses.

Supporters of the draft law argue that a person who completes a genetics test will be aware of its results whereas the insurance company will not. This causes, they argue, “information asymmetry” between the parties since the customer is in the possession of information which the insurance company does not have. Thus, the insurance company would necessarily not be in a position to precisely assess the risks which the insurer would have to take into account when concluding a contract which means, in turn, that the insurance company would not be able to set the insurance premium properly. One of the arguments of the supporters of the draft law is that nobody would wish to enter into a contract if the other party hides information which may have a significant importance from the perspective of the conclusion and performance of a contract. In other words, the principle of justice requires, they argue, that the customer informs the insurance company of the results of the genetics test prior to the conclusion of the life insurance contract.

It is important to note that, of course, the draft law does not require anyone to have a genetics test conducted and the insurance companies may not require the customer to obtain such a test for the purpose of concluding a life insurance contract either. The draft law simply provides that in the event that a person has in fact completed a genetics test and then wishes to enter into a life insurance contract, then he / she is required to inform the insurance company of the results. The draft law also provides that this disclosure requirement would only apply with respect to private life insurance and not compulsory life insurance.

The Alliance of Swiss Insurers argues that the reason it is necessary to inform the insurance companies of the results of actually completed genetics tests is that this is how the insurance companies are best placed to properly set the amount of the premium, i.e. this is how the premium can be determined in proportion with the relevant risks. In their view, in the absence of such information, the premiums will increase since there may be persons who would conclude a life insurance contract knowing that there is a high risk that they have inherited a certain kind of disease but would not disclose this information to the insurer.

At the same time, politicians opposing the draft law are afraid that if the proposal becomes law, it may divide the society into two. This is due to the fact that such a regulation may subsequently lead to a situation where life insurance will only be available to those whose genetics test results the insurance companies find satisfactory.

Representatives of the sick people have also expressed their concerns about the draft law. Namely, genetics test results reveal extremely sensitive data about the individual and his / her family, and there is no valid justification for handing over such data to insurance companies on a mandatory basis. At the same time, they also emphasize that a genetics test is by no means a diagnosis but merely about the likelihood of the existence of a risk, i.e. such a test is not about the medical identification and description of a certain state that has already taken place. It is completely unjust to discriminate individuals on the basis of the existence of a risk, they argue.

The Alliance of Swiss Insurers has indicated that they are well aware of the fact that a genetics test is not equal to the diagnosis of a disease and also added that they wish to draw up a list of suitable tests with the help of authorities and experts. These authorities and experts would assist in determining the genetics tests that are relevant for the purposes of the conclusion of life insurance contracts. Any such efforts by the insurers have, however, so far been unsuccessful.

The proposal will certainly trigger some serious disputes in Switzerland, including also the federal parliament. The issues that have been raised and need to be resolved will surely be addressed by applying the usual thoroughness and care, and, thus, may well result in an amendment that is acceptable from both legal and moral perspectives.

In addition to a number of other issues, the initiative described above could raise a further issue from the perspective of the European Union’s general data protection regulation (GDPR), which will be applicable from 25 May 2018.

The GDPR will apply if a Swiss insurance company concludes a life insurance contract with a person who is in the European Union which means, in this case, that the Swiss insurer is required to abide by the rules of the GDPR.

The GDPR lists the possible legal bases for processing genetic data. This list, however, does not seem to include the legal basis which would allow the processing by Swiss insurers of genetic data for the purpose as described above.

Thus, it raises the issue that if a Swiss insurance company concludes a life insurance contract with a person living in, for example, Germany (who can even be a Swiss citizen) and who hands over the results of his / her genetics test to the insurer upon concluding the contract, then what is the legal basis under the GDPR for the processing by the insurer of the genetic data?

Zoltán Balázs Kovács, LL.M. (McGill University), Partner, Szecskay Attorneys at Law, Budapest (zoltan.kovacs@szecskay.com)

(based on the article on srf.ch)

the author is a lawyer and author of the blog at eugdpr.blog.hu

The contents of this post are intended to provide only a general overview of the subject matter and do not qualify as legal advice.

A svájci biztosítók egyre nagyobb érdeklődést tanúsítanak a genetikai adatok iránt

Fontos és alapvető morális, jogi és filozófiai kérdéseket is felvet az a jogalkotói kezdeményezés, amely zöld utat adna Svájcban ahhoz, hogy a biztosítók megkapják a velük életbiztosítási szerződést kötni szándékozó olyan személyek genetikai adatait, akik genetikai tesztet végeztettek.

A jelenlegi svájci szabályozás szerint a genetikai adatokhoz a biztosítóknak nincs hozzáférése.

A szövetségi parlament előtt lévő javaslat lényege szerint abban az esetben, amennyiben egy személy genetikai tesztet végeztet, majd ezt követően életbiztosítási szerződést kíván kötni, akkor köteles a biztosító tudomására hozni a genetikai teszt eredményét.

Manapság egy genetikai teszt elvégeztetése egyre könnyebben és olcsóbban megoldható és sokan élnek ezzel a lehetőséggel abból a célból, hogy megtudják, lehet-e valamilyen öröklött betegségük, illetőleg fennáll-e esetükben valamilyen megbetegedés kockázata.

A jogszabálytervezet támogatóinak érvelése szerint abban az esetben, ha egy genetikai tesztet végeztetett személy a teszt eredményének ismeretében kötne szerződést a biztosítóval, a biztosítónak azonban nem lenne tudomása a genetikai teszt megállapításairól, akkor „információs aszimmetria” alakulna ki a felek között, hiszen az ügyfél olyan ismeretek birtokában kötné meg a szerződést, amely információkkal a biztosító nem rendelkezik. A biztosító társaság így szükségképpen nem lenne abban a helyzetben, hogy pontosan meg tudja ítélni a kockázatokat, amelyeket a szerződés megkötése során figyelembe kellene vennie, így nem tudja megfelelően meghatározni a biztosítási díj összegét. A javaslat támogatóinak egyik érve éppen az, hogy senki nem kívánna úgy szerződést kötni, ha a másik fél elhallgat előle olyan körülményeket, amelyeknek a szerződés megkötése és teljesítése szempontjából komoly jelentősége lehet. Más szóval, az igazságosság elve azt diktálja, hogy a genetikai teszt eredményének ismeretét az ügyfél megossza a biztosítóval az életbiztosítási szerződés megkötését megelőzően.

Fontos hangsúlyozni azt, hogy a tervezet természetesen senkit nem kötelez genetikai teszt elvégeztetésére és a biztosítók sem kérhetnek genetikai tesztet életbiztosítási szerződés megkötéséhez. A javaslatban foglaltak szerint kizárólag arról van szó, hogy amennyiben valaki elvégeztet egy genetikai tesztet, és ezt követően életbiztosítási szerződést kíván kötni, akkor köteles tájékoztatni a biztosítót a genetikai teszt eredményéről. A tervezet úgyszintén tartalmazza azt, hogy kizárólag magán életbiztosítások esetén állna fenn a tájékoztatási kötelezettség, a kötelező betegbiztosítások esetén nem.

A Svájci Biztosítók Szövetségének érvelése szerint azért is szükséges a genetikai teszt elvégeztetése esetén tájékoztatni a biztosítókat annak eredményéről, mert a biztosítók ezáltal kerülhetnek olyan helyzetbe, hogy megfelelően – azaz a kockázatokhoz mérten – tudják megállapítani a biztosítási díjat. A biztosítói érdekképviselet álláspontja szerint ilyen információk hiányában a biztosítási díjak növekedni fognak, mert lehetnek olyan személyek, akik valamilyen öröklött betegség magas kockázatának ismeretében kötnek életbiztosítást, azonban a kockázat fennállását nem osztják meg a biztosítóval.

A javaslatot ellenző politikusok ugyanakkor a javaslat szerinti szabályozás alapján attól tartanak, hogy az két részre oszthatja a társadalmat, mivel a javaslat szerinti szabályozás annak elfogadása esetén előbb-utóbb akár oda is vezethet, hogy csak azok fognak tudni életbiztosítást kötni, akiknek a genetikai tesztje és annak eredménye a biztosítók számára megfelelő.

Betegjogi képviselők is komoly aggályokat fogalmaztak meg a tervezettel kapcsolatban. Nevezetesen, abban az esetben, ha valaki genetikai tesztet végeztet, a teszt rá, valamint családjára nézve rendkívül érzékeny adatokat tartalmaz és indokolatlan, hogy ezek az információk a biztosítók kezébe kerüljenek. Egyidejűleg arra is felhívják a figyelmet, hogy a genetikai teszt korántsem diagnózis, az csupán egy kockázat fennállásának valószínűségéről szól, nem pedig egy már bekövetkezett állapot orvosi azonosításáról, leírásáról. Pusztán egy kockázat fennállása alapján pedig senkit nem szabadna hátrányba hozni másokkal szemben.

A Svájci Biztosítók Szövetsége jelezte, tisztában van azzal, hogy önmagában egy genetikai teszt nem egy betegség megállapítását jelenti, egyben hozzátette, hogy szándékában áll a hatóságokkal és szakértőkkel összeállítani egy olyan listát, amely a biztosítási szerződés megkötése szempontjából releváns genetikai teszteket nevesíti. A biztosítók ezirányú törekvése eddig nem járt sikerrel.

Bizonyos, hogy a javaslat komoly vitákat fog kiváltani az alpesi országban, így többek között a svájci szövetségi törvényhozásban is. A felvetődő és megoldandó kérdéseket minden bizonnyal ezúttal is a megszokott alapossággal és megfontoltsággal járja majd körbe a jogalkotó és egy jogi és igazságossági szempontból is elfogadható törvénymódosítás születhet meg.

A fentiek – a számos egyéb kérdésen felül – az Európai Unió 2018. május 25-től alkalmazandó általános adatvédelmi rendelete (GDPR) tekintetében felvethetik az alábbi kérdést.

Megállapítható, hogy a GDPR hatálya kiterjed arra az esetre, ha egy svájci biztosító életbiztosítási szerződést köt egy, az Európai Unióban tartózkodó személlyel, így ebben az esetben a svájci biztosító köteles a GDPR szabályait betartani.

A GDPR tételesen felsorolja a genetikai adatok kezelésének lehetséges jogalapjait. Ezek között nem található olyan, amely alapján megengedett lehet a fent leírt célból történő, svájci biztosítók általi genetikai adatkezelés.

Így felmerül a kérdés, hogy amennyiben egy svájci biztosító életbiztosítási szerződést köt egy, például Németországban élő – akár svájci állampolgárságú – személlyel, aki a szerződéskötéskor a biztosító rendelkezésére bocsátja a genetikai tesztje eredményét, akkor a biztosító milyen jogalap alapján kezeli ezen személyes adatokat?

dr. Kovács Zoltán Balázs, LL.M., (McGill University), Partner, Szecskay Ügyvédi Iroda, Budapest (zoltan.kovacs@szecskay.com)

(az srf.ch-n megjelent cikk alapján)

a szerző ügyvéd, az eugdpr.blog.hu szerzője

A jelen bejegyzés általános áttekintést kíván nyújtani a körüljárt kérdésekkel kapcsolatban és nem minősül jogi tanácsadásnak.

The data protection impact assessment (DPIA) I (Preparation of DPIA)

The GDPR contains rules on when controllers are required to prepare a data protection impact assessment (DPIA), when they have to seek the views of data subjects or their representatives on the intended processing and, furthermore, when they are obliged to consult the supervisory authority prior to processing.

The Article 29 Data Protection Working Party (WP29) issued guidelines on the DPIA on 4 April 2017 (WP248), that were then revised on 4 October 2017, and that interpret the respective provisions of the GDPR (Articles 35-36 and Recitals 75-76, 84 and 90-95).

Below you fill wind a Q&A concerning the obligation to prepare a DPIA.

1. Who is required to prepare a DPIA?

Under the GDPR, the obligation to prepare a DPIA lies with the controller.

It is worth mentioning that if the controller has a data protection officer (DPO), the controller is required to seek the advice of the data protection officer when carrying out a DPIA. Thus, the DPO may also have an essential role in preparing a DPIA. With respect to this, it is advisable to include a provision in the agreement with the DPO pursuant to which the DPO is required to assist the controller in every way in connection with the DPIA, including also the preparation of the same.

2. Does the processor have any obligation in connection with a DPIA?

Under the GDPR, the agreement that the controller concludes with the processor must stipulate that the processor is required to assist the controller in ensuring compliance with the obligations, including but not limited to the obligations connected to the DPIA taking into account the nature of processing and the information available to the processor.

3. When is it required to prepare a DPIA?

A DPIA is required when the processing is “likely to result in a high risk to the rights and freedoms of natural persons” unless the respective data processing is white-listed (Article 35(5) GDPR) or union or member state law meeting certain conditions allows for an exception (Article 35 (10) GDPR). 

DPIAs are about managing risks and managing them in an appropriate way. The purpose of a DPIA is a minimization of privacy risks. As the WP29 puts it, “a “risk” is a scenario describing an event and its consequences, estimated in terms of severity and likelihood.” Furthermore, risk management “can be defined as the coordinated activities to direct and control an organization with regard to risk.” 

It is important to note that just because the conditions for having to prepare a DPIA have not been met, controllers are still obliged to take appropriate measures with a view to ensuring an acceptable level of risk. In addition, the WP29 also stresses that in line with the principle of accountability, controllers are under the obligation to continuously monitor and assess the risks caused by their processing activities in order to identify when a type of processing is “likely to result in a high risk to the rights and freedoms of natural persons”.

For further details, please see the response to question 5 below.

4. At what point in time must a DPIA prepared?

The GDPR makes it clear that a DPIA must be prepared prior to commencing processing operations provided that the conditions as referred to in questions 3 and 5 apply. Thus, in accordance with the principles of privacy by design and by default, controllers are highly advised to plan well ahead and take into account that the launch of a new data processing activity may require the preparation of a DPIA, which may take some time.

5. When is processing “likely to result in a high risk?”

The GDPR is not quite explicit on this but contains some guidance and also three examples when a DPIA must be prepared, which are as follows: 

“(a) a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person; 

(b) processing on a large scale of special categories of data (such as, for example, health data or personal data relating to criminal convictions and offences); or 

(c) a systematic monitoring of a publicly accessible area on a large scale.” 

This list is non-exhaustive, meaning that there may be other data processing activities that are not covered by this list. The WP29 has developed a list of nine criteria to be taken into consideration when assessing if a DPIA is required. Such criteria are as follows: 

(i) evaluation or scoring, including profiling, especially from “aspects concerning the data subject's performance at work, economic situation, health, personal preferences or interests, reliability or behavior, location or movements” (Recitals 71 and 91 of the GDPR). Examples: a financial institution screening its customers against a credit reference database or an anti-money laundering database; company building marketing profiles based on the navigation on its website. 

(ii) automated-decision making with legal or similar significant effect: processing the purpose of which is to take decisions on data subjects producing “legal effects concerning the natural person” or which “similarly significantly affects the natural person”. 

(iii) systematic monitoring: e.g. data collected through networks. The data may be collected in a way that the data subjects may not be aware of who is collecting their data and how they will be used. 

(iv) sensitive data or data of highly sensitive nature: e.g. health / medical data, data concerning political opinions, religion, data concerning criminal convictions, financial data and personal documents, diaries may also be included. 

(v) data processed on a large scale: the GDPR does not define the term “large scale”. However, the WP29 gives some guidance on its meaning in its guidelines on the data protection officer (DPO). For details on the DPO, please click here. 

The following factors have to be assessed to decide if processing takes place on a large scale: 

- the number of data subjects concerned, either as a specific number or as a proportion of the relevant population;

- the volume of data and/or the range of different data items being processed;

- the duration, or permanence, of the data processing activity;

- the geographical extent of the processing activity. 

(vi) combining datasets: e.g. combining two databases containing personal data collected for different purposes. 

(vii) data concerning vulnerable data subjects: e.g. the personal data of children, the elderly, employees, patients or of people where there is an imbalance in the relationship between the controller and the data subjects. 

(viii) innovative use or applying new technological solutions: e.g. combining the use of finger print and facial recognition for physical access control. The use of a new technology may mean an increased level of risk to the rights and freedoms of data subject as the possible consequence of the use of such a new technology may be unknown. The WP29 emphasizes that certain Internet of Things applications may also require a DPIA. 

(ix) processing in itself “prevents data subjects from exercising a right or using a service or a contract”: e.g. a bank screens its customers against a credit reference database in order to decide whether to offer them a loan. 

The WP29 says in the guidelines that: 

“In most cases, a data controller can consider that a processing meeting two criteria would require a DPIA to be carried out. In general, the WP29 considers that the more criteria are met by the processing, the more likely it is to present a high risk to the rights and freedoms of data subjects, and therefore to require a DPIA, regardless of the measures which the controller envisages to adopt. 

However, in some cases, a data controller can consider that a processing meeting only one of these criteria requires a DPIA.” 

The guidelines also contain a non-exhaustive list of data processing activities where a DPIA is required and where a DPIA is not required. 

Examples where a DPIA is required: 

- a hospital processing its patients’ health data;

- a company systematically monitoring its employees’ activities, including the monitoring of the employees’ work station, internet activity;

- a company gathering social media data for generating profiles;

- a company storing (for archiving purpose) pseudonymised personal sensitive data concerning vulnerable data subjects of research projects or clinical trials. 

The WP29 adds that even if a data processing activity falls under any of the above criteria, it may still be that no DPIA is required provided that the data processing is not likely to result in a high risk. In such a case, however, the controller must document the reasons for not having to prepare a DPIA. 

Examples where a DPIA is not required: 

- processing of “personal data from patients or clients by an individual physician, other health care professional or lawyer”;

- an online magazine using a mailing list to send a daily digest to its subscribers. 

The WP29 recommends that when it is not clear if a DPIA must be prepared, the controller is advised to prepare one. 

6. What about processing operations that exist prior to 25 May 2018?

The GDPR provides that if a DPIA must be carried out, it must be carried out prior to the processing. Thus, one may come to the conclusion that no DPIA is required in regard of a data processing operation that is already underway prior to 25 May 2018 since it is not possible to prepare a DPIA prior to a processing which is already ongoing. However, such a conclusion should be treated with caution. The WP29 stresses that: 

“As a matter of good practice, a DPIA should be continuously reviewed and regularly re-assessed. Therefore, even if a DPIA is not required on 25 May 2018, it will be necessary, at the appropriate time, for the controller to conduct such a DPIA as part of its general accountability obligations.” 

Having the above in mind, in line with the principle of accountability, it is advisable to prepare an analysis in regard of the data processing operations as to whether or not a DPIA is required and if the analysis concludes that a DPIA is required, it is certainly recommended preparing one prior to 25 May 2018. Furthermore, even if the conclusion is that no DPIA is required, a regular monitoring and re-assessment of the analysis is required since risks may change over time and a DPIA may become required.

7. What does a DPIA have to contain?

The GDPR enlists the minimum elements a DPIA must contain, which are as follows: 

(a) a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller; 

(b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes; 

(c) an assessment of the risks to the rights and freedoms of data subjects; and 

(d) the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with the GDPR taking into account the rights and legitimate interests of data subjects and other persons concerned. 

The GDPR contains no rules as to the methodology of preparing a DPIA. However, the guidelines contain a non-exhaustive list of methodologies developed by certain DPAs (the UK, German, French and Spanish DPAs) and names also two-sector specific methodologies, namely, the DPIA framework for Radio Frequency Identification (RFID) applications and smart metering systems. 

The DPIA framework for RFID Applications ­specifies the issues as named under question 8 below, which must be addressed when it comes to preparing a DPIA. For details, please see the response to question 8.

8. How should a DPIA be prepared?

The GDPR only contains the minimum elements a DPIA must include but contains no rules as to the methodology. 

Furthermore, it is worth noting that Recital 90 of the GDPR contains some additional useful guidance as to what a DPIA must contain and assess. Namely, when preparing a DPIA, 

(a) the “nature, scope, context and purposes of the processing and the sources of the risk” must be identified and taken into account; 

(b) it is important to “assess the particular likelihood and severity of the high risk” and 

(c) it is essential to properly treat the risks. 

Although, the DPIA framework for RFID applications was tailor-made for RFID applications, it contains useful and practical information that controllers may find very helpful. Under the DPIA framework for RFID applications, the following issues must be addressed in a DPIA: 

(a) description of the data processing operations (overview of processing, who processes the data, what is the purpose of and legal basis for processing, where are the data stored, where are the data transferred to, who has access to the data, what is the duration of processing); 

(b) identification and evaluation of the privacy risks (what are the risks, what is the likelihood of the risks, what is the severity level of the risks); 

Below is a non-exhaustive list of possible privacy risks: 

- the purpose of data collection has not been specified, more data is used than necessary;

- the information given to data subjects is incomplete;

- the combination of data with other data to an extent that is not necessary to achieve the purpose of processing;

- the data is retained longer than necessary;

- some data are secretly recorded, i.e. without the knowledge of the data subject;

- the data subject cannot object to processing or exercise other rights;

- access rights are not revoked when they are no longer necessary;

- data subjects are not informed about the logics of automated individual decision-making;

- a suspicious number of attempts to authenticate are not prevented;

- there is no valid legal basis for processing;

- the implemented logging mechanism is insufficient. 

(c) measures to mitigate risks (what are the measures the controller takes to mitigate risks); 

Below is a non-exhaustive list of possible mitigating measures: 

- appropriate privacy policy is in place;

- access rights are properly set and implemented;

- appropriate data retention policy is in place;

- appropriate IT security measures are in place. 

(d) if there are any residual risks (if any risk remain despite the taking of mitigating measures); 

(e) implementation of measures and the drawing of consequences. 

The DPA in the UK, i.e. the Information Commissioner’s Office (ICO) issued a document named “Conducting privacy impact assessments, Code of Practice” in February 2014 and it basically follows the same logic as the DPIA framework described above.

9. Are controllers required to keep the DPIA up to date?

Yes. Pursuant to the GDPR, “where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change of the risk represented by processing operations.”

As the WP29 puts it, “carrying out a DPIA is a continual process, not a one-time exercise.” The DPIA is regarded as an important tool for compliance, “a process for building and demonstrating compliance” and it should be continuously reviewed and regularly re-assessed.

10. Does a data protection officer (DPO) have any task concerning a DPIA?

If the controller has a data protection officer (DPO), the controller is required to seek the advice of the data protection officer when carrying out a DPIA. Thus, the DPO may also have an essential role in preparing a DPIA. If the controller does not take the advice of the DPO, this fact and the reasons for not taking the advice have to be documented.

Also, it is advisable to include a provision in the agreement the controller has with the DPO pursuant to which the DPO is required to assist the controller in every way in connection with the DPIA, including also the preparation of the same.

11. Is the controller required to publish the DPIA?

No. However, the controller may decide to publish the DPIA or the most important findings of it (of course, without revealing any business secrets of sensitive information) on its website to demonstrate compliance.

In my next post, I will address issues concerning seeking the views of data subjects and prior consultation with the supervisory authority.

Zoltán Balázs Kovács, J.D. (LL.M.), Partner, Szecskay Attorneys at Law, Budapest, Hungary (zoltan.kovacs@szecskay.com)

The contents of this post are intended to provide only a general overview of the subject matter and do not qualify as legal advice.

Az adatvédelmi hatásvizsgálat I (Az adatvédelmi hatásvizsgálat elkészítése)

A GDPR előírásokat tartalmaz arra vonatkozóan, hogy az adatkezelők mikor kötelesek adatvédelmi hatásvizsgálatot (DPIA) készíteni, mikor kötelesek kikérni az érintettek vagy képviselőik véleményét a tervezett adatkezelésről, továbbá, mikor kötelesek konzultálni a felügyeleti hatósággal az adatkezelést megelőzően.

A 29. cikk alapján létrehozott Adatvédelmi Munkacsoport (WP29) 2017. április 4-én iránymutatást adott ki az adatvédelmi hatásvizsgálatról (WP248), amelyet 2017. október 4-én felülvizsgált, és amely a GDPR vonatkozó rendelkezéseinek (35-36. cikk és a (75)-(76), (84) és (90)-(95) preambulumbekezdések) értelmezéséről szól.

Az alábbiakban kérdések és válaszok formájában foglalom össze az adatvédelmi hatásvizsgálat elkészítésére vonatkozó előírásokat.

1. Ki köteles adatvédelmi hatásvizsgálatot készíteni?

A GDPR alapján az adatkezelőt terheli az adatvédelmi hatásvizsgálat elkészítésének kötelezettsége.

Érdemes megjegyezni, hogy amennyiben az adatkezelőnek van adatvédelmi tisztviselője (DPO-ja), akkor az adatkezelő az adatvédelmi hatásvizsgálat elvégzésekor köteles kikérni az adatvédelmi tisztviselő szakmai tanácsát. Így az adatvédelmi tisztviselőnek szintén fontos szerepe lehet az adatvédelmi hatásvizsgálat elkészítésében. Erre való tekintettel, érdemes egy olyan rendelkezést beemelni az adatvédelmi tisztviselővel kötött szerződésbe, amelynek értelmében az adatvédelmi tisztviselő köteles minden módon segíteni az adatkezelőt az adatvédelmi hatásvizsgálattal kapcsolatosan, beleértve annak elkészítését is.

2. Az adatfeldolgozó terheli bármilyen kötelezettség az adatvédelmi hatásvizsgálattal kapcsolatosan?

A GDPR alapján az adatkezelő és az adatfeldolgozó közötti szerződésnek tartalmaznia kell egy olyan kikötést, amely szerint az adatfeldolgozó köteles segíteni az adatkezelőt bizonyos, többek között az adatvédelmi hatásvizsgálattal kapcsolatos kötelezettségek teljesítésében, figyelembe véve az adatkezelés jellegét és az adatfeldolgozó rendelkezésére álló információkat.

3. Mikor kötelező adatvédelmi hatásvizsgálat készítése?

Adatvédelmi hatásvizsgálat készítése akkor kötelező, ha az adatkezelés “valószínűsíthetően magas kockázattal jár a természetes személyek jogaira és szabadságaira nézve”, kivéve, ha az adatkezelés szerepel azon adatkezelési tevékenységek jegyzékében, amelyek vonatkozásában nem szükséges adatvédelmi hatásvizsgálatot készíteni (35. cikk (5) bekezdés) vagy, ha bizonyos feltételeknek megfelelő uniós vagy tagállami jog alapján nem szükséges adatvédelmi hatásvizsgálatot készíteni (35. cikk (10) bekezdés). 

Az adatvédelmi hatásvizsgálat a kockázatok kezeléséről, azok megfelelő kezeléséről szól. Az adatvédelmi hatásvizsgálat célja, hogy a természetes személyek jogaira és szabadságaira nézve fennálló kockázatokat minimalizálja. Ahogyan a WP29 írja, „a „kockázat” olyan eshetőség, amely a súlyosság és valószínűség szempontjából jellemez valamilyen eseményt és annak következményeit”. Továbbá, a kockázatkezelés „összehangolt tevékenységek összességeként határozható meg, amelyek célja egy szervezet kockázati szempontú irányítása és ellenőrzése.” 

Fontos kiemelni, hogy az adatkezelők akkor is kötelesek megfelelő intézkedéseket tenni a kockázat elfogadható szintjének biztosítása érdekében, ha nem áll fenn az adatvédelmi hatásvizsgálat elkészítésének kötelezettsége. Úgyszintén hangsúlyozza a WP29 azt, hogy az elszámoltathatóság elvével összhangban az adatkezelők kötelesek folyamatosan értékelni az adatkezelési tevékenységeikből eredő kockázatokat, hogy felismerjék, ha az adatkezelés valamely fajtája „valószínűsíthetően magas kockázattal jár a természetes személyek jogaira és szabadságaira nézve”. 

További részletekért ld. az 5. kérdésre adott választ.

4. Mely időpontban kötelező az adatvédelmi hatásvizsgálat elkészítése?

A GDPR egyértelműen azt írja elő, hogy az adatvédelmi hatásvizsgálatot az adatkezelést megelőzően kell elkészíteni, amennyiben fennállnak a 3. és 5. kérdésben meghatározott feltételek. Így a beépített és az alapértelmezett adatvédelem elvének megfelelően az adatkezelők számára feltétlenül ajánlott az előre tervezés és annak figyelembe vétele, hogy egy tervezett adatkezelési tevékenység adatvédelmi hatásvizsgálat elkészítését teheti szükségessé, amely időbe telik. 

5. Mikor jár az adatkezelés “valószínűsíthetően magas kockázattal”?

A GDPR nem tartalmaz erre vonatkozóan kifejezett rendelkezést, azonban némi iránymutatással szolgál és felsorolja a három alábbi esetkört, amikor kötelező adatvédelmi hatásvizsgálat készítése: 

„(a) természetes személyekre vonatkozó egyes személyes jellemzők olyan módszeres és kiterjedt értékelése, amely automatizált adatkezelésen – ideértve a profilalkotást is – alapul, és amelyre a természetes személy tekintetében joghatással bíró vagy a természetes személyt hasonlóképpen jelentős mértékben érintő döntések épülnek; 

(b) személyes adatok különleges kategóriáinak (pl. egészségügyi adatok, büntetőjogi felelősség megállapítására vonatkozó személyes adatok) nagy számban történő kezelése; vagy 

(c) nyilvános helyek nagymértékű, módszeres megfigyelése.” 

Ez a lista nem teljeskörű, így lehetnek egyéb olyan adatkezelési tevékenységek, amelyeket nem tartalmaz a felsorolás. A WP29 kidolgozott egy olyan listát, amelyen az a kilenc kritérium szerepel, amelyeket figyelembe kell venni annak eldöntése érdekében, hogy szükséges-e adatvédelmi hatásvizsgálatot készíteni. Ez a kilenc feltétel a következő: 

(i) értékelés vagy pontozás (pl. profilozás), különösen “az érintett munkahelyi teljesítményére, gazdasági helyzetére, egészségi állapotára, személyes preferenciáira vagy érdeklődési köreire, megbízhatóságára vagy viselkedésére, tartózkodási helyére vagy mozgására vonatkozó jellemzők” (a GDPR (71) és (91) preambulumbekezdései) alapján. Példák: pénzügyi vállalkozás, amely hitelreferencia és pénzmosás elleni adatbázist használ ügyfelei szűrésére; vállalkozás, amely üzletszerzési profilokat készít a honlapjának böngészése alapján. 

(ii) joghatással vagy hasonló jelentős hatással járó automatizált döntéshozatal: adatkezelés, amelynek célja a „természetes személy tekintetében joghatással bíró” vagy „a természetes személyt hasonlóképpen jelentős mértékben érintő” döntések meghozatala. 

(iii) módszeres megfigyelés: pl. hálózatokon keresztül gyűjtött adatok. Az adatok olyan módon gyűjthetők, hogy az érintettek adott esetben nem tudják, ki gyűjti és hogyan használja fel adataikat. 

(iv) különleges adatok vagy fokozottan személyes jellegű adatok: pl. egészségügyi / orvosi adatok, politikai véleményre, vallásra vonatkozó adatok, büntetőjogi felelősségre vonatkozó adatok, pénzügyi adatok vagy személyes dokumentumok, naplók. 

(v) adatok nagy számban történő kezelése: a GDPR nem határozza meg a „nagy számban történő” kifejezést. Azonban a WP29 ad némi támpontot a kifejezés jelentéséhez az adatvédelmi tisztviselőről (DPO) szóló iránymutatásában. A részletekért kattintson ide.

Annak eldöntéséhez, hogy adatok nagy számban történő kezeléséről van-e szó az alábbi szempontokat kell figyelembe venni: 

- az érintettek száma konkrét számadatként vagy a lakosság arányában;

- a kezelt adatok mennyisége vagy adatfajták köre;

- az adatkezelési tevékenység időtartama vagy állandó jellege;

- az adatkezelési tevékenység földrajzi kiterjedése. 

(vi) adatkészletek összevonása: pl. két olyan adatkészlet összevonása, amelyek különböző célokból felvett adatokat tartalmaznak. 

(vii) sérülékeny érintettek adatai: pl. gyermekek, idősek, munkavállalók, betegek vagy olyan személyek adatainak kezelése, akik tekintetében az adatkezelő és az érintettek közötti kapcsolatban egyenlőtlen helyzet alakul ki. 

(viii) új technológiai és szervezési megoldása innovatív használata: pl. ujjlenyomat- és arcfelismerés együttes használata a hatékonyabb beléptetés érdekében. Az új technológia használata magasabb kockázatot jelenthet az érintettek jogaira és szabadságaira nézve, mert az ilyen új technológia használatának lehetséges következményei nem feltétlen ismertek. A WP29 kiemeli, hogy a „dolgok internetét” (IoT) használó alkalmazások szükségessé tehetik az adatvédelmi hatásvizsgálat elvégzését. 

(ix) adatkezelés, amely önmagában “megakadályozza, hogy az érintettek a jogaikat gyakorolják vagy szolgáltatásokat vegyenek igénybe vagy szerződést érvényesítsenek”: pl. egy bank hitelreferencia adatbázis alapján szűri ügyfeleit, hogy eldöntse, kínál-e nekik hitelt. 

A WP29 iránymutatás értemében 

“Az esetek többségében az adatkezelő tekintheti úgy, hogy két szempontnak megfelelő adatkezelés esetében szükség van adatvédelmi hatásvizsgálatra. A 29. cikk szerinti adatvédelmi munkacsoport általában véve úgy véli, hogy minél több szempontnak felel meg az adatkezelés, annál nagyobb a valószínűsége annak, hogy az magas kockázattal jár az érintettek jogaira és szabadságaira nézve, így az adatkezelő által végrehajtani tervezett intézkedésektől függetlenül szükséges az adatvédelmi hatásvizsgálat elvégzése. 

Bizonyos esetekben azonban az adatkezelő tekintheti úgy, hogy a mindössze egy szempontnak megfelelő adatkezelés esetében is szükség van adatvédelmi hatásvizsgálatra.” 

Az iránymutatás tartalmaz egy nem teljeskörű listát azon adatkezelési tevékenységekről, amelyek esetében szükséges, illetve nem szükséges adatvédelmi hatásvizsgálatot végezni. 

Példák arra, amikor szükséges adatvédelmi hatásvizsgálatot végezni: 

- betegek egészségügyi adatait kezelő kórház;

- munkavállalói tevékenységeit módszeresen megfigyelő, így az alkalmazottak munkaállomását, internetes tevékenységeit nyomon követő vállalkozás;

- a közösségi médiából származó adatok gyűjtése profilalkotás céljából;

- kutatási projektekben vagy klinikai vizsgálatokban részt vevő, kiszolgáltatott helyzetben lévő érintettekkel kapcsolatos, álnevesített, különleges személyes adatok tárolása (archiválás céljából). 

A WP29 hozzáteszi, hogy abban az esetben is, ha egy adatkezelés a fenti szempontok bármelyikét teljesíti, akkor is lehetséges, hogy nem szükséges adatvédelmi hatásvizsgálatot végezni, amennyiben az adatkezelés valószínűsíthetően nem jár magas kockázattal az érintettek jogaira és szabadságaira nézve. Ilyen esetben az adatkezelő köteles dokumentálni annak okát, hogy miért nem készített adatvédelmi hatásvizsgálatot. 

Példák arra, amikor nem szükséges adatvédelmi hatásvizsgálatot végezni: 

- „egy adott szakorvos, egészségügyi szakember betegei vagy egy adott ügyvéd ügyfelei személyes adatainak” kezelése;

- a feliratkozóknak napi sajtószemle küldéséhez levelezőlistát használó internetes magazin. 

A WP29 ajánlása szerint, amennyiben nem egyértelmű, hogy szükséges-e adatvédelmi hatásvizsgálatot végezni, akkor ajánlatos az adatkezelőnek elkészíteni azt.

6. Mi a helyzet azokkal az adatkezelésekkel, amelyek 2018. május 25-e előtt már folynak?

A GDPR értelmében, amennyiben adatvédelmi hatásvizsgálatot kell készíteni, akkor azt az adatkezelés előtt kell elkészíteni. Ez alapján arra a következtetésre juthatunk, hogy nem szükséges adatvédelmi hatásvizsgálatot végezni olyan adatkezelési tevékenység vonatkozásában, amely 2018. május 25-e előtt már folyamatban van, mivel nem lehetséges adatvédelmi hatásvizsgálatot készíteni egy már folyamatban lévő adatkezelést megelőzően. Azonban egy ilyen következtetést óvatosan kell kezelni. A WP29 hangsúlyozza, hogy 

„Az adatvédelmi hatásvizsgálatot érdemes folyamatosan felülvizsgálni, és rendszeresen újraértékelni. Jóllehet tehát, hogy még, ha 2018. május 25-ig nincs is szükség adatvédelmi hatásvizsgálatra, az adatkezelőnek az általános elszámoltathatósági kötelezettségei részeként el kell majd végeznie azt a megfelelő időben.” 

A fentieket figyelembe véve, az elszámoltathatóság elvével összhangban, ajánlott elemzést készíteni arról, hogy szükséges-e adatvédelmi hatásvizsgálatot készíteni és, amennyiben az elemzés arra a következtetésre jut, hogy szükséges, akkor feltétlen ajánlott elkészíteni azt 2018. május 25-ét megelőzően. Továbbá, még abban az esetben is, ha az a következtetés, hogy nem szükséges hatásvizsgálatot készíteni, az elemzés folyamatos figyelemmel kísérése és újraértékelése szükséges, tekintettel arra, hogy a kockázatok idővel változhatnak, és adatvédelmi hatásvizsgálat válhat szükségessé.

7. Mit kell tartalmaznia az adatvédelmi hatásvizsgálatnak?

A GDPR felsorolja azokat a tartalmi elemeket, amelyeket az adatvédelmi hatásvizsgálatnak mindenképpen tartalmaznia kell, amelyek a következők: 

(a) a tervezett adatkezelési műveletek és az adatkezelés céljainak módszeres leírása, beleértve adott esetben az adatkezelő által érvényesíteni kívánt jogos érdeket; 

(b) az adatkezelés céljaira figyelemmel az adatkezelési műveletek szükségességi és arányossági vizsgálata; 

(c) az érintett jogait és szabadságait érintő kockázatok vizsgálata; és 

(d) a kockázatok kezelését célzó intézkedések bemutatása, ideértve a személyes adatok védelmét és az e rendelettel való összhang igazolását szolgáló, az érintettek és más személyek jogait és jogos érdekeit figyelembe vevő garanciákat, biztonsági intézkedéseket és mechanizmusokat. 

A GDPR nem tartalmaz rendelkezést a hatásvizsgálat elkészítésének módszertanára vonatkozóan. Azonban az iránymutatás tartalmaz egy nem teljeskörű listát az egyes adatvédelmi hatóságok (angol, német, francia és spanyol adatvédelmi hatóságok) által kialakított, továbbá két szektor-specifikus módszertanról (jelesül a rádió frekvenciás (RFID) alkalmazások és az okos fogyasztásmérők adatvédelmi hatásvizsgálati sablonja). 

Az RFID alkalmazások adatvédelmi hatásvizsgálati sablonja megnevezi azokat a 8. kérdésben felsorolt szempontokat, amelyeket az adatvédelmi hatásvizsgálatnak tartalmaznia kell. Részletekért, ld. a 8. kérdésre adott választ.

8. Hogyan kell elkészíteni az adatvédelmi hatásvizsgálatot?

A GDPR csak azokat a tartalmi elemeket sorolja fel, amelyeket az adatvédelmi hatásvizsgálatnak mindenképpen tartalmaznia kell, azonban nem tartalmaz rendelkezést módszertanra. 

Érdemes megemlíteni továbbá, hogy a GDPR (90) preambulumbekezdése további hasznos iránymutatásokat tartalmaz abban a tekintetben, hogy mit kell tartalmaznia és elemeznie az adatvédelmi hatásvizsgálatnak. Nevezetesen, az adatvédelmi hatásvizsgálat készítésekor, 

(a) „az adatkezelés jellegét, hatókörét, körülményeit és céljait, valamint a kockázat forrásait” azonosítani kell és figyelembe kell venni; 

(b) fel kell mérni a „magas kockázat különös valószínűségét és súlyosságát”; 

(c) a kockázatokat megfelelően kell kezelni.” 

Jóllehet az RFID alkalmazások adatvédelmi hatásvizsgálati sablonja értelemszerűen az RFID alkalmazásokhoz készült, az hasznos és gyakorlatias információkat tartalmaz, amelyek az adatkezelők részére segítséget jelenthetnek. Az RFID alkalmazások adatvédelmi hatásvizsgálati sablonja alapján a következő kérdéseket kell kezelni az adatvédelmi hatásvizsgálatban: 

(a) az adatkezelési tevékenységek leírása (az adatkezelés áttekintő leírása, ki kezeli az adatokat, mi az adatkezelés célja és jogalapja, hol tárolják az adatokat, hova továbbítják az adatokat, kinek van hozzáférése az adatokhoz, mi az adatkezelés időtartama); 

(b) a kockázatok azonosítása és értékelése (mik a kockázatok, mi a kockázat valószínűsége, mi a kockázat súlyossági foka); 

Lehetséges kockázatok: 

- az adatgyűjtés célja nem lett meghatározva, a szükségesnél több adatot kezelnek;

- az érintettnek adott tájékoztatás nem teljeskörű;

- az adatok olyan adatokkal való együttes használata, amelyek nem szükségesek az adatkezelés céljának eléréséhez;

- az adatokat a szükségesnél tovább tárolják;

- egyes adatokat titkosan, azaz az érintett tudta nélkül vesznek fel;

- az érintett nem tud tiltakozni az adatkezelés ellen, illetőleg nem tudja gyakorolni a jogait;

- a hozzáférési jogokat nem vonják vissza miután azokra már nincs szükség;

- az érintetteket nem tájékoztatják az automatizált döntéshozatalhoz használt logikáról;

- gyanús mennyiségű, adatokhoz való hozzáférési kísérletet nem akadályoznak meg;

- az adatkezelésnek nincs megfelelő jogalapja;

- az alkalmazott „logolás” nem megfelelő. 

(c) a kockázatok csökkentését célzó intézkedések (melyek az adatkezelő által a kockázatok csökkentése érdekében tett intézkedések); 

Lehetséges csökkentő intézkedések: 

- megfelelő adatkezelési szabályzat alkalmazása;

- a hozzáférési jogok megfelelő kialakítása;

- megfelelő adatmegőrzési szabályzat alkalmazása;

- megfelelő IT biztonsági szabályzat alkalmazása. 

(d) vannak-e fennmaradó kockázatok (a kockázatokat csökkentő intézkedések ellenére maradnak-e fenn kockázatok); 

(e) intézkedések végrehajtása és a következtetések levonása. 

Az angol adatvédelmi hatóság (ICO) 2014. februárjában kiadott egy “Adatvédelmi hatásvizsgálatok elvégzése, Gyakorlati Útmutató” elnevezésű dokumentumot, amelynek logikája lényegében megegyezik az RFID alkalmazások adatvédelmi hatásvizsgálati sablonjáéval.

9. Kötelesek az adatkezelők naprakészen tartani az adatvédelmi hatásvizsgálatot?

Igen. A GDPR értelmében “az adatkezelő szükség szerint, legalább az adatkezelési műveletek által jelentett kockázat változása esetén ellenőrzést folytat le annak értékelése céljából, hogy a személyes adatok kezelése az adatvédelmi hatásvizsgálatnak megfelelően történik-e.”

A WP29 megfogalmazásában, “az adatvédelmi hatásvizsgálatot nem egyetlen alkalommal, hanem folyamatosan kell végezni.” Az adatvédelmi hatásvizsgálat a megfelelés egy fontos eszköze, “az adatvédelmi hatásvizsgálat tehát a rendelet betartásának elérésére és bizonyítására szolgáló eljárás” és azt folyamatosan figyelemmel kell kísérni és rendszeresen újra kell értékelni.

10. Az adatvédelmi tisztviselőnek van kötelezettsége az adatvédelmi hatásvizsgálattal kapcsolatban?

Ha az adatkezelőnek van adatvédelmi tisztviselője (DPO-ja), akkor az adatkezelő az adatvédelmi hatásvizsgálat elvégzésekor köteles kikérni az adatvédelmi tisztviselő szakmai tanácsát. Így az adatvédelmi tisztviselőnek szintén fontos szerepe lehet az adatvédelmi hatásvizsgálat elkészítésében. Amennyiben az adatkezelő nem fogadja meg az adatvédelmi tisztviselő tanácsát, akkor köteles annak tényét és a meg nem fogadás indokát dokumentálni.

Érdemes egy olyan rendelkezést beemelni az adatkezelő és az adatvédelmi tisztviselő közötti szerződésbe, amelynek értelmében az adatvédelmi tisztviselő köteles minden módon segíteni az adatkezelőt az adatvédelmi hatásvizsgálattal kapcsolatosan, beleértve annak elkészítését is.

11. Köteles az adatkezelő nyilvánosságra hozni az adatvédelmi hatásvizsgálatot?

Nem. Az adatkezelő azonban dönthet úgy, hogy a honlapján nyilvánosságra hozza az adatvédelmi hatásvizsgálatot vagy annak lényegi megállapításait (természetesen üzleti titkok vagy üzleti szempontból bizalmas információk megosztása nélkül) abból a célból, hogy ezáltal is igazolja a megfelelést.

A következő bejegyzésemben az érintettek véleményének kikérésével és a felügyeleti hatósággal való konzultációval kapcsolatos kérdéseket fogom körüljárni.

dr. Kovács Zoltán Balázs (LL.M.), Partner, Szecskay Ügyvédi Iroda, Budapest (zoltan.kovacs@szecskay.com)

A jelen bejegyzés általános áttekintést kíván nyújtani a körüljárt kérdésekkel kapcsolatban és nem minősül jogi tanácsadásnak.

Az adatvédelmi incidens III. (Az adatvédelmi incidensek nyilvántartása)

A GDPR meghatározza az adatvédelmi incidens fogalmát és szabályozza azt, hogy az adatkezelők mely esetekben kötelesek bejelenteni az adatvédelmi incidenst az illetékes felügyeleti hatóságoknak, valamint mikor kötelesek tájékoztatni az érintetteket az adatvédelmi incidensről. Az adatkezelők kötelesek továbbá nyilvántartást vezetni az adatvédelmi incidensekről. Úgyszintén, az adatfeldolgozók kötelesek az adatvédelmi incidenst, az arról való tudomásszerzését követően indokolatlan késedelem nélkül bejelenti az adatkezelőnek.

A 29. cikk alapján létrehozott Adatvédelmi Munkacsoport (WP29) 2017. október 3-án iránymutatást adott ki az adatvédelmi incidens bejelentésről, amelynek véglegesítése folyamatban van és amely a GDPR vonatkozó rendelkezéseinek (33-34. cikk és a (75)-(76), továbbá (85)-(88) preambulumbekezdések) értelmezéséről szól, valamint lehetséges adatvédelmi incidensekre hoz példákat.

Az alábbiakban kérdések és válaszok formájában foglalom össze az adatvédelmi incidensek nyilvántartására vonatkozó előírásokat. A blogom két külön bejegyzése foglalkozik az adatvédelmi incidensek felügyeleti hatóság felé történő bejelentésével, illetve az érintettek adatvédelmi incidensről való tájékoztatásával.

1. Ki köteles nyilvántartást vezetni az adatvédelmi incidensekről?

A GDPR 33. cikk (5) bekezdése szerint az adatkezelő köteles az adatvédelmi incidensek nyilvántartására. Úgyszintén, a GDPR értelmében az adatkezelő köteles megfelelő technikai és szervezési intézkedéseket végrehajtani annak érdekében, hogy képes legyen a sebezhetőségek és biztonsági incidensek felderítésére és értékelésére. Így, az adatvédelmi incidensek dokumentálásán felül az adatkezelő köteles megfelelő folyamatokat és intézkedéseket alkalmazni abból a célból, hogy a biztonsági incidenseket időben felderítse és kezelje.

Az adatvédelmi incidens nyilvántartás tartalmával kapcsolatosan ld. az alábbi 2. kérdésre adott választ.

A fentieken túl, az elszámoltathatóság elvére tekintettel, az adatfeldolgozók számára javasolt annak dokumentált igazolása, hogy időben tájékoztatták az adatkezelőt az adatvédelmi incidensről. Ilyen módon az adatfeldolgozók képesek lehetnek annak igazolására, hogy a tudomásszerzést követően indokolatlan késedelem nélkül tájékoztatták az adatkezelőt az adatvédelmi incidensről, ahogyan azt a GDPR 33. cikk (2) bekezdése megkívánja. Ezen kötelezettség teljesítésének előfeltétele, hogy az adatfeldolgozók megfelelő technikai és szervezési intézkedéseket hajtsanak végre annak érdekében, hogy időben azonosítani tudják a biztonsági incidenseket és meg tudják állapítani azt, hogy a biztonsági incidens adatvédelmi incidensnek minősül-e. Az adatvédelmi incidensről ezt követően tájékoztatni kell az adatkezelőt. Mindez azt jelenti, hogy az adatfeldolgozóknak szükségképpen képesnek kell lenniük annak kielemzésére, hogy egy biztonsági incidens adatvédelmi incidensnek minősül-e. Ezt az elemzést dokumentálni kell.

Az adatkezelő adatvédelmi incidensről való tájékoztatásakor az adatfeldolgozó köteles az adatkezelőt tájékoztatni az adatvédelmi incidenssel kapcsolatos tényekről annak érdekében, hogy az adatkezelő teljesíteni tudja az adatvédelmi incidenssel kapcsolatos kötelezettségeit.

Az adatfeldolgozók számára ajánlott annak figyelembe vétele, hogy egy biztonsági incidens a későbbiekben adatvédelmi incidenssé válhat, amit jelenteni kell az adatkezelő részére. Ha az adatfeldolgozó nem tudja eldönteni azt, hogy egy biztonsági incidens adatvédelmi incidensnek minősül-e vagy, ha a biztonsági incidens később adatvédelmi incidenssé válhat, akkor javasolt időben tájékoztatni az adatkezelőt az incidensről.

2. Az adatfeldolgozóknak van kötelezettsége az adatvédelmi incidenssel kapcsolatban?

Ld. a fenti 1. kérdésre adott választ.

3. Hogyan köteles az adatkezelő dokumentálni az adatvédelmi incidenst?

Az adatkezelő számára ajánlott külön nyilvántartást vezetni az adatvédelmi incidensekről. Például, egy Excel táblázat vagy egy word dokumentum megfelelő lehet erre a célra.

Az adatvédelmi nyilvántartás az alábbiakat tartalmazza

a) az adatvédelmi incidenshez kapcsolódó tények, így például azt, hogy mikor történt az incidens, mikor fedezték azt fel, annak leírása, hogy mi történt (tények és körülmények), az érintettek leírása, milyen személyes adatokat érintett az incidens, az adatvédelmi incidens okának leírása;

b) az adatvédelmi incidens hatásai, azaz mik az adatvédelmi incidens (valószínű) kockázatai / következményei;

c) az orvoslásra tett intézkedések leírása, azaz az orvoslásra tett intézkedések listája, a konkrét intézkedések megtételének indokai és az intézkedések hatásai. 

Ha az adatkezelő nem tájékoztatta a hatóságot / az érintetteket az adatvédelmi incidensről, akkor az adatvédelmi incidensek nyilvántartásában javasolt feltüntetni ennek indokát és magyarázatát. 

Úgyszintén javasolt dokumentálni a biztonsági incidens kivizsgálásának eljárását és az adatvédelmi incidens által a természetes személyek jogaira és szabadságaira nézve jelentett lehetséges kockázatok értékelésének módszertanát. Mindez azért fontos, hogy az adatkezelő képes legyen a megfelelés igazolására.

4. Köteles az adatkezelő / adatfeldolgozó adatvédelmi incidens szabályzatot készíteni?

A GDPR nem tartalmaz olyan konkrét előírást, amely szerint az adatkezelők és adatfeldolgozók kötelesek lennének ilyen szabályzatot készíteni. Azonban a GDPR alapján az adatkezelő és az adatfeldolgozók megfelelő technikai és szervezési intézkedéseket hajtanak végre annak érdekében, hogy a kockázat mértékének megfelelő szintű adatbiztonságot garantálják, ideértve, többek között, adott esetben:

a) a személyes adatok álnevesítését és titkosítását;

b) a személyes adatok kezelésére használt rendszerek és szolgáltatások folyamatos bizalmas jellegének biztosítását, integritását, rendelkezésre állását és ellenálló képességét;

c) fizikai vagy műszaki incidens esetén az arra való képességet, hogy a személyes adatokhoz való hozzáférést és az adatok rendelkezésre állását kellő időben vissza lehet állítani;

d) az adatkezelés biztonságának garantálására hozott technikai és szervezési intézkedések hatékonyságának rendszeres tesztelésére, felmérésére és értékelésére szolgáló eljárást.

Továbbá, az elszámoltathatóság elve alapján az adatkezelőknek és az adatfeldolgozóknak képesnek kell lenniük a GDPR-nak való megfelelés igazolására. Ez lényegében azt jelenti, hogy minden, az adatkezelő / adatfeldolgozó által megtett lépést dokumentálni kell.

A fentiek figyelembe vétele alapján, a GDPR követelményeinek való megfelelés érdekében mindenképpen javasolt, hogy az adatkezelők és adatfeldolgozók rendelkezzenek adatvédelmi incidens szabályzattal, amely tartalmazza az incidenssel kapcsolatos intézkedési tervet is. A munkavállalók adatvédelmi tudatosságának biztosítása érdekében tájékoztatni kell őket a szabályzatról és az intézkedési tervről, ezen tájékoztatást pedig dokumentálni kell. Rendszeres oktatás tartása javasolt.

5. Jellemzően mit tartalmaz az incidens szabályzat?

Az incidens szabályzat jellemzően az alábbi kérdésekkel foglalkozik:

a) a biztonsági incidens és az adatvédelmi incidens fogalma;

b) a szabályzat céljának leírása (az incidensek megelőzése és azok megfelelő kezelése);

c) a végrehajtott technikai és szervezési intézkedések leírása;

d) a belső jelentési eljárás leírása (hogyan történik az incidens jelentése);

e) az incidens belső kivizsgálásának leírása (az alkalmazott módszertan, a kockázat értékelési folyamat);

f) az intézkedési terv leírása, orvoslásra tett intézkedések;

g) az adatvédelmi incidens felügyeleti hatóság felé történő bejelentésével kapcsolatos kérdések;

h) az érintettek adatvédelmi incidensről való tájékoztatásával kapcsolatos kérdések;

i) az adatvédelmi incidensek nyilvántartásának leírása;

j) a fenti g), h) és i) pontokban foglaltak folyamatábrája;

k) az adatvédelmi incidensek utó-monitoringolása és az incidensből levont tapasztalatok.

A fenti lista csupán az incidens szabályzatban jellemzően szereplő kérdések nem kimerítő felsorolását tartalmazza.

6. Milyen szerepe van az adatvédelmi tisztviselőnek az adatvédelmi incidenssel kapcsolatban?

Ha az adatkezelő / adatfeldolgozó rendelkezik adatvédelmi tisztviselővel (DPO), a DPO fontos szerepet játszik az adatvédelmi incidensekkel kapcsolatban. Jelesül, a DPO együttműködik a felügyeleti hatósággal és kapcsolattartó pontként szolgál a felügyeleti hatóságok és az érintettek felé. Lehetőség van arra, hogy a DPO-val kötött szerződés tartalmazzon egy olyan kikötést, amely szerint a DPO köteles segíteni az adatkezelőt / adatfeldolgozót az incidens azonosításában és értékelésében, a konkrét kockázatelemzés elkészítésében és a felügyeleti hatóságok és az érintettek tájékoztatásában. Az adatvédelmi tisztviselővel kapcsolatos további részletekért, kattintson ide.

A következő bejegyzésemben az adatvédelmi hatásvizsgálattal (DPIA) kapcsolatos kérdéseket fogom körüljárni.

dr. Kovács Zoltán Balázs (LL.M.), Partner, Szecskay Ügyvédi Iroda, Budapest (zoltan.kovacs@szecskay.com)

A jelen bejegyzés általános áttekintést kíván nyújtani a körüljárt kérdésekkel kapcsolatban és nem minősül jogi tanácsadásnak.

The data breach III (Documentation of data breaches)

The GDPR defines the notion of data breach and contains rules on when it is mandatory for controllers to report a data breach to the competent supervisory authority and when they are obliged to communicate data breaches to the data subjects. Controllers are also required to document personal data breaches. In addition, processors are required to notify the controller without undue delay after becoming aware of a personal data breach.

The Article 29 Data Protection Working Party (WP29) issued guidelines on the personal data breach notification on 3 October 2017, which are being finalized, that interpret the respective provisions of the GDPR (Articles 33-34 and Recitals 75-76 and 85-88) and give some examples of possible data breaches.

Below, a Q&A will follow concerning the obligation to document data breaches. My blog contains two previous posts in which I have addressed in a Q&A format the issues concerning notifying the supervisory authorities of data breaches and the communication of data breaches to data subjects, respectively.

1. Who is required to document data breaches?

Pursuant to Article 33 (5) of the GDPR, controllers are required to document data breaches. Also, as per the GDPR, data controllers must have appropriate technical and organisational measures in place and must, therefore, be able to detect and assess vulnerabilities and security breaches. Thus, in addition to documenting data breaches, controllers are also required to implement appropriate procedures and measures to ensure that they are able to timely detect and address security issues.

For details as to the content of the document / register on data breaches, please see the response to question 2 below.

Apart from controllers, due to the principle of accountability, processors are advised to have a documentary proof of the fact that they have notified the controller of the data breach in a timely manner. This way the processors can demonstrate that they have complied with their obligation to notify the controller of the data breach without undue delay after becoming aware of a personal data breach, as required by Article 33 (2) of the GDPR. A prerequisite for the fulfillment of this obligation is that processors must have appropriate technical and organizational measures in place so that they are able to identify security breaches in a timely manner and tell if the security breach qualifies as a data breach. The data breach must then be reported to the controller. This means that processors necessarily have to (be able to) assess and actually carry out the specific assessment if the security breach qualifies as a data breach. The assessment should be documented.

When notifying the controller of the data breach, the processor is required to provide information on the facts relating to the data breach so that the controller is able to fulfill its obligations in connection with the data breach.

Processors are also advised to take into account the fact that a security breach may later turn out to be a data breach which is then reportable to the controller. If a processor is unable to decide if a security breach qualifies as a data breach or if the security breach may later turn out to be a data breach, it is advisable to notify the controller of the breach in time.

2. Do processors have any obligation in connection with data breaches?

Please see the response to question 1 above.

3. How should controllers document data breaches?

The controller is advised to prepare a registry of data breaches. For example, preparing an Excel sheet or word document for this purpose should suffice.

The document on data breaches must contain

a) the facts relating to the personal data breach, such as, for example, the date when the breach occurred and when it was discovered, a description of what happened (facts and circumstances), a description of individuals affected, what personal data have been affected, a description of the cause of the data breach;

b) the effects of the data breach, i.e. what are the (likely) risks / consequences of the data breach and

c) a description of the remedial action(s) taken, i.e. a list of the remedial measures taken, the reasons for taking the specific remedial action(s) and the effects of such actions.

If the controller did not notify the authority / the data subjects of the data breach, it is advisable that the registry of data breaches also contains the reasoning and justification for not making the notification.

It is also highly advisable to also document the procedure concerning how a security breach is addressed and how the potential risks such a breach may pose to the rights and freedoms of natural persons are assessed. This is to ensure that the controller is able to demonstrate compliance with the GDPR.

4. Are controllers / processors required to have a data breach policy?

The GDPR does not contain an explicit provision that requires controllers and processors to prepare such a policy. However, the GDPR requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

a) the pseudonymisation and encryption of personal data;

b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;

c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;

d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing. 

In addition, under the principle of accountability, controllers and also processors must be able to demonstrate compliance with the rules of the GDPR. This basically means that every step the controller / processor takes has to be documented. 

Taking the above into account, in order to comply with the requirements of the GDPR, it is certainly advisable for controllers and processors to have a data breach policy in place, including a breach response plan. In order to ensure data protection awareness among employees, they should be informed of such a policy and response plan and the fact that they have been informed about such a policy and response plan should be documented. Regular training sessions are recommended.

5. What does a breach policy typically contain?

A breach policy typically addresses the below issues:

a) the definition of security breach and data breach;

b) a description of the aim of the policy (prevention of breaches as well as properly addressing them);

c) a description of the implemented technical and organisational measures;

d) a description of the internal reporting procedure (how to report the breach internally);

e) a description of the internal investigation of the breach (methodology applied, risk assessment procedure);

f) a description of a response plan, remedial actions;

g) issues concerning the notification of data breaches to supervisory authorities;

h) issues concerning the communication of data breaches to data subjects;

i) a description of the register of data breaches;

j) a flowchart on clauses g), h) and i) above;

k) a description of the post-monitoring of data breaches and experiences learned from the breach.

The above is only a non-exhaustive list of the issues a breach policy typically contains.

6. What does a data protection officer (DPO) have to do with data breaches?

If the controller / processor has a DPO, the DPO has an important role to play in connection with data breaches. Namely, the DPO cooperates with the supervisory authority and acts as a contact point for the supervisory authority and the data subjects. Furthermore, it is possible to include a specific provision in the agreement with the DPO pursuant to which the DPO is required to assist the controller / processor when it comes to identifying and assessing a breach, preparing the actual risk assessment and making the notification to the supervisory authorities and the data subjects. For further details on the DPO, please click here.

In my next post, I will address issues concerning data protection impact assessments (DPIA).

Zoltán Balázs Kovács, J.D. (LL.M.), Partner, Szecskay Attorneys at Law, Budapest, Hungary (zoltan.kovacs@szecskay.com)

The contents of this post are intended to provide only a general overview of the subject matter and do not qualify as legal advice.

The data breach II (Communication of data breach to data subjects)

The GDPR defines the notion of data breach and contains rules on when it is mandatory for controllers to report a data breach to the competent supervisory authority and when they are obliged to communicate such breaches to the data subjects. Controllers are also required to document personal data breaches. In addition, processors are required to notify the controller without undue delay after becoming aware of a personal data breach.

The Article 29 Data Protection Working Party (WP29) issued guidelines on the personal data breach notification on 3 October 2017, which are being finalized, that interpret the respective provisions of the GDPR (Articles 33-34 and Recitals 75-76 and 85-88) and give some examples of possible data breaches.

Below, a Q&A will follow on the issues in relation to communicating the data breaches to data subjects and how to assess if the data breach is likely to result in a high risk to the rights and freedoms of natural persons. A separate post will analyse the obligation to document the data breaches.

1. When do controllers have to communicate the data breach to the data subjects?

When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller is required to communicate the personal data breach to the data subject without undue delay.

It can be established that the threshold for notifying the data subjects of the data breaches is higher than for making a notification to the supervisory authorities since the supervisory authorities must be informed of the data breach unless the data breach is unlikely to result in a risk to the rights and freedoms of natural persons.

2. When is a data breach likely to result in a high risk to the rights and freedoms of natural persons?

The controller is required to assess each breach, i.e. an evaluation needs to be done on a case by case basis. When it comes to evaluating the breach, various factors need to be taken into account, such as e.g.

- the type of breach (confidentiality, integrity or availability);

- the nature, sensitivity and volume of personal data;

- the issue of how easy it is to identify the individuals affected by the data breach;

- the likelihood and severity of consequences for individuals;

- if vulnerable individuals are affected (e.g. children, the elderly, people with disease);

- the number of affected individuals;

- the characteristics of the data controller, its activities.

The WP29 provides examples of data breaches which trigger a notification obligation. For example, if

- personal data of individuals are stolen from a secure website;

- a controller experiences a ransomware attack resulting in personal data being encrypted;

- an individual calls the bank and reports that she has received a monthly statement for someone else;

- medical records in a hospital are unavailable for several hours due to a cyber attack;

- a webshop suffers a cyber-attack and usernames, passwords and purchase history are published online by the attacker;

- a direct marketing email is sent to recipients in the “to:” or “cc:” field so that the recipients can see the email address of other recipients.

However, if, for example, a laptop which contains encrypted data is stolen and the controller has a back up of the data, no notification is necessary (as long as the encryption key is not compromised), and if there is a power outage lasting for minutes at the controller’s call center, then, likewise, the availability breach is not reportable to the data subjects.

For further details on the assessment of risks, please see the response to question 4 in my previous post "The data breach I (Notifying the supervisory authority of the data breach)", where the recommendations of the European Union Agency for Network and Information Security (ENISA) for a methodology of the assessment of severity of personal data breaches are also addressed. For details, please click here.

3. What information must be provided to the data subjects?

The controller is required to provide to the data subjects at least the following information:

a) a description of the nature of the data breach;

b) the name and contact details of the data protection officer or other contact point where more information can be obtained;

c) a description of the likely consequences of the data breach;

d) a description of the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.

It is important that the controller also give the data subject information on how they can protect themselves from the potential negative consequences. For example, if passwords were stolen, the controller is required to inform the data subjects of the necessity to change the password. As many individuals use the same password for different online services, it is of utmost importance to change the password as soon as possible, since unauthorized persons can have access to several accounts by having one password.

4. How should the controller contact the data subjects?

In general, the data breach must be reported to the data subject directly. However, if the communication involved a disproportionate effort, there must be a public communication or similar measure whereby the data subjects are informed in an equally effective manner.

Communication may be sent, for example, via email or sms, on website banners, by post or in print media. Depending on the circumstances, it may be advisable to use more than one channel. Also, it is advisable to communicate the breach to the data subjects in their native language to ensure that they understand the breach and the protective measures they should take.

The WP29 says in the guidelines that the controllers “might…wish to contact and consult the supervisory authority not only to seek advice about informing data subjects about a breach, but also on the appropriate messages to be sent to, and the most appropriate way to contact, individuals.”

5. When is a communication of the breach to data subjects not required?

Communication to the data subject is not required if any of the following conditions are met:

a) the controller has implemented appropriate technical and organizational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption;

b) the controller has taken subsequent measures which ensure that the high risk to the rights and freedoms of data subjects is no longer likely to materialise;

c) it would involve disproportionate effort. In such a case, there must instead be a public communication or similar measure whereby the data subjects are informed in an equally effective manner.

The WP29 emphasizes in its guidelines that while notification may initially not be required, it may be that the level of risk will subsequently increase and, thus, communication of the data breach to the data subjects will be required.

It is also worth noting that the supervisory authority may require the controller to communicate the data breach to the data subjects.

6. How should controllers assess risk and high risk?

The controller has to take into account a number of factors when it comes to evaluating a breach and assessing the risks it may trigger. For details on the assessment of risks, please see the response to question 4 in my previous post "The data breach I (Notifying the supervisory authority of the data breach)". For details, please click here.

In my next post, I will address issues concerning the obligation to document data breaches.

Zoltán Balázs Kovács, J.D. (LL.M.), Partner, Szecskay Attorneys at Law, Budapest, Hungary (zoltan.kovacs@szecskay.com)

The contents of this post are intended to provide only a general overview of the subject matter and do not qualify as legal advice.

Az adatvédelmi incidens II. (Az érintettek tájékoztatása az adatvédelmi incidensről)

A GDPR meghatározza az adatvédelmi incidens fogalmát és szabályozza azt, hogy az adatkezelők mely esetekben kötelesek bejelenteni az adatvédelmi incidenst az illetékes felügyeleti hatóságoknak, valamint mikor kötelesek tájékoztatni az érintetteket az adatvédelmi incidensről. Az adatkezelők kötelesek továbbá nyilvántartást vezetni az adatvédelmi incidensekről. Úgyszintén, az adatfeldolgozók kötelesek az adatvédelmi incidenst, az arról való tudomásszerzését követően indokolatlan késedelem nélkül bejelenti az adatkezelőnek.

A 29. cikk alapján létrehozott Adatvédelmi Munkacsoport (WP29) 2017. október 3-án iránymutatást adott ki az adatvédelmi incidens bejelentésről, amelynek véglegesítése folyamatban van és amely a GDPR vonatkozó rendelkezéseinek (33-34. cikk és a (75)-(76), továbbá (85)-(88) preambulumbekezdések) értelmezéséről szól, valamint lehetséges adatvédelmi incidensekre hoz példákat.

Az alábbiakban kérdések és válaszok formájában foglalom össze az adatvédelmi incidensek érintettek részére történő bejelentésére vonatkozó előírásokat, valamint azt, hogy a természetes személyek jogaira és szabadságaira nézve fennálló kockázatok valószínűsíthetően mikor járnak magas kockázattal. Külön bejegyzésben fogom elemezni az adatvédelmi incidensek nyilvántartását.

1. Mikor kötelesek az adatkezelők tájékoztatni az érintetteket az adatvédelmi incidensről?

Ha az adatvédelmi incidens valószínűsíthetően magas kockázattal jár a természetes személyek jogaira és szabadságaira nézve, az adatkezelő indokolatlan késedelem nélkül tájékoztatja az érintettet az adatvédelmi incidensről.

Megállapítható, hogy az érintettek tájékoztatása tekintetében magasabb a küszöb, mint a felügyeleti hatóság részére teendő bejelentés esetén, mivel a felügyeleti hatóságok felé be kell jelenteni az adatvédelmi incidenst, kivéve, ha az adatvédelmi incidens valószínűsíthetően nem jár kockázattal a természetes személyek jogaira és szabadságaira nézve.

2. Mikor jár az adatvédelmi incidens valószínűsíthetően magas kockázattal a természetes személyek jogaira és szabadságaira nézve?

Az adatkezelő köteles minden egyes adatvédelmi incidenst kiértékelni, azaz az elemzést esetről esetre szükséges elvégezni. Egy incidens értékelésekor számos tényezőt szükséges tekintetbe venni, úgy, mint például

- az incidens típusa (bizalmassági, integritási vagy elérhetőségi);

- a személyes adatok jellege, érzékenysége és száma;

- mennyire könnyen azonosítható az adatvédelmi incidenssel érintett természetes személy;

- a természetes személyre nézve fennálló következmények valószínűsége és súlyossága;

- kiszolgáltatott személyeket érint-e az incidens (például gyermekek, idősek, betegek);

- az érintett személyek száma;

- az adatkezelő és tevékenysége jellemzői.

A WP29 példákkal is szolgál olyan adatvédelmi incidensekre, amelyekről tájékoztatni kell az érintetteket. Például, ha

- személyek adatokat lopnak el egy biztonságos website-ról;

- az adatkezelő zsaroló vírusos támadást észlel, amely személyes adatok titkosításával jár;

- egy személy felhívja a bankot és bejelenti, hogy valaki más havi banki kimutatását kapta meg;

- egy kiber támadás következtében orvosi felvételek órákon át nem elérhetőek egy kórházban;

- egy webshopot kiber támadás ér és a támadó felhasználóneveket, jelszavakat és korábbi vásárlási adatokat tesz közzé a neten;

- direkt marketing emailt küldenek úgy, hogy a címzetteket a "to:" vagy "cc:" mezőkbe írják, így a címzett láthatja a többi címzett email címét.

Azonban, ha például egy titkosított adatokat tartalmazó laptopot ellopnak és az adatkezelőnek van back-up-ja az adatokról, akkor nem szükséges a bejelentés (feltéve, hogy a titkosítási kulcs érintetlen), vagy, ha áramszünet miatt perceken keresztül nem tudja fogadni a hívásokat az adatkezelő call center-e, akkor az elérhetőségi incidenst nem kell bejelenteni az érintetteknek.

A kockázatok elemzésével kapcsolatos további részletekért ld. az előző bejegyzésem "Az adatvédelmi incidens I. (Az adatvédelmi incidens felügyeleti hatóság részére történő bejelentése)" 4. kérdésére adott választ, amely az Európai Uniós Hálózat- és Információbiztonsági Ügynökség (ENISA) által az adatvédelmi incidensek súlyosságának értékelésére vonatkozó módszertanról kiadott ajánlásával is foglalkozik. A részletekért kattintson ide.

3. Milyen tartalmú tájékoztatást kell nyújtani az érintetteknek?

Az adatkezelő köteles legalább az alábbiak szerinti tájékoztatást adni az érintettek részére:

a) ismertetni kell az adatvédelmi incidens jellegét;

b) közölni kell az adatvédelmi tisztviselő vagy a további tájékoztatást nyújtó egyéb kapcsolattartó nevét és elérhetőségeit;

c) ismertetni kell az adatvédelmi incidensből eredő, valószínűsíthető következményeket;

d) ismertetni kell az adatkezelő által az adatvédelmi incidens orvoslására tett vagy tervezett intézkedéseket, beleértve adott esetben az adatvédelmi incidensből eredő esetleges hátrányos következmények enyhítését célzó intézkedéseket.

Lényeges, hogy az adatkezelő arról is tájékoztassa az érintettet, hogy hogyan tud védekezni a lehetséges hátrányos következményekkel szemben. Például, ha jelszavakat lopnak el, akkor az adatkezelő köteles tájékoztatni az érintetteket a jelszó megváltoztatásának szükségességéről. Tekintettel arra, hogy sokan ugyanazt a jelszót használják különböző online szolgáltatások igénybevétele esetén, alapvető jelentőségű a jelszó megváltoztatása, mivel ugyanazzal a jelszóval a jogosulatlan személyek hozzáférhetnek több fiókhoz is.

4. Hogyan köteles az adatkezelő tájékoztatni az érintetteket?

Az adatvédelmi incidensről jellemzően közvetlenül kell tájékoztatni az érintettet. Azonban, amennyiben a tájékoztatás aránytalan erőfeszítést tenne szükségessé, az érintetteket nyilvánosan közzétett információk útján kell tájékoztatni, vagy olyan hasonló intézkedést kell hozni, amely biztosítja az érintettek hasonlóan hatékony tájékoztatását.

A tájékoztatás megküldhető például emailen, sms-ben, weboldalon található hirdetéssel, postán vagy a nyomtatott sajtó útján. A körülményektől függően, javasolt lehet több csatornát is igénybe venni. Úgyszintén, javasolt a tájékoztatást az érintett anyanyelvén megadni annak biztosítása céljából, hogy megértsék az adatvédelmi incidenst és megtegyék a szükséges óvintézkedéseket.

A WP29 az iránymutatásban azt is hozzáteszi, hogy az adatkezelők "felvehetik a kapcsolatot a felügyeleti hatósággal és konzultálhatnak vele nemcsak arról, hogy szükséges-e tájékoztatni az érintetteket az adatvédelmi incidensről, hanem arról is, hogy milyen tartalmú üzenetet küldjenek nekik és mi a legalkalmasabb mód az érintettekkel való kapcsolatfelvételre."

5. Mikor nem szükséges tájékoztatni sz érintetteket az incidensről?

Az érintettet nem kell tájékoztatni, ha a következő feltételek bármelyike teljesül:

a) az adatkezelő megfelelő technikai és szervezési védelmi intézkedéseket hajtott végre, és ezeket az intézkedéseket az adatvédelmi incidens által érintett adatok tekintetében alkalmazták, különösen azokat az intézkedéseket – mint például a titkosítás alkalmazása –, amelyek a személyes adatokhoz való hozzáférésre fel nem jogosított személyek számára értelmezhetetlenné teszik az adatokat;

b) az adatkezelő az adatvédelmi incidenst követően olyan további intézkedéseket tett, amelyek biztosítják, hogy az érintett jogaira és szabadságaira jelentett magas kockázat a továbbiakban valószínűsíthetően nem valósul meg;

c) a tájékoztatás aránytalan erőfeszítést tenne szükségessé. Ilyen esetekben az érintetteket nyilvánosan közzétett információk útján kell tájékoztatni, vagy olyan hasonló intézkedést kell hozni, amely biztosítja az érintettek hasonlóan hatékony tájékoztatását.

A WP29 hangsúlyozza az iránymutatásban, hogy míg kezdetben nem feltétlen szükséges a tájékoztatás, elképzelhető, hogy a későbbiekben a kockázat szintje növekedni fog és így szükségessé válik az érintettek adatvédelmi incidensről való tájékoztatása.

Fontos megjegyezni azt is, hogy a felügyeleti hatóság elrendelheti, hogy az adatkezelő tájékoztassa az érintettet.

6. Hogyan elemezze az adatkezelő a kockázatot és magas kockázatot?

Az adatkezelő számos tényezőt köteles tekintetbe venni akkor, amikor egy incidens és az abból fakadó kockázatok értékelésére kerül sor. A kockázatok elemzésével kapcsolatos további részletekért ld. az előző bejegyzésem "Az adatvédelmi incidens I. (Az adatvédelmi incidens felügyeleti hatóság részére történő bejelentése)" 4. kérdésére adott választ. A részletekért kattintson ide.

A következő bejegyzésemben az adatvédelmi incidensek nyilvántartásával kapcsolatos kérdéseket fogom körüljárni.

dr. Kovács Zoltán Balázs (LL.M.), Partner, Szecskay Ügyvédi Iroda, Budapest (zoltan.kovacs@szecskay.com)

A jelen bejegyzés általános áttekintést kíván nyújtani a körüljárt kérdésekkel kapcsolatban és nem minősül jogi tanácsadásnak.

The data breach I (Notifying the supervisory authority of the data breach)

The GDPR defines the notion of data breach and contains rules on when it is mandatory for controllers to report a data breach to the competent supervisory authority and when they are obliged to communicate such breaches to the data subjects. Controllers are also required to document personal data breaches. In addition, processors are required to notify the controller without undue delay after becoming aware of a personal data breach.

The Article 29 Data Protection Working Party (WP29) issued guidelines on the personal data breach notification on 3 October 2017, which are being finalized, that interpret the respective provisions of the GDPR (Articles 33-34 and Recitals 75-76 and 85-88) and give some examples of possible data breaches.

Below, a Q&A will follow on the issue of notifying the supervisory authorities of data breaches and how risks to the rights and freedoms of individuals can be assessed. I will analyse in separate posts the issues in relation to communicating data breaches to the data subjects and, respectively, the obligation to document the data breaches.

1. What is a data breach?

A personal data breach (data breach) means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed. Under the definition, it can be established that a security breach not involving personal data is not considered a data breach, however, all personal data breaches are security breaches.

Data breaches can typically be classified in the below three categories:

- “confidentiality breach”: any unauthorized or accidental disclosure of, or access to, personal data (for example, a hacker retrieves protected content and passwords from a website);

- “integrity breach”: where there is an unauthorised or accidental alteration of personal data (e.g. a hacking is committed in a way that the hacker deletes from or alters certain data in a data base);

- “availability breach”: accidental or unauthorised loss of access to, or destruction of, personal data (e.g. a laptop is stolen and no back-up of the data is available).

It is worth noting that if e.g. an employee accidentally deletes a file from the employer’s system and the file is recovered from the back up immediately or within a very short period of time, then the breach does not qualify as a data breach but rather only as a security breach.

If a security breach occurs, one of the first things a controller has to decide is if the security breach involves any personal data, in other words, if the breach qualifies as a data breach. This is because the administrative obligations in Articles 33-34 of the GDPR are all connected to data breaches and not to security breaches. However, this does not at all mean that controllers and processors do not have any obligation under the GDPR as far as security breaches are concerned. This is because controllers and processors are required to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. As the WP29 puts it, “a key element of any data security policy is being able, where possible, to prevent a breach and, where it nevertheless occurs, to react to it in a timely manner.”

2. When do controllers have to notify the supervisory authority?

In the case of a personal data breach, the controller must without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the competent supervisory authority of the personal data breach, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.

Since risk serves as a trigger for notifying the authority, it is indispensable to be able to properly analyse the data breach and identify the potential negative consequences of the same. When it comes to assessing the risks, certain factors must be taken into account, such as, for example,

- the type of breach (confidentiality, integrity or availability);

- the nature, sensitivity and volume of personal data;

- the issue of how easy it is to identify the individuals affected by the data breach;

- the likelihood and severity of consequences for individuals;

- if vulnerable individuals are affected (e.g. children, the elderly, people with disease);

- the number of affected individuals;

- the characteristics of the data controller, its activities.

For further details, please see the response to question 4 below.

3. When does a controller become "aware" of a data breach?

The WP29 says in its guidelines that once the controller has a reasonable degree of certainty that a data breach has occurred, the controller should be regarded as having become aware of the data breach.

In practice, it is not always obvious when there is a reasonable degree of certainty and this is an issue that has to be examined and decided on a case by case basis. The guidelines add, though, that “after first being informed of a potential breach by an individual, a media organisation, or another source, or when it has itself detected a security incident, the controller may undertake a short period of investigation in order to establish whether or not a breach has in fact occurred. During this period of investigation the controller may not be regarded as being “aware”.”

It is essential that the controller starts the investigation as soon as possible and establishes if a security breach or a data breach has taken place. To be able to do so, it is of utmost importance to have appropriate internal processes in place so that the controller is able and well prepared to detect and address the breach.

4. When is a data breach likely to result in a risk to the rights and freedoms of natural persons?

Recitals (75)-(76) of the GDPR may serve as guidance as to what may be regarded as a risk to the rights and freedoms of individuals (for example, identity theft, identity fraud, discrimination, financial damages, damage to reputation, loss of confidentiality of personal data protected by professional secrecy, economic or social disadvantage). The WP29 says in its guidelines that if the controller is not certain if there may be / is a risk to the rights and freedoms of individuals, the controller should err on the side of caution and assume that there is a risk and notify the supervisory authority.

The WP29 also provides examples for data breaches which trigger a notification obligation. For example, if

- personal data of individuals are stolen from a secure website;

- a controller experiences a ransomware attack resulting in personal data being encrypted;

- an individual calls the bank and reports that she has received a monthly statement for someone else;

- medical records in a hospital are unavailable for hours due to a cyber attack;

- a webshop suffers a cyber-attack and usernames, passwords and purchase history are published online by the attacker;

- a direct marketing email is sent to recipients in the “to:” or “cc:” field so that the recipients can see the email address of other recipients.

However, if, for example, a laptop which contains encrypted data is stolen and the controller has a back up of the data, no notification is necessary (as long as the encryption key is not compromised), and if there is a power outage lasting for minutes at the controller’s call center then, likewise, the availability breach is not reportable to the authority.

It is worth noting that, in December 2013, the European Union Agency for Network and Information Security (ENISA) in cooperation with the Data Protection Authorities of Greece and Germany issued recommendations for a methodology of the assessment of the severity of personal data breaches. The document was produced with the objective of providing both data controllers and national authorities with a quantitative tool / methodology for assessing the severity of data breaches. Due to the general nature of the methodology, both data controllers and national authorities need to apply special care when using the methodology as it cannot take into account all kinds of breaches. Thus, the specificities of the given breach need to be addressed accordingly. Still, the document provides very useful information on how to assess a breach.

In the document, a formula was set up based on which severity may be assessed. The formula reads as follows:

SE = DPC x EI + CB

(SE means severity of the breach, DPC stands for data processing context, EI means ease of identification of the relevant individuals and CB stands for circumstances of the breach.)

The document explains how the factors in the formula need to be evaluated and categorizes the breaches into four classes as per the below:

- Low risk. If the SE value is less than 2, the risk is considered to be low. Low risk means that “individuals either will not be affected or may encounter a few inconveniences, which they will overcome without any problem (time spent re-entering information, annoyances, irritations, etc.).”;

- Medium risk. If the SE value is equal to or more than 2 and less than 3, there is a medium level of risk. Medium risk means that “individuals may encounter significant inconveniences, which they will be able to overcome despite a few difficulties (extra costs, denial of access to business services, fear, lack of understanding, stress, minor physical ailments, etc.).”;

- High risk. If the SE value is equal to or more than 3 and less than 4, the risk is considered to be high. High risk means that “individuals may encounter significant consequences, which they should be able to overcome albeit with serious difficulties (misappropriation of funds, blacklisting by banks, property damage, loss of employment, subpoena, worsening of health, etc.).” and

- Very high risk. If the SE value is equal to or more than 4, the risk is considered to be very high. Very high risk means that “individuals may encounter significant, or even irreversible, consequences, which they may not overcome (financial distress such as substantial debt or inability to work, long-term psychological or physical ailments, death, etc.).”

Within the DPC factor, the document differentiates four categories of data: simple, behavioural, financial and sensitive. In addition to the types of data breached, the data volume, special characteristics of the controller and the individuals and the nature of data must also be taken into account and evaluated. The fact if the data are inaccurate or are published also has to be assessed. The document contains a scoring method for the calculation of the DPC factor, the result of which can be 1, 2, 3 or 4 points.

As regards the EI factor, the document defines four levels of EI: negligible, limited, significant and maximum. The lowest score (negligible) means that it is extremely difficult to identify the individual based on the data breached, whereas the highest score (maximum) means that identification is ascertainable directly from the data breached. The document contains guidance according to which the EI value can be either 0.25, 0.50, 0.75 or 1, depending on the data breached, i.e. direct (e.g. name) or indirect (e.g. phone number, email address) identifiers.

Concerning the CB factor, it has to be assessed if the breach is a confidentiality, integrity or availability breach and if there was a malicious intent. The CB value can be 0, 0.25 or 0.5, depending on the circumstances.

Once the assessment is done, two additional factors need to be taken into account. Although, they do not affect a prior the scoring, they are important for the final assessment. Namely, (i) if the number of individuals exceeds 100 and (ii) if the data breached is unintelligible. For example, if a strong encryption was used to protect the data and the encryption key is intact, this can substantially decrease the negative consequences of the breach.

The document adds that the severity level could be integrated into the notification the controller sends to the supervisory authority and could be used by the controller and the competent authority to assess if there is a need to notify the data subjects.

5. What information must be provided to the supervisory authority?

The notification must at least

a) describe the nature of the personal data breach including where possible the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;

b) communicate the name and contact details of the data protection officer or other contact point where more information can be obtained;

c) describe the likely consequences of the personal data breach;

d) describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.

6. Is it allowed to notify the supervisory authority in phases?

Yes. In so far as it is not possible to provide all the information at the same time, the information may be provided in phases without undue further delay.

Depending on the circumstances of the case, it can happen that the controller simply cannot make a complete notification within 72 hours of becoming aware of the data breach. In this case, the controller is urged to make a notification within 72 hours giving as many details as possible and indicating that the data breach is still being investigated and that further details will follow later.

If the controller is not certain if a given data breach must be notified to the supervisory authority, it is advisable to notify. This is because there is no sanction for reporting a breach which later turns out not to be a data breach or a reportable data breach. As opposed to this, if no notification is made but the controller should have made one, the authority may impose a fine for breach of an administrative obligation. In addition, the authority may also inspect if, for example, the controller has appropriate technical and organizational measures in place.

7. Which supervisory authority must be notified if the data breach affects individuals in more than one Member State?

Whenever a data breach affects the personal data of individuals in more than one Member State and notification is required, the controller will need to notify the lead supervisory authority, i.e. the supervisory authority of the Member State in which the controller’s main establishment or only establishment is situated.

As regards a controller with establishments in more than one Member State, the main establishment is the place of its central administration in the Union, unless the decisions on the purposes and means of the processing of personal data are taken in another establishment of the controller in the Union and the latter establishment has the power to have such decisions implemented, in which case the establishment which took such decisions is to be considered as being the main establishment.

Multinational companies carrying out cross-border processing are advised to prepare a breach response plan in a way that it is also assessed to which supervisory authority the data breach must be reported. The WP29 stresses that the controller may also proactively report the data breach to a supervisory authority which is not the lead supervisory authority. Furthermore, if the controller notifies the lead supervisory authority of the data breach, the controller should indicate in the report if the data breach has likely affected individuals in other Member States.

8. What happens if the controller makes a delayed notification?

The WP29 guidelines admit that there may be scenarios where it may be justified to notify the supervisory authority of the data breach (or rather a series of similar breaches) after more than 72 hours of becoming aware of the breach(es). The guidelines say that “depending on the circumstances, it may take the controller some time to establish the extent of the breaches and, rather than notify each breach individually, the controller instead organises a meaningful notification that represents several very similar breaches, with possible different causes.”

According to the GDPR, in the event that the notification is made after 72 hours it must be accompanied by reasons for the delay. The guidelines emphasize that the fact that the GDPR allows for delayed notification under certain circumstances “should not be seen as something that regularly takes place.”

Overall, it is advisable to avoid making a notification after 72 hours and rather make the notification within 72 hours and then supplement the notification later as necessary.

9. Are processors required to notify anyone about a data breach?

Yes. The processor is required to notify the controller without undue delay after becoming aware of a personal data breach.

It is important that the controller makes the processor aware of this obligation because the guidelines stress that the controller uses the processor to achieve its purposes; therefore, in principle, the controller should be considered as being “aware” of the data breach once the processor has become aware. Taking this into account, it is good practice to have such measures in place that ensure that the processor notifies the controller of any breach without undue delay after becoming aware of the data breach, so that the controller can fulfill its obligations in due course.

10. When is a notification not required?

If the security breach does not affect personal data it is not considered to be a data breach, thus no notification is required. Furthermore, if the data breach is “unlikely to result in a risk to the rights and freedoms of natural persons”, no notification is required.

As per the guidelines, for example, the loss of a securely encrypted mobile device utilized by the controller and its staff would not require notification (if the controller has a back up of the data) because such a breach is unlikely to pose a risk to the rights and freedoms of individuals. If the encryption key which was properly generated remains within the secure possession of the controller, then the personal data would be unintelligible to a hacker. However, if it later turns out that the key was compromised or the encryption is vulnerable, the level of risk may change and notification may be required.

Taking the above into account, controllers are urged to monitor a data breach even after the initial assessment and after going through the steps of the breach response plan and addressing the breach as per Articles 33 and 34 of the GDPR. This is because, over time, the risk level may increase to an extent that notification and the taking of certain (additional) measures may become necessary.

11. Are there additional notification obligations under other laws?

Yes. For example, providers of electronic communication services are required to notify the competent national authority of personal data breaches no later than 24 hours after the detection of the personal data breach, where feasible. There are and there may be some other laws as well which set forth notification obligations for controllers active in certain sectors, thus controllers should always be vigilant and should not think that if they have complied with the notification obligation under the GDPR there can be no additional notification obligation.

In my next post, I will address issues concerning the notification of data breaches to the data subjects. For details, please click here.

Zoltán Balázs Kovács, J.D. (LL.M.), Partner, Szecskay Attorneys at Law, Budapest, Hungary (zoltan.kovacs@szecskay.com)

The contents of this post are intended to provide only a general overview of the subject matter and do not qualify as legal advice.

Az adatvédelmi incidens I. (Az adatvédelmi incidens felügyeleti hatóság részére történő bejelentése)

A GDPR meghatározza az adatvédelmi incidens fogalmát és szabályozza azt, hogy az adatkezelők mely esetekben kötelesek bejelenteni az adatvédelmi incidenst az illetékes felügyeleti hatóságoknak, valamint mikor kötelesek tájékoztatni az érintetteket az adatvédelmi incidensről. Az adatkezelők kötelesek továbbá nyilvántartást vezetni az adatvédelmi incidensekről. Úgyszintén, az adatfeldolgozók kötelesek az adatvédelmi incidenst, az arról való tudomásszerzését követően indokolatlan késedelem nélkül bejelenti az adatkezelőnek.

A 29. cikk alapján létrehozott Adatvédelmi Munkacsoport (WP29) 2017. október 3-án iránymutatást adott ki az adatvédelmi incidens bejelentésről, amelynek véglegesítése folyamatban van és amely a GDPR vonatkozó rendelkezéseinek (33-34. cikk és a (75)-(76), továbbá (85)-(88) preambulumbekezdések) értelmezéséről szól, valamint lehetséges adatvédelmi incidensekre hoz példákat.

Az alábbiakban kérdések és válaszok formájában foglalom össze az adatvédelmi incidensek felügyeleti hatóságok részére történő bejelentésére vonatkozó előírásokat, valamint azt, hogy a természetes személyek jogaira és szabadságaira nézve fennálló kockázatok miként értékelhetők. Külön bejegyzésekben fogom elemezni az érintettek adatvédelmi incidensekről történő tájékoztatását, valamint az adatvédelmi incidensek nyilvántartását.

1. Mi az adatvédelmi incidens?

Az adatvédelmi incidens a biztonság olyan sérülése, amely a továbbított, tárolt vagy más módon kezelt személyes adatok véletlen vagy jogellenes megsemmisítését, elvesztését, megváltoztatását, jogosulatlan közlését vagy az azokhoz való jogosulatlan hozzáférést eredményezi. A definíció alapján megállapítható, hogy az olyan biztonsági incidens, amely nem érint személyes adatot nem adatvédelmi incidens, azonban valamennyi adatvédelmi incidens biztonsági incidens.

Az adatvédelmi incidensek jellemzően az alábbi három fő kategóriába sorolhatók:

- "bizalmassági incidens": személyes adatok jogellenes vagy véletlen közlése vagy az azokhoz való jogosulatlan hozzáférés (például, ha egy hacker védett tartalmat és jelszavakat szerez meg egy website-ról);

- "integritási incidens": személyes adatok jogellenes vagy véletlen megváltoztatása (például az adatbázis olyan módon történő feltörése, hogy a hacker személyes adatokat töröl belőle);

- "elérhetőségi incidens": személyes adatok véletlen vagy jogellenes megsemmisítése, a személyes adatokhoz való hozzáférés véletlen vagy jogellenes elvesztése (például egy laptopot ellopnak és nincs back-up az adatokról).

Amennyiben egy munkavállaló véletlenül töröl egy fájlt a munkáltató rendszeréből, majd a törlést követően azonnal vagy rövid időn belül visszaállítják a fájlt, akkor ez csupán biztonsági incidensnek minősül, nem adatvédelmi incidensnek. 

Amennyiben biztonsági incidens történik, az adatkezelőnek először tisztáznia kell, hogy a biztonsági incidens érint-e személyes adatokat, azaz el kell döntenie, hogy az incidens adatvédelmi incidensnek minősül-e. Az adatkezelőnek azért kell így eljárnia, mert a GDPR 33-34. cikkeiben szereplő adminisztratív kötelezettségek adatvédelmi incidenshez kapcsolódnak és nem biztonsági incidenshez. Mindez azonban nem jelenti azt, hogy az adatkezelőknek és az adatfeldolgozóknak ne lennének kötelezettségei a GDPR alapján a biztonsági incidensekkel kapcsolatban. Az adatkezelők és az adatfeldolgozók kötelesek megfelelő technikai és szervezési intézkedéseket végrehajtani a kockázat mértékének megfelelő szintű adatbiztonság garantálása érdekében. A WP29 megfogalmazásában "bármely adatbiztonsági szabályzat kulcsfontosságú eleme az, hogy lehetőség szerint előzzék meg az incidenst és, amennyiben az mégis bekövetkezik, akkor kellő időben intézkedjenek azzal kapcsolatban."

2. Mikor köteles az adatkezelő bejelenteni az adatvédelmi incidenst a felügyeleti hatóság részére?

Az adatvédelmi incidenst az adatkezelő indokolatlan késedelem nélkül, és ha lehetséges, legkésőbb 72 órával azután, hogy az adatvédelmi incidens a tudomására jutott, bejelenti az illetékes felügyeleti hatóságnak, kivéve, ha az adatvédelmi incidens valószínűsíthetően nem jár kockázattal a természetes személyek jogaira és szabad­ságaira nézve.

Mivel a kockázat fennállása keletkezteti a hatóság felé történő bejelentési kötelezettséget, elengedhetetlen az adatvédelmi incidens megfelelő elemzése és a lehetséges negatív következményeinek azonosítása. Amikor a kockázatok elemzésére kerül sor, bizonyos tényezők figyelembe vétele szükséges, mint például

- az incidens típusa (bizalmassági, integritási vagy elérhetőségi);

- a személyes adatok jellege, érzékenysége és száma;

- mennyire könnyen azonosítható az adatvédelmi incidenssel érintett természetes személy;

- a természetes személyre nézve fennálló következmények valószínűsége és súlyossága;

- kiszolgáltatott személyeket érint-e az incidens (például gyermekek, idősek, betegek);

- az érintett személyek száma;

- az adatkezelő és tevékenysége jellemzői.

További részletekért ld. az alábbi 4. kérdésre írt választ.

3. Mikor jut az adatvédelmi incidens az adatkezelő "tudomására"?

A WP29 iránymutatásában foglaltak szerint azt, amikor az adatkezelő az adatvédelmi incidens megtörténtéről ésszerű mértékű bizonyosságot szerzett, úgy kell tekinteni, hogy az adatvédelmi incidens a tudomására jutott.

A gyakorlatban nem mindig egyértelmű annak megítélése, hogy mikor áll fenn az ésszerű mértékű bizonyosság és ezt a kérdést esetről esetre kell megvizsgálni és eldönteni. Az iránymutatás azonban hozzáteszi, hogy "azt követően, hogy egy személy, egy média szervezet vagy más forrás lehetséges incidensről tájékoztatta az adatkezelőt vagy az maga azonosított egy biztonsági incidenst, az adatkezelő rövid ideig tartó vizsgálatot folytathat le annak megállapítása végett, hogy adatvédelmi incidens történt-e. Ezen vizsgálati időszak alatt az adatkezelőt nem lehet úgy tekinteni, mint, akinek tudomása van az incidensről."

Lényeges, hogy az adatkezelő minél előbb megkezdje a vizsgálatot és megállapítsa, hogy biztonsági vagy adatvédelmi incidens történt-e. Ahhoz, hogy erre képes legyen, alapvetően fontos, hogy megfelelő belső folyamatok legyenek kialakítva és így az adatkezelő kellőképpen fel legyen készülve az incidens felderítésére és kezelésére.

4. Az adatvédelmi incidens mikor jár valószínűsíthetően kockázattal a természetes személyek jogaira és szabadságaira nézve?

A GDPR (75)-(76) preambulumbekezdései segítségül szolgálthatnak annak megítélésében, hogy mi tekinthető kockázatnak a természetes személyek jogaira és szabadságaira nézve (például személyazonosság-lopás, személyazonossággal való visszaélés, diszkrimináció, pénzügyi veszteség, jóhírnév sérelme, a szakmai titoktartási kötelezettség által védett személyes adatok bizalmas jellegének sérülése, gazdasági vagy szociális hátrány). A WP29 iránymutatásában foglaltak szerint, ha egy adatkezelő nem biztos abban, hogy fennáll(hat)-e kockázat a természetes személyek jogaira és szabadságaira nézve, az adatkezelő inkább járjon el elővigyázatosan, vélelmezze azt, hogy fennáll a kockázat és jelentse be az incidenst a felügyeleti hatóságnak.

A WP29 példákkal is szolgál olyan adatvédelmi incidensekre, amelyeket kötelező bejelenteni a felügyeleti hatóságoknak. Például, ha

- személyek adatokat lopnak el egy biztonságos website-ról;

- az adatkezelő zsaroló vírusos támadást észlel, amely személyes adatok titkosításával jár;

- egy személy felhívja a bankot és bejelenti, hogy valaki más havi banki kimutatását kapta meg;

- egy kiber támadás következtében orvosi felvételek órákon át nem elérhetőek egy kórházban;

- egy webshopot kiber támadás ér és a támadó felhasználóneveket, jelszavakat és korábbi vásárlási adatokat tesz közzé a neten;

- direkt marketing emailt küldenek úgy, hogy a címzetteket a "to:" vagy "cc:" mezőkbe írják, így a címzett láthatja a többi címzett email címét.

Azonban, ha például egy titkosított adatokat tartalmazó laptopot ellopnak és az adatkezelőnek van back-up-ja az adatokról, akkor nem szükséges a bejelentés (feltéve, hogy a titkosítási kulcs érintetlen), úgyszintén, ha áramszünet miatt perceken keresztül nem tudja fogadni a hívásokat az adatkezelő call center-e, akkor az elérhetőségi incidenst nem kell bejelenteni a hatóságnak.

Érdemes megemlíteni, hogy 2013. decemberében, az Európai Uniós Hálózat- és Információbiztonsági Ügynökség (ENISA) a német és a görög adatvédelmi hatóságokkal együttműködésben ajánlást adott ki az adatvédelmi incidensek súlyosságának értékelésére vonatkozó módszertanról. Az ajánlást azzal a céllal készítették, hogy mind az adatkezelők, mind az adatvédelmi hatóságok részére segítséget nyújtson / módszertant adjon az adatvédelmi incidensek súlyosságának értékelésére. A módszertant annak általános jellege miatt mind az adatkezelőknek, mind az adatvédelmi hatóságoknak kellő körültekintéssel kell alkalmazniuk, tekintettel arra, hogy az valamennyi incidensre nem feltétlenül alkalmazható egy az egyben. Így, az adott incidens sajátosságait minden esetben figyelembe kell venni. Azonban, a dokumentum így is nagyon hasznos információkat tartalmaz arra vonatkozóan, hogy hogyan értékelhető egy incidens.

A dokumentum felállít egy képletet, amely alapján kiértékelhető a kockázat súlyossága. A képlet az alábbiak szerinti:

SE = DPC x EI + CB

(az SE az incidens súlyosságát jelenti, a DPC az adatkezelés jellegét, az EI az érintett azonosíthatóságának nehézségi fokát, míg a CB az incidens körülményeit jelenti.)

A dokumentum kifejti, hogy hogyan kell a képlet egyes összetevőit kiértékelni. Az osztályozás alapján az alábbi négy kategóriába sorolhatók az incidensek:

- Alacsony kockázat: a természetes személyekre lényegében nincs kihatással az incidens vagy az részükre csupán kisebb kellemetlenséget okoz, amelyet gond nélkül meg tudnak oldani (pl. újra meg kell adniuk információt, idegeskedést okoz az incidens stb.); 

- Közepes kockázat: a természetes személyek jelentős kellemetlenségeket tapasztalhatnak, amelyeket nehézségek árán meg tudnak oldani (extra költségek, szorongás, stressz, bizonyos szolgáltatásokhoz nem férnek hozzá, nem értik mi történik stb.); 

- Magas kockázat: a természetes személyek jelentős következményekkel szembesülhetnek az incidens kapcsán, amelyeket képesek lehetnek leküzdeni, azonban csak komoly nehézségek árán (vagyoni veszteség, bank általi fekete listára helyezés, tulajdonban bekövetkező kár, állás elvesztése, egészségi állapot romlása stb.);

- Nagyon magas kockázat: a természetes személyek jelentős vagy akár visszafordíthatatlan következményekkel szembesülhetnek, amelyeket adott esetben nem képesek leküzdeni (pénzügyi nehézségek, úgy, mint például jelentős adósság vagy munkaképtelenség, hosszútávú pszichés vagy testi betegség, halál stb.).

A DPC elemen belül a dokumentum négy adat kategóriát különböztet meg, úgy, mint egyszerű, viselkedési, pénzügyi és érzékeny adat. Az incidenssel érintett adatok típusán felül, az adatok száma, az adatkezelő és a természetes személyek sajátos jellemzői és az adatok jellege figyelembe veendő és értékelendő tényezők. Amennyiben az adatok pontatlanok vagy nyilvánosan elérhetők, az szintén értékelendő. Az ajánlás egy pontozási módszert tartalmaz a DPC elem kiszámítására, amelynek értéke 1, 2, 3 vagy 4.

Az EI elem tekintetében a dokumentum négy EI szintet definiál: elenyésző, korlátozott, jelentős és maximális. A legalacsonyabb (elenyésző) pontszám azt jelenti, hogy az incidenssel érintett adatok alapján rendkívül nehéz az egyén azonosítása, míg a legmagasabb pontszám (maximális) azt jelenti, hogy az incidenssel érintett adatok alapján közvetlenül lehetséges az egyén azonosítása. Az ajánlás iránymutatást tartalmaz, amely alapján az EI értéke 0.25, 0.5, 0.75 vagy 1 az incidenssel érintett adatoktól függően, azaz attól függően, hogy közvetlen (pl. név) vagy közvetett (pl. telefonszám, email cím) azonosítókról van-e szó.

A képlet CB eleme vonatkozásában tisztázandó, hogy az incidens bizalmassági, integritási vagy elérhetőségi incidens és, hogy volt-e rossz szándék az incidens mögött. A CB értéke 0, 0.25 vagy 0.5.

Amikor a fentiek szerinti értékelés elkészül, még két továbbá tényezőt kell figyelembe venni, amelyek jóllehet közvetlenül nem jelennek meg a pontozásban, a végső értékelés szempontjából fontosak. Ezek a következők: (i) az érintettek száma meghaladja-e a százat és (ii) az incidenssel érintett adatok értelmezhetőek-e / olvashatóak-e. Például, ha erős titkosítást használtak az adatok védelméhez és a titkosító kulcs érintetlen, akkor ez jelentősen csökkenteni tudja az incidens hátrányos következményeit.

A dokumentum hozzáteszi, hogy a súlyosság értékelését be lehet emelni az adatkezelő által a felügyeleti hatóságnak megküldött bejelentésébe és fel lehet használni abból a célból is, hogy az adatkezelő és a felügyeleti hatóság kiértékelje azt, hogy szükség van-e az érintettek tájékoztatására.

5. Milyen információt kell tartalmaznia a felügyeleti hatóság felé teendő bejelentésnek?

A bejelentésben legalább

a) ismertetni kell az adatvédelmi incidens jellegét, beleértve – ha lehetséges – az érintettek kategóriáit és hozzávetőleges számát, valamint az incidenssel érintett adatok kategóriáit és hozzávetőleges számát;

b) közölni kell az adatvédelmi tisztviselő vagy a további tájékoztatást nyújtó egyéb kapcsolattartó nevét és elérhetőségeit;

c) ismertetni kell az adatvédelmi incidensből eredő, valószínűsíthető következményeket;

d) ismertetni kell az adatkezelő által az adatvédelmi incidens orvoslására tett vagy tervezett intézkedéseket, beleértve adott esetben az adatvédelmi incidensből eredő esetleges hátrányos következmények enyhítését célzó intézkedéseket.

6. Lehetséges több részletben tájékoztatni a felügyeleti hatóságot?

Igen. Amennyiben nem lehetséges az információkat egyidejűleg közölni, azok további indokolatlan késedelem nélkül később részletekben is közölhetők.

Az eset körülményeitől függően elképzelhető, hogy az adatkezelő nem tudja megtenni a teljes bejelentést az adatvédelmi incidens tudomására jutásától számított 72 órán belül. Ebben az esetben az adatkezelő számára ajánlott, hogy 72 órán belül tegyen bejelentést az általa ismert tényekről és jelezze, hogy az adatvédelmi incidens kivizsgálás alatt áll és később további részleteket fog bejelenteni.

Ha az adatkezelő nem biztos abban, hogy egy adatvédelmi incidenst be kell-e jelenteni a felügyeleti hatóság részére, akkor ajánlott bejelenteni azt. Azért célszerű így eljárni, mert nincs szankciója annak, ha bejelentenek egy incidenst, amiről később kiderül, hogy nem adatvédelmi incidens vagy nem bejelentendő adatvédelmi incidens. Ezzel szemben, ha az adatkezelő nem tesz bejelentést, azonban kiderül, hogy kellett volna, akkor a hatóság bírságot szabhat ki a bejelentési kötelezettség elmulasztásáért. Továbbá, a hatóság megvizsgálhatja például azt is, hogy az adatkezelő megtette-e a megfelelő technikai és szervezési intézkedéseket.

7. Melyik felügyeleti hatóság felé kell megtenni a bejelentést, ha az adatvédelmi incidens több tagállamban érint személyeket?

Amennyiben az adatvédelmi incidens több tagállamban lévő természetes személy személyes adatait érinti és kötelező az adatvédelmi incidens bejelentése, az adatkezelő a fő felügyeleti hatóság felé kell megtegye a bejelentést, azaz annak a tagállamnak a felügyeleti hatósága felé, amelyben az adatkezelő tevékenységi központja vagy egyetlen tevékenységi helye található.

Az egynél több tagállamban tevékenységi hellyel rendelkező adatkezelő esetében a tevékenységi központ az Unión belüli központi ügyvitel helye, ha azonban a személyes adatok kezelésének céljaira és eszközeire vonatkozó döntéseket az adatkezelő egy Unión belüli másik tevékenységi helyén hozzák, és az utóbbi tevékenységi hely rendelkezik hatáskörrel az említett döntések végrehajtatására, az említett döntéseket meghozó tevékenységi helyet kell tevékenységi központnak tekinteni.

A határon átnyúló adatkezelést végző multinacionális társaságok részére ajánlott olyan incidens intézkedési tervet kidolgozni, amely kitér arra a kérdésre is, hogy mely felügyeleti hatóság részére kell bejelenteni az adatvédelmi incidenst. A WP29 hangsúlyozza, hogy az adatkezelő proaktívan eljárva bejelentheti az adatvédelmi incidenst olyan felügyeleti hatóságnak is, amely nem a fő felügyeleti hatóság. Úgyszintén, amennyiben az adatkezelő bejelenti az adatvédelmi incidenst a fő felügyeleti hatóságnak, az adatkezelőnek célszerű jeleznie a bejelentésben, ha az adatvédelmi incidens valószínűleg több tagállamban érintett természetes személyeket.

8. Mi történik akkor, ha az adatkezelő késedelmesen teljesíti a bejelentési kötelezettséget?

A WP29 iránymutatás elismeri, hogy adódhatnak olyan helyzetek, amikor indokolt lehet, ha az adatkezelő a felügyeleti hatóság felé több, mint 72 órával azt követően jelenti be az adatvédelmi incidenst (vagy hasonló incidensek sorozatát), hogy az a tudomására jutott. Az iránymutatás tartalmazza azt, hogy "a körülményektől függően, némi időbe telhet az adatkezelőnek az incidens mértékének megállapítása és ahelyett, hogy az incidenseket egyenként bejelenti, az adatkezelő egy bejelentést tesz, amely számos nagyon hasonló incidensre vonatkozik, amelyeknek adott esetben különböző oka van."

A GDPR szerint, amennyiben a bejelentés nem történik meg 72 órán belül, mellékelni kell hozzá a késedelem igazolására szolgáló indokokat is. Az iránymutatás hangsúlyozza, hogy az a tény, hogy a GDPR bizonyos körülmények fennállása esetén megengedi a késői bejelentést "nem tekinthető úgy, hogy az gyakran fordul elő."

Összességében javallott elkerülni a 72 órát követően tett bejelentést és célszerű inkább megtenni azt 72 órán belül és később szükség szerint kiegészíteni a bejelentést.

9. Az adatfeldolgozók kötelesek bárkit értesíteni az adatvédelmi incidensről?

Igen. Az adatfeldolgozó az adatvédelmi incidenst, az arról való tudomásszerzését követően indokolatlan késedelem nélkül köteles bejelenteni az adatkezelőnek. 

Lényeges, hogy az adatkezelő felhívja az adatfeldolgozó figyelmét erre a kötelezettségre, mert az iránymutatás is hangsúlyozza, hogy az adatkezelő a céljai eléréséhez veszi igénybe az adatfeldolgozót, így elvben, az adatkezelő tudomására jutottnak tekintendő az adatvédelmi incidens, akkor, ha az adatfeldolgozó tudomással bír arról. Ezt figyelembe véve, jó gyakorlatnak számít, ha olyan folyamatok kialakítására kerül sor, amelyek biztosítják azt, hogy az adatfeldolgozó az adatvédelmi incidensről való tudomásszerzését követően indokolatlan késedelem nélkül bejelentse azt az adatkezelőnek és így az adatkezelő időben teljesíteni tudja a kötelezettségeit.

10. Mikor nem kell bejelenteni az adatvédelmi incidenst a hatóságnak?

Amennyiben az incidens nem érint személyes adatokat, az nem minősül adatvédelmi incidensnek, így azt nem kell bejelenteni. Továbbá, amennyiben az adatvédelmi incidens valószínűsíthetően nem jár kockázattal a természetes személyek jogaira és szabadságaira nézve, akkor sem szükséges bejelentést tenni.

Az iránymutatás szerint, például az adatkezelő és személyzete által használt, biztonságosan titkosított mobil eszköz elvesztése nem bejelentendő, ha az adatkezelőnek van back-up-ja az adatokról, mert az incidens valószínűsíthetően nem jár kockázattal a természetes személyek jogaira és szabadságaira nézve. Ha a megfelelően képzett titkosító kulcs az adatkezelő birtokában marad, akkor a személyes adatok nem lesznek értelmezhetők a hacker számára. Azonban, ha később kiderül, hogy a kulcsot feltörték vagy a titkosítás sebezhető, akkor a kockázat szintje változhat és a bejelentés megtétele szükséges lehet.

A fentieket figyelembe véve, az adatkezelők számára ajánlott az adatvédelmi incidenst figyelemmel kísérni a kezdeti értékelést, majd az intézkedési terv szerinti lépések megtételét és a GDPR 33-34. cikkei szerinti eljárást követően. Mindez ajánlott mivel a kockázat mértéke idővel olyan mértékben nőhet, hogy bejelentés és bizonyos (további) lépések megtétele lehet szükséges.

11. Vannak egyéb jogszabályok alapján fennálló további bejelentési kötelezettségek?

Igen. Például az elektronikus hírközlési szolgáltatók a személyes adatok megsértésének észlelésétől számított lehetőleg 24 órán belül kötelesek bejelenteni az esetet az illetékes nemzeti hatóságnak. Vannak és lehetnek további jogszabályok is, amelyek bizonyos szektorokban tevékenykedő adatkezelők számára írnak elő bejelentési kötelezettséget, így az adatkezelőknek mindig körültekintően kell eljárniuk és nem gondolhatják azt, hogy amennyiben teljesítették a GDPR szerinti bejelentési kötelezettségüket, akkor nem állhat fenn további tájékoztatási kötelezettség.

A következő bejegyzésemben az érintettek adatvédelmi incidensről való tájékoztatását fogom körüljárni. A részletekért kattintson ide.

dr. Kovács Zoltán Balázs (LL.M.), Partner, Szecskay Ügyvédi Iroda, Budapest (zoltan.kovacs@szecskay.com)

A jelen bejegyzés általános áttekintést kíván nyújtani a körüljárt kérdésekkel kapcsolatban és nem minősül jogi tanácsadásnak.