# VDAI (Lithuania) - 3R-1143

- Type: Enforcement
- Source: VDAI (Lithuania)
- Date: 2026-06-19
- Original: https://gdprhub.eu/index.php?title=VDAI_(Lithuania)_-_3R-1143
- Canonical: https://overview.legal/posts/53896
- Topics: Security, Data Breaches, Access Controls, Healthcare, Notification Obligation, Health Data, Personal Data, Controllers, Healthcare, Fines

## Summary

Facts — Two medical companies (the controllers) had fallen victim to data breaches where a third party had gained access to their internal systems containing both health data and other personal data of patients (the data subjects). The first breach potentially concerned 63 data subjects, whereas the latter breach affected approximately 10,000 employees and 383,000 data subjects. The DPA initiated two separate investigations against the controllers in September 2024 and November 2025 respectively and later combined the cases. Holding — The DPA imposed a fine of €450,000 on the first controller it investigated as this company was also the legal successor of the other controller. It held that the controllers had failed to implement appropriate technical and organisational measures to ensure the security of processing and compliance with the principles of integrity and confidentiality. The controller had violated Articles 5(1)(f), 24(1), and 32(1)(b) GDPR. When assessing the GDPR infringements, the DPA took into account that the controllers processed sensitive categories of personal data. The DPA held the controllers lacked adequate security measures for protecting against unauthorised access to an IT system, such as access control and authentication. For instance, passwords used by employees did not reach a certain level of complexity, and multi-factor authentication was not used.

## Full text

