View source for NAIH (Hungary) - NAIH – 6427-1/2023

== English Machine Translation of the Decision ==
The decision below is a machine translation of the Hungarian original. Please refer to the Hungarian original for more details.

<pre>
Case
number:
History:
NAIH-6427-1/2023
NAIH/2020/1160/10.
Subject
:
decision after judicial review
repeated
Privacy in
official proceedings
H A T T E R
The Hungarian National Authority for Data Protection and Freedom of Information
(hereinafter: the Authority) has received a complaint concerning the electronic data transmission by
Digi Távközlési és Szolgáltató Kft (registered office: 1134 Budapest, Váci út 35., company
registration number: 01-09- 667975) (hereinafter: the Customer or the Data Controller)
(represented by [...]), dated 2019. (hereinafter referred to as "the General Data Protection
Regulation") on the data protection incident notified by him on 25 September 2019 under the
identification number [...] in connection with the findings of the official control initiated on 8 October
2019 in relation to the fulfilment of its obligations under Regulation (EU) 2016/679 on the protection
of natural persons with regard to the processing of personal data and on the free movement of
such data, and repealing Directive 95/46/EC (hereinafter referred to as "the General Data
Protection Regulation"), which was opened ex officio on 16 December 2019 and closed by decision
No. NAIH/2020/1160/10, and subsequently referred to the Budapest Metropolitan Court No.
105.K.704.076/2022/4 of the Court of First Instance of the European Communities
1. states that
a. the Customer has breached Article 5(1)(e) ('limited retention') of the General Data
Protection Regulation by failing to delete the test database affected by the data breach after
running the necessary tests and correcting the error. The large amount of customer data
stored in the test database was thus stored in its systems for the next period of almost one
and a half years in such a way that the personal data of natural persons remained
identifiable and the data subjects identifiable, even though it no longer needed these data in
the context of the provision of its services. The failure to delete the database directly
allowed the data breach to occur and the personal data to become available.
b. The Customer has breached Article 32(1) to (2) of the GDPR by failing to implement
appropriate technical and organisational measures proportionate to the risks involved in the
security of processing, by
- the content manager it used ([...]) exploited a vulnerability known for more than 9 years,
which could otherwise be detected and fixed by appropriate means, to access the
databases affected by the incident through the publicly accessible digi.hu website;
- did not apply encryption to the personal data concerned by the data breach ([...]), which
greatly increased the risks arising from the incident.
.................................................................................................................................
1055 Budapest Tel: +36 1 391-1400 ugyfelszolgalat@naih.hu
9-11 Falk Miksa Street. Fax: +36 1 391-1410 www.naih.hu
2
The lack of these measures directly allowed customer data stored in the databases to be
accessed through a vulnerability that was also discovered by the hacker who carried out the
attack.
2. obliges the Customer to review all databases containing personal data processed by the
Customer with a view to determining whether encryption is justified and to inform the Authority
of the results of this review.
3. within 30 days of the date on which this Decision becomes final, by reason of the above
infringements.
order the company to pay a data protection fine of
HUF 80.000.000,-, i.e. eighty million HUF;
4. order the final decision to be made public by publishing the identity of the data controller, but
without revealing any business secrets.
In the event of non-compliance with the notice under point 2, the Authority will order the
enforcement of the decision, the fine and the interest on late payment.
There is no right of administrative appeal against this decision, but from the date of notification
may be challenged in administrative proceedings within 30 days by an application to the
Metropolitan Court of Budapest. The emergency situation does not affect the time limit for bringing
an action. The application must be submitted electronically to the Authority, which will forward it to
the court together with the case file.1 The request for a hearing must be indicated in the application.
For persons who do not benefit from a full personal exemption from the fee, the fee for the judicial
review procedure is HUF 30 000 and the action is subject to a right to a remission of the fee. Legal
representation is mandatory in proceedings before the Metropolitan Court.
I N D O C U L A R Y
I. Background, clarification of the facts
a. The incident report received by the Authority and the findings of the Authority's
inspection
(1) On 8 October 2019, the Authority launched an administrative inquiry into the data breach
notified electronically by the Customer on 25 September 2019, as the information provided
in the notification was insufficient to assess whether the Customer had fully complied with
its obligations under the General Data Protection Regulation, in particular Articles 32-34
thereof.
(2) According to the notification, no later than 23 September 2019, the Customer became
aware that an attacker had exploited a vulnerability available through the website
www.digi.hu to access the personal data of approximately 322,000 data subjects, the
majority of whom (approximately 297,000
1 T h e form NAIH_K01 is used to initiate administrative proceedings: Form NAIH_K01 (16.09.2019). The form
can be filled in using the general form filling program ("General Form Filling Program"). See:
3
https://www.naih.hu/kozig-hatarozat-birosagi-felulvizsgalata
4
people) were subscribers and customers of the Customer, and a smaller proportion (around
25,000 people) were subscribers to the Customer's newsletter. The personal data of the
subscribers and subscribers included their name, mother's name, date and place of birth,
address, ID number (sometimes personal identification number), e-mail address, landline
and mobile phone numbers.
(3) The Authority issued Orders NAIH/2019/7105/2. and NAIH/2019/7105/4. requesting the
Client to submit statements and documents. On the basis of the statements made by the
Customer, the Authority has established the following during the Authority's inspection.
(4) The Customer learned of the attack by being informed of it by the attacking hacker himself
[...] In his report, the attacker indicated that he had only retrieved a line of the database in
question as evidence, and that his intentions were of a facilitative nature, and therefore he
explained the technical nature of the error to the Customer. The Customer then corrected
the error, [...].
(5) Most of the data involved in the incident (around 297,000 people) was part of a "test"
database created on 21 April 2018 for testing purposes. The Client attempted to reconstruct
the reason and purpose for the creation of the test database by examining log files, system
alerts and correspondence. As the log files and alerts for the supposed upload date were
no longer available, the Customer was not able to clearly reconstruct the events. An email
from a testing colleague dated 23 April 2018 revealed that an error occurred on 21 April
2018, during which the web servers failed to reach the database servers. As a result, the
availability of subscriber data was lost. The Customer assumes that the data was uploaded
to the test database to temporarily resolve this error, in order to ensure the availability of
subscriber data.
(6) The source of the data loaded into the above test database created in connection with the
correction of the error was the personal data previously provided by the Data Controller's
customers. The customers had provided their personal data in various applications for
access to the test database via online or other sales channels [...]. The latest order resulting
in the data being loaded into the test database was dated [...]. In this database, there were
approximately 297,000 natural persons providing data.
(7) After correcting the above error and restoring access, the data uploaded to the test
database should have been deleted according to the Client, but this was not done due to an
oversight. The Customer was not aware of the availability of this data through the above
vulnerability until the attacker reported it. Access to the data by the attacker was not
detected by the Customer (e.g. by a network security device alert) before it was brought to
the attention of the attacker.
(8) In addition to the test database, the discovered vulnerability also a l l o w e d t h e attacker
to access another database behind the digi.hu website maintained by the Customer, called
[...], which contained personal data of the data subjects who subscribed to the newsletter
on the website. It contained data (name, e-mail address) of about 25.000 natural persons.
However, the investigations did not reveal any unauthorised access to the specific personal
data stored in this database according to the Client. However, due to the vulnerability, there
was a risk of access to this data.
5
(9) The specific vulnerability was through [...]. Here the vulnerability of the website was
exploited through the "sort field". The flaw that allowed unauthorised access was due to a
vulnerability in the content management system used by the Customer [...]2 , which was
exploited by the attacker. The vulnerability had been known for more than 9 years and a
patch was available, but the Customer had not previously installed it. The reason for this
was that the patch was not part of the patch packages officially released for the software.
Following the incident, the patch3 was installed.
(10) The Customer has not detected any further unauthorised access to the data concerned
through the security breach. No other circumstances indicated that the data could have
been accessed by anyone other than the hacker.
(11) The customer has also informed the Authority that, in order to prevent similar data
protection incidents, it regularly checks the databases it manages to ensure that personal
data are only processed/stored for legitimate purposes. Furthermore, it cleans the
databases from time to time, checks their security, identifies the applications and data hosts
associated with them. In addition, as a result of further external scrutiny, it will consider
purchasing and operating a higher level firewall.
(12) The Customer has an internal policy to keep the applications used by the Customer up to
date and to check them regularly for this purpose. At the time of the incident, the latest
version of the [...] system (with which the affected database was managed) was in use, but
did not include an unofficial patch to fix the vulnerability. In any case, the vulnerability itself
was included in the so-called "core" of [...]. In this respect, the Customer submitted that,
since many unofficial patches are released for the official version, it is not possible to check
them.
(13) Regarding the use of an open source content management system, Client [...] said that he
chose this system because it is free, widely used around the world, and is a software that is
constantly tested and supported.
(14) The Customer shall carry out vulnerability scans of the systems used by it on a regular
basis [...] using the [...] software. However, this scan did not cover the digi.hu website until
the date of the data breach. After the incident, the Customer extended the scan to this
website.
(15) [...]
(16) The vulnerability attacker [...]. The test database "body" affected by the incident was also
deleted by the Customer after learning about the bug.
b. Opening of a data protection authority procedure in the case and further clarification of
the facts
(17) In addition to further clarification of the facts of the case, the case is subject to Articles 5 and 32 of
the General Data Protection Regulation.
34 of the Directive on Freedom of Information and Informational Self-Determination, because of
the need to further investigate alleged breaches by the Customer of its obligations under Articles
2 [...]
6
3 Availability of the installed patch [...]
7
of Act CXII of 2011 (hereinafter: Infotv.), the Authority has decided to initiate a data
protection authority procedure with effect from 16 December 2019.
(18) In addition to the findings of the Authority's inspection, the facts of the case required further
clarification, therefore the Authority issued Orders NAIH/2020/1160. and
NAIH/2020/1160/3. requesting the Client to submit statements and documents, to which the
Client replied within the deadline. On the basis of the statements made by the Customer,
the Authority has established the following in the course of the Authority's procedure, in
addition to the circumstances clarified in the Authority's inspection.
(19) The Customer has provided a detailed description of the structure of the servers and other
network elements involved in the incident and the location of the databases, with a diagram
and description.4 Based on this, the datasets affected by the incident were accessible on a
[...]5 [...], which were located on the affected network at [...] (see figure below).
[...]
(20) The Customer used [...] to create and further manage the database.
(21) The personal data stored in the [...] database table affected by the incident was not
encrypted on the basis of the Customer's declaration. According to the Customer, this is
because the requirement for encryption of [...] databases is not reflected in the internal
policies.
(22) According to the Customer, the database [...] was not considered justified either because
the protection of personal data is in principle ensured by restricting access and by
appropriate assignment of rights, and the use of such encryption could cause problems in
the usability and operation of the databases. The reason for the specific problem was not
explained in detail by the Customer.
(23) Moreover, contrary to the above statements, the use of encryption in the Customer's IT
systems is generally reflected in the Customer's policy of [...]. The relevant parts of the
policy have been provided by the Customer at the Authority's request.
(24) At the Authority's request, the Customer provided a detailed description of how the attacker
managed to carry out the attack and gain access to the personal data stored in the
database. The method was described to the Customer by the attacker himself. Based on
this, the attacker carried out a so-called [...] attack on the affected digi.hu website. In the
Customer's opinion, the execution of this attack is a time-consuming task and can only be
carried out with the intention of unauthorised access and requires a high level of technical
knowledge. During the attack, the queries executed by the attacker finally revealed a
vulnerability on page [...], which made available and expropriated a total of 297,649 rows of
[...] in the [...] based test database.
4 In the Authority's reply to the clarification order NAIH/2020/1160, received on 10 February 2020, and in Annex 1.
5 [...]
8
(25) At the Authority's request, the Customer provided details of the exact categories of data
processed in the two separate databases concerned by the incident, the purpose and legal
basis for the processing of these data, and the exact number of personal data of the data
subjects processed.
- A test database called "body" containing subscriber data: name, birth name, mother's
name, place and date of birth, address, ID card number, personal identification number,
e-mail address, fixed and mobile phone number, bank account number, contract data,
service used data. In this case, the purpose of the processing is the conclusion of a
subscription contract. Legal basis for the processing: Article 6(1)(b) of the General Data
Protection Regulation (processing is necessary for the performance of a contract to
which the data subject is a party). A total of 297,649 data subjects' personal data were
processed in the database. This number represents 32.37% of the Data Controller's
residential customers.
- A live database of newsletter subscribers' data called "digihu", linked to the digi.hu
website: name and e-mail address. The purpose of data processing in this case is to
contact the data subjects with offers made by the Customer for commercial purposes
(direct marketing). Legal basis for data processing: Article 6(1)(a) of the General Data
Protection Regulation (consent to the processing of personal data for one or more
specific purposes). A total of 25,269 data subjects' personal data were processed in the
database. This number represents 2.74% of the Data Controller's residential
customers.
(26) The Customer has forwarded to the Authority its data management policies and internal
data protection incident handling procedures relating to the handling of the data files
affected by the incident.6
(27) The Customer provided the Authority with a technical description of the vulnerability on the
digi.hu website, which was also communicated to the Authority by the attacker in his
message.
(28) An email message sent by the hacker describing the vulnerability reveals that, in addition to
the database named "body" (containing 297,649 data records), the database involved in the
incident
The database called "digihu" contains, in addition to the personal data of the data subjects
who subscribe to the newsletter on the digi.hu website, access data to the interface of the
digi.hu website. In this database called 'digihu', the data of the partial/full administrator user
[...] can also be read from the database table [...], according to the hacker's letter. This
information includes the administrator [...]. According to the message, this data may allow
access to the administration interface of the digi.hu website.
(29) Based on the above, the databases and personal data involved in the incident according to
the hacker's email message are illustrated in the table below:
6 Annexes 2-3 to the Authority's reply to the clarification order NAIH/2020/1160, received on 10 February 2020.
9
Database name Number of people affected Type of data
"Test" 297.649 subscribers
Name, name at birth, place and date of
birth, mother's name, e-mail address,
password, mobile phone number, bank
account number, ID number, ownership
(owner or tenant), payment method,
willingness to pay (e.g. collection),
contract details, type of service used,
start/end date of service.
"Digihu"
25.269 newsletter subscribers
[...] partial / full
administrator
Newsletter subscribers: name, email
address Administrators: [...]
c. The first decision in a DPA procedure and its judicial review
(30) On the basis of the above facts, the Authority found an infringement by the Customer and
issued a decision on 18 May 2020 under case number NAIH/2020/1160/10, in which it
censured the Customer for breach of Article 5(1)(b) and (e) ("purpose limitation" and
"limited storage" principles) and Article 32(1) to (2) ("security of processing") of the General
Data Protection Regulation. As a result, the Authority has required the Customer to review
all its databases containing personal data with a view to determining whether encryption is
justified and to notify the Authority of the results. Furthermore, the Authority ordered the
Customer to pay a data protection fine of HUF 100,000,000 for the infringements found and
ordered the publication of the decision with the Customer's identification data.
(31) The Client, through its legal representative, challenged the Authority's Decision No
NAIH/2020/1160/10 before the Budapest General Court (hereinafter the "General Court").
By Order No 105.K.705.596/2020/11, the General Court referred the case to the Court of
Justice of the European Union (hereinafter 'CJEU') for a preliminary ruling on the
interpretation of Article 5(1)(b) and (e) of the General Data Protection Regulation.
(32) In its judgment C-77/21, the CJEU ruled that the principle of 'purpose limitation' does not
preclude a controller from recording and storing in a database created for the purpose of
carrying out tests and correcting errors personal data previously collected and stored in
another database, provided that such further processing is compatible with the specific
purposes for which the personal data were originally collected, as required by the General
Data Protection Regulation
shall be determined having regard to the criteria set out in Article 6(4). However, it
considered it contrary to the principle of "limited retention" for the controller to use personal
data previously collected for other purposes for the purpose of carrying out tests and
correcting errors
10
in the database for longer than is necessary to carry out these tests and correct these
errors.
(33) The General Court, also having regard to the findings of the CJEU, held in its judgment No
105.K.704.076/2022/4 that the Client's action challenging the Authority's Decision
NAIH/2020/1160/10 was partially well founded.
Findings of the General Court on the principle of purpose limitation (34-38):
(34) In its judgment, the General Court pointed out that it was not disputed between the parties
to the litigation (the Customer as the claimant and the Authority as the defendant) that the
claimant Customer collected and stored the personal data of its retail customers for the
purpose of concluding and performing subscriber contracts and that this initial purpose of
data processing was lawful under Article 6(1)(b) of the General Data Protection Regulation.
In addition, in April 2018, the Test Database was created for troubleshooting purposes due
to a technical failure affecting the operation of the server and resulting in the loss of
subscriber data. Although the original purpose of the data processing was the conclusion
and performance of subscriber contracts, this did not in itself mean that this purpose could
not be accompanied by additional so-called "data processing" activities.
"overarching goals", which also means that the principle of "purpose" is not
"overarching objective" also applies.
(35) In its judgment (point 35), the CJEU stated that processing for additional purposes may be
possible if the further processing of personal data is compatible with the purpose for which
the data were originally collected, which must be determined by taking into account, in the
light of Article 6(4) of the GDPR, inter alia: the possible link between the purpose for which
the personal data were collected and the purpose of the envisaged further processing; the
circumstances in which the personal data were collected; the nature of the personal data;
the possible consequences of the further processing for the data subjects; the existence of
appropriate safeguards. The definition of these criteria in Article 6(4) of the GDPR is
illustrative and the existence of even one of them may be sufficient to comply with Article
5(1)(b) of the GDPR. The CJEU has also held in its Judgment (paragraph 38) that it is for
the national court to determine, in the light of those criteria and taking into account the
totality of the circumstances of the case, the purposes of the initial collection and the
purposes of the further processing and, where the purposes of the further processing are
different from the purposes of the initial processing, to assess whether the further
processing is compatible with the purposes of the initial collection.
(36) In the light of the CJEU judgment and the facts not disputed by the parties, the General
Court found that the applicant had originally collected and stored the personal data for the
purpose of concluding and performing subscriber contracts, and that the direct purpose of
creating the Test Database was to carry out the necessary tests and correct the error in
relation to a specific error that had occurred. The Court further found, in accordance with
paragraph 44 of the Judgment, that although the Test Database was created by the
applicant for the purpose of troubleshooting, it was at the same time specifically linked to
the original purpose of the processing of the personal data. The testing and the correction
of the errors were clearly necessary to allow the applicant to access and use the subscriber
data for the purposes of
11
to conclude subscriber contracts,to perform therebyfurthering the original
purpose of the data processing.
(37) The Authority, in its statement at the hearing of the case in the light of the CJEU's
Judgment, did not contest the compatibility of the original purpose of the processing
(conclusion and performance of contracts) and the additional purpose of the processing
(troubleshooting) during the case, and it was irrelevant that compatibility could not be
established on the basis of other circumstances among those to be examined, as the
existence of even a single circumstance could establish compatibility.
(38) On the basis of the above, the Client has, subject to Article 6(4)(a) of the GDPR, lawfully
processed the personal data of the customers in the test database in accordance with
Article 5(1)(b) of the GDPR and in a manner compatible with the original purpose of the
processing, according to the General Court.
Findings of the General Court with regard to the principle of limited storage (39-41):
(39) The General Court has also held in its judgment, referring to points 54 and 57 of the CJEU
judgment, that over time, even initially lawful processing may become incompatible with the
GDPR if the data are no longer necessary for the purposes for which they were processed
and must be deleted once those purposes have been fulfilled. Although the purpose for
which the test database was created was indeed closely related to the original purpose of
the processing, it was not fully identical insofar as it was directly related to the purpose of
carrying out the necessary tests and correcting the error that occurred.
(40) Consequently, the compliance with the principle of limited storage of data in the test
database had to be examined in relation to this purpose and it had to be established that
the data in the test database could be lawfully stored for the time necessary to carry out the
tests and correct the errors. As the error was rectified in April 2018 and the Customer only
terminated the Test Database in September 2019, the data retention period of more than
one and a half years exceeded the necessary data retention period by an unreasonably
long period. The Customer has not been able to demonstrate compliance with the
principles of Article 5(2) of the General Data Protection Regulation; it has itself admitted
that it did not delete the test database out of negligence, although its maintenance was no
longer justified by the failure to remedy the error, and that it had forgotten about the test
database until it became aware of the attack. All this clearly indicates that the Customer no
longer had the direct purpose of the contested processing (but not per se precluding the
purpose limitation of the processing as described above).
(41) On the basis of the above, the processing of the applicant Client's data, as stated in the
judgment of the Metropolitan Court of Budapest, is contrary to the principle of "limited
storage" in Article 5(1)(e) of the General Data Protection Regulation.
12
Further findings of the General Court (data security, legal consequences)(42-45):
(42) In addition to the above, in its judgment the General Court found a violation of Article 32(1)
to (2) of the General Data Protection Regulation, as stated in the Authority's original
Decision NAIH/2020/1160/10.
(43) The General Court further found that, based on the facts of the case, the Authority's
decision did not constitute a breach of Article 5(1)(b) of the General Data Protection
Regulation, and therefore, pursuant to Article 89(1)(b) and Article 92(1)(b) of Act I of 2017
on Administrative Procedure (hereinafter: the "Act"), the decision was annulled as regards
the finding of a breach of Article 5(1)(b) of the General Data Protection Regulation. The
General Court also annulled the part of the decision imposing the fines and the publication
of the decision and ordered the Authority to initiate new proceedings in respect of the
penalties. Further to the judgment of the Court of First Instance of the European
Communities of 20 June 2006 in Case C-133/07. 88.
§ Paragraph (1)(a) of the judgment, the action was dismissed. The Court did not examine
the merits of the part of the action relating to the assessment of the legal consequences of
the finding of infringement which differed from that of the Authority.
(44) In its judgment, the General Court ruled that, in a retrial, the Authority must decide only on
the legal consequences and must consider the extent to which the lack of a breach of the
"purpose limitation" principle affects the imposition of the fine and the applicability of the
publication of the decision. If the Authority decides to impose a fine in the retrial, it should
also take into account, when determining the amount of the fine, that this infringement does
not exist in relation to the data processing activities of the Customer under investigation. In
view of this, the amount of the fine to be imposed may not exceed HUF 100,000,000 as
imposed in the original Authority procedure.
(45) In the light of the judgment of the General Court set out above, the Authority adopted the
present decision in the repeated administrative procedure.
II. Legal provisions applied
Pursuant to Article 99 of Act CL of 2016 on the General Administrative Procedure (hereinafter: the
General Administrative Procedure Act), the authority shall, within the limits of its competence,
verify compliance with the provisions of the legislation and the enforceability of the decision.
Pursuant to Article 2(1) of the General Data Protection Regulation, the General Data Protection
Regulation applies to the processing of the notified incident.
Article 4(12) of the General Data Protection Regulation defines what constitutes a personal data
breach, according to which a 'personal data breach' is 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.
13
According to Article 5(1)(b) of the General Data Protection Regulation, personal data should be
collected only for specified, explicit and legitimate purposes and not be processed in a way
incompatible with those purposes; [...] ('purpose limitation').
According to Article 5(1)(e) of the General Data Protection Regulation, personal data must be kept
in a form which permits identification of data subjects for no longer than is necessary for the
purposes for which the personal data are processed; [...] ('limited storage').
Pursuant to Article 5(2) of the GDPR, the controller is responsible for compliance with the
principles set out in Article 5(1) and must be able to demonstrate such compliance
('accountability').
Pursuant to Article 6(4) of the General Data Protection Regulation:
Where the processing for purposes other than those for which the data were collected is not based
on the data subject's consent or on a Union or Member State law which constitutes a necessary
and proportionate measure in a democratic society for the purposes laid down in Article 23(1), the
controller shall take into account, inter alia, in order to determine whether the processing for the
other purposes is compatible with the purposes for which the personal data were initially collected:
a) the purposes for which the personal data are collected and any links between the purposes for
which further processing is envisaged;
b) the circumstances in which personal data are collected, in particular the relationship between
the data subjects and the controller;
c) the nature of the personal data, in particular whether special categories of personal data are
processed under Article 9 and whether data relating to criminal liability and criminal offences are
processed under Article 10;
d) the possible consequences for the data subjects of the envisaged further processing of the
data;
e) appropriate safeguards, which may include encryption or pseudonymisation.
Pursuant to Article 17(1)(a) of the GDPR, the data subject has the right to obtain on his or her
request the erasure of personal data relating to him or her without undue delay and the controller is
obliged to erase personal data relating to him or her without undue delay when [...] the personal
data are no longer necessary for the purposes for which they were collected or otherwise
processed.
According to Article 32(1)(a) of the GDPR, the controller and the processor shall implement
appropriate technical and organisational measures to ensure a level of security appropriate to the
scale of the risk, including, where appropriate, pseudonymisation and encryption of personal data,
taking into account the state of the art and the cost of implementation, the nature, scope, context
and purposes of the processing and the varying degrees of probability and severity of the risk to
the rights and freedoms of natural persons.
According to Article 32(2) of the General Data Protection Regulation, when determining the
appropriate level of security, explicit account must be taken of the risks arising from the
processing, in particular the risks of accidental or unlawful loss or alteration of personal data
transmitted, stored or otherwise processed, or of
14
unlawful destruction, loss, alteration, unauthorised disclosure or unauthorised access.
Pursuant to Article 33(1) to (2) and (4) to (5) of the GDPR, the controller shall notify a personal
data breach to the supervisory authority competent under Article 55 without undue delay and, if
possible, no later than 72 hours after the personal data breach has come to its attention, unless the
personal data breach is unlikely to pose a risk to the rights and freedoms of natural persons. If the
notification is not made within 72 hours, it shall be accompanied by the reasons justifying the delay.
The processor shall notify the data protection incident to the controller without undue delay after
becoming aware of it. If and to the extent that it is not possible to communicate the information at
the same time, it may be communicated in batches at a later stage without further undue delay.
The controller shall keep records of the data breach, indicating the facts relating to the data breach,
its effects and the measures taken to remedy it. This record shall enable the supervisory authority
to monitor compliance with the requirements of this Article.
Pursuant to Section 101 (1) a) of the Public Act, if the authority finds an infringement during the
official inspection, it initiates official proceedings. Pursuant to Section 38(3) and Section 60(1) of
the Infot Act, the Authority shall, in the exercise of its duties under Section 38(2) and (2a) of the
Infot Act, conduct ex officio data protection authority proceedings in order to enforce the right to the
protection of personal data.
Pursuant to Section 103 (1) of the Act, the provisions of the Act relating to proceedings instituted
on application shall apply with the exceptions provided for in Sections 103 and 104 of the Act.
Pursuant to Article 61(1)(a) of Act CXII of 2011 on the Right to Informational Self-Determination
and Freedom of Information ( hereinafter: Infotv.), the Authority may apply the legal consequences
set out in the General Data Protection Regulation in connection with the processing operations
specified in Article 2(2) and (4).
Pursuant to Article 58(2)(b) and (i) of the General Data Protection Regulation, the supervisory
authority, acting in its corrective capacity, shall impose a penalty on a controller or processor where
its processing activities have infringed the provisions of the Regulation or an administrative fine in
accordance with Article 83, in addition to or instead of the measures referred to in this paragraph,
depending on the circumstances of the case. Paragraph 2 of the same Article
(d), the supervisory authority, acting in its corrective powers, shall instruct the controller or
processor to bring its processing operations into compliance with the provisions of the Regulation,
where appropriate, in a specified manner and within a specified period.
The conditions for imposing administrative fines are set out in Article 83 of the General Data
Protection Regulation. Pursuant to Article 75/A of the GDPR, the Authority shall exercise its powers
under Article 83(2) to (6) of the GDPR taking into account the principle of proportionality, in
particular by taking action to remedy a first infringement of the provisions on the processing of
personal data laid down by law or by a legally binding act of the European Union, in particular by
issuing a warning to the controller or processor in accordance with Article 58 of the GDPR.
Pursuant to Section 104(1)(a) of the General Procedural Act, the Authority shall initiate
proceedings ex officio within its jurisdiction if it becomes aware of circumstances giving rise to the
initiation of proceedings; pursuant to Section 104( 3)(a) of the same Act, the ex officio procedure
shall be the first procedural act
15
shall begin on the day of its completion, notification of its initiation to the known customer may be
waived if the authority decides within eight days of the initiation of the procedure.
The Kp. (3)-(4) of Article 97, the administrative body shall conduct the repeated procedure or
perform the administrative act within the time limit set in the final decision, or, failing this, within the
time limit set by law. The operative part of the court's decision and the reasons for the decision
shall bind the administrative bodies acting in the course of the repeated procedure and the
performance of the act ordered by the court's decision.
III. Decision
a. Applicability of the General Data Protection Regulation
(46) Pursuant to Article 99(2) of the General Data Protection Regulation, the Regulation shall
apply from 25 May 2018. The test database "test" affected by the data breach was created
in April 2018 for testing and troubleshooting purposes, according to the Customer's
declaration.
(47) The database called "digihu", which contained data related to the digi.hu website, contained
direct marketing data, newsletter subscribers' data and administrative data giving access to
the website interface, which were not test data but live, up-to-date data.
(48) The Customer was informed about the fact that the two above databases could be
accessed from outside by exploiting one of the vulnerabilities of the digi.hu website by an
external attacker who discovered the security flaw on 23 September 2019 at the earliest.
The data processing affected by the incident, namely the storage of customer data in the
databases affected by the incident, continued after the General Data Protection Regulation
became applicable. The processing is therefore subject to the provisions of the Regulation,
both under Article 99(2) and under the scope provisions of Article 2(1).
(49) In addition to the above, it should be noted that the relevant time for the application of the
provisions of the General Data Protection Regulation on the handling of data breaches is
the time of knowledge of the breach, since the Regulation links the legal consequences
provided for to this time. From this perspective, the fact when the test database affected by
the incident and managed with inadequate data security measures was created and when
the data collected from the data subjects is included in it is not a relevant factor. The risks
to the rights and freedoms of data subjects posed by both the occurrence of the incident
and the inadequate level of data security continued to exist after the Regulation became
applicable.
b. The nature of the incident and the measures taken by the controller
(50) On the basis of the facts found, the Authority has established that the earliest that the
Customer was aware of the data breach occurred, according to the Customer's own
account, was when the hacker conducting a vulnerability assessment on the digi.hu website
concerned notified the Customer by e-mail on 23 September 2019. Prior to that, the
Customer was not aware of the existence of the vulnerability. The vulnerability scan carried
out by the attacker, the
16
the delisting of data categories in the affected databases and access to the data stored in
the test database could not be detected by the Customer on its own, so the incident and the
vulnerability that enabled it were only reported by the hacker who had committed it.
(51) According to Article 4(12) of the General Data Protection Regulation, a personal data
breach is a breach of security that results in unauthorised access to personal data
processed. The link with the security incident can thus be considered a key element for the
purposes of the concept. In the context of the Customer's incident report and the
clarification of the facts, it can be established that the test database containing personal
data created for testing and troubleshooting purposes was accessed by the attacker by
exploiting a vulnerability available through the digi.hu website maintained by the Customer.
The unauthorised access to personal data could therefore have been obtained by exploiting
an IT security vulnerability, resulting in a data breach.
(52) According to Article 33(1) of the General Data Protection Regulation, as a general rule, a
data protection incident must be notified to the supervisory authority. This paragraph and
also recital 85 of the Regulation state that the notification may be waived by the controller
only if the controller can demonstrate, in accordance with the principle of accountability7 ,
that the personal data breach is unlikely to pose a risk to the rights and freedoms of natural
persons. As the main rule is that the incident must be notified to the authorities, the
exception to this is also narrowly understood.
(53) As stated in recital 75 of the General Data Protection Regulation, if the processing, such as
the storage of data of residential customers and administrators in the present case, could
give rise to identity theft or identity fraud, it is considered to be a substantial risk.
(54) The data (name, birth name, mother's name, place and date of birth, address, ID card
number, personal number, e-mail address, landline and mobile phone number, payment
and banking details, data related to the service requested) stored in the database created
by the Customer for testing and error correction purposes may be used to commit identity
theft or identity fraud.
(55) With regard to the other data accessible through the security breach, which is linked to the
digi.hu website and stored in the database called "digihu" (newsletter and administrator
data), the hacker also indicated the vulnerability of this data, although he did not request
specific data, but only listed the types of data available to administrators ([...]).
Nevertheless, there were also shortcomings in the security measures, such as an
inadequate level of protection against unauthorised access to this data.
(56) On the basis of the above, the Authority considers that a data breach can be considered as
a risk and therefore, if such an incident becomes known to the controller, it should be
reported to the
7 GDPR Article 5(2): the controller is responsible for compliance with paragraph 1 [the principles] and must
be able to demonstrate such compliance ('accountability').
17
must report to the supervisory authority pursuant to Article 33(1) of the General Data
Protection Regulation. The Data Controller notified the Authority on 25 September 2019
and complied with its obligation to do so within 72 hours of becoming aware of the incident.
The Authority therefore found no breach of the notification obligation.
(57) In relation to the incident, the Data Controller has described the measures it has taken to
mitigate any adverse consequences that may arise from the incident. On this basis, the test
database was deleted and a patch was installed to fix the vulnerability in the [...] system
used. The Customer had already implemented organisational measures to filter out
unnecessary data and databases before the incident occurred, but the affected test
database had not been detected earlier. In addition, the Customer has stated that it is
considering installing higher firewalls to increase the level of protection and will extend the
regular vulnerability scans and [...] it already performs to the digi.hu website in the future.
c. Data security measures related to the storage of data affected by the incident
(58) With regard to security of processing, Article 32(1) of the Regulation states that, taking into
account, inter alia, the state of science and technology and the risks involved, it is the
responsibility of the controller to ensure the security of the data by appropriate technical
and organisational measures. This Article (1)(a) i n c l u d e s , where appropriate, the
pseudonymisation and encryption of personal data.
(59) Pursuant to Article 32(2), the determination of the appropriate level of security shall
explicitly take into account the risks arising from the processing, in particular from
accidental or unlawful destruction or accidental loss, alteration, unauthorised disclosure of
or access to personal data transmitted, stored or otherwise processed.
(60) Based on the information provided in the incident report and the facts established during
the administrative inspection and the procedure, the occurrence of the data protection
incident was due to the existence of a vulnerability in the [...] system used by the Customer
for content management, which was also used to manage the databases affected by the
incident, which was known and correctable for a long time at the time of the incident. The
Customer claims that it did not fix this vulnerability until the incident occurred, as the patch
package for it is not part of the officially released version of the software. The Customer
does not track or monitor the unofficial patches available for [...], as it says it does not have
the capacity or capability to do so, due to the number of unofficial patches available for the
Software.8 The Customer regularly performs vulnerability scans on the systems it manages,
but this did not include the digi.hu website until the incident occurred.9
8 Paragraph 6 of the Authority's reply to the clarification order NAIH/2019/7105/2, received on 24 October 2019.
9 Paragraph 5 of the Authority's reply to the clarification order NAIH/2019/7105/4, received on 3 December 2019.
18
(61) According to the Client's IT Security Policy [...] [...].
(62) The handling of customer data affected by the incident can be considered risky, also on the
basis of the content of the data categories, as set out in point III./b. of this Decision. The
fact that the database managed by the Customer contained personal data of a large
number of data subjects is a factor that significantly increased the risks:
- test database "test": 297,649 subscribers concerned, representing 32.37% of the Data
Controller's residential customers,
- database called "digihu": 25.269 subscribers concerned, 2,74% of the Data Controller's
residential customers, in addition [...] partial / full administrator access data related to
the digi.hu website.
(63) These are therefore sensitive data processing operations involving hundreds of thousands
of data subjects, more than one third of the Data Controller's residential customers, a
significant number of data subjects in relation to the Hungarian population, which, according
to the preamble of the General Data Protection Regulation (75), entail significant risks to
the rights and freedoms of data subjects. Article 32 of the Regulation requires the controller
to implement security measures proportionate to the risks.
(64) The testing and error correction activities carried out by the Customer in relation to the
customer database called "body" would not otherwise pose a problem if security measures
proportionate to the risks posed by such data management are also applied. The
Customer's internal information security policies also include requirements to conduct a
prior risk assessment of the systems used, mapping historical vulnerabilities and available
patches, and to apply appropriate encryption. In addition, systems should be regularly
scanned to identify potential vulnerabilities.
(65) The Customer sent the Authority a technical description of the vulnerability on the digi.hu
website, which the attacker communicated to the Authority in his message. The Authority's
IT security expert has examined the description of the vulnerability provided by the attacker
and the information provided by the Customer in relation to it. The description of the
vulnerability is set out in the Information Security Expert's Opinion NAIH/2020/1160/5,
which was communicated to the Customer by Order NAIH/2020/1160/7 pursuant to Section
76 of the General Administrative Procedure Act.
(66) According to the expert opinion, it can be concluded that the vulnerability assessment
carried out by the assailant shows that [...] vulnerability is involved. This type of flaw is
characterised by [...]. However, there are web vulnerability scanning applications that can
filter out [...] vulnerabilities by automation. For example, the [...] software referred to and
used by the Customer is also widely used for this purpose. The use of such vulnerability
checking software is in particular
do not require "high level IT knowledge" or code-breaking skills, they can be mastered by a
person interested in the subject and moderately familiar with IT security issues after some
practice and time.
(67) The vulnerability scan parameters described by the attacker show that the vulnerability was
found via the [...] link. On this link, [...] was vulnerable, i.e. [...] vulnerability [...] was
exploitable. The peer review
19
the database [...] within the relevant databases ("body" and "digihu" databases) can be
successfully retrieved. Within these databases, additional data can be obtained, if [...], so
that [...] (the specific personal data) can be obtained.
(68) The storage of sensitive data in the database in plain text is considered to be a high-level
security problem, which can be avoided by using appropriate encryption. The use of [...], as
mentioned by the Client, could have prevented the specific contents of the relevant [...]
database from being known.
(69) An email message sent by the attacker describing the vulnerability also revealed that the
from the database "digihu", [...] partial/full administrator user data can be retrieved. These
data include the [...]. The possibility of accessing such sensitive administrator level data
also greatly increases the risks of an incident, as it is easy to commit identity theft or even
unauthorised access to additional data in possession of such data.
(70) The Customer submitted its comments and observations on the above IT security opinion to
the Authority, after it was notified by the Authority by means of Order No NAIH/2020/1160/7
pursuant to Section 76 of the General Administrative Procedure Act.
(71) On this basis, the Customer reiterated that the hacker only retrieved one line of the "body"
database as evidence and described it in his letter, a n d t h a t there was no evidence
of further unauthorised access. The Authority does not contest this fact in the present
Decision. Regardless of this circumstance, the data security weaknesses assessed in this
point of the Decision (Chapter III / point c) existed in relation to all personal data processed
in the databases concerned and therefore the risks to data subjects can be linked to all
personal data processed.
(72) The Client also highlighted that the high level of IT knowledge required to detect
vulnerabilities is time-consuming and complex. In this respect, the Authority notes that the
vulnerability detection software mentioned above can automatically detect vulnerabilities, is
easily accessible to anyone (possibly free of charge) and therefore does not require any
specific cryptographic knowledge on the part of the specific user.
(73) The Client reiterated in its statement that, as access control to the database is theoretically
secured by means of a privilege allocation, it did not consider the use of encryption to be
justified. Furthermore, the encryption of the [...] database table [...] seemed to the Client to
be meaningless, as some of the personal data concerned (e.g. names, addresses,
telephone numbers), the encryption of which would have caused problems for the usability
and functioning of the database in the present case. The reasons for this were not further
specified by the Customer. For the Authority's findings in this respect, see paragraphs 68 to
70 of this Decision.
(74) Finally, the Customer drew the Authority's attention to the fact that [...] employees
(administrators, system administrators, users) had stored [...] in the relevant "digihu"
database. [...] The Authority does not dispute the above, but notes (in line with the
Authority's IT security opinion) that, notwithstanding the above, the
20
the possibility of accessing other [...] data is in itself a serious security risk.
(75) The vulnerability in the content management system ([...]) used by the Customer was
known for 9 years, along with the workaround to fix it. The related postings were made
public on the official website of the software, in the forum there.10 No patch was officially
produced for the bug, but an unofficial patch was available, publicly and free of charge to
anyone.
(76) The vulnerability was detected during a vulnerability scan of the digi.hu website by an
external attacker. The [...] software used by the Customer to check other systems is also
suitable for this purpose. However, the Customer had previously failed to carry out these
tests on the website, so that the vulnerability could not be detected. The lack of security
scans on the publicly accessible website visited by customers thus allowed the vulnerability
to remain undetected until the actual incident occurred. Regular vulnerability scanning could
have detected the flaw, as evidenced by the investigation of the hacker who discovered the
vulnerability. From this point of view, the "unofficial" nature of the software component that
can be used to fix the existing vulnerability is irrelevant, as it has no bearing on the
existence and detectability of the flaw. Increased attention and measures regarding
vulnerabilities in the systems used are also required by the Customer's internal policies.
(77) For websites that are publicly available on the internet and may be visited by a large
number of customers (where applicable), there is a strong expectation that operators
should be prepared for potential vulnerabilities. This should not be a major concern for the
Customer in this case either, given the state of the art and the cost of implementation, given
its position in the market. The requirement for periodic vulnerability testing of the website
and all other publicly available systems on the Internet was also addressed by the
Customer after the incident, acknowledging the need for this.
(78) The level of security of the databases involved in the incident was therefore not in
compliance with Article 32(1) to (2) of the GDPR, as the long-standing, otherwise
detectable and correctable security flaw and the failure to perform vulnerability checks on
the digi.hu site allowed unauthorised access to personal data.
(79) The Customer has also informed the Authority that no encryption has been applied to
personal data in the databases concerned ([...]). This is confirmed by the message sent by
the hacker, as it states that the specific personal data could be retrieved from the database
in a readable form. In order to prove this, the hacker requested the data of the person
concerned
a row of the "body" database, which was also communicated to the Client.
(80) The Customer's IT Security Policy [...].
(81) The databases were created by the Customer using the [...] software, which allows for the
encryption of data [...] The technology used therefore allowed for the use of encryption on
the personal data processed, at an additional cost
10 [...]
21
can't mean. Nevertheless, the Customer has stated that it does not apply encryption to the
[...] databases it manages, and has not applied this option to the databases affected by the
incident. The Customer indicated that the protection of personal data is in principle ensured
by restricting access and by appropriate allocation of rights, and that the use of such
encryption could cause problems in the usability and operation of the databases. The
potential problems were not specified by the Customer.
(82) However, in the absence of the use of encryption in the present case, the vast majority of
the personal data stored in the databases affected by the incident became readable and
unauthorizedly accessible. This fact, in turn, significantly increased the risks to the data
subjects in relation to the data breach that occurred.
(83) In general, the encryption of personal data is covered by Article 32 of the General Data Protection
Regulation
(1)(a) as an appropriate security measure.
(84) Although the Customer did not specify why it considers the encryption of the database [...]
to be problematic in relation to this particular processing, it should seek to protect sensitive
and bulk personal data from leaks even in its absence. He should also be able to justify the
exact reasons for not encrypting the data in accordance with Article 5(2) of the General
Data Protection Regulation.
(85) As the risks to data subjects posed by the incident and the security measures applied were
significantly increased by the lack of encryption, in order to comply with Article 32(1)(a) of
the General Data Protection Regulation and its internal rules on the matter, the Authority
has by the present Decision requested the Customer to review all databases containing
personal data processed by it with a view to reducing the risks, to assess whether
encryption is justified and to inform the Authority of the results, also in accordance with the
principle of accountability.
(86) In the light of the above, the Authority therefore concluded that the Customer did not
comply with the legal requirements on data security laid down in Article 32(1) to (2) of the
General Data Protection Regulation.
(87) This infringement is confirmed by the judgment of the General Court in Case
105.K.704.076/2022/4.
d. Compliance of the management of the test database affected by the incident with certain
principles
Goal orientation (88-96):
(88) The principle of 'purpose limitation' referred to in Article 5(1)(b) of the GDPR requires that
personal data are collected only for specified, explicit and legitimate purposes and are not
processed in a way incompatible with those purposes.
22
(89) According to the related opinion of the Working Party on Data Protection 29 (WP203), the
principle is composed of two further sub-principles, namely firstly the obligation to specify
the purpose and secondly the obligation to use the data in this context.
(90) In its previous Decision NAIH/2020/1160/10, the Authority found that the purpose of the
creation of the 'body' database (error correction) is separate from the purpose of the original
processing of personal data (performance of a contract). According to the previous
decision, error correction as a separate processing purpose may be legitimate, but this
separate processing must also comply with the requirements of the General Data
Protection Regulation, including the purpose limitation principle. The purpose of error
correction in relation to the creation of a test database should continue to exist until the
error itself has been corrected by the Controller. As previously stated in the Decision, once
the error was corrected, the separate purpose of the processing ceased to exist and the
test database containing the personal data should have been deleted, subject to Article
17(1)(a) of the General Data Protection Regulation. By unnecessarily continuing to store
the database, the Client's processing of this data, in the Authority's view as set out in the
previous Decision, therefore infringed the 'purpose limitation' principle referred to in Article
5(1)(b) of the GDPR.
(91) In its judgment No 105.K.704.076/2022/4, also referred to in point I/c of the present
decision, the General Court held that the principle of purpose limitation, also in view of the
findings of the preliminary ruling procedure of the CJEU, was not infringed in the context of
the processing at issue, contrary to the Authority's previous decision.
(92) The reason given by the General Court was that the Customer collected and stored the
personal data of its retail customers for the purpose of concluding and performing
subscriber contracts, and that this initial purpose of processing was lawful under Article
6(1)(b) of the GDPR. This legitimate purpose of processing may be linked to so-called
'further purposes', which also result in the principle of 'purpose limitation' being applied to
this
"overarching objective" also applies.
(93) The processing for these additional "incidental purposes" may be lawful if the further
processing of personal data is compatible with the purpose for which the data were
originally collected, subject to Article 6(4) of the GDPR. The definition of these criteria in
Article 6(4) of the GDPR is illustrative and the existence of any one of them may be
sufficient to comply with the purpose limitation principle. The CJEU has also stated in its
Judgment (paragraph 38) that in the present case it is for the national court to assess
whether the storage of data in a test database deviates from the purpose of the original
processing (performance of the contract) and, if so, whether the additional processing is
compatible with the original purpose of the data collection.
(94) In the light of the CJEU judgment and the facts not contested by the parties, the General
Court found that the applicant had originally collected and stored the personal data for the
purpose of concluding and performing subscriber contracts, and that the direct purpose of
creating the test database was to carry out the necessary tests and correct the error in
relation to a specific error that had occurred. The Court further found, in line with paragraph
44 of the Judgment, that although the test database was created by the Client for the
purpose of troubleshooting, it was at the same time specifically related to the original
purpose of the processing of the personal data. The testing and correction of errors was
clearly necessary
23
to enable the applicant to access and use the subscriber data for the conclusion and
performance of subscriber contracts, thereby furthering the original purpose of the data
processing.
(95) The General Court found that the Client lawfully processed the personal data of the
customers in the test database in accordance with Article 5(1)(b) of the General Data
Protection Regulation, in a manner compatible with the original purpose of the processing,
subject to Article 6(4)(a) of the General Data Protection Regulation.
(96) As stated in the judgment, the Authority concludes in the present reopened procedure that
no breach of the purpose limitation principle can be established in relation to the handling of
the test database involved in the incident.
Limited shelf life (97-103):
(97) The principle of 'limited storage' referred to in Article 5(1)(e) of the General Data Protection
Regulation requires that personal data must be stored in a form which permits identification
of data subjects for no longer than is necessary for the purposes for which the personal
data are processed.
(98) Closely related to the purpose limitation principle, this principle prohibits the storage of
personal data that are obsolete and can no longer be used for any purpose. However, the
principle limits the limitation of the storage period in terms of the storage of data in a way
that is capable of identifying the data subjects. Thus, the storage of anonymised data is still
possible for the controller, but it must be in a form that does not allow the data subject to be
identified or to be identified in the future.
(99) In its previous Decision No 2020/1160/10 NAIH/2020/1160/10, the Authority found that the
handling of the test database involved in the incident was also in breach of the principle of
limited storage.
(100) The General Court in its judgment 105.K.704.076/2022/4, also referred to in point I/c of the
present decision, has held, with reference to paragraphs 54 and 57 of the CJEU decision,
that even initially lawful processing may become incompatible with the GDPR over time, if
the data are no longer necessary for the purposes of the processing and must be erased
once those purposes have been fulfilled. Although the purpose for which the test database
was created was indeed closely related to the original purpose of the processing, it was not
identical in so far as it directly served to carry out the necessary tests and to correct the
error that occurred.
(101) Consequently, the Customer was only legally able to store the data in the test database for
the time necessary to perform the tests and correct the errors. As the error was corrected in
April 2018 and the Customer only deleted the test database in September 2019, the data
management for more than one and a half years exceeded the necessary data
management period by an unreasonably long time. The Customer has not been able to
demonstrate compliance with the principles of Article 5(2) of the General Data Protection
Regulation; it has itself acknowledged that the test database
24
negligently did not delete it, even though it was no longer justified to maintain it, and then
forgot about the test database until the attack was discovered.
(102) The above, as stated in the General Court's judgment, do not in themselves exclude the
purpose limitation of the processing, but the contested processing (troubleshooting) no
longer had a legitimate purpose directly compatible with the original collection (performance
of the contract). The originally compatible and therefore legitimate
"therefore, the Customer was no longer legally able to continue to store the test database in
a form that allowed the identification of the data subjects.
(103) On the basis of the above, the Authority concludes in the present re-proceeding that the
Client's continued storage of the test database for an unjustified period of time for further
storage which is no longer compatible with the original legitimate purpose of the processing
is contrary to the principle of 'limited retention' in Article 5(1)(e) of the GDPR.
e. Findings on the sanction applied.
(104) The Authority has considered the type of sanction it intends to impose on the Customer for
the breaches found and whether it is justified to impose a data protection fine on the
Customer. In this context, the Authority, on the basis of Article 83(2) of the GDPR and
Section 75/A of the GDPR, and also having regard to Section 61(5) of the GDPR,
considered all the relevant circumstances of the case and concluded that, in the case of the
infringement found in the present procedure, the warning and the notice to the Customer
are not in themselves a proportionate and dissuasive sanction and that the imposition of a
fine is therefore justified.
(105) In determining the need to impose fines, the Authority weighed the aggravating and
mitigating circumstances of the infringements as follows:
Aggravating circumstances (106-115):
(106) The data breach at the Customer's premises was due to a data security flaw for which a
free patch had long been available on the market and the vulnerability was easily
detectable even by a third party, so that the Customer would have had the opportunity to
avoid exposure to unauthorised access to the data for a very long time, had the risks been
properly assessed.
(107) The large amount of data concerned by the Client in the case, the risks posed by the
sensitivity of the data, and the Client's market position, which make it more likely to be
required to apply appropriate data security measures.
(108) As reflected in its own internal policies, the risks arising from the use of the (open source)
content management system used by the Customer and the assessment of those risks
must be carried out by the Customer. By not taking these measures, the Customer has not
adequately complied with the requirements of its own internal policies.
(109) The lack of encryption and risk assessment applied to the personal data concerned also
increased the risk of exposure to an incident. According to this
25
measure is also reflected in the Customer's relevant internal policies, which it has also failed to
comply with or has not complied with fully.
(110) With regard to the digi.hu website, the involvement of personal data of users with
administrator rights (see paragraph (29) and the related table) was considered by the
Authority as a factor seriously increasing the security risks.
(111) The Authority considers the identified data security weaknesses to be a systemic problem,
according to which the infringing situation had existed for a long time before the incident
occurred at the data controller Customer in respect of the databases concerned.
(112) In addition to the data security weaknesses, the occurrence of the incident can be directly
traced back to the storage of the test database created for troubleshooting purposes for a
long period of time (one and a half years), which is in principle unlawful and capable of
identifying the data subjects. If the test database had been deleted in accordance with the
principle of limited storability after the debugging, the risks to data subjects posed by the
incident would have been much less severe, as the number of data subjects affected could
have been reduced by the number of data subjects in this test database (297,649 data
subjects). If the test database had been deleted in time, the data security vulnerabilities
would have only existed for the personal data processed in the direct marketing database
(25,269 data subjects) and the administrative data of the digi.hu website ([...] data
subjects).
(113) The identification of outdated, redundant data, the cleaning, updating and deletion of data
as necessary is also included in the Customer's internal specifications, which are not
consistent with the circumstances of the management of the test database involved in the
incident.
(114) The data security breaches and the unlawful processing of personal data affected a large
number of data subjects (322,966 in total), which includes more than two thirds of the
Client's retail customers. This is a significant number compared to the country's population
(around 3% of the Hungarian population).
(115) In determining the amount of the fine, the Authority took into account that the breaches of
the principle committed by the Customer constitute a breach falling under the higher
maximum fine category pursuant to Article 83(5) of the GDPR.
Mitigating circumstances (116-117):
(116) The Authority took into account that it had not found any breach of the law relating to the
processing of personal data against the Customer in the period prior to the adoption of the
initial decision.
(117) The Customer also admitted in its statement that it should have deleted the test database
involved in the incident earlier.
Other circumstances taken into account (118-119):
(118) After being notified of a data breach that has occurred, the Customer is entitled to exercise
almost all of the rights under Article 33 of the General Data Protection Regulation
26
immediately took the action required by the Authority, investigated the incident, reported it
to the Authority within 72 hours of becoming aware of it, installed the patch to fix the
vulnerability, deleted the unlawfully managed database, and amended its internal policies in
relation to the vulnerability scans. The Authority has thus not identified any problem in the
Customer's specific data breach management practices. The Authority did not explicitly
assess this conduct as a mitigating circumstance, as it did not go beyond compliance with
the requirements of the General Data Protection Regulation on incident handling (Articles
33-34).
(119) The Authority also took into account the fact that the Client had fully cooperated with the
Authority during the investigation of the case, although it did not consider this conduct as a
specific mitigating circumstance, as it did not go beyond compliance with its legal
obligations.
Economic weight of the client (120-122):
(120) In setting the amount of the fine, the Authority took into account that the publicly available
financial information of the Customer for the financial year ending 1 January 2018 to 31
December 2018 report on the basis of in this at year total
47.299.383.000 HUF (forty-seven billion two hundred and ninety-nine million
three hundred and eighty-three thousand HUF). The Authority has also taken into account
that the Customer has, in the financial year from 1 January 2019 to 31 December 2019,
submitted to the Authority a notification of the Authority No NAIH/2020/1160/6.
statement of facts clarifying order sent to response
according to had a net turnover of 51.890.528. 182HUF (fifty-one
billion eight hundred and ninety-nine million five hundred and twenty-eight thousand one
hundred and eighty-two forints).
(121) Finally, the Authority has audited the Client's latest publicly available accounts for the
financial year ending 1 January 2022 - 31 December 2022, which show a total net turnover
of HUF 61,763,389,000 (sixty billion seven hundred and sixty-three million three hundred
and eighty-nine thousand HUF) for the period.
(122) In setting the fine, the Authority took into account the financial years 2018 and 2019 with
regard to the period of the infringement and checked the latest available sales data to
assess the current financial situation of the Customer. On the basis of the above, the
amount of the fine imposed is proportionate to the gravity of the infringement and should
not impose a disproportionate financial burden on the Customer compared to its historical
and current turnover data.
Consideration of the judgment of the General Court in Case 105.K.704.076/2022/4 (123-
126):
(123) Finally, the Authority took into account that the General Court stated in its judgment that in
the repeated procedure the Authority only has to decide on the legal consequences and
has to consider that the amount of the fine to be imposed in the repeated procedure cannot
reach the HUF 100,000,000 imposed in the original official procedure due to the lack of
violation of the principle of "purpose limitation" compared to the original decision of
NAIH/2020/1160/10.
27
(124) Taking into account all the circumstances of the case, the Authority decided to reduce the
amount of the fine originally imposed by 1/5 of the HUF 100,000,000 and thus to impose a
total fine of HUF 80,000,000. The reason for this is that, although no breach of the principle
of purpose limitation can be established in relation to the data processing in question, the
fact of serious data security deficiencies and the fact of the long-lasting data processing in
breach of the principle can still be established. The absence of a breach of one of the
principles (purpose limitation) does not invalidate the serious data security deficiencies, the
resulting data breach, the breach of the other principle (limited storage) and the risks to the
privacy of the data subjects in relation to the processing of the Client's data. The vast
majority of the breaches identified in the original NAIH Decision No 2020/1160/10 can
therefore still be established in the case (see paragraph 125 below).
(125) For the purposes of determining the proportionality of the fine, the Authority took into
account the following five balancing points, based on the previous and current Decision:
- The breach of data security is due to a known, correctable vulnerability that has existed
for 9 years, so that the measures applied were not in line with the state of science and
technology (Article 32(1) of the GDPR). See first indent of point 1(b) of the operative
part of this Decision (first finding) and in particular paragraphs 60, 75 to 76 and 78 of
the Explanatory Memorandum.
- Due to the lack of security testing and vulnerability assessment of the website, the data
security risks were not properly assessed (Article 32(1) and (2) of the General Data
Protection Regulation). See operative part of this Decision, point 1.
(b), first indent (second finding), and in particular paragraphs 61, 64 to 66, 72 and 76 to
78 of the Explanatory Memorandum.
- The lack of adequate encryption has significantly increased the risks to data security
(Article 32(1)(a) and (2) of the GDPR) See the second indent of point 1(b) of the
operative part of this Decision, and in particular paragraphs 58, 64, 67 to 69, 74, 76 to
77 and 79 to 85 of the Explanatory Memorandum.
- The storage of the database concerned by the incident was in breach of the principle of
limited storage (Article 5(1)(e) of the GDPR) See point 1(a) of the operative part of this
Decision and in particular paragraphs 97 to 103 of the Explanatory Memorandum.
- The retention of the database concerned by the incident did not violate the purpose
limitation principle (Article 5(1)(b) of the GDPR). See paragraphs 88 to 96 of the
reasoning of the present decision.
The Authority has therefore imposed a fine of 4/5 of the previous amount, taking into
account the above weightings and applying a pro rata amount to the original fine in the
present re-opened procedure.
(126) The Authority has also reordered the publication of the decision with the Customer's
identification data (with the trade secrets being withheld) on the basis of Article 61(2)(a) and
(c) of the Infotv., as the infringement remains serious and affects a wide range of persons.
28
considers that the present decision should be made public, as all previous decisions taken
in the course of the procedure (the Authority's previous decision, the CJEU's decision and
the judgment of the Metropolitan Court) are also public documents and the present decision
has been taken in light of them. Moreover, the procedure itself and the legal assessment of
the facts in terms of data protection law, both from an administrative and a judicial point of
view, contain findings of principle which are of importance for future EU practice, in
particular with regard to the findings on the principles.
IV. Other issues
The competence of the Authority is defined in Paragraphs (2) and (2a) of Article 38 of the Infot Act,
and its competence extends to the whole territory of the country.
Pursuant to § 112, § 116 (1) and § 114 (1) of the Civil Code, the decision may be appealed against
by means of an administrative procedure.
The rules for administrative proceedings are set out in the Code of Civil Procedure. The Kp.
Pursuant to Article 12 (2) (a) of the Administrative P r o c e d u r e Act, an administrative action
against a decision of the Authority is subject to the jurisdiction of the courts.
(11) of § 13, the Metropolitan Court shall have exclusive jurisdiction. Pursuant to Section 72 of Act
CXXX of 2016 on the Code of Civil Procedure (hereinafter: CC), applicable pursuant to Section 26
(1) of the CC, legal representation is mandatory in proceedings within the jurisdiction of the
Tribunal. Article 72 of the Code of Civil Procedure. Pursuant to Article 39 (6), unless otherwise
provided by law, the filing of a statement of claim shall not have suspensory effect on the
effectiveness of the administrative act.
Pursuant to Article 29 (1) of the Hungarian Civil Code and in view of this, the Hungarian Civil Code.
Section 604 of the Act CCXXII of 2015 on the General Rules of Electronic Administration and Trust
Services (hereinafter: E-Administration Act), applicable pursuant to Section 9 (1) b) of the Act, the
legal representative of the client is obliged to maintain electronic communication.
The time and place for lodging the application shall be determined by the Kp. Article 39(1).
Information on the possibility of requesting a hearing is given in the notice of the Court of First
Instance of the European Communities, Kp. The amount of the fee for administrative proceedings
shall be determined in accordance with Section 44/A(1) of Act XCIII of 1990 on Fees (hereinafter
referred to as "the Act"). Exemption from the advance payment of the fee is provided for in Section
44.1. Section 59(1) and Section 62(1)(h) of the Act exempts the party initiating the proceedings
from the payment of the fee.
Pursuant to Section 132 of the General Civil Code, if the debtor has not complied with the
obligation contained in the final decision of the authority, the decision is enforceable. The decision
of the Authority becomes final upon notification pursuant to Section 82(1) of the General Civil
Code. Pursuant to Section 133 of the General Civil Code, enforcement is ordered by the authority
that issued the decision, unless otherwise provided by law or government decree. Pursuant to
Section 134 of the General Tax Code, enforcement is ordered by the State Tax Authority, unless
otherwise provided by law, government decree or local government ordinance in a municipal
authority case. The Infotv.
Pursuant to Article 60(7), the Authority shall enforce the decision in respect of an obligation to
perform a specified act, to engage in a specified conduct, to tolerate or to desist from a specified
conduct, contained in a decision of the Authority.
29
Budapest, 22 June 2023.
Dr habil. Attila Péterfalvi
President, c. Professor
</pre>