Tietosuojavaltuutetun toimisto (Finland) - 2206/171/20
From GDPRhub
| Tietosuojavaltuutetun toimisto - 2206/171/20 | |
|---|---|
 | |
| Authority: | Tietosuojavaltuutetun toimisto (Finland) |
| Jurisdiction: | Finland |
| Relevant Law: | Article 5(1)(c) GDPR Article 5(1)(e) GDPR Article 25(2) GDPR Article 32(1)(d) GDPR Article 32(2) GDPR |
| Type: | Investigation |
| Outcome: | Violation Found |
| Started: | |
| Decided: | |
| Published: | |
| Fine: | n/a |
| Parties: | Forenom |
| National Case Number/Name: | 2206/171/20 |
| European Case Law Identifier: | n/a |
| Appeal: | Unknown |
| Original Language(s): | Finnish |
| Original Source: | Finnish DPA (in FI) |
| Initial Contributor: | n/a |
Hackers accessed around 165.000 personal data stored by the controller. The Finnish DPA found that the controller violated both the minimization and the storage limitation principles and failed to adopt adequate security measures to prevent the attack.
English Summary
Facts
Hackers invaded the information systems of the accommodation service provider Forenom, the controller. They gained access to a database containing approximately 165.000 personal details of the controller's customers. After receiving complaints from affected data subjects, the Finnish DPA launched investigations to ascertain the circumstances of the data leak. When asked to comment on the facts, the controller argued that the type of data collected depended on the group to which the person belonged, whether tenant, owner or company contacts. As for the data retention period, landlord and tenant information were kept for 10 years from the end of the tenancy or contract, while customer relationship management data were kept for 5 years since the last activity. According to the controller, long-term apartment rentals play a significant role in its business. Therefore, they found it necessary to keep the data to respond to eventual compensation claims that, based on the national Accounting Act, can be made within a 10-year time limit. After this period, the data were either deleted or anonymized.
Holding
The DPA held that the data controller did not comply with the data minimization principle nor with the storage limitation principle. It emphasized that not all accommodation and tenancy information would fall under the scope of the the Accounting Act and that the controller did not provide a clear explanation of which data was being retained for 10 years and why. According to the DPA, the controller must also implement appropriate technical and organizational measures to ensure by default that only necessary personal data were being processed for the purpose of responding to eventual damage claims. It recalled that this obligation applies not only in relation to the amount of personal data collected, but also to the storage time and the availability of the data. Finally, the DPA stated that the controller failed to assess the possible risks involved in retaining such data and to take appropriate technical and organizational security measures to prevent these risks. Consequently, the DPA found a violation of Article 5(1)(c) and (e), Article 25(2), Article 32(1)(d) and Article 32(2) GDPR.
Comment
Share your comments here!
Further Resources
Share blogs or news articles here!
English Machine Translation of the Decision
The decision below is a machine translation of the Finnish original. Please refer to the Finnish original for more details.
Minimizing data, limiting storage and regular testing of security measures Keywords: personal data security breach data breach data minimization limiting storage Legal basis: decision in accordance with the EU General Data Protection Regulation Diary number: 2206/171/20 Decision of the Data Protection Commissioner Thing Data breach and data minimization Registrar Accommodation service Forenom Oy Background of the matter The data security breach was committed against the data controller on Friday, March 13, 2020. The attack targeted the data controller's extranet service (customer self-service portal) and the interface it uses with the ERP system. The attack was detected on Friday, March 13, 2020, while it was still running, based on abnormal log data. The registrar's staff identified the used vulnerability and fixed it immediately after making the discovery. In this case, the attack was interrupted and the attacker's access to the systems was prevented. Based on the log data, it was verifiable that the attack had started approximately 12 hours before the vulnerability was patched. Based on the log data and the investigation, it was about the automated search for various vulnerabilities and the automated experiments of various types of SQL injections, the majority of which did not allow the attacker access, but one of which the attacker was able to exploit the vulnerability of the interface. Based on the first phase investigation carried out on the same day and the methods and findings found in it, the preliminary assessment was that the attacker did not have time to access the data contained in the database (including personal information) through a vulnerability in the interface. The investigation was continued on Monday, March 16, 2020, when it was discovered that the attacker had access to the database. Even though the vulnerability of the system was fixed, the attacker got hold of personal data and there is no information on what the attacker did with the information he got. As a result of the data breach, the attacker gained access to approximately 165,000 personal data records, some of which are duplicates and concern the same data subjects. 14 complaints were made to the data protection commissioner's office about the data breach. The complainants are not parties to the case in the sense of Section 11 of the Administrative Law (434/2003), as it does not concern their interests, rights or obligations. Statement received from the registrar In a letter dated July 3, 2020, the Office of the Data Protection Commissioner has requested an explanation regarding the cyber attack on the data controller's system and the related information security breach notification. The controller has submitted the report on August 14, 2020 and answered the questions of the data protection authorized officer's office as follows: 1. What personal data does Forenom collect from its customers? Forenom works as a provider of accommodation services and is the leading provider of furnished apartments in the Nordics. Forenom focuses on offering services to business customers, but there are also private individuals as customers. The personal data collected depends on which group of registered persons the persons belong to and which information is absolutely necessary to fulfill the processing purposes. Forenom has, for example, personal data of tenants, business contacts and landlords. Accommodation/rental contracts: service delivery and invoicing: contact information, date of birth, language, registration information (username and other possible identifying identifiers collected during registration), credit rating information (invoicing), camera monitoring, log data, code lock usage log data, call recording, instant message history. Forenom's online store: contact information (address, phone number, e-mail), registration information (username and other possible identifiers collected during registration), purchase/behavior history information. Customer service and communication: contact information, customer relationship information (information about newsletter subscriptions or information related to customer contact requests). Analysis, statistics and development of business, products and services: data on purchasing behavior, customer feedback data. Direct marketing and marketing campaigns: contact information (address, e-mail address and phone number), information about the subscription to the newsletter, purchase history information (targeting of marketing messages). Analysis of website usage: information collected by cookies. Access control: information about the state of the apartment (occupied, free) and availability of keys when guests leave and arrive. 2. On what basis does Forenom process personal data? The table below lists the legal grounds used by Forenom for each purpose of processing personal data. The same processing entity may include several different legal bases, on the basis of which the processing is carried out, but we have added in parentheses a description of the situations to which each legal basis is applied. Processing purpose and legal basis: Accommodation/rental contracts, service delivery and invoicing - Contract (contracts, service delivery) - Consent (credit rating information) - Legitimate interest (customer relationship management, customer service, investigation of abuses and faults, camera surveillance, log data, code lock usage log data) Forenom's online store - The contract Customer service and communication - Legitimate interest Analysis, statistics and development of business, products and services - Legitimate interest Direct marketing and marketing campaigns - Legitimate interest (business customers) - Consent (private customers, newsletter subscription) Analysis of website usage - Consent Access control - Legitimate interest 3a. How long are customers' personal data kept in the register? Before the entry into force of the data protection regulation, as part of its GDPR project, Forenom has clarified and compiled the customer data it collected and documented or determined the missing personal data retention periods. The main retention periods for personal data concerning customers are defined as follows: Landlord and tenant information: 10 years from the end of the tenancy or contract CRM data: 5 years since last activity Information related to invoicing: in accordance with accounting legislation (6 years + current year) Due to the data security breach that occurred in March 2020 and the subsequent customer inquiries regarding data retention periods, Forenom has taken the data inventory and related personal data retention periods for review during the spring and summer, and is assessing at best whether there is a need to change the retention periods in such a way that the business or Forenom's statutory obligations are not jeopardized. 3b. What is done with the data after the storage period ends? At the end of the retention period specified by Forenom or legislation, customer data is either deleted or anonymized. 4a. Do customers have the option to delete their own data from Forenom's customer register? Forenom customers have the option to delete their Forenom account (online store credentials) by logging in to their account. For the processing of other deletion requests, Forenom has defined responsible persons and an internal process based on which requests for deletion of registered personal data are processed. Forenom has statutory obligations to store certain personal data (for example, passenger notification information), but personal data outside the statutory retention obligation will be deleted from Forenom's customer register based on a registered request within one month of receiving the deletion request. 4b. If not, why not? As a data controller, Forenom has statutory and business-related obligations to store certain personal data about customers. If customers had the opportunity to delete large amounts of information about themselves, the fulfillment of Forenom's data retention obligation would be jeopardized. Forenom has evaluated the options and has come to the conclusion that customers have been given the right to independently manage their online store IDs, but information related to accommodation and rental activities and contracts must be requested to be deleted in accordance with Forenom's registered rights implementation process, so that Forenom, as the data controller, can assess on a case-by-case basis what information can be deleted. 5a. How the collected personal data is protected a) when data is collected Data is transferred from the user to our servers using a secure HTTP connection. 5b. How is the collected personal data protected b) during storage? The information is stored in encrypted databases and log files, to which a limited number of people have access. 6. Other relevant factors? Due to the updating of the information inventory, Forenom's Privacy Policy also needs to be updated and internally approved, and the updated version has not yet been published. The updated Privacy Statement can be found as an attachment to the response to this clarification request. 7. What measures have been taken or are going to be taken in the case of a data breach? Forenom has implemented an additional firewall layer to protect against attacks, limited access to the systems to certain geographic locations, performed a security audit of the system's source code, and implemented encryption for less relevant information as well. As an organization, Forenom is committed to regular third-party security audits of Forenom's systems. The entire staff participates in mandatory online training on personal data processing and data security. Separate training materials will be introduced for those roles and teams that need deeper skills (for example, sales, customer service and the technology team). Consultation of the controller With the hearing request sent on April 16, 2021, the controller has been given the opportunity to make a statement about the preliminary assessment on the matter and the confusion of facts presented in the hearing request. In addition, the data protection commissioner's office has reserved an opportunity for the data controller to be heard about the sanction that may be imposed in the case. In its reply submitted on 18 May 2021, the controller has stated, among other things, the following: [- -] It was verifiable that some of the database queries made by the attacker had returned information about the base for the registered groups detailed below as follows: • Customer information, 60,569 pcs - name, address, postal code, city, country, e-mail address, phone number, language, account number - personal identification number for 24,315 registered persons • Business customers' contact persons and company information, 5,707 pcs - VAT identifier, company name, address, postal code, city, country, language, phone number, email address, credit limit and information about Forenom's customer representative • Information of Forenomin ERP users, 1,800 pcs - name, email address, phone number, language, encrypted and salted password, country and team • Information on city/municipal contact persons, 1,383 pcs - name, title, phone number, email address • Online store users, 96,196 - email address, encrypted and salted password, and for some, name, phone number and reference to customer information The consultation request of the Office of the Data Protection Commissioner states that "as a result of the data security breach, the name, date of birth, social security number and contact information of approximately 165,000 customers ended up with an external party". In this regard, Forenom would like to clarify that the above-mentioned numbers describe the number of registered users belonging to each group, and there are overlaps in the groups. The same data subject can belong to several groups: for example, online store users have people whose information is also in the customer information. Due to this, the actual number of registrants is lower than the total number mentioned above (165,655). The personal data groups also vary according to the registered groups. The data security breach affected 24,315 registrants in terms of personal identification numbers. The controller says that after the data security breach, he took measures to improve the data security of his systems and the data protection skills of his personnel. The controller says that in October 2020, he had an external expert carry out security testing, which included penetration testing of the systems. The assessment of the external expert was that no vulnerabilities that could be exploited from the public network were found in the systems, and the targets to be tested are difficult targets for attackers due to effective countermeasures against attacks. The registrar has commented on the presenter's preliminary assessment as follows, among other things: [- -] In connection with the previous project, the data storage period of landlords and lodgers has been defined as 10 years from the end of the contract. The information is contact and identification information (name, contact information, social security number, account number). In addition, Forenom states that the attacker did not have access to the data of the guests (the information of the guests and the information of the customers are separate, because the guest is always an individual person, while the customer can be, for example, the person's employer). In the factual section of the hearing request (p. 5), the data protection commissioner's office states that the data controller has not demonstrated a clear legal need to keep personal data for 10 years. In this regard, Forenom states that in addition to the retention periods specified separately in legislation, the retention period can be based either in parallel or in addition to, for example, business needs. This is also the case with Forenom. [- -] When defining the retention period, the practical content of the principle of limiting retention was partly unspecified, and according to Forenom's view, taking into account the quality of the data to be retained, business needs, contractual obligations and previous experiences of the need to return to old data, a retention period of 10 years could be considered justified. For example, the expiration of the right to compensation according to the Damages Act has also been taken into account when defining the retention period. Forenom notes that old information has had to be returned to, e.g. after the end of tenancy relationships, in the investigation of disputes in court in situations where the landlord has demanded compensation based on the condition of the apartment. In this case, it has been necessary to go back to the information of the people who stayed in the apartment and, for example, find out their observations about the condition of the apartment during the tenancy (Forenom rents the apartment from its owner and hands it over to the customer, and the guests can be employees of the customer, for example). Forenom has since specified and limited the retention periods on a data-specific level at a more precise level, following the review referred to in the reply submitted to the data protection commissioner's office on 14 August 2020. With regard to the principle of data minimization, the consultation request does not specify to what extent the data protection commissioner's office considers that the data being processed is not appropriate and essential and limited to what is necessary for the purposes of the processing. In Forenom's opinion, information related to contracts is necessary for the purposes of processing (renting apartments, providing accommodation services, complying with statutory and contractual obligations). In accordance with Article 25, Paragraph 2 of the Data Protection Regulation, Forenom states that the background of the personal data security breach in question is not the default making of personal data available to an unlimited number of people, as described in the consultation request. According to the controller: The attacker has gained access to personal data through a data breach (i.e. criminal activity) by exploiting the vulnerability of a single interface. In other words, the information has not been freely available, but access to it has occurred as a result of a data breach. The interface used as an attack vector is connected to the extranet service used by Forenom's customers and therefore also open to the public network, as discussed in the description of the security breach. As a result of the attack, personal information has become available to an individual attacker. Forenom has no information that the attacker has also made information available to an unlimited number of people. Therefore, Forenom considers that Forenom has not made personal data available to an unlimited number of people as referred to in Article 25, Paragraph 2 of the Data Protection Regulation. In order to prevent the information in question from becoming available to an unlimited number of people, Forenom had implemented technical and organizational measures to protect the systems and the information they contain before the data security breach. With regard to the provisions of Article 32, Section 1, Subsection d and Section 2 of the General Data Protection Regulation, Forenom states that the attack that caused the security breach under consideration was aimed at Forenom's extranet (i.e. the self-service portal intended for Forenom's customers) and the related interface to the operational management system. According to the controller: The extranet is used by Forenom's customers, which is why it is necessary for the extranet to also be open to the public internet. The operational control system also has other public interfaces to, for example, external services (e.g. Shortcut). The other interfaces of the system have input validation to prevent SQL injections, but the input validation was omitted from the interface used in the attack due to a previous error, which created the vulnerability. Forenom has implemented several technical and organizational measures to ensure data security before the current data security breach. Application development follows Forenom's application development process and Forenom's built-in and default data protection policy (Privacy by Design Policy). In addition to Forenom's own measures, services provided by the Amazon Web Services (AWS) platform are utilized in the technical protective measures. In terms of information security measures, Forenom has also used external service providers even before the security breach, for example for the external audit of the source code in 2018. Organizational safeguards (for example, regularly reviewing log information) helped to detect an attack while it was still in progress and to stop the attack. Finally, Forenom states that the background of the security breach was a single vulnerable interface related to an extranet service that was open to the public network due to its purpose of use. Forenom has tried to implement adequate technical and organizational security measures to protect personal data before the data breach occurred. Forenom has also tried to ascertain the adequacy of these measures in accordance with Article 32, paragraph 1, subparagraph d of the data protection regulation referred to in the consultation request of the Data Protection Commissioner's office, for example with the above-mentioned code analysis by an external expert and with an internal review of the source code related to the application development process. The data security measures implemented are also informed by the final result of the data security audit carried out by an external expert after the data security breach, in which no similar or other exploitable vulnerabilities open to the public network were found. Therefore, Forenom considers that it has implemented the appropriate technical and organizational measures to protect data as referred to in Article 32 of the Data Protection Regulation. The security breach of personal data has been discussed above mainly from the point of view of Article 83(2)(d) of the Data Protection Regulation and technical and organizational measures. Regarding the other points to be taken into account in Article 83, paragraph 2, Forenom states the following. Forenom discovered the security breach itself and fixed the vulnerability immediately, which was able to limit the extent of the security breach. Forenom reported the data security breach on its own initiative to both the data protection commissioner's office and the data subjects, and has also actively cooperated with the cyber security center and the police in the investigation of the attack. Forenom has directed significant resources to the investigation and investigation work after the data security breach and has reviewed the entire IT infrastructure for similar and other vulnerabilities as described above. [--] The cross-border nature of the matter The General Data Protection Regulation provides for the handling of matters that are cross-border as defined in Article 4, Section 23 of the General Data Protection Regulation. Such matters must be handled in the manner stipulated in Article 56 and Chapter VII of the General Data Protection Regulation. On August 13, 2020, the controller was asked to clarify the possible cross-border nature of the matter. The registrar submitted an additional report on 30 August 2020. In its report, the controller has stated that it acts as the controller for the processing of the personal data in question. The controller operates in Finland, Sweden, Denmark and Norway. According to the controller, the information is processed in the group's common customer information system. The controller states that the main office is in Finland and that the office in Finland makes decisions about the processing of personal data at hand. Accordingly, the data protection commissioner's office has been deemed competent to handle the matter as the leading supervisory authority. The Office of the Data Protection Commissioner has handled the case in accordance with the procedure stipulated in Article 60 of the General Data Protection Regulation in cooperation with the supervisory authorities of the participating member states. On 29 October 2020, the Office of the Data Protection Commissioner has submitted relevant relevant information to other supervisory authorities in accordance with Article 56 and Article 60, Paragraph 3 of the General Data Protection Regulation. The data protection supervisory authorities of Ireland, Poland, Norway, Lithuania, Spain, Latvia, Belgium, Bulgaria, France, Luxembourg, Denmark, Hungary, Slovakia, Sweden, the German state of Bavaria and Italy have indicated that they are participating supervisory authorities on the basis that the processing of personal data in question affects or may affect those registered in that Member State. Handling the matter in the cooperation procedure The draft decision of the Deputy Data Protection Commissioner was submitted to the participating supervisory authorities for information on 24 August 2021 in accordance with Article 60, Paragraph 3 of the General Data Protection Regulation. The Data Protection Commissioner received an objection to the draft from the Polish supervisory authority and comments from the Danish, Hungarian and French supervisory authorities. According to the opinion of the Polish supervisory authority, the draft decision of the Office of the Data Protection Commissioner should be supplemented. According to the Polish supervisory authority, the decision should state a violation of Article 6 subsection 1 of the Data Protection Regulation. The Polish Supervisory Authority also considered that the Data Protection Commissioner should issue a notice to the data controller regarding the violation of Article 6 and Article 25(2) of the Data Protection Regulation. In the opinion of the Polish supervisory authority, the fact that the violation has since been corrected does not affect the matter. In the opinion of the Polish supervisory authority, the notice is a necessary sanction to prevent possible violations in the future. According to the Polish supervisory authority, imposing a fine in addition to a warning would be a proportionate, effective and dissuasive sanction. Failure to apply a proportionate and effective remedial measure could, in the opinion of the Polish supervisory authority, result in the controller not being sufficiently warned against violating the Data Protection Regulation again. The Danish supervisory authority has called for a supplement to the assessment regarding the adequacy of the technical and organizational protection measures implemented by the data controller before a data security breach occurs. The Hungarian supervisory authority has stated that the imposition of a fine would not be a disproportionate sanction in relation to the violations found in the decision. The French supervisory authority has commented that it accepts the proposed decision. On 27 May 2022, the Office of the Data Protection Commissioner gave the data controller the opportunity to comment on the comments and objections of the participating supervisory authorities. In this context, in addition to the points mentioned earlier, the controller has already brought up that he has made various improvements and enhancements to information security. According to the registrar, the long retention period had been decided on the basis of the expiration of the right to compensation according to the Damages Act. According to the registrar, long-term apartment rentals play a significant role in its business, where damage compensation cases can appear after a considerable period of time, in contrast to damage cases related to normal hotel operations. According to the controller, it has since, taking into account the opinion of the data protection officer, defined the minimum retention period according to the Accounting Act as the length of time the customer data is stored in the enterprise resource planning system and has taken a conscious business risk for itself in relation to damage compensation cases that cannot be processed within this deadline. According to the registrar, the data security breach mainly targeted customers who were active in the online service, and the subject of the breach was to a small extent personal data, for which the retention period according to the Accounting Act had expired. The controller considers that the number of data subjects subject to a data breach would not have been substantially lower, even if the retention periods according to the current specifications had been used. According to the registrar, it detected the security breach itself and fixed the vulnerability immediately, which was able to limit the scope of the security breach. According to the data controller, it reported the data security breach on its own initiative to both the data protection commissioner's office and the data subjects, and has also cooperated actively with the cyber security center and the police in the investigation of the attack. According to the registrar, it has directed significant resources to the investigation and investigation work after the data security breach and has gone through the entire IT infrastructure for similar and other vulnerabilities as described in this and the previous reply. The registrar considers that the imposition of a penalty fee would be a disproportionate penalty in relation to the violations found. The Data Protection Commissioner has partially taken into account the objection presented by the Polish supervisory authority in his decision and added to the decision the remarks due to the violation of Article 25(2), Article 32(1)(d) and Paragraph 2. As a result of the Danish supervisory authority's comment, the data protection commissioner's decision has supplemented the assessment of the protective measures and stated that the protective measures were not sufficient as required by Article 25, paragraph 2, Article 32, paragraph 1, subparagraph d, and paragraph 2. The Office of the Data Protection Commissioner has submitted a revised decision proposal to the participating supervisory authorities in accordance with Article 60, Paragraph 5 of the General Data Protection Regulation. None of the participating supervisory authorities has submitted a meaningful and justified objection to the revised decision proposal of the Office of the Data Protection Commissioner by February 15, 2023. The final decision will be notified to the controller, the complainants and the participating supervisory authorities. Applicable legislation The General Data Protection Regulation (EU) 2016/679 of the European Parliament and the Council (data protection regulation) has been applied since 25 May 2018. As a regulation, the legislation is immediately applicable law in the member states. The general data protection regulation is specified by the national data protection act (1050/2018), which has been applied since January 1, 2019. The previously valid Personal Data Act (523/1999) was repealed by the Data Protection Act. In that case, the general data protection regulation applies. Legal issues The Data Protection Commissioner evaluates and decides the case based on the General Data Protection Regulation (EU) 2016/679. The matter has to be resolved: 1) Has the data controller complied with the data minimization principle laid down in Article 5, paragraph 1, letter c of the General Data Protection Regulation and the retention limitation principle, laid down in letter e, when keeping the personal data of registered persons for 10 years? 2) Has the data controller complied with the obligation laid down in Article 25, Paragraph 2 of the General Data Protection Regulation to implement appropriate technical and organizational measures, with the help of which it is necessary to ensure in particular that personal data is not made available to an unlimited number of people by default and that the storage period of personal data is limited? 3) Has the data controller complied with the obligations regarding the assessment and testing of the appropriate security level stipulated in Article 32(1)(d) and (2) of the General Data Protection Regulation? If the processing of personal data has not been in accordance with the above-mentioned provisions, the matter to be decided is what penalty for the activity should be imposed on the controller. Decision of the Data Protection Commissioner In its decision, the Data Protection Commissioner considers the following: 1) The Data Protection Commissioner considers that the data controller has not complied with the data minimization principle laid down in Article 5(1)(c) of the General Data Protection Regulation and the retention limitation principle laid down in the same article's point(e) when keeping the personal data of registered users for 10 years in principle. Likewise, the Data Protection Commissioner considers that the data controller has not complied with the obligation under Article 25, Paragraph 2 of the General Data Protection Regulation to implement appropriate technical and organizational measures to ensure that the data is only stored for the necessary storage period. 2) The Data Protection Commissioner considers that, in the event of the described data security breach, the data controller has not complied with the obligation laid down for it in Article 25, paragraph 2 of the Data Protection Regulation to take appropriate technical and organizational measures, with the help of which it is necessary to ensure, in particular, that personal data is not made available to an unlimited number of people by default. 3) The Data Protection Commissioner considers that, in the event of a data security breach, the data controller had not complied with the obligations laid down in Article 32(1)(d) and (2) of the General Data Protection Regulation to implement appropriate technical and organizational measures to ensure a level of security corresponding to the risk. Regulation The Data Protection Commissioner gives the data controller an order in accordance with Article 58, paragraph 2, subparagraph d of the General Data Protection Regulation to assess which personal data should be kept in order to comply with the obligations laid down in the Accounting Act. To the extent that data does not need to be stored in order to comply with accounting or other statutory obligations, the data protection commissioner orders the data controller to shorten the processing time of the personal data it processes. Note The Data Protection Commissioner gives the data controller a notice in accordance with Article 58, Section 2, Subsection b of the General Data Protection Regulation. The Data Protection Commissioner points out that, in the event of a data breach, the data controller had not complied with the built-in and default data protection obligations of the Data Protection Regulation (Article 25 paragraph 2 of the General Data Protection Regulation), nor the obligation to properly protect personal data (Article 32 paragraph 1 subparagraph d and paragraph 2 of the General Data Protection Regulation ). Reasoning The principle of data minimization The principle of data minimization is stipulated in Article 5(1)(c) of the General Data Protection Regulation. Personal data must be appropriate and relevant and limited to what is necessary in relation to the purposes for which it is processed. As mentioned above, the processed personal data must be necessary for the purpose of the defined personal data processing. The content of the so-called necessity requirement had already been specified in the government's presentation concerning the Personal Data Act. Personal data can be considered necessary for the purpose of processing when they are appropriate and essential, and not too broad for the purpose for which they were collected and for which they will be processed later (HE 96/1998 vp, p.42). In paragraph 39 of the preamble of the General Data Protection Regulation, it is also stated that personal data should be sufficient and essential and limited to what is necessary for the purposes of their processing. Therefore, it can be stated that personal data may only be processed if the purpose of the processing cannot reasonably be fulfilled by other means. The European Data Protection Council has provided guidance on the minimization principle in connection with its guidelines. According to these instructions, you should first find out whether the processing of personal data is necessary at all. The processing of personal data is expressly advised to be avoided whenever possible. In addition, it has been separately emphasized that the personal data being processed must be relevant for the purpose of the processing in question. All processed personal data should also be necessary to achieve a separately defined purpose. The processing of certain personal data would only be permitted if the purpose of the processing cannot be achieved in other ways. In practice, as little personal data as possible should therefore be collected in each situation. The principle of limitation of storage Article 5(1)(e) of the General Data Protection Regulation provides for limiting the storage of personal data. Personal data must be kept in a form from which the data subject can be identified only for as long as is necessary to fulfill the purposes of the data processing. The storage period for personal data must therefore be as short as possible. According to recital 39 of the preamble of the General Data Protection Regulation, personal data should only be processed if the purpose of the processing cannot reasonably be fulfilled by other means. Personal data should therefore not be stored longer than necessary. According to recital 65 of the preamble of the General Data Protection Regulation, a natural person should, on the other hand, have the right to "be forgotten" if the retention of data violates this regulation or the Union law or the legislation of a member state applicable to the data controller. In particular, the data subject should have the right to have his personal data deleted and not processed after the personal data are no longer needed for the purposes for which they were collected or for which they were otherwise processed, or when he has objected to the processing of his personal data or when the processing of his personal data otherwise does not comply with the provisions of this regulation. About that case The registrar has stated that accommodation and tenancy information was kept for ten years after the end of the tenancy. The controller has justified the length of the storage period, e.g. with a business need; old information has had to be returned to, for example, after the end of the tenancy, when resolving disputes in court in situations where the landlord has demanded compensation based on the condition of the apartment. However, it is obvious that, for example, disputes usually start to be settled soon after the end of the tenancy, and in this case, information related to the case in question can be stored for a longer period of time than information related to undisputed customer relationships. The registrar had not presented a clear reason why all personal data related to the accommodation and rental relationship of the apartments was basically kept for ten years. In connection with the latest consultation, the controller has stated that it has shortened the retention period after the data security breach. According to the registrar, it has defined the length of the retention period for customer data in the ERP system as the minimum retention period according to the Accounting Act and has taken a conscious business risk for itself in relation to damage compensation cases that cannot be processed within this deadline. According to the Accounting Act (1336/1997), chapter 2, section 10, subsection 1, the financial statements, activity report, accounts, list of accounts and list of accounts and materials must be kept for at least 10 years after the end of the accounting period. Furthermore, according to Chapter 2, Section 10, Subsection 2 of the Accounting Act, unless a longer retention period is provided elsewhere in the Act, vouchers for the accounting period, correspondence regarding business transactions and accounting material other than those mentioned in Subsection 1 must be kept for at least six years from the end of the year in which the accounting period has ended. In Chapter 2 § 5 of the Accounting Act there is a provision on the voucher. Receipt refers to a dated and identified written statement of a business transaction, such as a receipt. In the board's proposal, on the other hand, regarding the definition of correspondence regarding business transactions, reference is made to the Accounting Board's general instruction of 1 February 2011 on accounting methods and materials, in section 4.2 of which it is stated that correspondence regarding business transactions are documents other than vouchers belonging to accounting materials. This kind of material includes, for example, official notifications made on the basis of accounting (for example, tax notifications) and notifications given to entities managing pension insurance or other entities and other notifications issued pursuant to legislation (HE 89/2015 vp, p. 49). The registrar has not submitted a more detailed explanation of which accommodation and rental relationship data is subject to the storage period defined on the basis of the Accounting Act. However, based on the legal provisions explained above, it is clear that not all accommodation and tenancy information can be considered information referred to in Chapter 2, Section 10 of the Accounting Act. The registrar has not presented a clear reason why a retention period based on the Accounting Act has been defined for all personal data related to the accommodation and rental relationship of apartments. Based on the reasons presented above, the Data Protection Commissioner considers that the data controller has not complied with the provisions of Article 5(1)(c) and (e) of the General Data Protection Regulation in its processing activities regarding data retention. Built-in and default data protection According to Article 25, paragraph 2 of the Data Protection Regulation, the controller must implement appropriate technical and organizational measures to ensure that by default only personal data necessary for each specific purpose of the processing is processed. This obligation applies to the amount of personal data collected, the extent of processing, storage time and availability. With the help of these measures, it must be ensured in particular that personal data is not, by default, made available to an unlimited number of people without the contribution of a natural person. Security of processing According to Article 32(1)(d) of the Data Protection Regulation: Taking into account the latest technology and implementation costs, the nature, scope, context and purposes of the processing, as well as the risks to the rights and freedoms of natural persons, which vary in probability and severity, the controller and the processor of personal data must implement appropriate technical and organizational measures to ensure a level of security corresponding to the risk, such as [--] d) the procedure for regularly testing, examining and evaluating the effectiveness of technical and organizational measures to ensure the security of data processing. According to Article 32, paragraph 2 of the Data Protection Regulation, when assessing the appropriate level of security, special attention must be paid to the risks involved in processing, especially due to the accidental or illegal destruction, loss, alteration, unauthorized disclosure or access to personal data of transferred, stored or otherwise processed personal data. The processing of personal data must be confidential and secure. The controller must assess possible risks, the level of the organization's data protection and information security guidelines, and the technical protection of personal data. The adequacy of protective measures must be weighed in relation to the circumstances and risks. The purpose of security measures is to ensure the confidentiality, integrity and availability of systems, services and data. Personal data is protected against unauthorized and illegal processing and against accidental disposal, destruction or damage. Data security breaches can cause serious risks for data subjects, such as being the target of identity theft or fraud. Personal data must be protected in all processing activities directed at them and during the entire life cycle of personal data processing. The controller must test the functionality of the security measures regularly and make the necessary improvements. About the case in question Based on the report provided, the controller considers that it has implemented the appropriate technical and organizational measures to protect the data as referred to in Article 32 of the Data Protection Regulation. According to the report given by the registrar, it had used, among other things, the following protective measures • Data is transferred from the user to the registrar's servers using a secure HTTP connection. • The information is stored in encrypted databases and log files, to which a limited number of people have access. • In addition to the data controller's own measures, services provided by the Amazon Web Services (AWS) platform are utilized in the technical protection measures. • The system's other interfaces have input validation to prevent SQL injections (the input validation was omitted from the interface used in the attack due to a previous error, which caused the vulnerability). • In its application development, the controller follows the application development process and the built-in and default data protection policy (Privacy by Design Policy). • The application development process includes viewing the source code. • Before the data security breach, the data controller has used external experts, for example for the external audit of the source code in 2018. According to the registrar, after the data security breach, it commissioned an external expert to conduct a data security audit, which found no similar or other exploitable vulnerabilities open to the public network. In that case, the security breach was carried out by means of SQL injection. SQL injection means affecting the content of the database environment in use with an arbitrary command that is executed in the target system. The attack can be successful, for example, through the check of missing or incorrectly implemented input data, and in some cases also through the incorrect processing of data in the database interface itself. In the data breach, the attacker had executed several different commands with the help of automation, at least one of which has used the vulnerability to return the personal data mentioned above to the attacker. Since SQL injections are a widely recognized information security risk, it is important that the administrators of online services and database servers protect themselves from them with appropriate information security measures. In combating SQL injections, it is necessary to ensure that the system has been sufficiently tested, and in web applications, injections can also be prevented with comprehensive firewall functions. Because the system subject to a data breach is a so-called extranet, i.e. the customers' self-service portal, it is not appropriate to prevent its operation via the public internet; otherwise customers would not be able to use the service. According to the data controller, the source code was audited in 2018. The data protection commissioner has taken into account that two years had passed since the audit when the data security breach occurred, and the data controller has not brought up that after 2018 it had performed penetration testing or audits before the data security breach occurred. The controller has stated in its report that, after the data security breach, it has had its systems performed by an external expert for penetration testing. In this testing, no exploitable vulnerabilities were found on the public network. If the data controller had performed penetration testing before the security breach occurred, the vulnerability exploited in the security breach could possibly have been detected. As stated above, SQL injections are one of the most critical security risks for web applications. The controller could have performed more regular testing to detect and fix vulnerabilities. Consequently, the Data Protection Commissioner considers that the data controller had not implemented sufficient measures to ensure a level of security corresponding to the risk as required by Article 25(2), Article 32(1)(d) and Article 32(2) of the General Data Protection Regulation. Applicable legal provisions Those mentioned in the justifications. Appeal According to Section 25 of the Data Protection Act (1050/2018), this decision can be appealed by appealing to the Administrative Court in accordance with the provisions of the Act on Trial in Administrative Matters (808/2019). The appeal is made to the Helsinki Administrative Court. Service The decision is notified in accordance with § 60 of the Administrative Act (434/2003) by mail against receipt. The decision is not legally binding.