Extract of an electronic document STATE DATA PROTECTION INSPECTORATE DECISION June 19, 2026 No. 3R-1143 (2.13-1 E) Vilnius The State Data Protection Inspectorate (hereinafter referred to as the Inspectorate) in the oral procedure at the meeting held on 2 June 2026 [DATA NOT PUBLISHED] examined the case regarding the imposition of an administrative fine on UAB InMedica (hereinafter referred to as the Company or Clinic), legal entity code 300011170. Circumstances for initiating inspections by the Inspectorate The Inspectorate, taking into account the September 2024. publicly available information1 about a personal data breach (hereinafter referred to as ADSP 1), which indicates that a third party has accessed the internal data management system of UAB “Kardiolita” (hereinafter referred to as Company 1), which displays the personal data of data subjects, and in accordance with Subsection 5.1 of the Rules for Monitoring by the State Data Protection Inspectorate2 and Subsection 1a of Article 57 of the GDPR3, has monitored the application of the GDPR in relation to Company 1. Taking into account the information obtained during the monitoring and in accordance with Subsections 1 and 2 of Article 20 of the ADTAĮ4, Subsections 4.4 and 16.1 of the Rules for Conducting Investigations and (or) Inspections by the State Data Protection Inspectorate5 (hereinafter referred to as the Rules), Order No. of the Director of the State Data Protection Inspectorate of 24-01-2025 1T-16 (1.12.E) “On the inspection of UAB “Kardiolita” at the initiative of the State Data Protection Inspectorate” decided to initiate an inspection on its own initiative regarding a possible violation of the provisions of the GDPR in respect of Company 1 (hereinafter referred to as Inspection 1). The Inspectorate, having received the notification submitted by the Company on a personal data security violation (hereinafter referred to as ADSP 2) (received by the Inspectorate on 2025-11-03, reg. No. 1R-7533 (2.23 Mr)) (hereinafter referred to as Notification 2) on 31 October 2025 and in accordance with Article 20, Parts 1 and 2 of the ADTAĮ, Subparagraphs 4.2, 4.4 and 16.1 of the Rules, Order No. 1T-81 (1.12 E) of the Director of the State Data Protection Inspectorate of 2025-11-03 “On the inspection of UAB InMedica at the initiative of the State Data Protection Inspectorate”, initiated an investigation into a possible violation of the provisions of the GDPR in relation to the Company (hereinafter referred to as Inspection 2). 1. Legal regulation6 1 https://www.youtube.com/watch?v=uqRnL6iNYq8 2 Rules for conducting monitoring by the State Data Protection Inspectorate, approved by the Order of the Director of the State Data Protection Inspectorate of 8 November 2023 No. 1T-91 (1.12.E.) “On the approval of the rules for conducting monitoring by the State Data Protection Inspectorate” 3 27 April 2016 Regulation (EU) 2016/679 of the European Parliament and of the Council 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 (General Data Protection Regulation) (hereinafter referred to as the GDPR) 4 of the Law of the Republic of Lithuania on the Legal Protection of Personal Data (hereinafter referred to as the LPD) 5 of the Rules for conducting investigations and/or inspections carried out by the State Data Protection Inspectorate, approved by Order No. 17 of the Director of the State Data Protection Inspectorate of 17 July 2019 1T-92 (1.12.E) “On the approval of the rules for conducting investigations and (or) inspections carried out by the State Data Protection Inspectorate” 6 Analogous legal regulation applies to both Inspection 1 and Inspection 2 2 In Article 4(1)(15) of the GDPR, health data is defined as personal data relating to the physical or mental health of a natural person, including data on the provision of health care services, revealing information about the health status of that natural person. The processing of personal data is considered lawful if it is based on at least one of the conditions for lawful processing of personal data set out in Article 6(1) of the GDPR and complies with at least one of the exceptions provided for in Article 9(2) of the GDPR (when processing special categories of personal data) and complies with the principles relating to the processing of personal data set out in Article 5 of the GDPR. According to Article 5(2) GDPR, the controller is responsible for compliance with Article 5(1) GDPR and must be able to demonstrate compliance (accountability principle). Article 5(1)(f) GDPR provides that personal data shall be processed in such a way that appropriate technical or organisational measures ensure adequate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage (principle of integrity and confidentiality). The principles of integrity and confidentiality are inextricably linked to the obligations of the controller to implement appropriate technical and organisational measures to ensure the security of the personal data processed, as laid down in Articles 24 and 32 GDPR. In accordance with Article 24(1) of the GDPR, taking into account the nature, scope, context and purposes of the processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller shall implement appropriate technical and organisational measures to ensure and be able to demonstrate that the processing is carried out in accordance with this Regulation. Those measures shall be reviewed and updated where necessary. In accordance with Article 32(1)(b) of the GDPR, taking into account the state of the art of technical possibilities, the costs of implementation and the nature, scope, context and purposes of the processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risks, including the ability to ensure the confidentiality, integrity, availability and resilience of the processing systems and services at all times. In accordance with Article 32(2) of the GDPR, when determining the appropriate level of security, first of all, account shall be taken of the risks arising from the processing of data, in particular accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to data transmitted, stored or otherwise processed. When determining the risks and dangers to personal data and assessing whether the controller implements appropriate technical and organisational security measures, the methodological recommendations set out in the ISO/IEC 27002:2022 standard “Information technology. Security techniques. Code of practice for information security controls” (hereinafter referred to as the ISO standard) shall be taken into account. Notification of a personal data breach to the supervisory authority (hereinafter referred to as the personal data breach notification) is governed by Articles 33 and 34 of the GDPR. It should be noted that according to Article 5(2) of the GDPR, the obligation to ensure appropriate technical and organizational measures and to demonstrate that personal data are processed in accordance with the GDPR applies to the data controller (in the case of Inspection 1 – Company 1, later7 – Company). 2. Results of Inspection 1 2.1. Circumstances and nature of ADSP 1 Company 1's notification of ADSP 1 (Received by the Inspectorate on 2024-09-13, reg. no. 1R-5836 (2.23 E)) and additional information (Received by the Inspectorate on 2024-09-18, reg. no. 1R-5962 (2.29 Mr), Received by the Inspectorate on 2024-09-24, reg. no. 1R-6105 (2.29 Mr), Received by the Inspectorate on 2024-10-01, reg. no. 1R-6304 (2.29 Mr), Received by the Inspectorate on 2024-02-17, reg. no. 1R-1032 (2.29 Mr)) (hereinafter collectively referred to as Notification 1) 7 As of 2025-06-25 3 it is stated that On 08 September 2024, Company 1 received information that a third party, using publicly available login details, had potentially illegally accessed the patient information system used by Company 1. In light of this, Company 1 immediately initiated an investigation into the incident and, upon completion, submitted an investigation report (hereinafter referred to as Report 1) to the Inspectorate. In Report 1, Company 1 indicated that ADSP 1 had potentially occurred when a third party, using the login details of an employee of Company 1, had accessed the information system “Foxus” (hereinafter referred to as Foxus). Company 1 believes that the employee’s login details had been leaked to the database on the dark web after she had previously been the victim of a social engineering attack (hereinafter referred to as phishing attack). The system provider UAB “Softdent” provided log entries, which Company 1 analyzed and determined that during the period from 2024-08-27 to 2024-09-07, the information of 63 patients of Company 1 was accessed using the employee’s login data. Report 1 additionally noted that the employee herself could have accessed some of them while performing her work functions. Company 1 determined that during the unauthorized access, a patient search was performed, the patient’s card was opened and immediately closed. Data theft, exfiltration and downloading from Foxus were not recorded. Company 1 indicated in Report 1 that during ADSP 1, a third party had access to the following personal data of 63 patients: 1) Questionnaire data: Contact data and summary information of Company 1 clients (patients): name, surname, nationality, date of birth, address, telephone number, including personal identification numbers. 2) Special categories of personal data: Health data of Company 1 clients (patients) (Summary of healthcare services provided to Company 1 clients (patients), names of tests performed, prescriptions, vaccinations, etc.). It should be additionally noted that Company 1, in Report 1, describing the sequence of the incident, stated that: “ using the Login Data of the Company’s employee (Doctor), during the period from 2024.08.27 to 2024.09.07, short-term, episodic illegal access to the Information system “Foxus” was carried out several times in order to (i) check whether it is possible to log in to the System with the aforementioned Login Data; (ii) check how much and what data can be accessed after logging in to the System and (iii) take several print screens, screen shots of the data (patient cards) in the System (text not corrected). Company 1 indicated in Report 1 that Foxus synchronizes with external databases or information systems (e.g. ESPBI IS8). Synchronization is performed after registering a patient for a visit to the clinic of Company 1 or in other cases when actions related to the provision of services to the patient are performed, therefore, Foxus stores patient data until their last visit to Company 1. Considering the above, it can be concluded that ADSP 1 may have occurred when a third party, using the logins of an employee of Company 1 found in a leaked database on the dark web, logged into Foxus and viewed the information of data subjects. 2.2. Assessment of the explanations provided by Company 1 and the circumstances established during the investigation regarding the ability to ensure the ongoing confidentiality, integrity, availability and resilience of data processing systems and services (Article 32(1)(b) of the GDPR) After conducting the ADSP 1 investigation in accordance with the Notification 1 submitted by Company 1 and, within the competence of the Inspectorate, assessing the circumstances of the ADSP 1 and the evidence collected, the Information Technology Division of the State Data Protection Inspectorate prepared Report No. 2025-09-17 4R-474 (2.14.E) regarding the personal data security breach of UAB “Kardiolita” (hereinafter referred to as Inspection Report 1). Access control and authentication Access control and authentication are essential security requirements to protect against unauthorized access to the IT system in which personal data is processed. 8 Electronic Health Services and Collaboration Infrastructure Information System (hereinafter referred to as ESPBI IS) 4 According to paragraph 86 of the Guidelines9, “There must be a functioning authentication mechanism that allows access to the IT system (based on the Access Control Policy). The minimum requirement for a user to log in to the IT system is a user login and password. The password is created taking into account a certain level of complexity”. Subclause 5.17 of the ISO standard “Authentication information” states that “The assignment and management of authentication information should be controlled in accordance with a management process, including advising personnel on the appropriate handling of authentication information”. The data controller must ensure, by means of technical and organisational measures, that the login passwords used by system users meet the required level of security and a certain level of complexity. Given that Company 1 employees access personal data of patients, including health data, when connecting to Foxus, stricter requirements must be applied to login passwords. It is additionally noted that, according to the Inspectorate’s recommendation on the importance of using secure and strong passwords10, a password that meets a certain level of complexity must consist of at least 12 characters, use uppercase and lowercase letters, numbers and special characters. According to paragraph 91 of the Guidelines, “ When such systems are accessed from outside the internal computer network, additional security measures, such as IP address control , shall be used”, and sub-clause 8.3 of the ISO standard “Restriction of access to information” shall prevent unauthorized access, taking into account the granting of access permissions by identity, device, location or application. Also, sub-clause 8.5 of the ISO standard “Secure authentication” shall specify that an appropriate authentication method should be chosen. In view of this, the data controller, in order to ensure the security of personal data, must select appropriate authentication methods (e.g. multi-factor authentication (MFA)) and/or permission to connect to systems only from known IP addresses, from certain LAN networks, from a certain territory or other. The Inspection Report 1 indicates that during the investigation of Company 1, it was assessed whether Company 1 had taken appropriate technical and organizational measures before the ADSP 1 occurred to prevent such ADSPs, and it was determined that: 1. Employees connected to Foxus with passwords that were at least 8 characters long, consisting of letters and numbers11, without using personal information; 2. Foxus was accessible via an external network (Internet); 3. Two-factor authentication (2FA) was not applied to external connections; 4. Access to Foxus was not restricted to authorized persons only, i.e., no IP address filtering was performed, therefore, Company 1 employees could connect to Foxus from unknown IP addresses located outside Lithuania. Considering that ADSP 1 could have occurred because a third party knew the employee's login name and password in advance, it should be noted that if MFA had been applied to employees who connected to Foxus via an external network (the Internet) or access had been restricted to authorized persons only (for example, based on pre-specified IP addresses or only from certain LAN networks), the third party would not have illegally connected to Foxus and ADSP 1 would not have occurred. Since when connecting to Foxus with multi-factor authentication, when the first step is completed, the login name and password are entered, authentication is initiated by sending a login code to a pre-defined email or phone, therefore the second step of the authentication would not be carried out even if the third party knew the login name and password in advance. Analogously to the restriction of access to Foxus 9 Guidelines of the State Data Inspectorate of 13 August 2024 on security measures and risk assessment guidelines for data controllers and data processors (hereinafter referred to as the Guidelines) 10 https://vdai.lrv.lt/public/canonical/1734937137/678/Rekomendacia_del_slaptazodziu_2024.pdf 11 Without using special characters 5 by IP addresses or from the internal network of Company 1, i.e. even if the login name and password were known it would not be possible to log in, since Foxus itself would not be accessible, the third party would additionally have to access the internal network of Company 1 or obtain access by IP address. Taking into account the established circumstances, it can be concluded that during ADSP 1, the Foxus did not ensure an appropriate level of personal data security. Summarizing the information provided in this part of the letter and taking into account the legal regulation established by the GDPR and the explanations (recommendations) provided in the Guidelines and the ISO standard already provided in the letter, and the circumstances of ADSP 1, it should be concluded that ADSP 1 occurred due to insufficient access control and improper authentication when connecting to Foxus in Company 1, when multi-factor authentication was not applied to Company 1 employees when connecting via an external network (the Internet) and access was not restricted to authorized persons only, as well as the passwords for employees' logins to Foxus did not meet a certain level of complexity. The Inspectorate decides that Company 1, by not ensuring the requirements established in sub-clauses 5.17, 8.3 and 8.5 of the ISO standard, violated the requirements of Article 24(1) of the GDPR, Article 32(1)(b) of the GDPR and the confidentiality principle established in Article 5, paragraph 1, point f. 3. Results of Inspection 2 3.1. Circumstances and nature of ADSP 2 In Notification 2, it was stated that on 29-10-2025 between 12-13:00. After the Company's employees started to record information system failures, the IT Department determined that an incident had occurred, during which data processed in 4 systems used by the Company (hereinafter collectively – Systems) were encrypted: • an inpatient patient management system used to process patient health data in two of the Company's clinics (hereinafter – Med.I.S); • a radiology imaging system used for storing and reviewing radiological examinations (hereinafter – PACS); • a personnel management system in which employee data is stored (hereinafter – Edrana); • a shared file server in which administrative documents and other work files are stored (hereinafter – File Share). The Company indicated in Notification 2 that all of these Systems were operating on separate virtual Windows Servers, in the same virtualization environment. The Company indicated in Notification 2 that during the ADSP, four of the Company's Systems were affected, which process personal data of patients and employees (employees - about 10 thousand, patients - 383 thousand). It also indicated that the following were affected: 1) employees - names, surnames, positions, departments, e-mail addresses, contact phone numbers, user IDs, personal codes, employees' administrative data (employment contract information, salary, vacation requests, work schedules, other documents related to employment relations and personal data contained therein); 2) patients - names, surnames, dates of birth, age, personal codes, phone numbers, e-mail email addresses, health data (medical records, diagnoses, treatment history, data on tests and procedures performed, laboratory test results, radiological images (MRI, CT, X-ray, etc.), reports related to tests), identifiers in the medical records system (ID numbers, medical card numbers). Notice 2 states that the Company immediately began incident management actions, i.e. suspended the operation of the affected servers and began restoring data from backup copies. On the same day around 5-6 p.m. The operation of the systems was fully restored after restoring data from backup copies. While investigating the management actions of ADSP 2, the Inspectorate asked the Company additional questions, to which the Company provided answers (Inspection reg. date 2025-11-11, reg. No. 1R-7829 (2.14 K); 6 2025-11-21, reg. No. 1R-8073 (2.23 Mr); 2025-11-11, reg. No. 1R-7829 (2.14 K) and 2026-01-06, reg. No. 1R-62 (2.14 E). The Company conducted a cyber incident investigation, the report of which was submitted to the Inspectorate on 2025-12-04 (Inspection reg. date 2025-12-05, reg. No. 1R-8529 (2.14 K) (hereinafter referred to as Report 2). The report 2 indicated that on 2025-10-29 12:24:32 a.m. the server [DATA UNCLASSIFIED] (hereinafter referred to as the Server) was successfully connected from a malicious IP address with the user [DATA UNCLASSIFIED]. A domain account with administrator rights was used to connect, which provided an opportunity to further access other internal systems and initiate data encryption actions. The Company experienced a ransomware attack when a third party, connecting via the Remote Desktop Protocol (hereinafter referred to as the RDP) service and using lateral movement12, encrypted data on four Systems. The Company stated that the unauthorized access continued until 2025-10-29 at 13:34:58, when the Company's IT department team terminated the active session, blocked RDP access and isolated the affected Servers, immediately stopping further actions by the third party. The total unauthorized access by the third party lasted 70 minutes and 30 seconds. The Company also stated that all affected Systems were fully restored and normal service provision was fully resumed on 2025-10-29 at approximately 17:00. The Company noted that during the incident, service provision was not interrupted, as doctors could use the medical records and personal data in the ESPBI IS that had been transferred from local systems earlier. Medical document records stored in physical (paper) patient cards were also used. Taking into account the above, it can be concluded that the Company suffered a ransomware attack when a third party, connecting via the RDP service and using lateral movement, encrypted the data of four Systems. 3.2. Assessment of the explanations provided by the Company and the circumstances established during the investigation regarding the ability to ensure the ongoing confidentiality, integrity, availability and resilience of data processing systems and services (Article 32(1)(b) of the GDPR) Having conducted the ADSP 2 investigation in accordance with the Notification 2 submitted by the Company and, within the competence of the Inspectorate, having assessed the circumstances of the ADSP 2 incident and the evidence collected, the State Data Protection Inspectorate Information Technology Division prepared Report No. 4R-145 (2.14.E) of 2026-03-10 regarding the personal data security breach of UAB INMEDICA (hereinafter referred to as the Inspection Report 2). The Company indicated in Report 2 that ADSP 2 occurred after a third party obtained RDP access to the Server. The third party connected to the Server with a [DATA NOT PUBLISHED] domain account (i.e., with privileged access rights), and therefore accessed all 4 affected Systems. The requirements set out in the Description of Cybersecurity Requirements (hereinafter referred to as the Description) approved by the Resolution of the Government of the Republic of Lithuania of 13 August 2018 No. 81813 “On the Implementation of the Law on Cybersecurity of the Republic of Lithuania” (hereinafter referred to as the Description) apply to cybersecurity entities that are included in the list of cybersecurity entities. The technical and organizational measures set out in the Description are assessed in this Decision as generally recognized good practice in the field of cybersecurity. Taking into account the obligation of data controllers under the GDPR to implement appropriate technical and organizational measures in order to ensure a higher level of personal data protection and more effective management of cyber threats, it should be considered that the measures set out in the Description must be known and applied, regardless of whether data controllers are included in the list of cybersecurity entities or not. 12 Lateral movement is a stage when a third party, having already entered one system, begins to move within the network, looking for where else they can connect. 13 https://e-seimas.lrs.lt/portal/legalAct/lt/TAD/94365031a53411e8aa33fe8f0fea665f/asr 7 During the investigation of the Company, it was assessed whether the Company had taken appropriate technical and organizational measures before the ADSP 2 occurred to prevent such ADSPs from occurring. The Inspectorate found that: 1. A third party logged in to an account with privileged access rights. 2. The affected Server was accessible via an external network (Internet). 3. MFA was not applied to users with privileged access rights when connecting via an external network. 4. IP address filtering was not applied to connecting to the Server via RDP. In Section XII of the Description “Access Control and Multi-Factor Authentication”, Table 7, Item 61, states that: “The user and administrator must authenticate themselves with a password and an additional authentication method (multi-factor authentication).”, Sub-clause 8.5 of the ISO standard “Secure Authentication” states that a suitable authentication method should be selected. Point 91 of the Guidelines states that multi-factor authentication must be applied to privileged users (e.g. system administrators) to access personal data management systems. It should be noted that according to point 91 of the Guidelines, “ When such systems are accessed from outside the internal computer network, additional security measures, such as IP address control , shall be used” and sub-clause 8.3 of the ISO standard “Restriction of access to information”, which states that unauthorized access must be prevented, taking into account the granting of access permissions by identity, device, location or application. In this regard, the data controller, in order to ensure the security of personal data, must choose appropriate authentication methods (MFA and/or permission to connect to systems only from known IP addresses, from certain LAN networks, from a certain territory or other). Considering that the Company indicated that ADSP 2 could have occurred due to the fact that a third party knew in advance the login name and password of a user with privileged access rights, it should be noted that if MFA were applied when connecting to the Server via an external network (the Internet) or access was restricted to authorized persons only (for example, according to pre-specified IP addresses or only from certain LAN networks), the third party would not have illegally connected to the Server and ADSP 2 would not have occurred. It should be noted that when connecting to the Server with multi-factor authentication, after completing the first step (entering the login name and password), the second step (authentication) is initiated by sending a login code to a pre-defined e-mail or phone and the user enters it. Accordingly, in the case under consideration, the second step would not have been performed even if the third party knew the login name and password in advance. Similarly to the restriction of access to the Server by IP addresses or from the Company's internal network, i.e. even knowing the login name and password, it would not be possible to connect, since the Server would not be accessible, since a third party would have to additionally access the Company's internal network or obtain access by IP address. Taking into account the arguments presented, it should be concluded that during ADSP 2, the Company's affected Systems did not ensure an appropriate level of personal data security. In addition, assessing the Company's arguments that there was no loss of personal data confidentiality during the incident and having established that the Company did not apply two-level authentication before ADSP 2, it should be additionally noted that the Company did not apply other technical measures that would ensure that personal data would not be understandable to a person who does not have permission to access it, for example, by applying advanced encryption or using access keys. However, in this case, such measures were not applied before ADSP 2 occurred, therefore, when assessing the circumstances of ADSP 2, it must be taken into account that although the data was not directly exfiltrated, a third unauthorized person gained access to personal data, including special category (health) personal data, therefore, it is assessed that the confidentiality of personal data was lost during the incident. 8 In addition, taking into account the fact that four of the Company's Systems were encrypted and employees were unable to access the data in the affected Systems for a certain period of time until the data was fully restored from backup copies, it must be concluded that the continuous availability of data processing systems and services was also compromised. Taking into account the above, it must be concluded that four of the Company's Systems, which process personal data of patients and employees (employees - approximately 10 thousand, patients - 383 thousand), were affected during ADSP 2. ADSP 2 occurred due to the Company's insufficient access control and authentication when connecting to the affected Server, when privileged users connect via an external network (Internet) and access restriction was not implemented only for authorized persons. Therefore, by not ensuring the requirements set out in sub-clauses 5.17, 8.3 and 8.5 of the ISO standard, the Company violated Article 24(1) of the GDPR, the requirements of Article 32(1)(b) of the GDPR and the confidentiality principle established in Article 5(1)(f) of the GDPR. 4. Written explanations provided by the Company after the proposal to impose a fine The Company submitted its explanations to the Inspectorate on 2026-05-08 (Inspection reg. No. 1R-3709 (2.13 Mr)). 4.1. Regarding ADSP 1, the Company additionally notes that from the moment of setting ADSP 1 (September 2024) to 2026-05-08, i.e. for more than 1 (one) year and 8 (eight) months, the Company has not received a single complaint, claim or notification from a data subject about any real negative impact related to ADSP 1. It is also indicated that in accordance with the requirements of Articles 24 and 32 of the GDPR, the Company consistently carries out a risk assessment of its information systems, databases and data processing operations. The Company systematically assesses the security, resilience and protection of IT systems and other IT resources (including personal data), selects adequate and proportionate security measures and solutions, and implements and maintains them accordingly. It is explained that the assessment of IT systems security and related risks is a continuous, dynamic and complex process, including the analysis of constantly changing and newly emerging technologies, processes and the threats they pose. It is noted that when performing the risk assessment, the Company follows the Inspectorate's recommendations, good sector practice, as well as ENISA guidelines developed based on international standards (LST ISO/IEC 27001:2017, ISO/IEC 27002:2017, ISO/IEC 27701:2019, etc.). The Company acknowledges that during ADSP 1, Foxus did not have MFA authentication implemented for external access, while noting that this fact should be assessed in the context of all circumstances identified during the investigation: 1) According to the Company, the application of MFA for access to third-party information systems in healthcare institutions in 2024 was not a universal practice – on the contrary, the Inspection carried out in 2025 scheduled monitoring of security measures of healthcare institutions14 confirms that in 2025 only 11% of healthcare institutions applied this measure. In the Company's opinion, this shows that the absence of MFA is not an exceptional sign of negligence on the part of the Company, but a systemic issue of maturity of the entire healthcare sector. 2) It is noted that the Company corrected this deficiency promptly, on its own initiative - actively coordinating the process with Foxus' supplier UAB "Softdent", providing it with specific instructions and legal and technical assistance, ensuring the implementation of MFA within a few days of the establishment of ADSP 1. Considering that, according to the Inspectorate's monitoring data, only 1 out of 10 monitored healthcare institutions apply MFA, the Company assumes that that one institution is the Company, on whose initiative the MFA was implemented back in September 2024 - well before the aforementioned monitoring was carried out. 14 https://vdai.lrv.lt/lt/naujienos/vdai-atlikusi-sveikatos-prieziuros-istaigu-stebesena-teika-rekomendations-9Qv/ 9 3) It is explained that the process of implementing MFA in Foxus objectively took a long time, because it required significant technical preparation from the Foxus supplier UAB “Softdent” – MFA functionality had not been implemented in this system before, so the supplier had to design, create and integrate a completely new authentication module. At the same time, it is noted that the Company was the first of all UAB “Softdent” clients to request the implementation of MFA in Foxus, although UAB “Softdent” provides information system services to many healthcare institutions in Lithuania. According to the Company, this means that it not only responded promptly to the identified vulnerability, but also actually initiated and encouraged the creation of a new security standard for the entire Foxus user community - acting proactively and exceeding the prevailing practice in the sector at that time (and, likely, even currently). It is noted that UAB "Softdent" is inclined to offer this MFA solution to other Foxus users after the events discussed, but to the Company's knowledge, no other data controller has implemented this solution to date. Accordingly, the Company believes that it remains the only one (both among the healthcare institutions monitored by the Inspectorate and among all Foxus users) to have actually implemented this measure on its own initiative. 4) It is noted that the decision to implement MFA was not technically trivial and did not depend solely on the will of the Company - Foxus is a product developed and administered by a third party (UAB "Softdent"), therefore, the creation and integration of MFA functionality was exclusively a matter of the competence and technical capabilities of the Foxus supplier. Its implementation required active coordination with the system supplier, technical modifications on the supplier's side and organizational changes in the Company's work processes. Despite this dependence on a third party, the Company indicates that it initiated this step decisively and promptly. The Company also indicates that after ADSP 1, password requirements were tightened - among other things, the password must be at least 12 characters long (prior to ADSP 1, functionality was implemented in Foxus that required combinations of at least 6 characters). 4.2. Regarding ADSP 2, the Company emphasized that the theoretical threshold of affected data subjects (numbers) reflects only the total number of data subjects processed in the affected systems and in no way reflects the actual extent of the impact. When assessing the nature, scope and impact of ADSP 2 on data subjects, the Company concluded that the potential negative consequences for data subjects remain exclusively hypothetical: the breach was contained quickly, no breach of confidentiality and integrity was identified, there are no indications that personal data had been viewed, copied or exfiltrated, services were provided to patients without interruption using alternative sources, and data availability was restored on the same day. The Company also did not receive any complaints or other signals from patients that would indicate a real impact on their rights or freedoms. It is also the case that the Company's readiness to respond to ADSP and the technical and organizational measures in place allowed ADSP 2 to be managed promptly and effectively and to limit its consequences, therefore the actual impact on data subjects is minimal, and the risk of possible negative consequences is low. Nevertheless, the Company acknowledged that during ADSP 2, MFA was not applied to privileged users' logins via RDP, but noted that after ADSP 1, the Company implemented MFA Foxus for external access - this was a targeted, operational reaction to ADSP 1. The Company noted that the decision to implement MFA was a planned organizational action that the Company did not have time to implement before ADSP 1, but the circumstances of ADSP 1 led to its immediate implementation. Meanwhile, the RDP infrastructure is a technically separate system to which the MFA solution was not directly applied. The company emphasized that after ADSP 1, this gap was eliminated radically and comprehensively: MFA was activated in the entire organizational environment, covering all users; in parallel, a strategic transition to a single sign-on (SSO)15 architecture was carried out. 15 Single Sign-On 10 The company also acknowledged that during ADSP 2, an unauthorized actor had the technical ability to access personal data stored in the Systems, but the significance of this fact must be assessed taking into account the actual duration of access and physical access to the data. The total unauthorized access lasted 70 minutes and 30 seconds, but this period includes all actions: initial login, lateral movement in the network, loading of encryption tools and their execution. Given that the majority of this time was spent performing the encryption process, rather than viewing the data, the actual period during which an unauthorized actor could actively access personal data is extremely limited. The Company concluded that it is physically and technically possible to access only a very limited number of data subjects in such a short period of time. Even with access to the System, a person can only view a fragmented and random portion of the data within a few minutes, which means that the actual extent of the impact is incomparably lower than the maximum theoretical limit reflected by the total number of data subjects stored in the Systems. The Company also assessed the loss of availability as insignificant, as the provision of services to patients was not interrupted and no complaints were received from patients or other data subjects. In response to the conclusions drawn by the Inspection in Inspection Report 2, the Company noted that The Inspection cannot establish a violation of Article 32 of the GDPR solely on the basis of the failure to comply with individual sub-clauses of the ISO/IEC 27002:2017 standard, as compliance with or non-compliance with the ISO standard does not in itself constitute a violation of the GDPR. Article 32 of the GDPR requires appropriate measures taking into account the risk – that is, a flexible, contextual assessment, not a mechanical application of ISO clauses. 5. Explanations received during the oral hearing During the oral hearing, the Company provided the chronology of ADSP 1, drew attention to the context in which it occurred, the broader circumstances of ADSP 1, emphasizing that: 1) The Company believes (qualitative logs have not survived) that about 80 percent. of the cards were opened by the doctor herself (because the incident occurred during work), i.e. indicates that 63 is the maximum number of entities; 2) The Company reacted extremely quickly - MFA was implemented within a few days (2 days) from learning about ADSP 1, which, according to the Company, indicates that this (implementation) had already been discussed with the Foxus supplier for some time, but it was not implemented in time; 3) It is noted that the incident occurred exclusively in the data processor's infrastructure, but to the Company's knowledge, UAB "Softdent" was not involved, interviewed, and an investigation was not initiated against it (although the data processor is also subject to obligations under Article 32 of the GDPR); 4) The Company notes that the product is practically unique and difficult to replace on the market, therefore the Company seeks to ensure that it is safe for the entire healthcare sector. The Company repeated the information already submitted before the oral hearing regarding both ADSP 1 and ADSP 2, emphasizing that there is no evidence that the affected data would be disclosed to other unidentified persons; also emphasizing its activity in implementing new additional security measures after ADSP. 6. Assessment of the additional16 explanations provided by the Company It is worth noting that after the proposal to impose a fine, the Company provided additional information, which it had not provided before the preparation of the aforementioned Inspection Reports. The additional information was assessed in the Inspection Conclusion of the Information Technology Division of the Inspectorate on 08 June 2026 on the information provided (Inspection Reg. No. 4R-353 (2.14 E)) (hereinafter referred to as the Conclusion). 6.1. Regarding the Company's password policy prior to ADSP 1 16 After the proposal to impose a fine and an oral hearing 11 The Inspectorate stated in its Inspection Report 1 that employees used passwords to log in to Foxus with passwords that were at least 8 characters long, consisting of letters and numbers, without using personal information. The Company further stated that prior to ADSP 1, a documented password policy was in place, requiring user passwords to be at least 6 characters long, contain at least one number, one uppercase and one lowercase letter, and one special character, and in fact, a rule was applied regarding passwords that were at least 8 characters long and contained at least one letter and one number. The conclusion notes that, in accordance with paragraph 86 of the Guidelines, “There shall be a functioning authentication mechanism to allow access to the IT system (based on the Access Control Policy). The minimum requirement for a user to log in to the IT system is a user login name and password. The password shall be created taking into account a certain level of complexity” and sub-clause 5.17 of the ISO standard “Authentication information”, which states that “The assignment and management of authentication information should be controlled in accordance with a management process, including advising personnel on the appropriate handling of authentication information”. The data controller must ensure by technical and organizational means that the login passwords used by system users meet the required level of security and a certain level of complexity. Additionally, attention is drawn to the fact that, according to the Inspectorate's recommendation on the importance of using secure and strong passwords17, a password that meets a certain level of complexity must consist of at least 12 characters, use uppercase and lowercase letters, numbers and special characters. Considering that the Company once again confirmed and did not deny that passwords of insufficient complexity were used before ADSP 1, the Inspectorate concludes that before ADSP 1, the passwords of employees' logins to Foxus did not meet the appropriate level of complexity. 6.2. Regarding the unauthorized login of a third party to an unused administrator account in ADSP 2, the Inspectorate indicated in Inspection Report 2, based on the information provided by the Company, that a domain account with administrator rights was used for login, which provided the opportunity to further access other internal systems and initiate data encryption actions. The Company stated in the Letter that “The investigation analysis confirmed that an unauthorized actor used the RDP service available on the server [DATA NOT PUBLISHED] and logged in using the domain user account [DATA NOT PUBLISHED]. This account was created on 22 June 2023, but the Clinic’s IT team did not use it and did not assign it any legitimate operational functions. In other words, the attack vector was the exploitation of an inactive administrative account – a circumstance due to which the existence of such an account could have largely gone unnoticed by applying routine access monitoring measures.” (text uncorrected). It should be noted that in Section XII of the Description “Access Management and Multi-Factor Authentication Measures”, Table 7, Item 65, states that: “Unnecessary or unused network and information system accounts must be blocked immediately, but not later than within the deadline set by the cybersecurity entity and deleted after the end of the log record retention period (not less than 90 calendar days)”, and also in Item 73 of Table 7, it is specified that administrator accounts must be monitored: for important cybersecurity entities, Sub-item 73.1 must be applied “regularly, at least once a year, it is checked whether administrator accounts comply with the requirements set out in this Section, and the authorized responsible person is notified of administrator accounts that do not comply with the requirements set out in this Section.”, and for essential ones – Sub-item 73.2 “administrator account monitoring measures are used that periodically check administrator accounts. Administrator accounts that do not comply with the requirements set out in this section shall be reported to an authorised person. Sub-clause 5.18 of the ISO standard “Access rights” states that it shall be ensured that access rights are revoked when they are no longer required, and sub-clause 8.2 of the ISO standard “Privileged access rights” states that users working with privileged access rights shall be reviewed regularly or after certain changes. Paragraph 18 of the Guidelines states that “Access rights shall be revoked when access to personal data is no longer required (activity, duties have changed)”. Also, point 20 of the Guidelines states that “Access rights (especially privileged access rights) must be reviewed at least once a year.” In this regard, the data controller must ensure that unused accounts are immediately blocked, and all, including privileged access rights, are regularly reviewed at least once a year. The Inspectorate notes that the account to which a third party illegally accessed ADSP 2 was created on 2023-06-22, and the incident occurred on 2025-10-29, i.e. more than 2 years after the creation of the account with privileged rights, therefore it can be concluded that ADSP 2 would not have occurred if the Company had applied MFA or had implemented access restrictions only for authorized persons (for example, based on pre-specified IP addresses or only from certain LAN networks) prior to ADSP 2. Also, if the Company had properly ensured access control and immediately blocked the unused Admin account and carried out regular access rights reviews, the Company would have been able to determine that there was an unused account with privileged access rights and immediately block it, and a third party would not have been able to illegally log in to the unused administrator account and hack into the Systems affected by the Company's ADSP 2. Summarizing the information provided in subparagraphs 6.1 and 6.2 of this section, the Conclusion establishes that: • The explanations provided by the Company additionally did not refute the violations of the requirement set out in Article 32(1)(b) of the GDPR in relation to ADSP 1 and ADSP 2 established in Inspection Report 1 and Inspection Report 2 and the failure to use technical and organizational measures ensuring a level of security appropriate to the risk. • The Company, prior to ADSP 2, did not additionally ensure the blocking of unused accounts and regular, at least once a year, reviews of access rights, thereby violating Article 32(1)(b) of the GDPR, the requirements of Table 7, items 65 and 73 of the Description, and the requirements set out in sub-items 5.18 and 8.2 of the ISO standard. • The use of at least one of the measures18 listed in Inspection Report 1 would have prevented the hacking of the Company's system affected during ADSP 1. • The use of at least one of the measures19 listed in this Conclusion and Inspection Report 2 would have prevented the unauthorized login of a third party to an unused account and the hacking of the Company's Systems affected during ADSP 2. 6.3. Summary of the assessment The Inspectorate notes that the Company's arguments regarding generally applicable practices do not negate the responsibility of the Company as an independent data controller. The inaction of other market participants or the low maturity of the sector does not exempt a specific data controller from the obligation to ensure the security of the data it processes, in particular when processing health data, which is subject to the highest protection standard. According to Article 24(1) of the GDPR, the obligation to implement appropriate technical and organizational measures is provided for specifically for the data controller, respectively, the data controller must 18 If MFA is used or access is restricted to authorized persons only (for example, according to pre-specified IP addresses or only from certain LAN networks). 19 If MFA is used or access is restricted to authorized persons only (for example, according to pre-specified IP addresses or only from certain LAN networks) or access control is ensured by immediately blocking unused accounts and conducting regular reviews of access rights. 13 to control that the measures are not only foreseen, but also actually applied (implemented). At the same time, it should be noted that according to Article 28 of the GDPR, the data controller shall use only those data processors who sufficiently ensure that appropriate technical and organizational measures will be implemented in such a way that the data processing complies with the requirements of this Regulation and the protection of the rights of the data subject is ensured. In the case under consideration, according to the Company's explanations, it can be seen that the Company was aware that MFA Foxus was not applied, but decisive action was taken only after ADSP 1, i.e. the implementation of MFA within 2 days (and only for the Company) indicates that there were no technical obstacles or they were not significant, and MFA could have been implemented separately only for the Company (despite the passivity/disapproval of other market participants using Foxus), but the real impetus to take measures arose only after the incident. It should also be noted that the Company's finding of violations is not related to the specific non-application of MFA, but to the failure to apply appropriate security measures (taking into account other possible alternative measures). It should be noted that even without applying MFA, the Company could have applied other security measures, such as installing restrictions on access to Foxus by IP addresses or from the Company's internal network, but did not apply them, and the passwords did not meet the appropriate level of complexity. The totality of these circumstances shows that the data controller (the Company), taking into account the sensitivity of the personal data processed by Foxus, did not ensure the appropriate security of this data (this is confirmed by the ADSP 1). The Company indicated that the Inspectorate cannot find a violation of Article 32 of the GDPR solely on the basis of the failure to comply with individual subparagraphs of the ISO/IEC 27002:2017 standard, since compliance with or non-compliance with the ISO standard does not in itself mean a violation of the GDPR. Article 32 of the GDPR requires appropriate measures taking into account the risks – this is a flexible, contextual assessment, and not a mechanical application of ISO points. It should be noted that the GDPR is a European Union regulation establishing rules relating to the protection of natural persons with regard to the processing of their personal data. Although the GDPR does not provide for specific technical and organisational measures that must be implemented by the data controller and/or processor, this does not mean that the Information Technology Division of the Inspectorate, when preparing the Conclusion, as well as the Inspectorate, when proposing to impose a fine, cannot rely on generally recognised security standards and good practice guidelines developed on their basis. Otherwise, i.e. if it were recognised that in the absence of technical and organisational measures specifically mentioned in Article 32 of the GDPR, data controllers and data processors have full discretion not to implement them, the effectiveness of this provision itself would be denied. Such an interpretation would mean that data controllers and processors could not in fact be held liable for the application of insufficient or inappropriate security measures, although Article 32 of the GDPR clearly establishes the obligation to ensure an appropriate level of data security, taking into account the risks associated with data processing. This means that the adequacy of the technical and organizational measures applied is assessed in each case taking into account the circumstances of the specific case. During the inspections, the Company did not deny that: (1) ADSP 1 occurred due to insufficient access control and inappropriate authentication when connecting to Foxus in Company 1, when multi-factor authentication was not applied to Company 1 employees when connecting via an external network (the Internet) and access was not restricted to authorized persons only, and the passwords for employees' connections to Foxus did not meet the appropriate level of complexity. (2) ADSP 2 occurred due to insufficient access control and inadequate authentication in the Company when connecting to the affected Server, where multi-factor authentication is not applied to privileged users when connecting via the external network (internet) and access restriction to authorised persons was not implemented. 7. Reasons for the decision to impose/not impose an administrative fine 14 In accordance with Article 83(1) of the GDPR, each supervisory authority shall ensure that the administrative fines imposed in accordance with this Article for infringements referred to in paragraphs 4, 5 and 6 of this Regulation are effective, proportionate and dissuasive in each specific case. In accordance with Article 83(2) of the GDPR, administrative fines shall be imposed in addition to or instead of the measures referred to in points (a) to (h) and (j) of Article 58(2) of the GDPR, taking into account the circumstances of each specific case. When deciding whether to impose an administrative fine and when determining the amount of the administrative fine, due account shall be taken of the following in each individual case: a) the nature, gravity and duration of the infringement, taking into account the nature, scope or purpose of the processing concerned, as well as the number of data subjects affected and the extent of the damage suffered by them; b) whether the infringement was committed intentionally or negligently; c) any steps taken by the controller or processor to mitigate the damage suffered by data subjects; d) the extent of the liability of the controller or processor, taking into account the technical and organisational measures implemented by them in accordance with Articles 25 and 32; e) any significant previous infringements by that controller or processor; f) the degree of cooperation with the supervisory authority to remedy the infringement and mitigate its potential adverse effects; g) the categories of personal data affected by the infringement; (h) the manner in which the supervisory authority became aware of the breach, in particular whether the controller or processor notified the breach (and if so, to what extent); (i) where the controller or processor concerned has previously been subject to measures referred to in Article 58(2) in respect of the same matter, whether those measures have been complied with; (j) whether approved codes of conduct pursuant to Article 40 or approved certification mechanisms pursuant to Article 42 are complied with; (k) other aggravating or mitigating factors relating to the circumstances of the case, such as the financial benefit gained or the loss avoided, directly or indirectly as a result of the breach. Recital 129 of the GDPR states that, in order to ensure consistent monitoring of the application of this Regulation and its enforcement throughout the European Union, supervisory authorities in each Member State should carry out the same tasks and exercise the same effective powers, including investigatory powers, powers to take corrective action and to impose sanctions, as well as authorisation and advisory powers, in particular in cases where complaints are received from natural persons, and, without prejudice to the powers of criminal prosecution authorities under Member State law, to bring infringements of this Regulation to the attention of judicial authorities and/or to be a party to legal proceedings. The powers of supervisory authorities should be exercised in accordance with appropriate procedural safeguards laid down in Union and Member State law, impartially, fairly and within a reasonable time. In particular, any measure should be appropriate, necessary and proportionate to ensure compliance with this Regulation, taking into account the circumstances of each individual case, respect the right of each individual to be heard before any specific measure is taken which would adversely affect them, and be applied in a way that does not entail unnecessary costs and disproportionate inconvenience for the individuals concerned. Recital 148 of the GDPR states that, in order to ensure better enforcement of the rules of this Regulation, infringements of this Regulation should be subject to sanctions, including administrative fines, in addition to or instead of the appropriate measures adopted by the supervisory authority pursuant to this Regulation. In the case of a minor infringement or where the fine that may be imposed would constitute a disproportionate burden on the natural person, a reprimand may be imposed instead of a fine. However, due account should be taken of the nature, gravity and duration of the infringement, whether the infringement was intentional, the steps taken to mitigate the damage suffered, the extent of the liability15 or any significant previous infringements, how the infringement came to the attention of the supervisory authority, whether the measures taken against the controller or processor concerned were complied with, whether the code of conduct was complied with and any other aggravating or mitigating factors. Sanctions, including administrative fines, should be imposed taking into account appropriate procedural safeguards and in compliance with the general principles of Union law and the Charter, including effective judicial protection and due process. The European Data Protection Board (hereinafter referred to as the EDPB) has adopted Guidelines 04/2022 on the calculation of administrative fines under the GDPR (hereinafter referred to as the Guidelines on Fines) on 24 May 2023, which set out the methodology for calculating fines and note that the following three elements must be taken into account when imposing fines: the classification of the infringements by nature, the gravity of the infringement and the turnover of the undertaking, and also indicate that data protection authorities must also take into account aggravating or mitigating factors, which may increase or decrease the fine and which are explained in a consistent manner by the EDPB. When assessing the information collected during the procedure for imposing an administrative fine and provided in this decision, when deciding whether or not to impose an administrative fine on the Company and when deciding on the amount of the administrative fine, the Inspectorate shall take into account the relevant aspects set out in Article 83(2). 7.1. Article 83(2)(a) of the GDPR – nature, gravity and duration of the breach, taking into account the nature, scope or purpose of the data processing concerned, as well as the number of data subjects affected and the extent of the damage suffered by them 7.1.1. Company’s explanations In providing explanations, the Company further divided the matter set out in Article 83(2)(a) of the GDPR into two parts and presented its assessment for each incident separately: 7.1.1.1. Nature, gravity and duration of the breach, taking into account the nature, scope or purpose of the data processing concerned: (a) ADSP 1 – the unauthorised access lasted from 2024-08-27 to 2024-09-07 (12 days), however, the actual extent of the unauthorised access is significantly lower than the theoretical one – the access took place during working hours, when the employee was using the system legitimately at the same time; no data exfiltration identified; limited patient visit data accessed; (b) ADSP 2 - unauthorized access lasted 70 minutes and 30 seconds; systems restored in approximately 5 hours; no data exfiltration identified; service provision not disrupted; limited visit data accessed. 7.1.1.2. Number of affected data subjects and extent of harm suffered by them: (a) ADSP 1 - number of affected data subjects – 63 patients, is the maximum theoretical limit and not the actual extent of unauthorized access; this number includes both legitimate and illegitimate access episodes, as the illegitimate access occurred during working hours when the employee was simultaneously legitimately using the system in the performance of her normal professional functions; no data exfiltration, transfer or dissemination identified; actual negative consequences for data subjects – financial damage, identity theft or other tangible impact, were not identified during the investigation; The Company did not receive a single complaint or claim from a data subject related to this incident; (b) ADSP 2 - the maximum theoretical number of affected data subjects – approximately 383 thousand patients and approximately 10 thousand employees, reflects the total number of all data subjects stored in the systems, and not the actual extent of unauthorized access. This number cannot be equated with the actual number of affected individuals; no data exfiltration, transfer or distribution was identified; actual negative consequences for data subjects – financial, moral or other tangible damage, were not identified; The Clinic did not receive a single complaint, claim or negative response from a data subject during or after the incident. 16 7.1.2. Inspection assessment Nature of the breach. Having established that the Company, in the course of both ADSPs, has violated not only Article 32(1)(b) of the GDPR, but also the principle of confidentiality set out in Article 5(1)(f) of the GDPR, for which a maximum fine may be imposed under Article 83(5) of the GDPR, the Company's actions by their nature fall into the category of more serious infringements. Severity and duration of the infringement. The Guidelines on fines state that the seriousness of the infringement is assessed in accordance with the specific circumstances and includes the nature of the processing, as well as the scope, purpose of the processing, the number of data subjects affected and the amount of the damage. The damage caused by the unlawful processing of personal data does not necessarily have to be material. Point 75 of the GDPR preamble explains that risks of varying likelihood and seriousness to the rights and freedoms of natural persons may also arise from such processing, where data subjects may lose the opportunity to exercise their rights and freedoms and are prevented from controlling their personal data. In this particular case, the Inspectorate does not have information about the material damage suffered by the data subjects (patients and Company employees), however, taking into account the fact that the health data of the data subjects could be viewed by illegally logged in third parties, it can be concluded that the data subjects (including patients) were prevented from controlling their data and this should be assessed as non-material damage. Taking into account the conclusion made above and the fact that dozens of people could have been affected by ADSP 1 and hundreds of thousands by ADSP 2, the Inspectorate decides that such damage cannot be assessed as insignificant. Despite the fact that during Inspection 1 and Inspection 2 the Company presented arguments that the personal data of the Company's patients and employees were not disclosed to a larger number of data recipients, the Inspectorate decides that, taking into account the circumstances set out in this subparagraph, the factor specified in Article 83, Paragraph 2, Point a) of the GDPR should be assessed as aggravating liability. 7.2. Article 83, Paragraph 2, Point b) of the GDPR – whether the violation was committed intentionally or due to negligence 7.2.1. The Company's explanations The Company indicated that there was no intent in both cases. That both ADSPs arose from external, malicious actions of third parties – a targeted phishing attack (ADSP 1) and a ransomware attack via RDP (ADSP 2). The actions of the clinic do not show signs of systemic, repeated or organizational negligence. Prior to the incidents, the Clinic applied documented technical and organisational measures, carried out periodic employee training, and had incident management procedures. 7.2.2. Inspectorate assessment Point 55 of the Guidelines on Fines states that “in general, ‘intentional’ means that the infringement is committed with knowledge of it and with the intention of committing it, and ‘unintentional’ means that although the controller or processor has breached the legal duty of care, he or she did not intend to commit the infringement”. According to the Guidelines on Fines, the intentional or negligent nature of the infringement (Article 83(2)(b) GDPR) should be assessed taking into account objective elements of conduct established in the assessment of the factual circumstances of the case. The EDPB stressed that it is generally accepted that intentional infringements, which “show a disregard for the provisions of legal acts, are more serious than unintentional ones”. In the case of an intentional violation, it is likely that the supervisory authority will give more importance to this factor. Depending on the circumstances of the case, the supervisory authority may also give importance to the degree of negligence. In the best case scenario, negligence could be considered a neutral factor. In the case under consideration, the Company's actions should be assessed as neutral, since the Inspectorate has no grounds to conclude that both ADSPs occurred intentionally, but concludes that ADSP 2 occurred due to the Company's negligence, since a sufficient period of time has passed between ADSP 1 and ADSP 2 for the Company to be able to eliminate the violations identified during ADSP 1. 17 7.3. Article 83(2)(c) of the GDPR – actions taken to mitigate the damage suffered by data subjects 7.3.1. Company explanations The clinic's actions in managing ADSP, providing assistance and information to patients, data subjects, and authorities were proactive, constructive, effective, and timely. 7.3.2. Inspectorate assessment According to the GDPR, data controllers must implement technical and organizational measures to ensure a level of security appropriate to the risk, but if this is not done properly, the responsible party should take all measures to mitigate the consequences of the breach for the person(s) concerned. When choosing a remedy and calculating the sanction to be imposed, the supervisory authority should take into account the responsible behavior (or lack thereof) of the data controller. This provision helps to assess the extent of the data controller's liability after the breach occurs, and may be applied in cases where the data controller, being clearly negligent and/or negligent, but having become aware of the breach, has taken all measures to remedy its actions. The Guidelines on fines state that in the event of a breach, the controller or processor should “do everything in its power to mitigate the consequences of the breach for the person(s) concerned”. The adoption of appropriate measures to mitigate the damage suffered by data subjects may be considered a mitigating factor leading to a reduction in the amount of the fine. The measures taken must be assessed in particular in the light of the element of timeliness, i.e. the time at which the controller or processor implements them, and their effectiveness. In this regard, measures that were implemented spontaneously before the supervisory authority started an investigation and became known to the controller or processor are more likely to be considered as mitigating factors than those that were implemented after that point. In the case under consideration, the Company, having learned about the ADSP, took active and timely actions in both cases so that the data subjects would not suffer or would suffer the least possible damage, therefore this factor should be assessed as mitigating liability. 7.4. Article 83(2)(d) of the GDPR – the extent of the liability of the data controller or data processor, taking into account the technical and organizational measures implemented by them in accordance with Articles 25 and 32 7.4.1. Company's explanations Since the beginning of the application of the GDPR, the Clinic has consistently, continuously and systematically implemented the requirements of the GDPR 24, 25, 28, 32 and other GDPR requirements, consistently invests in increasing security, increasing the security of patient data, etc. 7.4.2. Inspectorate assessment Articles 25 and 32 of the GDPR regulate the obligation of the controller to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risks involved in the processing of personal data. The Guidelines on fines note that, given the increased level of accountability under the GDPR, the degree of responsibility of the controller or processor is likely to be considered as an aggravating or neutral factor and only in exceptional circumstances, where the controller or processor exceeds their obligations under Articles 25 and 32 of the GDPR, will this be considered as a mitigating factor. The Inspectorate notes that, taking into account the clarification provided in the Guidelines on Fines, as well as the regulation of Articles 25 and 32 of the GDPR, the data controller must implement appropriate organizational and technical data security measures both before starting personal data processing activities and during the data processing itself (taking into account the level of development of technical capabilities, the nature, scope, purposes of data processing, identified - emerging issues, etc.). 18 Given that the Inspection identified violations of Article 32 of the GDPR, the Inspectorate does not assess this aspect additionally. 7.5. Article 83, paragraph 2, point e of the GDPR - previous violations of the Company 7.5.1. Explanations of the Company There were none that would be related to the assessed ADSP. 7.5.2. Assessment by the Inspectorate This criterion is intended to assess the reputation of the entity that committed the violation. The Guidelines on Fines indicate that the presence of previous violations may be considered an aggravating factor when calculating the administrative fine. The nature and frequency of previous violations are taken into account. However, it is also noted that the absence of previous violations could not be considered a mitigating factor, since compliance with the GDPR is the norm and the fact that there are no previous violations could be assessed as neutral. The Inspectorate has no information that the Company has previously violated the provisions of the GDPR, therefore it considers the factor set out in Article 83(2)(e) of the GDPR to be neutral. 7.6. Article 83(2)(f) of the GDPR – cooperation with the Inspectorate in order to rectify the violation and reduce its potential negative impact 7.6.1. Company's explanations The clinic, in fulfilling its obligations under the GDPR, informed the Inspectorate about the ADSP within no more than 72 hours, and later provided the Inspectorate with an supplemented notification, additional explanations, answers and information. The clinic has made and continues to make great efforts to cooperate with the Inspectorate, the National Commission for the Protection of Personal Data, as well as other competent authorities. The clinic has taken necessary and sufficient measures to control the ADSP and mitigate its consequences to the maximum extent possible. 7.6.2. Inspectorate's assessment Article 83(2)(f) of the GDPR provides that when deciding whether to impose an administrative fine, and when setting the amount of the fine, “due regard may be had” to cooperation with the supervisory authority. The Guidelines on Fines note that the fulfillment of the ordinary duty of cooperation should be considered a neutral, not a mitigating, factor. It should be noted that during the ADSP investigations and inspections, the Company cooperated with the Inspectorate, provided the requested information, as required by the GDPR, and such actions of the Clinic should be assessed as a neutral factor. 7.7. Article 83(2)(g) of the GDPR – categories of personal data affected by the breach 7.7.1. The Company did not provide any explanations 7.7.2. Inspectorate assessment The Guidelines on fines specify, as one of the factors characterizing the seriousness of the breach, the requirement to take into account the categories of personal data affected by the breach (Article 83(2)(g) of the GDPR). Paragraph 57 of these Guidelines explains that the GDPR clearly specifies the types of data that require special protection and, therefore, a stricter response when imposing fines. This relates at least to the types of data referred to in Articles 9 and 10 of the GDPR and to data not falling within the scope of these Articles, which cause direct harm or distress to the data subject (such as location data, private conversation data, national identification numbers or financial data such as transaction overviews or credit card numbers). In general, the more categories of such data or the more sensitive the data, the more weight the supervisory authority may attach to this factor. It is also important to determine the amount of data relating to each data subject, given that the greater the amount of data per data subject, the greater the risk of infringement of the right to privacy and the protection of personal data. Given that both ADSPs concern the processing of health data, the Inspectorate considers that this circumstance constitutes an aggravating factor. 7.8. Article 83(2)(h) of the GDPR – The Inspectorate’s knowledge of the infringement. 7.8.1. Company explanations Clinical reports submitted in accordance with the requirements and conditions of Article 33 of the GDPR. 7.8.2. Inspection assessment The supervisory authority may become aware of the breach through an investigation, through complaints, through the media, anonymous reports or through a report by the controller. The Guidelines on fines indicate that particular attention may be paid to whether the controller or processor has notified the breach on its own initiative before the supervisory authority has become aware of the breach, for example through a complaint or through an investigation. This circumstance is not relevant where the controller is subject to specific reporting obligations (e.g. in the case of ADSP under Article 33 of the GDPR). In such cases, this notification should be considered a neutral factor. In the case under consideration, ADSP 1 was noticed and reported in the media by a media representative, ADSP 2 was already reported by the Company itself. The Inspectorate assesses this factor as neutral. 7.9. Article 83(2)(i) of the GDPR – application of the measures specified in Article 58(2) of the GDPR 7.9.1. Explanations of the Company Not applied. 7.9.2. Assessment of the Inspectorate Article 83(2)(i) of the GDPR is related to the circumstance of assessing whether the data controller complied with the measures specified in Article 58(2) of the GDPR if these measures were previously applied to the data controller for the same matter. Considering that no corrective measures were previously applied to the Company, the Inspectorate does not assess the factor specified in Article 83(2)(i) of the GDPR. 7.10. Article 83(2)(j) of the GDPR – applicable codes of conduct or certification mechanisms 7.10.1. Company’s explanations There are no approved codes of conduct, but the Clinic follows good practices. 7.10.2. Inspectorate’s assessment Given that the Company’s actions are not subject to any codes of conduct or certification mechanisms, this point will not be assessed. 7.11. Article 83(2)(k) of the GDPR – other mitigating or aggravating factors The Company did not indicate any other mitigating or aggravating factors and the Inspectorate did not establish any other mitigating or aggravating factors. Summarizing the assessment of the ADSP carried out in sections 4, 5, 6 and 7 of this decision, the Inspectorate decides to impose an administrative fine on the Company. 8. Regarding the amount of the administrative fine 20 Point 48 of the Guidelines on fines provides that when imposing an administrative fine, it is necessary to take into account three elements which form the basis for calculating the administrative fine: the classification of the infringements into categories according to their nature in accordance with Article 83(4) to (6) of the GDPR, the gravity of the infringement and the turnover of the undertaking as one of the relevant elements to be taken into account in order to impose an effective, dissuasive and proportionate fine in accordance with Article 83(1) of the GDPR. Given that the infringement committed by the Company qualifies by its nature as falling within the category of infringements set out in Article 83(5) of the GDPR, administrative fines of up to EUR 20,000,000 or, in the case of an undertaking, up to 4% of its total annual worldwide turnover in the preceding financial year, whichever is the higher. In the case under consideration, the Company submitted the total global annual turnover of UAB Kardiolita for the financial year 2024 and the total global annual turnover of UAB Inmedica for the financial year 2025. Based on the data of the State Enterprise Centre of Registers, the successor of the rights and obligations of the Company from 25 June 2025 is UAB InMedica. Accordingly, the administrative fine will be calculated from the total global annual turnover of UAB InMedica for the financial year 2025. The Guidelines on fines explain that the gravity of the infringement is determined taking into account points a, b and g of Article 83(2) of the GDPR, i.e. the gravity of the entire infringement is determined by assessing the nature, gravity and duration of the infringement (point a of Article 83(2) of the GDPR); whether the infringement was committed intentionally or negligently (Article 83(2)(b) GDPR) and the categories of personal data affected by the infringement (Article 83(2)(g) GDPR). Based on the assessment of the factors, the infringement is considered to be of (i) minor, (ii) medium or (iii) high severity. These categories do not affect the question of whether a fine can be imposed. The Inspectorate has determined that the infringements committed by the Company relate to a large number of data subjects, a large amount of data, including health data, and non-material damage to data subjects, but has not determined that the Company acted intentionally, therefore it decides that the infringements committed by the Company are classified as medium-severity infringements and in such a case the initial amount of the fine determined corresponds to 10 to 20 percent of the maximum amount of the applicable fine, i.e. from EUR 20,000,000. The Inspectorate, taking into account the circumstances set out in this decision, decides that The Company shall be imposed a starting fine of 15 percent of the maximum amount of EUR 20,000,000, i.e. EUR 3,000,000 (starting fine). The Guidelines on fines also indicate that the supervisory authority may consider the possibility of adjusting the starting fine according to the gravity of the infringement in cases where this infringement is committed by an undertaking with an annual turnover not exceeding EUR 100 million, EUR 250 million and EUR 500 million. - For undertakings with an annual turnover of EUR 50–100 million, supervisory authorities may consider the possibility of making calculations based on an amount falling within the range of 8–20 percent of the set starting fine. - For undertakings with an annual turnover of EUR 100–250 million EUR, supervisory authorities may consider the possibility of calculating the amount based on an amount falling within the range of 15-50% of the initial fine. - For undertakings with an annual turnover of EUR 250-500 million, supervisory authorities may consider the possibility of calculating the amount based on an amount falling within the range of 40-100% of the initial fine. In the case at hand, it should be noted that the fine is imposed on a Company whose annual worldwide turnover for the financial year 2025 amounted to EUR 147,459,349, i.e. exceeded EUR 100,000,000. Taking into account these established circumstances and in accordance with the explanations of the Guidelines on Fines, applying a coefficient of 15% to the initial fine (EUR 3,000,000), the minimum administrative fine is EUR 450,000. Taking into account the information provided in this decision and the legal regulation, the Inspectorate decides that the administrative fine to be imposed on the Company - EUR 450,000 - is to be considered effective, proportionate and dissuasive. 21 The Inspectorate, having taken into account what is set out in this decision and in accordance with Article 58(2)(i), Article 83(1) and (2), Article 83(5), Article 34(10) of the GDPR, decides: 1. To impose a fine of EUR 450,000 (four hundred and fifty thousand euros) on the Company for the violations of the provisions of Article 24(1), Article 32(1)(b) and Article 5(1)(f) of the GDPR established in this decision. 2. To inform the Company about the decision taken. This decision may be appealed to the Regional Administrative Court (address: Žygimantų g. 2, Vilnius) within one month from the date of its delivery in accordance with the procedure established by the Administrative Procedure Code of the Republic of Lithuania. In accordance with Article 35(1) of the Administrative Procedure Code, the fine imposed must be paid to the budget revenue collection account20 (contribution code 6803, recipient of funds State Tax Inspectorate under the Ministry of Finance of the Republic of Lithuania, legal entity code 188659752) no later than three months from the date of acceptance of the fine. Deputy Director, Acting Director Danguolė Morkūnienė20 No. LT787290000000130151 (AB “Citadele” bankas); No. LT744010051001324763 and No. LT122140030002680220 (Luminor Bank AS Lithuanian branch); No. LT057044060007887175 (AB SEB bankas); No. LT327180000000141038 (AB Šiaulių bankas); No. LT247300010112394300 (AB „Swedbank“); LT427230000000120025 (UAB Medicinos bankas)

---
Generated by overview.legal · https://overview.legal/posts/53896 · 2026-08-22