Holder’s Duties
Data Protection Commission Case Studies
Data Breach at an Online Retailer
In July 2016, we received a breach report from an organisation operating retail and online sales. The organisation had been notified by a customer that their credit card was used in a fraudulent transaction without their knowledge which they believed arose from their provision of payment details online to the organisation.
The organisation engaged an expert third party to conduct an analysis of its website. It was determined that the payments system on the website had been compromised by malware for the previous 6-8 weeks. The malware copied data entered by customers during the online payment stage to an external destination.
Our assessment of the breach identified that there were deficiencies in the measures which the organisation had taken to secure users’ personal data including the following.
No contract or service level agreement existed between the data controller and the data processor.
No steps were taken to ensure that the data processor was compliant with technical security and organisational measures.
Insufficient measures were in place relating to appropriate technical security and organisational security measures to:
ensure that the server and website platform were maintained and that the software versions were up to date;
ensure that appropriate user authentication and access control measures were in place;
ensure appropriate technical security was in place, such as secure configuration of the website platform, measures to detect malware, measures to monitor suspicious activity and measures to ensure regular backups were taken; and
ensure governance processes were in place such as periodic reviews of the data processor and its technical security and organisational measures.
In light of the above, we considered that the organisation had contravened Section 2(1)(d) of the Data Protection Acts 1988 and 2003 by failing to take appropriate security measures against unauthorised access to, or unauthorised alteration, disclosure or destruction of, its users’ personal data.
Recommendations were issued to the organisation that it take steps to mitigate the risks identified. The organisation subsequently informed us that it had taken the following steps to address the recommendations:
Contracts are now in place to ensure that the appropriate technical security and organisational measures are in operation;
The organisation conducts regular reviews of the server and website platforms to ensure they are maintained and that the software versions are up to date;
The organisation conducts annual reviews by a third party expert to ensure compliance and to independently validate that the appropriate technical security and organisational measures are in place.
This case highlights the need for organisations to ensure that they have appropriate technical security and organisational measures for ICT security in place, particularly when engaging a data processor. Organisations should be cognisant of the measures outlined under Section 2C of the Acts to understand their obligations, in particular:
To ensure that appropriate security measures are in place;
Reasonable steps are taken to ensure that employees of the Data Controller and any other persons, for example, Data Processor employees, associated with the processing are aware of their obligations;
To ensure that proper contractual agreements are in place governing the processing;
That reasonable steps are taken to ensure compliance with the measures.
Crypto Ransomware Attack on a Primary School
In October 2016, we received a breach report from a primary school that had been the victim of a “Crypto Ransomware” attack, whereby parts of the school’s information systems had been encrypted by a third party thereby rendering the school’s files inaccessible. These files contained personal details including names, dates of birth and Personal Public Service Numbers (PPSNs). A ransom was demanded from the school to release the encrypted files.
Our assessment of the attack identified that the school had deficiencies in the measures it had taken to secure pupils’ personal data including:
No polices or procedures were in place to maintain adequate backups;
No procedures or policy documents existed focusing on system attacks such as ransomware or viruses;
No contracts with data processors (the ICT services providers) were in place (as is required under Section 2C(3) of the Data Protection Acts 1988 and 2003) setting out their obligations and, as a result, actions taken by the ICT suppliers were inadequate in response to the attack; and
A lack of staff training and awareness of the risks associated with opening unknown email attachments or files.
We considered that the school had contravened the provisions of Section 2 (1) (d) of the Acts, having failed to ensure that adequate security measures were in place, to protect against the unauthorised processing and disclosure of personal data.
Recommendations were issued to the school that it take steps to mitigate the risks identified. The school subsequently informed us that it had taken the following steps based on the recommendations issued:
Implement a staff training and awareness programme on the risks associated with email and the use of personal USB keys.
Implementation of a contract review process to ensure appropriate contracts are in place with its ICT suppliers
Ensure that any ICT support the school engages with either on a local basis or as recommended by the Board is performed by competent data processors.
This case demonstrates that schools, like any other organisation – commercial, public sector or private, operating electronic data storage systems and interacting online must ensure that they have appropriate technical security and organisational measures in place to prevent loss of personal data, and to ensure they can restore data in the event of Crypto Ransomware attacks.
By continuing to use this website, you consent to the use of cookies in accordance with our Cookie Policy.HIDE THIS NOTICE
Data Protection Commissioner Data Protection Commissioner
Prosecution of James Cowley Private Investigator
James Cowley was charged with sixty-one counts of breaches of the Data Protection Acts, 1988 & 2003. All charges related to breaches of Section 22 of the Data Protection Acts for obtaining access to personal data without the prior authority of the data controller by whom the data is kept and disclosing the data to another person. The personal data was kept by the Department of Social Protection. The personal data was disclosed to entities in the insurance sector – the State Claims Agency, Zurich Plc and Allianz Plc.
On 13 June 2016, at Dublin Metropolitan District Court, James Cowley pleaded guilty to thirteen sample charges. He was convicted on the first four charges and the Court imposed a fine of €1,000 in respect of each of these four charges. The remaining nine charges were taken into consideration in the sentence imposed.
The investigation in this case uncovered access by the defendant to social welfare records held on databases in the Department of Social Protection. To access these records, the defendant used a staff contact who was known to him. Mr. Cowley then used the information he obtained for the purposes of compiling private investigator reports for his clients. These activities continued for a number of years up to September 2015 when our investigation team first made contact with him about its concerns in relation to his processing of personal data.
Third-Level Student Data Appeared on Third-Party Website
The Office received a notification from a data controller, in accordance with the Personal Data Security Breach Code of Practice. The notification alerted the Office to the fact that data relating to a large number of students had been discovered on a website that was unrelated to the data controller. The data related to the 2010 academic year.
The Office began an investigation of the matter. The data controller advised the investigation team that the information disclosed on the website included the name, email address and password of the student. The investigation team confirmed that there was no financial or sensitive data involved.
The data controller engaged an external security company to carry out its own investigation into the security breach.
Due to the passage of time, there were no server logs showing when or by whom the data had been uploaded to the website. However, the data controller was able to identify that the data published matched a file created for testing purposes in mid-2011. This file was then sent to a third-party service provider who was engaged in developing a management system for the data controller. The file was sent via unsecured email.
The third-party service provider informed the data controller that while there was a relationship between their staff and the website on which the data was published, they had conducted a very thorough review of the matter and could find no evidence to show that the file had been posted onto the website due to an act of omission on their part.
Our evaluation of the information showed that the data controller, when creating student accounts, used generic passwords when generating the student accounts. The password was the date of birth of the student. While students could change their passwords, they were never advised to change them.
While it could not be determined exactly how the data appeared on the website, it was evident that there had been a breach of the Data Protection Acts, in that appropriate security measures were not in place to prevent the unauthorised disclosure of personal data.
Our investigation also found that the use of live data for testing purposes was not in accordance with data-protection best practices. Where live data is being used by an organisation for testing purposes, there would have to be a strong justification for such use and we were not aware of any justification applicable in this particular case. The Office recommended that the data controller cease the use of live personal data for testing and either anonymise the data or create a fictitious data set for testing purposes.
The transmission of such student data via an unsecured channel is also inconsistent with the Data Protection Acts. It was found that, during the development of the management system, personal data, including passwords, was exchanged between the data controller and the service provider, using an unsecured channel. The data controller advised my Office of the fact that they now transmit such data via a secure mechanism. The Office recommended that this mechanism be brought to the attention of all staff.
Another issue discovered during our investigation that caused great concern was the use of a generic password. The fact that the date of birth of the student was assigned as their password meant that any individual who had access to the date of birth of another student could access the user account of that student. The Office recommended that the data controller communicate with students, advising that they change their password and that the new password be a minimum of 12 characters and include upper- and lower-case characters, numerals and special characters, such as a symbol or punctuation mark.
Data Controller Discloses Personal Data to Business Partner
The Office received notification from a data controller advising that an email had been issued to a business partner which included personal data that should not have been disclosed.
The data controller advised the Office that it had entered into a business agreement with a third-party company to provide anonymised data to allow for a feasibility assessment of a proposed business venture. An email was issued to the third-party company which included the names of individuals in addition to the agreed anonymised data. This allowed for the third-party company to identify the individuals involved.
The data controller, in notifying this Office, stated that the third-party company had provided assurances that the data had been deleted.
The Office commenced an investigation of a data-security breach, under Section 10 of the Data Protection Acts.
Given the nature of the data involved and additional information received by a third party, this Office decided to visit the premises of the third-party business partner to satisfy ourselves that the data had been deleted and not further processed.
An investigation team, using our powers under Section 24 of the Data Protection Acts, arrived unannounced at the premises of the business partner. The team obtained documents in relation to the business agreement; these showed that only anonymised data had been sought. The team also obtained reports that had been created on foot of the receipt of the personal data. It was evident from these reports that, while personal data was available to the third party, it had not been used in the preparation of the reports and had no impact on the reports.
The team then examined the computer systems of the company and discovered several instances of the email it had received which contained the personal data.
The Commissioner felt it appropriate to issue an Enforcement Notice to the third-party company, requiring them to engage an external IT security company to delete any and all copies of the personal data it had received. The IT security company was to provide my Office with a report on the completion of the work. This report was duly received and this Office was satisfied that all copies of the personal data had been securely deleted.
The investigation found that personal data had been disclosed without consent or a legal basis. The investigation also noted that non-business related email accounts had been used by members of staff of the data controller in the conduct of business matters. The data controller was advised to prevent the use of non-business email accounts as the data controller could not control any data that would be transmitted through these non-business accounts.
Case Study 14: Employee of Financial Institution Resigns Taking Customer Personal Data
The Office received a notification from a data controller, in accordance with the Personal Data Security Breach Code of Practice. The notification stated that an employee had tendered their resignation and the data controller then discovered that the employee had emailed a spreadsheet to their personal email account prior to their resignation. The spreadsheet contained details of customers, including their employment details, salaries, contact details and medical consultant.
The data controller provided the name and home address of the employee.
The Office was also contacted by the umbrella organisation of the data controller seeking assistance on how to advise their member.
The Office verified, through the Companies Registration Office, that a business was operating from the home address of the employee. We then contacted the employee on the basis that they were now operating as a data controller in their own right. We sought clarification from the employee as to the consent they had to process any personal data they obtained from their previous employment.
The employee advised the Office that, as part of their employment, they were asked to use their own laptop and personal phone for all business dealings. The employee also advised that they had not yet started canvassing for clients. The employee also confirmed that they had deleted all the personal data they held in relation to their previous employment.
We also engaged with the data controller who had made the notification in relation to the security procedures that were in place to protect customer data in its possession. The Office noted that the employment contract contained appropriate data-protection clauses. However, of concern was the fact that employees were using their own equipment for business purposes. In such circumstances, the data controller has little or no control over that data held on personal equipment.
The data controller introduced further procedures and policies on foot of the issue to prevent a repeat of this type of incident, including the introduction of software to password protect any data records being emailed. Furthermore, all employees must sign an undertaking on termination of employment that all data has been returned and will not be further processed.
Case Study 15: Theft of Unencrypted Laptop
The Office received a data-security breach notification during the year from a medical professional relating to a stolen laptop.
The notification advised that the laptop was password protected, but not encrypted. The notification also advised that the data stored on the laptop related to a medical study that was undertaken in 2009 and included audio files of interviews carried out with the study subjects which contained limited information. It was determined that a file listing the subjects of the study contained an ID number rather than the name of the individual. However, a further file that correlated the ID number with the subject name was also stored on the laptop. This file was also password protected.
It was noted that, before the study began, approval was obtained from the relevant Ethics Committee that covered the storage of data.
This Office advised the data controller of our guidance in relation to the notification of the affected individuals. In this particular case, the data controller advised the Office that it was of the view that notification to affected individuals would cause more distress than help to the affected individuals. This view was offered by the relevant medical professional overseeing the project. This Office must note the opinion of a medical professional who has a professional relationship with the affected individuals. We assume this decision is taken weighing the potential effects of an unauthorised disclosure of this data against the potential distress of the individual being notified of the security breach.
The Office, however, noted that laptops are now being encrypted. This case highlights the fact that data-protection considerations need to be constantly monitored. What may have been an acceptable standard five years previous may not now be acceptable, and security arrangements must be periodically reviewed.
Compromise of Adobe Network
Adobe Systems Software Ireland Ltd notified this Office in October 2013, in accordance with the Personal Data Security Breach Code of Practice, of a data-security breach regarding an unauthorised access to their systems. Personal data was compromised and the attacker also took Adobe software source-code elements.
Two data controllers were affected: Adobe US and Adobe Systems Software Ireland Ltd (Adobe Irl). We engaged in a coordinated investigation with the Office of the Privacy Commissioner of Canada and we were co-joined in our investigation by the Office of the Australian Information Commissioner.
Nature of Data Compromised
Adobe Irl created three classifications of individuals affected:
• Payment-card users, i.e. those whose encrypted payment-card numbers were accessed during the breach. The data involved was encrypted payment-card data – approximately 3.65 million payment cards (1 million controlled by Adobe Irl) relating to approximately 3.1 million individuals.
• Active users, i.e. those who had logged in to Adobe systems at least once in the two years prior to the discovery of the breach. The data involved was: email address and current encrypted password – 41 million (reduces to 33 million, as 8 million email notifications were undeliverable) (20.5 million controlled by Adobe Irl).
• Non-active users, i.e. those who had not logged in to Adobe in the two years prior to the discovery of the breach. The data involved was: email address and current encrypted password – 71 million (reduces to 46.5 million due to 25 million email notifications undeliverable) (28.5 million controlled by Adobe Irl).
How the Breach Occurred
The attack was a sophisticated and sustained intrusion of Adobe’s computer systems. Attackers identified and removed data from a backup server that stored the compromised data described above. Adobe states it has no evidence to show that unencrypted card details were taken. Forensic consultants engaged by Adobe supported this conclusion.
When Adobe learned of the security breach, they began an investigation of the cause of the issue and also initiated a series of measures including the following:
· Disconnected the impacted database server from the network
· Blacklisted IP addresses from which the attacker accessed their systems
· Reset passwords for all potentially affected users (including active, non-active)
· Changed passwords for relevant administrator accounts
· Notified the banks processing customer payments for Adobe, so they could work to protect customers’ accounts
· Reported the breach to law-enforcement authorities
· Employed a third-party company to conduct an investigation of the cause of the security breach of its systems and to identify what data may have been compromised
· Took actions to reduce the risks related to the theft of certain source-code elements
· Issued notifications to affected individuals, beginning on 3 October 2013, which alerted customers to the security breach
Passwords
At risk: the attacker posted some data that was exfiltrated on a website and included the email address and encrypted password of certain Adobe users. A number of research articles have demonstrated that some passwords have been deciphered by reference to password hints and repeated passwords (i.e., the same password used by more than one user). One article highlighted an organisation that had checked the compromised usernames and deciphered passwords against its own platform and found a significant number of these credentials would have worked on its own platform. The organisation contacted some of its affected users, alerting them to the issue, and also confirmed the scenario to this office. At issue here is that while Adobe enforced a password change on its own site and advised users to change their passwords elsewhere, it is evident that not all users followed such advice.
Hints: Parts of the data exfiltrated by the attacker were the password hints of a small percentage of users. These hints were stored in clear text and associated with the username (email address). This information, along with an analysis of the encrypted passwords, will allow for the identification of certain simple passwords. However, as previously noted, Adobe reset the passwords for all impacted users.
Storage: The Office queried why passwords were stored in one system in an encrypted manner rather that hashed and salted. Encrypted passwords can be unencrypted, which would allow a data controller to see the passwords of users, or attackers, if they gained access. Adobe stated it was actually hashing and salting passwords within a new system for a number of years prior to the discovery of the security breach, but decided to also keep the database in the old system as a backup measure in case of issues with the new system. Passwords in the old system’s database had been encrypted.
Retention of Card Data with Customer Records
Customers who used payment cards to purchase Adobe products or services had their card details (encrypted) stored with the customer account within one particular system. Card numbers have now been replaced with a token system. This process began prior to the discovery of the security breach and was completed shortly thereafter. The token, which is encrypted, represents the payment-card number within the customer record and Adobe systems transmits the encrypted token to a third-party service provider, whose systems are located outside Adobe’s network, for payment processing.
Notifications to Affected Individuals
Adobe provided the Office with a list of when they notified each class of affected individuals and the relevant notification. In addition, Adobe publicly announced the 2013 breach in posts on its website, which included discussion of the theft of source code. The various notifications did advise individuals to monitor their credit-card statements and change their password if it was used on another site.
When we queried why notifications did not issue to those individuals where only contact details were compromised and did not include password or payment-card data, Adobe replied that it believed that notice in this scenario would lead to over-notification and notification fatigue and that there is not a significant risk of harm with respect to a compromise of this type of data element. The Code of Practice recommends that affected users are notified, so that each affected individual can consider the consequences for themselves and take appropriate measures.
This Office would expect that if a similar incident were to occur in the future, Adobe, or any other data controller, would automatically include all individuals for whom personal data had been compromised in its notification process.
Conclusion and Findings
Adobe fully cooperated with our investigation of the security breach reported to us on 2 October 2013. Adobe took appropriate action on discovery of the attack to prevent further access to their systems as required under Section 2(1)(d) of the Data Protection Acts 1988 and 2003. It also enforced a password change for its users to protect against unauthorised access to account data. Adobe’s quick reaction on learning of the security breach prevented the attacker from exfiltrating unencrypted payment-card details.
Adobe’s transitioning from the use of encrypted passwords in the old system to the use of hashed and salted passwords in the new system could have been achieved more effectively and expeditiously than was the case. Of concern to those users who provided password hints, Adobe stored these in plain text rather than in an encrypted format, some of which have been compromised.
This Office is cognisant of the fact that data controllers such as Adobe will always be a target for attackers and new attack methods are constantly being devised.
This Office found that Adobe was in breach of Section 2(1)(d) of the Acts by failing to have in place appropriate security measures to protect the data under its control, despite its documented security programme. It was also recommended that Adobe engages a third party to carry out an independent review of its systems.
Adobe has since put in place substantial improvements in its security protocols, practices and procedures, and this Office is satisfied that it now has appropriate procedures in place to minimise the possibility of a similar security breach in the future.
Client list taken by ex-employee to new employer
In January, 2013 we received a complaint from an individual in relation to receipt of unsolicited correspondence to her home address, from a company with whom she had no business relationship. The correspondence referred to the individual’s existing pension plan with another company and offered a review of the individual’s existing assets or advice concerning her future provision. The letter also indicated the sender’s intention to phone the recipient to discuss the matter further. The individual stated that she was annoyed and aggrieved that her personal and financial details were now in the hands of a company of which she had no knowledge.
The individual contacted the company with which she had set up her pension plan and they confirmed to her that the person who had sent her the unsolicited letter had left their employment in December 2011.
Section 2 of the Data Protection Acts, 1988 and 2003 (the Acts), provides that personal data shall be fairly obtained and processed and shall not be further processed without the prior consent of the individual concerned. We asked the new employer to confirm whether the employee had brought in data relating to clients that he obtained from his time working in his previous employment. We also asked the new employer to confirm what consent, in line with the Data Protection Acts, it had to process such data.
Our letter also informed the new employer that it should be aware that contacting an individual by phone, for the purposes of electronic direct marketing, without first receiving their consent, is an offence under Statutory Instrument No 336 of 2011.
The new employer confirmed that, having conducted its own internal investigation into the matter, that approximately fifty former contacts of the employee were written to. It stated that no follow up phone calls were made. The new employer confirmed that any such data that the employee possessed had been destroyed and that no further attempts would be made to contact those individuals.
The complaint was resolved on an amicable basis when the company provided this Office with a letter of apology dated 28 January, 2013 to forward, on its behalf, to the individual concerned.
However, in early April, 2013 this Office received a data security breach notification from the former employer informing us that another of their clients had informed them that she had received a letter from one of its former employees soliciting business. The nature of the letter, although addressed to a different client, was similar to the incident previously investigated by this Office in January 2013. The letter was dated 15 January, 2013 thus predating the confirmation of 28 January, from the new employer, that the client data had been destroyed.
Our investigations of such instances are twofold. We contact the company responsible for sending the unsolicited correspondence and we also deal with the company responsible for the data, to determine whether the security procedures it has in place to protect against the unauthorised access and disclosure of personal data are sufficient.
In this instance we requested the former employer to inform us of the policies it had in place regarding the security of client information in circumstances where an employee is moving to a new employment. We also requested to be provided with a copy of the data protection element of the contract of employment.
When providing this Office with a copy of the Confidentiality and Solicitation agreement signed by the former employee, the former employer also provided us with a copy of another letter sent to one of their clients by the former employee. The letter was dated 15 April, 2013 and was similar in nature to the letters sent to individuals in January 2013. However, on this occasion, the unsolicited correspondence made no reference to contacting the individual by telephone.
This information contradicted the confirmation we had received from the new employer in January 2013 that all data relating to the employee’s previous employment had been destroyed. On becoming aware of this development, this Office had no option but to have two of our Authorised Officers carry out a site inspection, as provided under Section 24 of the Acts, at the premises of the company. To assist with the site inspection, we requested the former employer to provide us with a copy of the client list of the former employee.
The purpose of the site visit by the Authorised Officers was twofold. Firstly to ascertain how it happened that a letter dated 15 April, 2013 issued to a client of the former employer, despite assurance from the new employer, in a letter dated 28 January, 2013 that all client data from their employee’s previous employment had been destroyed. Secondly to carry out a search of the company’s systems to satisfy ourselves that there was no further data in the company’s possession relating to the clients of the previous employer. Using the data provided by the original employer, the Inspection Team carried out a search on the computer systems for individuals’ names and addresses. The Inspection Team was satisfied that no further customer data remained.
We informed the new employer, on the morning of the site inspection, of our intention to visit his place of business that afternoon. We had not informed the new employer, prior to the site visit, of our knowledge of the letter dated 15 April, 2013. The new employer cooperated with the inspection.
Our investigation of the matter concluded on the basis of our receipt of written confirmation in May 2013 from the Managing Director of the new employer, stating that he fully accepted that breaches had occurred and outlining the actions his company was taking to prevent a recurrence. The Managing Director also confirmed that he personally oversaw the destruction of the data held by the employee.
This Office has noticed a significant increase in the number of data security breach notifications we are receiving in relation to this type of matter. We may first become aware of the matter via the receipt of a complaint from an individual relating to their receipt of unsolicited communications or from our receipt of a data security breach notification from the data controller. While there are obvious business related implications to such incidents, the focus of this Office’s investigation concerns the basic principles of data protection relating to security, fair obtaining and processing of personal data.
Loss of photocopies of passports
In November 2013, a voluntary organisation that is involved with young people notified us of a data security breach relating to the loss by one of its local groups of photocopies of passports. The organisation informed us that one of its local groups had reported that a file containing photocopies of individual passports for 44 young people and leaders, and 38 Parental Consent forms, was lost or mislaid on the return journey from a trip abroad the previous August. We were informed that the Volunteer in charge only became aware of the loss of the documentation in November.
The three pronged approach from this Office when dealing with personal data security breaches is that we expect that the Data Controller,
1. Informs the affected individuals (including what information was disclosed)
2. Secures the data in question and,
3. Informs this Office of steps taken to reduce the risk of a similar incident reoccurring.
As the whereabouts of the documentation was unknown this prevented the data controller from securing the data.
The organisation confirmed that it was arranging immediately to contact the parents to advise them of the loss. As per the provision of the Code of Practice, this allows the individuals to consider the consequences for each of them individually and to take appropriate measures.
This Office queried the reason why the organisation considered it necessary to hold photocopies of the passports. We informed the organisation that we did not consider the photocopying of the passports to be best practice. The organisation confirmed that it too was questioning why passports were being photocopied and was investigating the extent of this practice within the organisation. It put forward the suggestion that perhaps the purpose of photocopying the passports was done as a precaution in case the original passports were lost while abroad. We also informed the organisation that, even if it was in a position to provide a legitimate basis for the photocopying of the passports, the documents should have been destroyed once the trip abroad was over. This procedure would have alerted the Volunteer sooner to the loss of the documents.
The Personal Data Security Breach Code of Practice also provides that, in appropriate cases, data controllers should also notify organisations that may be in a position to assist in protecting data subjects. In this regard, this Office, for the benefit of our own understanding of the matter, contacted the Passport Office, Department of Foreign Affairs. The purpose of our communication with the Passport Office was to seek advice on the potential implications of the loss of a photocopy of a passport and whether this was an issue that should be reported to the Passport Office.
The Passport Office advised that there was a possibility that a photocopy of passport details, if it fell into the wrong hands, could be used to create a duplicate as a fraudulent document. The Passport Office advised that the affected passports could be put on the Department of Foreign Affairs “check list”. This Office understands that this involves the placing of a computer block that means when an individual reapplies for a passport, a double check is carried out on the application.
Our investigation of the data security breach concluded on receipt of confirmation from the organisation that it had written to all the parents advising them of what had been lost. The organisation also informed us that a parents meeting had been held. The organisation also confirmed that it had taken advice from the Department of Foreign Affairs and was preparing guidelines for its groups on the issue of the handling of passports.
This case demonstrates the basic principles of data protection in relation to data security and the requirements under the Data Protection Acts 1988 & 2003 (the Acts), for a data controller to have a clear purpose in relation to the obtaining and retention of personal data. In this instance it was not clear why the local group had photocopied the passports. The Acts provide that the data should be obtained only for one or more specified, explicit and legitimate purposes. The Acts also provide that the data shall not be kept for longer than is necessary for the purpose for which it was initially obtained.
Medical files sent to incorrect email address
The Office received a data security breach notification from a G.P. which reported that an email containing a patient file had been sent to an incorrect recipient. This was the result of a typographical error when entering the email address. The patient file was exported from the software system used by the G.P and attached to the email. The data controller became aware of the matter when the intended recipient contacted the data controller advising that they had not received the email.
The data controller advised our Office that they had notified the affected individual of the matter.
As part of our investigation into the matter, we contacted the software supplier to determine how easy it would be for a third party to access a patient file exported from their system. The software company stated that only an individual with a registered copy of their software could open or access the patient file. The file would have to be imported into the software system to be read. Our Office asked whether there was any other software that could be used to open the file. We were advised that the file could not be opened in a legible format outside of their own software.
The data controller also advised our Office that, as a means of preventing the repeat of such an incident, it proposed that, where it was sending a patient file to another G.P., that the receiving G.P. must first send it an email requesting the patient file. The data controller can then reply directly to the email, ensuring the correct address is used.
The data controller also sought our advice on raising this issue in a public forum as a means of raising awareness of the dangers. We responded by stating we had no objections to such a course of action, provided that no personal data was disclosed.
As our Office was advised by the software company that the email could not be accessed by the recipient, we recorded the matter as a non-breach.
This issue highlights the necessity for sending sensitive data, such as medical data, via a secure means. It shows how easy it is for emails to be issued to an incorrect recipient and without some means of securing the data contained within the email, could be disclosed to an unauthorised party.
Computer affected by Ransomware
Our Office received a notification from a Medical Practitioner that their computer system had been compromised by Ransomware.
Ransomware is a malicious file which is designed to extort money from a user by disabling their computer or encrypting files stored on the computer. The user is then informed that they must pay to have the files restored. There is a risk that after paying the “ransom”, the user will not regain control of their system.
The data controller notified the Office that they were unable to access their computer system, due to the Ransomware that had been installed on their systems. This meant that they were unable to access their patient files. They also advised the Office that they had received a demand for €5,000 in return for the re-instatement of the data. The data controller stated that they had informed An Garda Síochána and had not paid the ransom.
The data controller, on discovering the issue, alerted their IT service provider. After an initial investigation, a third party IT service provider was also employed to help recover the data. During this process, the data controller discovered that backup data for the previous five months had also been compromised. The data controller had therefore lost all patient data obtained in the previous five months.
Our Office contacted the data controller and asked that we speak directly to the IT service provider to determine how the backup tapes going back over a period of five months had been compromised. The IT service provider informed us that there were two separate backup facilities in place. Firstly, there was an on-site hard drive device that was written to each night. Secondly, there was a system of backup tapes in place, which were then stored off-site.
The on-site hard drive had been affected by the Ransomware software. However, it was discovered that the backup media tape system had not actually been recording, but there were no alerts issued by the backup software to identify an issue.
We sought assurance from the IT service provider that the data had not been exported by the Ransomware. The IT service provider stated it had found no evidence to suggest that the data had been taken from the data controller.
It was noted that the data controller had a basic firewall in place and an up-to-date anti virus system. The data controller had also set aside a budget for an upgrade to their computer systems to take place later in the year.
The data controller informed this Office that it was preparing to notify all its patients. We recommended that the notification be directed to those individuals for whom records had been compromised. Any patients who had not attended the practice since the last viable backup tape was created were not affected by the security breach as their records were not compromised.
It was clear that the data controller had installed systems to protect the data under its control and was planning on upgrading the systems. However, it is imperative that, when systems are implemented, they are checked on a regular basis to ensure they are operating correctly.
Case Study 19: Customer had on-line access to third party telephone bill details.
The Office received a breach notification from a telecommunications provider notifying us of a personal data security breach under the provisions of Commission Regulation (EU) No 611/2013 of 2013.
This Regulation imposes a legal obligation on providers of publicly available electronic communications networks or services to notify this Office of a personal data security breach, no later than 24 hours after the detection of the breach, where feasible.
The Service Provider informed us that one of its customers, who was a member of an organisation, while reviewing his telephone bill via the Provider’s on-line facility, noticed that he had access to the details of bills of over 400 other members of the same organisation. On becoming aware of the incident, the Service Provider quickly removed a shared billing code that linked a limited number of accounts related to members of the organisation on the Service Provider’s billing system.
The Service Provider informed us that it was able to confirm from the customer’s log-in details that he had access only to customers’ name, surname, mobile number and six months call records. We were informed that the customer did not have access to the individuals’ financial details or address details.
The root cause of the incident was identified as being a customer service agent applying a shared billing code via the administration systems. We were informed that the agent incorrectly set up the shared billing code resulting in the accounts being linked in error and making the individual who accessed the data the master account holder.
The Service Provider confirmed that it was informing all individuals affected by the incident. The Service Provider also informed the individuals that the matter had been rectified and had ensured that a similar incident would not occur again.
This case demonstrates how the speed at which a breach is identified and dealt with may assist in minimising the overall security risk of the breach. Informing the affected individuals of the matter permits them to consider the consequences for each of them individually and to take appropriate measures as they see fit. The reporting of the matter to us by Data Controllers as speedily as possible, as per the above legislation, also assists in our role of trying to improve compliance with Data Protection legislation.
O2 – Missing media tape
Under the requirements of S.I. 336 of 2011, O2 notified the Office of a data security breach involving a missing backup media tape in July.O2 stated that the tape had been identified as missing by its service provider, IBM, in February. IBM had conducted searches for the missing backup media tape but was unable to locate the tape and notified O2 of the matter in May.In their notification to this Office, O2 stated that the data held on the media tape could only be accessed using the same technical equipment utilised to create the tape, which would cost in excess of €600,000.
We investigated this claim and found evidence contrary to the claim of O2. We then informed O2 of our findings, requested details of the type of data held on the backup media tape, and informed O2 of the need to notify affected individuals.O2 reverted stating that the backup media tape was created in August, 2011 and it no longer held records as to what was held on the media tape. It was therefore not in a position to identify the type of data held on the tape and the affected individuals.
We also sought an explanation as to the delay in notifying our Office of the data security breach. Under the obligations imposed by S.I. 336 of 2011, Telecommunications companies & ISP’s are required to notify both this Office and affected individuals without undue delay. O2 explained that they had not been notified by their service provider of the data security breach until 3 months after the issue was identified. The service provider during this time was carrying out searches for the missing media tape and analysing the potential issues. We informed O2 that this delay was unacceptable.
O2, as part of their report to the Office, provided two separate external forensic analysis reports on the backup media. Both of these reports examined the possibility of a third party gaining access to the data held on the missing media tape. Both reports stated that the data could not be accessed by an individual without access to proper equipment and technical expertise. O2 therefore argued that the data on the media was unintelligible, given the requirements to access the data.
However, this Office pointed out that both external reports supplied by O2 did note that the data could be accessed by a third party with sufficient resources. As the data was potentially accessible, Regulation 4(6)(b) of S.I. 336 of 2011 applied, requiring notification of affected individuals. The appropriate standard to be applied is not whether a member of the public could access the data, but whether the data could be accessed at all.
Whilst O2 disagreed with the views and interpretation of this Office, they agreed, as a matter of goodwill, but without any acknowledgement of liability or failure under the Data Protection Acts or S.I.336, to make a charitable donation and notify customers of the matter. As O2 were unable to identify specifically affected individuals, it was agreed that they would make a public announcement of the matter, via their website and press release. This announcement was made in early December. O2, as a gesture of goodwill, also made a charitable donation of €50,000 to Headstrong, a non-profit organisation supporting young people’s mental health.
To ensure that this type of data security breach did not occur again, O2 had undertaken a number of steps, including improved security and controls regarding the storage of media tapes. The Office also made a number of recommendations to O2, including the encryption of its backup media and that the contract between O2 and its third party service providers be amended to include a requirement for immediate notification of any potential data security breaches.
Stolen Laptops – Phone Companies Prosecuted For Loss of Personal Data
In the first prosecution case of its kind in Ireland, two telecommunications companies, Eircom and Meteor, appeared in the Dublin District Court in September 2012 to face charges relating to the loss of customer personal data which was stored on two unencrypted laptops, which had been stolen several months previously.
Background
A data breach report was received by this Office on 2 February 2012 from Eircom and Meteor. Regulation 4(6) of SI 336 of 2011 obliges telecommunications companies to notify the Data Protection Commissioner of personal data breaches without undue delay. This Regulation also obliges telecommunications companies to notify affected individuals of a data breach where the said breach is likely to adversely affect their personal data or privacy. The breach report informed us that two unencrypted laptops had been stolen from Eircom’s offices at Parkwest in Dublin between 28 December, 2011 and 2 January, 2012.
The report confirmed that the stolen laptops contained information relating to customers, including personal data. It indicated that the number of affected customers were 454 in the case of Meteor and 6,597 in the case of eMobile. The theft of the laptops was discovered on 3 January, 2012 and the matter was reported to the Gardai (national police force) on 4 January, 2012. The breach report was made thirty days after the laptops were reported as stolen. An updated breach report was submitted on 15 March, 2012. This followed intensive contact between ourselves and eircom/Meteor including two meetings on site. The report indicated that, following a second phase of internal investigation, it was found that the number of affected customers was greater than previously reported. The revised figures were 3,944 Meteor customers and 6,295 eMobile customers.
Eircom (trading as eMobile)
6,295 eMobile customers were affected by the data breach. In relation to 142 of these cases, the personal data in question was in the form of customer application forms including proof of identity (e.g. copy of passport, driving licence, national identification, bank account/credit card details, financial statements and utility bills).
The other 6,153 cases contained details such as name, address, telephone and account number. The process of Eircom notifying its affected customers by letter began on 10 February 2012 (38 days after the laptops were reported stolen). A large number of affected customers were notified for the first time on 20 March, 2012 (77 days after the laptops were reported stolen). Letters included an apology to customers for the loss of their personal data. At our request, Eircom notified the banks of the breach via the Irish Banking Federation on 9 February, 2012.
Meteor
3,944 Meteor customers were affected by the data breach. In relation to approx 1,244 of these cases the personal data in question was in the form of proof of identity documents (e.g. copy of passport, driving licence, national identification, Bank Account/Credit Card details, financial statements and utility bills). The other 2,700 cases approx contained details such as name, address and telephone and account number. The process of Meteor notifying its affected customers by letter began on 10 February 2012 (38 days after the laptops were reported stolen). An update of the 10 February, 2012 letter was issued on 20 March, 2012. A large number of affected customers were notified for the first time on 16 March, 2012 (73 days after the laptops were reported stolen). Letters included an apology to customers for the loss of their personal data. At our request, Meteor notified the banks of the breach via the Irish Banking Federation on 9 February, 2012.
Data Security
In relation to the electronic communications services sector, Regulation 4(1) of SI 336 of 2011 places an obligation on providers to take appropriate technical and organisational measures to safeguard the security of their services. Regulation 4(2) details some requirements specific to the electronic communications services sector. It provides that the measures to ensure the level of security shall at least ensure that personal data can be accessed only by authorised personnel for legally authorised purposes, protect personal data stored or transmitted from access or disclosure and ensure the implementation of a security policy with respect to the processing of personal data. We published a comprehensive guidance note on data security on our website in August, 2010.
This included guidance to the effect that encryption is considered an essential security measure where personal data is stored on a portable device or transmitted over a public network. Encryption is the method of converting data from a readable format to an unreadable or unintelligible format so that unauthorised persons are unable to access the data. On a portable device such as a laptop, encrypting data is a method of securing the data to protect it from access by unauthorised persons in the event that the device on which the data is stored comes into the possession of unauthorised persons.
Following this breach, the Eircom Group identified approximately 160 laptops which were not encrypted. All unencrypted laptops were encrypted by 24 February, 2012.
Breach Notification
This Office considers that data breaches of this nature should normally be reported to us within two working days of the data controller becoming aware of the incident. This has been our stated position since a data security breach Code of Practice was published in July 2010. Once we are notified of a breach we can quickly advise the data controller of what steps to take, what areas to focus on, how best to notify affected parties quickly, whether other bodies such as banks need to be informed of the breach, etc. Notification of a data breach to affected individuals quickly is also critical and essential as it allows them to take remedial action to protect themselves and their identities – particularly in cases where financial and identification documentation is stolen.
Court Hearing
At the Dublin District Court on 10 September, 2012 guilty pleas were entered on behalf of each defendant, Eircom and Meteor, in relation to three charges each in respect of offences under Regulation 4(1), Regulation 4(6)(a) and Regulation 4(6)(b) of SI 336 of 2011. These charges related to the failure to protect the personal data on the laptops by means of encryption, the failure to notify the Data Protection Commissioner of the data breach without undue delay and the failure to notify the affected customers of the data breach without undue delay.
After hearing the prosecution evidence, the Court was satisfied that the prosecution case was proven. The Court applied Section 1(1) of the Probation of Offenders Act, conditional upon a charitable donation of €15,000 being made by each Defendant to charities nominated by the Court – the Laura Lynn Foundation in the case of Eircom and Pieta House in the case of Meteor. This Office also recovered from the defendants the legal costs arising from the prosecution.
Credit unions transmitting personal data via unsecured e-mails
I received complaints from two individuals concerning e-mails they had received from two credit unions confirming details about online access to their accounts.
My Office contacted both credit unions for their views on the matter. It transpired that both credit unions were using the same third party vendor to supply their online account facilities.
When a customer registered to use the online facility, they received a confirmation e-mail that contained details about their account, including username, account number and password. A separate letter was sent to their home giving them a PIN number which would allow them to get online access to their credit union account.
Section 2 (1) (d) of the Acts requires that adequate security measures shall be taken against unauthorised access to, or unauthorised alteration, disclosure or destruction of, the data, in particular where the processing involves the transmission of data over a network. My Office entered into discussions with the third party vendor to address this issue.
The vendor’s initial concern was that when people registered, they would not remember their account details when they went to log on to the system at a future date and for this reason they were e-mailing the account details to the customers. As a solution, my Office proposed that when a customer was registering they should be encouraged to print off or otherwise record the details. This would eliminate the need to have confidential information transmitted to them via an unsecured e-mail.
The third party vendor agreed to change its systems to reflect this and to inform all of its clients that it was changing its systems for security reasons.
My Office was also concerned that one of the credit unions was using a free web-based e-mail service as a method of communicating with its customers. My Office took the view that this mode of communication was not adequately secure because the data controller could not adequately control access to the contents of such an e-mail account. The data controller had no record of access to the e-mails, even within their own organisation. My Office instructed the credit union concerned to stop using the free web-based e-mail account as a method of contacting customers. The credit union responded promptly and it changed its email to a more secure system.
This case highlights the need for all data controllers to be aware of the need for appropriate security when processing personal data. If there is a weakness in security, the matter needs to be addressed and a more secure method of providing the service must be established. Although I understand that the purpose of credit unions is to provide services to the community in a cost effective manner, this does not in any way exempt them from ensuring that appropriate steps
Case study 16: Failure to properly safeguard a staff member’s medical certificate
My Office received a complaint from a solicitor on behalf of a data subject whose personal information, contained in a medical certificate, had been accessed in an unauthorised manner while in the possession of her employer.
The data subject was employed by a catering company that had a contract to provide services to the Defence Forces. It was brought to her attention by a member of the Defence Forces that her medical certificate was displayed on a notice board in the office of a Unit Manager in the catering company. This office was shared with a member of the Defence Forces.
Upon receipt of the complaint, my Office contacted the catering company and requested that the medical certificate be removed from the notice board immediately. We also advised the company that a medical certificate, which reveals the health status of a person, is sensitive personal data under the Data Protection Acts. We informed them that, from the information supplied by the data subject, it appeared likely that appropriate security measures were not in place to prevent unauthorised access to the medical certificate.
My Office received a response from the catering company outlining the findings of its investigation into the alleged breach. It explained that the Unit Manager placed the certificate on her personal notice board which hangs directly behind her desk. It was not on view at any time. It was placed behind a number of other documents on the notice board. It alleged that the third party who had accessed the certificate had entered the office without permission and would have had to deliberately seek the certificate. The company informed my Office that it takes its obligations under the Data Protection Acts very seriously and that all personal data relating to employees at any unit is the responsibility of the Unit Manager. Such data is to be held securely in locked cabinets unless required by another department within the business. The company also informed my Office that steps had been taken to remind all managers of their duties when dealing with confidential data.
The main concern for my Office was that the certificate was placed on a notice board in an unlocked office and it was clear that the Unit Manager did not adhere to the company’s security procedures when handling the data subject’s medical certificate. Under Section 10 of the Acts I am mandated to seek an amicable resolution of complaints. To this end my Office requested that the company submit proposals to help achieve an amicable resolution. The company subsequently proposed to make a donation to a charity of the data subject’s choice and it agreed to send a letter of apology to the data subject. The data subject, through her solicitor, accepted this proposal as an amicable resolution of her complaint.
This case demonstrates well the care which data controllers must exercise in the processing of all personal data in its possession, especially sensitive personal data.
Member of staff at Revenue accessing and using personal data of a taxpayer
In January 2007, I received a complaint from a data subject who claimed to have been harassed by the receipt of a large number of anonymous text messages on her mobile phone. Among other things, the text messages referred to various details of personal information related to the data subject and personal information of some of her family members. Prior to referring the matter to my Office, the data subject informed me that she had made a complaint to An Garda Síochána about this matter. She claimed that the Gardaí traced the sender’s number to a particular person to whom she had once been introduced very briefly. The data subject alleged that the sender, who was employed by the Revenue Commissioners, had obtained her personal information and that of her family members by accessing personal files held by the Revenue Commissioners.
My Office began an investigation of this complaint by contacting the Revenue Commissioners. We asked that the audit trail of the relevant files of the individuals concerned be examined to determine if they had been accessed by any staff member who did not have a legitimate business reason for doing so.
Following a prolonged examination, the Revenue Commissioners confirmed in June 2007 that it had been ascertained that one of its officers had accessed the records of the data subject and members of her family during the period November 2006 to February 2007, that such access was not part of the officer’s official duties and that it would appear that information gained from this access was passed to third parties unknown. The Revenue Commissioners stated that the matter was being dealt with by its Personnel Branch under the Civil Service Disciplinary Code. It went on to state that it was seriously concerned about any instances of unauthorised access by its staff to taxpayer data held on its computer systems and that appropriate disciplinary action had been taken and would continue to be taken in individual cases.
Some time later, the Revenue Commissioners issued a letter to the data subject in which it acknowledged that her records and those of her family had been accessed by one of its officers and that the access was not part of the officer’s official duties. The letter sincerely apologised to the data subject for the inappropriate accessing of her records and those of members of her family and it expressed deep regret that this occurred.
I regard this case as a very serious matter. A large amount of personal information is entrusted to the Office of the Revenue Commissioners which has a responsibility to ensure that it is kept safe and secure. A minimum standard of security for such information would include, among other things, that access was restricted to authorised staff on a ‘need to know’ basis. In this case, it emerged that the staff member who accessed the information had no legitimate business in doing so. That staff member abused a position of trust and proceeded to access and use personal information unlawfully. I will await with keen interest the outcome of the disciplinary proceedings which the Revenue Commissioners have commenced under the Civil Service Disciplinary Code in connection with this matter.
Visa application details accidentally put on website of Department of Justice, Equality and Law Reform
A journalist contacted my office with urgent concerns regarding the publication on a website of personal details of visa applicants. I investigated the matter and found that the personal data of visa applicants had been displayed by the Immigration & Citizenship Division of the Department of Justice, Equality & Law Reform on the Department’s website on 6 February, 2003. It appeared that through an unfortunate and accidental breach in operating procedures visa decisions for 506 applicants were posted live on the website with the inadvertent inclusion of the applicants’ name and nationality. The data had been accidentally on the website for about two hours but as soon as the error was noticed the details were deleted.
This situation arose as a result of a decision to revise and improve the visa process. It was considered of benefit to place non-personal visa decision information on the website as it would be of merit to staff and visa applicants to have 24 hour easily accessible information available on the website which would reduce the need for applicants to contact the section. It had been agreed that no personal details would be shown; the only information to be posted would be the visa application number, the decision and, where an application was refused, the reason for the refusal.
Due to an operational oversight, the personal details were included contrary to the Department’s intention. Accordingly, this was a contravention of Section 2(1) (c) of the Acts, being an incompatible disclosure of personal data. Appropriate security measures were inadequate and constituted a contravention of section 2(1) (d) of the Acts.
I note and appreciate that this accidental and unfortunate action was a once off which was swiftly resolved by the immediate action taken by Immigration & Citizenship Division. Nevertheless inappropriate disclosure took place for a short period. I was assured that new procedures were put in place for any future postings on the website which would avoid a recurrence of this incident. I commend the Division for its response.
On a more general level I would strongly advise all data controllers to take special care when it is proposed to place personal data on a website. Even where there is legislation providing that information must be made available to the public, this need not always mean that it is appropriate to place such information on a web site. Consideration must be given to the balance required of the right of the public to certain information and the right of the individual to privacy. Sometimes it may be appropriate to inform the public by means of information on a web site, without disclosing personal details. These rights have to be balanced, and I would encourage data controllers to have procedures in place to ensure that adequate consideration is given to these matters. Furthermore security procedures must be adequate and staff must be aware of and implement them so as to avoid the occurrence of a situation as described in this case study.
Details of other bank account holders of the same name, supplied in response to access request-inadequate response to customer-security procedures-lack of awareness at branch level of data protection
An individual complained to my Office in relation to her bank account as she was concerned about the accuracy and security of the information held and the potential disclosure of her details to other account holders, as there appeared to be confusion regarding her account and that of another account holder of the same name. She informed me that though she had complained to the institution concerned she had encountered difficulty in having the matter resolved. She was advised by my Office to make an access request, under section 4 of the Act, to this major banking group in order to establish what personal data was held about her on computer.
The bank’s initial response to her access request comprised a copy of her data from the particular branch to which she had sent the request, and advised that if she wished to obtain personal details from other areas of the bank, she should write to the offices concerned, enclosing a separate fee with each request. It included a listing of the Bank’s registrations relating to the Public Register of data controllers that is held in my Office.
It then transpired that her personal details as supplied by the Bank, contained a number of inaccuracies, viz. accounts at two other locations, neither of which related to her personally; the date of opening of the account, her marital status, her occupation and credit card details were incorrect; details showed her as having a mortgage which was not the case. She had obtained this information by supplying to her branch in Dublin her name, address and ATM card number only. She was justifiably concerned that her data and that of other customers was being inappropriately disclosed and not kept in a secure manner.
My Office contacted the bank but the investigation encountered considerable difficulty in obtaining an adequate response, as there did not appear to be anybody designated with responsibility to co-ordinate the provision of information in response to the access request. There also appeared to be then a distinct lack of awareness and appreciation of data protection requirements amongst management and staff. Eventually, my Office contacted the Group Compliance Officer. Later my Office was informed that
“Our processing system endeavours to match customers across branches to highlight their entire relationship with the Bank. An error occurred in our system, either human or technical, whereby the customer’s account number was matched to an account in the name of (same customer name) in two other (named) branches, even though they did not meet the required matching criteria. The accounts in both these branches had different account numbers. This was an unfortunate error that should not have happened. We have amended the process with regard to matching customers’ accounts whereby the criteria for matching has been expanded considerably”.
I concluded that important bank account details were not maintained in an accurate and up-to-date fashion and this was highly unsatisfactory from a data protection perspective. It also raised questions about the security of customer’s accounts and improper disclosure of data. I noted the bank’s commitment to expand considerably the criteria for matching, which should ensure that a recurrence of this incident is avoided. I also noted that the Bank was now very much aware of its responsibilities regarding the protection of personal data.
I informed the bank also that many data subjects making access requests might not necessarily be familiar with the requirements of the Act.
Accordingly, I suggested that data subjects be advised in plain language of the procedures in operation for accessing their data in other branches of the organisation as I considered that improvements were necessary in the letter that issued to the complainant.
In general I receive great co-operation from the main financial institutions. While this was a very serious case I trust it was an isolated incident.
Employee performance ratings disclosed to other staff – inadequate security
I received a letter of complaint from a number of employees within a particular company. It appeared that the company had created a computer file setting out performance assessment reports for individual members of staff. The file – of which staff members had been unaware – was accessible throughout the company to a wide range of line managers, including managers who had no role in relation to the staff members in question. The employees were concerned that their data protection rights had been infringed by the unnecessarily widespread dissemination of confidential personnel details, and they asked me to investigate the matter.
On raising the issue with the company, it was explained that the line manager of a particular unit had created a file, setting out performance ratings for staff under his supervision. However, the “access permissions” on this file had inadvertently been set to allow numerous people outside of his management team to read it. A staff member who noticed this problem had brought it to the attention of management, and the file in question was destroyed. The company had also arranged for a formal investigation into the matter, which had concluded that there had been –
a failure to adequately protect and secure sensitive information held on the staff within the particular business unit
insufficient detailed knowledge by managers of the security environment in which the data were held
a failure by the staff member who initially discovered the file to alert the appropriate manager to its existence, as required under various HQ policies and the unit’s own confidentiality statement
subsequent failures by some staff members to prevent ongoing disclosure of the contents of the file.
The company accepted these findings and that a breach of the Data Protection Act, 1988 had occurred in this incident. They acknowledged the need to address these issues, and had put in place the following measures –
an immediate training programme in IT security for all managers and staff, together with regular refresher programmes
all remaining hard- and soft-copies of the file in question to be destroyed as a matter of the utmost urgency, with all company systems swept to confirm this
HQ policies on security should be reissued to all managers and staff
standards for holding sensitive data, both personal and commercial, to be reviewed and published.
As regards my own findings, I accepted that, in an employment context, staff members may not automatically have the option of objecting to their data being used for appraisal purposes – this would naturally depend on conditions of employment and industrial relations norms. However, I concluded that staff should be made fully aware of new appraisal initiatives which involve the use of their personal data, if the ‘fair obtaining’ requirements of section 2(1)(a) of the Act were to be respected. The performance appraisal file in this case had not met these standards, and so its creation entailed a contravention of the Act.
I also confirmed that the failure to implement appropriate access restrictions contravened the security requirements of the Act (section 2(1)(d)), and that the resulting dissemination of the file to other unauthorised staff members amounted to an incompatible disclosure of the personal data (contrary to section 2(1)(c)(ii) of the Act).
However I was pleased to note that the Company had taken immediate and appropriate steps to address the issues involved in this case, particularly in terms of ensuring that appropriate security measures are in place and improving awareness of staff and management regarding the importance of adhering to correct procedures. I believe that this case is a useful reminder of the need for appropriate internal security measures – both as regards the pitfalls, and as regards the correct way to address any deficiencies that are identified. This issue now takes on an added importance with the implementation in Ireland, from 1 April 2002, of the revised security provisions introduced in the European Communities (Data Protection) Regulations, 2001, which have transposed certain provisions of the European Data Protection Directive into Irish law.
Financial institution – Laser card – printing of home address on receipts – incompatible disclosure – adequate security
An individual wrote to me expressing his concern that when using his Laser card – a type of debit card that can be used in shops for cashless transactions – his home address was printed on the receipt slip. Since retailers keep a copy of the receipt slip, the individual felt that his private details were being disclosed unnecessarily by his financial institution, which was responsible for the Laser card.
My Office raised this matter with the financial institution, which responded promptly to the matter. The institution indicated that it had itself received a small number of complaints from customers about this matter. The institution explained that Laser cards issued after October 1999 included the customer’s home address details in the magnetic stripe. However, these details were only supposed to be read by automated lodgement machines, arising from a legal requirement that a receipt – including the address – could be issued to customers using this service. The address details were not supposed to be readable by ordinary point-of-sale (POS) terminals found in shops.
Investigation by the institution revealed that some POS terminals had had their software upgraded to a new version, with the unintended result that the address details were read by the terminal and printed on the receipt. Having established the cause of the matter, the financial institution took the following steps:
Address details were omitted from new Laser cards, in cases where the cardholder did not need to avail of the lodgement facility. In other cases, technical steps were taken to ensure that the address details on new Laser cards could not be printed by POS terminals.
The Laser cardholders affected by this problem were identified, and a roll-out of replacement Laser cards was initiated.
The institution took steps to ensure that, whenever the POS terminal software was upgraded in future, it was made aware of this, so that any possible impact on existing Laser cards could be considered.
I considered these steps to be an appropriate response by the financial institution. The important point to emerge from this case is that personal data, stored in debit cards, credit cards, and indeed in any type of card using a magnetic strip or similar storage mechanism, should be kept secure from inappropriate disclosure, in accordance with the requirements of section 2(1)(d) of the Data Protection Act.
Life insurance company – retention by ex-employee of customer data
unauthorised access – obligation to take appropriate security measures
The complainant was a long-standing customer of a particular life insurance company. One of the company’s representatives, who had in the past been dealing with the customer’s affairs, left the company to join a different company in the same line of business. He subsequently called to the complainant and asked her if she would like to transfer her policies to the company he now represented, or take out new policies with this company. The complainant said that she did not have documents relating to her existing policies to hand. At this, the representative opened his laptop computer and accessed details of her existing policy, notwithstanding the fact that he now represented an entirely different insurance company.
The customer was very unhappy that confidential personal data relating to her insurance were still available to an ex-employee of her insurer who now worked for a competitor. She took the matter up with her insurer but was not satisfied that the breach of confidentiality was treated with the seriousness it deserved. She then wrote to me to complain about the matter.
Section 2(1)(d) of the Data Protection Act, 1988, provides that –
Appropriate security measures shall be taken against unauthorised access to, or alteration, disclosure or destruction of [personal data] and against their accidental loss or destruction.
I wrote to the complainant’s insurer and asked them to comment on the case in the light of this provision. I also asked the company to provide further details on the background to the case and to outline its security arrangements.
The company responded by explaining that the nature of its business (with a direct sales force operating at locations nation-wide) required that the company’s field representatives should have access to client information on laptop computers. Representatives were under clear instructions that, if they left the company’s employment, they should return all company records and documents to their immediate supervisor. Supervisors were under instruction to ensure that this happened. The company said that in the case of the former employee involved in this case, these procedures had not been complied with. Numerous attempts had been made to recover the laptop and the client data from the former employee. However he did not return phone calls or meet with company officials. Attempts to recover the client data were ongoing, according to the company, at the time of the events giving rise to the complaint.
With regard to the requirement to keep personal data secure, the company said that it had put new procedures in place, so that client data would automatically be erased from laptop computers every six weeks, unless a representative’s authorisation was renewed. When these matters were explained by my Office to the complainant, she was reassured that the company was now taking its data protection obligations as regards security seriously and that, accordingly, breaches of confidentiality of the kind she had encountered were unlikely to recur.
In my view, this case illustrates the need for data controllers to have firm and enforceable procedures in place to ensure that they do not lose control of personal data, for which they are legally responsible, on the departure of any of their employees. Provision for the automatic deletion of records, of the kind now put in place by the company, may have a useful part to play in such arrangements.
Employee data – appropriate security measures – disclosure
A large organisation, whose staff are employed at several locations throughout the country, used a central database to record information relating to its employees and their work. The complainant questioned the security arrangements in respect of his personal data, and the extent of access to such data throughout the organisation.
The organisation’s computer system comprised about a hundred personal computers nationwide connected to a central computer in the Dublin head office. Some sixty laptop computers were also provided for use by employees when away from their offices. These laptops contained a version of the organisation’s main database which was downloaded from the main computer and updated periodically. Accordingly, data kept by the organisation on its main database was available to staff in the head office, in the local offices, and at off-site locations.
The complainant, an employee, made his complaint while the computer system was still being developed and implemented by the organisation. He made the following points. First, he alleged there had been a breach of security because the laptops were without any password protection for a period during the development of the system. Second, the complainant objected to certain of his personnel data and details of his work activity being generally available to staff, and argued that such data should only be available to those who needed them to perform their managerial functions.
Section 2(1)(d) of the Data Protection Act provides that “appropriate security measures shall be taken against unauthorised access to, or alteration, disclosure or destruction of, the data and against their accidental loss or destruction.” The question of the security of access to the laptop computers was considered in the light of this provision.
My investigation established that each laptop required use of a password for access to the local version of the database. Where a laptop was establishing a connection to the main computer, another password was needed, and access to the main database itself required the use of a third password. In principle this approach appeared to conform well with the requirements of section 2(1)(d) above. However, the apparent effectiveness of this approach had been compromised. In the interests of simplicity of operation the organisation issued a unique centrally-generated password to each member of staff (so that each staff member would only need to remember one password) thus reducing the effectiveness of the password system as a whole. Furthermore, in the course of training staff on an upgraded version of the software, the password security system was modified to allow trainees ease of access to the system. This modification gave open access to the main database from a number of laptops.
As soon as this fact was discovered, the data controller took steps to rectify the matter. It is not appropriate for a data controller to allow his standards of security to slip, so that personal data becomes more widely accessible than is necessary. However, I noted the prompt action taken by the data controller to put matters right, and – given that my investigation did not discover any evidence of unauthorised access or use of the data during the period when the passwords were not in operation – I did not uphold this part of the complaint.
The second ground for complaint put forward was the alleged wide availability throughout the organisation of details relating to the complainant’s work activities including particulars of annual and sick leave. This raised two separate but related issues: first, whether this wide availability constituted “disclosure” for the purposes of the Data Protection Act; and second, whether the wide availability of data was consistent with the organisation’s duty to take “appropriate security measures … against unauthorised access to, or alteration, disclosure or destruction of, the data and against their accidental loss or destruction.”
On the first question, I noted that the only people with access to the main database were the staff of the data controller. The definition of “disclosure” given in section 1(1) of the Act, specifically states that disclosure “does not include a disclosure made … to an employee … for the purpose of enabling the employee … to carry out his duties”. In my opinion, these words require a data controller to make an assessment, in respect of particular employees, as to whether such employees need to have access to particular holdings of personal data, and to provide accordingly. Thus, one would expect a Human Resources Manager to have access to personal data not necessarily available to the manager of a client database, and vice versa. Data controllers should, in my view, take reasonable steps to prevent personal data from being made available to employees who may have no work-related interest in the data.
On the second question, I consider that sensible restriction of the availability of personal data is one of the “appropriate security measures” that data controllers must consider. The more people who have access to personal data, the greater is the risk of unauthorised access or disclosure. These issues were discussed with the data controller in detail. The organisation explained that the wide availability of personnel information and staff operational details was due in part to business requirements, and in part to the culture and tradition of the organisation. Following discussions, the data controller made a number of significant changes to the computer system, at some expense, in order to restrict access to the personal data of employees. It is my view that, in a case such as this, an appropriate balance must be struck between the concerns of the employee as data subject, the real operational requirements of the organisation and the costs to the organisation. I took the view that, following the changes referred to above, the data controller was compliant with the Act.
EDPB Guidance Design & Default
The European Data Protection Board
Having regard to Article 70 (1e) of the Regulation 2016/679/EU of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC], (hereinafter “GDPR”),
Having regard to the EEA Agreement and in particular to Annex XI and Protocol 37 thereof, as amended by the Decision of the EEA joint Committee No 154/2018 of 6 July 2018,
Having regard to Article 12 and Article 22 of its Rules of Procedure,
HAS ADOPTED THE FOLLOWING GUIDELINES
Executive summary
In an increasingly digital world, adherence to Data Protection by Design and by Default requirements plays a crucial part in promoting privacy and data protection in society. It is therefore essential that controllers take this responsibility seriously and implement the GDPR obligations when designing processing operations.
These Guidelines give general guidance on the obligation of Data Protection by Design and by Default (henceforth “DPbDD”) set forth in Article 25 in the GDPR. DPbDD is an obligation for all controllers, irrespective of size and varying complexity of processing. To be able to implement the requirements of DPbDD, it is crucial that the controller understands the data protection principles and the data subject’s rights and freedoms.
The core obligation is the implementation of appropriate measures and necessary safeguards that provide effective implementation of the data protection principles and, consequentially, data subjects’ rights and freedoms by design and by default. Article 25 prescribes both design and default elements that should be taken into account. Those elements, will be further elaborated in these Guidelines.
Article 25(1) stipulates that controllers should consider DPbDD early on when they plan a new processing operation. Controllers shall implement DPbDD before processing, and also continually at the time of processing, by regularly reviewing the effectiveness of the chosen measures and safeguards. DPbDD also applies to existing systems that are processing personal data.
The Guidelines also contain guidance on how to effectively implement the data protection principles in Article 5, listing key design and default elements as well as practical cases for illustration. The controller should consider the appropriateness of the suggested measures in the context of the particular processing in question.
The EDPB provides recommendations on how controllers, processors and producers can cooperate to achieve DPbDD. It encourages the controllers in industry, processors, and producers to use DPbDD as a means to achieve a competitive advantage when marketing their products towards controllers and data subjects. It also encourages all controllers to make use of certifications and codes of conduct.
1 SCOPE
1. The Guidelines focus on controllers’ implementation of DPbDD based on the obligation in Article 25 of the GDPR.1 Other actors, such as processors and producers of products, services and applications (henceforth “producers”), who are not directly addressed in Article 25, may also find these Guidelines useful in creating GDPR compliant products and services that enable controllers to fulfil their data protection obligations.2 Recital 78 of the GDPR adds that DPbDD should be taken into consideration in the context of public tenders. Despite all controllers having the duty to integrate DPbDD into their processing activities, this provision fosters the adoption of the data protection principles, where public administrations should lead by example. The controller is responsible for the fulfilment of the DPbDD obligations for the processing carried out by their processors and sub-processors, they should therefore take this into account when contracting with these parties.
2. The requirement described in Article 25 is for controllers to have data protection designed into the processing of personal data and as a default setting and this applies throughout the processing lifecycle. DPbDD is also a requirement for processing systems pre-existing before the GDPR entered into force. Controllers must have the processing consistently updated in line with the GDPR. For more information on how to maintain an existing system in line with DPbDD, see subchapter 2.1.4 of these Guidelines. The core of the provision is to ensure appropriate and effective data protection both by design and by default, which means that controllers should be able to demonstrate that they have the appropriate measures and safeguards in the processing to ensure that the data protection principles and the rights and freedoms of data subjects are effective.
3. Chapter 2 of the Guidelines focuses on an interpretation of the requirements set forth by Article 25 and explores the legal obligations introduced by the provision. Examples on how to apply DPbDD in the context of specific data protection principles are provided in Chapter 3.
4. The Guidelines address the possibility to establish a certification mechanism to demonstrate compliance with Article 25 in Chapter 4, as well as how the Article may be enforced by supervisory authorities in Chapter 5. Finally, the Guidelines provide stakeholders with further recommendations on how to successfully implement DPbDD. The EDPB recognizes the challenges for small and medium enterprises (henceforth “SMEs”) to fully comply with the obligations of DPbDD, and provides additional recommendations specifically to SMEs in Chapter 6.
2 ANALYSIS OF ARTICLE 25(1) AND (2) DATA PROTECTION BY DESIGN AND BY DEFAULT
5. The aim of this Chapter is to explore and provide guidance on the requirements to data protection by design in Article 25(1) and to data protection by default in Article 25(2) respectively. Data protection
1 The interpretations provided herein equally apply to Article 20 of Directive (EU) 2016/680, and Article 27 of Regulation 2018/1725.
2 Recital 78 GDPR clearly states this need: “When developing, designing, selecting and using applications, services and products that are based on the processing of personal data or process personal data to fulfil their task, producers of the products, services and applications should be encouraged to take into account the right to data protection when developing and designing such products, services and applications and, with due regard to the “state of the art”, to make sure that controllers and processors are able to fulfil their data protection obligations”.
by design and data protection by default are complementary concepts, which mutually reinforce each other. Data subjects will benefit more from data protection by default if data protection by design is concurrently implemented – and vice versa.
6. DPbDD is a requirement for all controllers, including small businesses and multinational companies alike. That being the case, the complexity of implementing DPbDD may vary based on the individual processing operation. Regardless of the size however, in all cases, positive benefits for controller and data subject can be achieved by implementing DPbDD.
2.1 Article 25(1): Data protection by design
2.1.1 Controller’s obligation to implement appropriate technical and organisational measures and necessary safeguards into the processing
7. In line with Article 25(1) the controller shall implement appropriate technical and organisational measures which are designed to implement the data protection principles and to integrate the necessary safeguards into the processing in order to meet the requirements and protect the rights and freedoms of data subjects. Both appropriate measures and necessary safeguards are meant to serve the same purpose of protecting the rights of data subjects and ensuring that the protection of their personal data is built into the processing.
8. Technical and organizational measures and necessary safeguards can be understood in a broad sense as any method or means that a controller may employ in the processing. Being appropriate means that the measures and necessary safeguards should be suited to achieve the intended purpose, i.e. they must implement the data protection principles effectively3. The requirement to appropriateness is thus closely related to the requirement of effectiveness.
9. A technical or organisational measure and safeguard can be anything from the use of advanced technical solutions to the basic training of personnel. Examples that may be suitable, depending on the context and risks associated with the processing in question, includes pseudonymization of personal data4; storing personal data available in a structured, commonly machine readable format; enabling data subjects to intervene in the processing; providing information about the storage of personal data; having malware detection systems; training employees about basic “cyber hygiene”; establishing privacy and information security management systems, obligating processors contractually to implement specific data minimisation practices, etc.
10. Standards, best practices and codes of conduct that are recognized by associations and other bodies representing categories of controllers can be helpful in determining appropriate measures. However, the controller must verify the appropriateness of the measures for the particular processing in question.
2.1.2 Designed to implement the data protection principles in an effective manner and protecting data subjects’ rights and freedoms
11. The data protection principles are in Article 5 (henceforth “the principles”), the data subjects’ rights and freedoms are the fundamental rights and freedoms of natural persons, and in particular their right to the protection of personal data, whose protection is named in Article 1(2) as the objective of the
3 “Effectiveness” is addressed below in subchapter 2.1.2.
4 Defined in Article 4(5) GDPR.
GDPR (henceforth “the rights”)5. Their precise formulation can be found in the EU Charter of Fundamental Rights. It is essential for the controller to have an understanding of the meaning of the principles and the rights as the basis for the protection offered by the GDPR, specifically by the DPbDD obligation.
12. When implementing the appropriate technical and organisational measures, it is with respect to the effective implementation of each of the aforementioned principles and the ensuing protection of rights that the measures and safeguards should be designed.
Addressing effectiveness
13. Effectiveness is at the heart of the concept of data protection by design. The requirement to implement the principles in an effective manner means that controllers must implement the necessary measures and safeguards to protect these principles, in order to secure the rights of data subjects. Each implemented measure should produce the intended results for the processing foreseen by the controller. This observation has two consequences.
14. First, it means that Article 25 does not require the implementation of any specific technical and organizational measures, rather that the chosen measures and safeguards should be specific to the implementation of data protection principles into the particular processing in question. In doing so, the measures and safeguards should be designed to be robust and the controller should be able to implement further measures in order to scale to any increase in risk6. Whether or not measures are effective will therefore depend on the context of the processing in question and an assessment of certain elements that should be taken into account when determining the means of processing. The aforementioned elements will be addressed below in subchapter 2.1.3.
15. Second, controllers should be able to demonstrate that the principles have been maintained.
16. The implemented measures and safeguards should achieve the desired effect in terms of data protection, and the controller should have documentation of the implemented technical and organizational measures.7 To do so, the controller may determine appropriate key performance indicators (KPI) to demonstrate the effectiveness. A KPI is a measurable value chosen by the controller that demonstrates how effectively the controller achieves their data protection objective. KPIs may be quantitative, such as the percentage of false positives or false negatives, reduction of complaints, reduction of response time when data subjects exercise their rights; or qualitative, such as evaluations of performance, use of grading scales, or expert assessments. Alternatively to KPIs, controllers may be able to demonstrate the effective implementation of the principles by providing the rationale behind their assessment of the effectiveness of the chosen measures and safeguards.
2.1.3 Elements to take into account
17. Article 25 (1) lists elements that the controller has to take into account when determining the measures of a specific processing operation. In the following, we will provide guidance on how to apply
5 See Recital 4 of the GDPR.
6 “Fundamental principles applicable to the controllers (i.e. legitimacy, data minimisation, purpose limitation, transparency, data integrity, data accuracy) should remain the same, whatever the processing and the risks for the data subjects. However, due regard to the nature and scope of such processing have always been an integral part of the application of those principles, so that they are inherently scalable.” Article 29 Working Party. “Statement on the role of a risk-based approach in data protection legal frameworks”. WP 218, 30 May 2014,
p. 3. ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp218_en.pdf
7 See Recitals 74 and 78.
these elements in the design process, which includes design of the default settings. These elements all contribute to determine whether a measure is appropriate to effectively implement the principles. Thus, each of these elements is not a goal in and of themselves, but are factors to be considered together to reach the objective.
2.1.3.1 “state of the art”
18. The concept of “state of the art” is present in various EU acquis, e.g. environmental protection and product safety. In the GDPR, reference to the “state of the art”8 is made not only in Article 32, for security measures,910 but also in Article 25, thus extending this benchmark to all technical and organisational measures embedded in the processing.
19. In the context of Article 25, the reference to “state of the art” imposes an obligation on controllers, when determining the appropriate technical and organisational measures, to take account of the current progress in technology that is available in the market. The requirement is for controllers to have knowledge of, and stay up to date on technological advances; how technology can present data protection risks or opportunities to the processing operation; and how to implement and update the measures and safeguards that secure effective implementation of the principles and rights of data subjects taking into account the evolving technological landscape.
20. The “state of the art” is a dynamic concept that cannot be statically defined at a fixed point in time, but should be assessed continuously in the context of technological progress. In the face of technological advancements, a controller could find that a measure that once provided an adequate level of protection no longer does. Neglecting to keep up to date with technological changes could therefore result in a lack of compliance with Article 25.
21. The “state of the art” criterion does not only apply to technological measures, but also to organisational ones. Lack of appropriate organisational measures can lower or even completely undermine the effectiveness of a chosen technology. Examples of organisational measures can be adoption of internal policies; up-to date training on technology, security and data protection; and IT security governance and management policies.
22. Existing and recognized frameworks, standards, certifications, codes of conduct, etc. in different fields may play a role in indicating the current “state of the art” within the given field of use. Where such standards exist and provide a high level of protection for the data subject in compliance with – or go beyond – legal requirements, controllers should take them into account in the design and implementation of data protection measures.
2.1.3.2 “cost of implementation”
23. The controller may take the cost of implementation into account when choosing and applying appropriate technical and organisational measures and necessary safeguards that effectively
8 See German Federal Constitutional Court’s “Kalkar” decision in 1978: https://germanlawarchive.iuscomp.org/?p=67 may provide the foundation for a methodology for an objective definition of the concept. On that basis, the “state of the art” technology level would be identified between the “existing scientific knowledge and research” technology level and the more established “generally accepted rules of technology”. The “state of the art” can hence be identified as the technology level of a service or technology or product that exists in the market and is most effective in achieving the objectives identified.
9 https://www.enisa.europa.eu/news/enisa-news/what-is-state-of-the-art-in-it-security
10 www.teletrust.de/en/publikationen/broschueren/state-of-the-art-in-it-security/
implement the principles in order to protect the rights of data subjects. The cost refers to resources in general, including time and human resources.
24. The cost element does not require the controller to spend a disproportionate amount of resources when alternative, less resource demanding, yet effective measures exist. However, the cost of implementation is a factor to be considered to implement data protection by design rather than a ground to not implement it.
25. Thus, the chosen measures shall ensure that the processing activity foreseen by the controller does not process personal data in violation of the principles, independent of cost. Controllers should be able to manage the overall costs to be able to effectively implement all of the principles and, consequentially, protect the rights.
2.1.3.3 “nature, scope, context and purpose of processing“
26. Controllers must take into consideration the nature, scope, context and purpose of processing when determining needed measures.
27. These factors should be interpreted consistently with their role in other provisions of the GDPR, such as Articles 24, 32 and 35, with the aim of designing data protection principles into the processing.
28. In short, the concept of nature can be understood as the inherent11 characteristics of the processing. The scope refers to the size and range of the processing. The context relates to the circumstances of the processing, which may influence the expectations of the data subject, while the purpose pertains to the aims of the processing.
2.1.3.4 “risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing”
29. The GDPR adopts a coherent risk based approach in many of its provisions, in Articles 24, 25, 32 and 35, with a view to identifying appropriate technical and organisational measures to protect individuals, their personal data and complying with the requirements of the GDPR. The assets to protect are always the same (the individuals, via the protection of their personal data), against the same risks (to individuals’ rights), taking into account the same conditions (nature, scope, context and purposes of processing).
30. When performing the risk analysis for compliance with Articles 25, the controller has to identify the risks to the rights of data subjects that a violation of the principles presents, and determine their likelihood and severity in order to implement measures to effectively mitigate the identified risks. A systematic and thorough evaluation of the processing is crucial when doing risk assessments. For example, a controller assesses the particular risks associated with a lack of freely given consent, which constitutes a violation of the lawfulness principle, in the course of the processing of personal data of children and young people under 18 as a vulnerable group, in a case where no other legal ground exists, and implements appropriate measures to address and effectively mitigate the identified risks associated with this group of data subjects.
11 Examples are special categories personal data, automatic decision-making, skewed power relations, unpredictable processing, difficulties for the data subject to exercise the rights, etc.
31. The “EDPB Guidelines on Data Protection Impact Assessment (DPIA)”,12 which focus on determining whether a processing operation is likely to result in a high risk to the data subject or not, also provide guidance on how to assess data protection risks and how to carry out a data protection risk assessment. These Guidelines may also be useful during the risk assessment in all the articles mentioned above, including Article 25.
32. The risk based approach does not exclude the use of baselines, best practices and standards. These might provide a useful toolbox for controllers to tackle similar risks in similar situations (nature, scope, context and purpose of processing). Nevertheless, the obligation in Article 25 (as well as Articles 24, 32 and 35(7)(c)) to take into account “risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing” remains. Therefore, controllers, although supported by such tools, must always carry out a data protection risk assessment on a case by case basis for the processing activity at hand and verify the effectiveness of the appropriate measures and safeguards proposed. A DPIA, or an update to an existing DPIA, may then additionally be required.
2.1.4 Time aspect
2.1.4.1 At the time of the determination of the means for processing
33. Data protection by design shall be implemented “at the time of determination of the means for processing”.
34. The “means for processing” range from the general to the detailed design elements of the processing, including the architecture, procedures, protocols, layout and appearance.
35. The “time of determination of the means for processing” refers to the period of time when the controller is deciding how the processing will be conducted and the manner in which the processing will occur and the mechanisms which will be used to conduct such processing. It’s in the process of making such decisions that the controller must assess the appropriate measures and safeguards to effectively implement the principles and rights of data subjects into the processing, and take into account elements such as the state of the art, cost of implementation, nature, scope, context and purpose, and risks. This includes the time of procuring and implementing data processing software, hardware, and services.
36. Early consideration of DPbDD is crucial for a successful implementation of the principles and protection of the rights of the data subjects. Moreover, from a cost-benefit perspective, it is also in controllers’ interest to take DPbDD into account sooner rather than later, as it could be challenging and costly to make later changes to plans that have already been made and processing operations that have already been designed.
2.1.4.2 At the time of the processing itself (maintenance and review of data protection requirements)
37. Once the processing has started the controller has a continued obligation to maintain DPbDD, i.e. the continued effective implementation of the principles in order to protect the rights, staying up to date on the state of the art, reassessing the level of risk, etc. The nature, scope and context of processing operations, as well as the risk may change over the course of processing, which means that the
12 Article 29 Working Party “Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is “likely to result in a high risk” for the purposes of Regulation 2016/679”. WP 248 rev.01, 4 October 2017. ec.europa.eu/newsroom/document.cfm?doc_id=47711 – endorsed by the EDPB.
controller must re-evaluate their processing operations through regular reviews and assessments of the effectiveness of their chosen measures and safeguards.
38. The obligation to maintain, review and update, as necessary, the processing operation also applies to pre-existing systems. This means that legacy systems designed before the GDPR entered into force are required to undergo reviews and maintenance to ensure the implementation of measures and safeguards that implement the principles and rights of data subjects in an effective manner, as outlined in these Guidelines.
39. This obligation also extends to any processing carried out by means of data processors. Processors’ operations should be regularly reviewed and assessed by the controllers to ensure that they enable continuous compliance with the principles and allow the data controller to fulfil its obligations in this respect.
2.2 Article 25(2): Data protection by default
2.2.1 By default, only personal data which are necessary for each specific purpose of the processing are processed
40. A “default”, as commonly defined in computer science, refers to the pre-existing or preselected value of a configurable setting that is assigned to a software application, computer program or device. Such settings are also called “presets” or “factory presets”, especially for electronic devices.
41. Hence, the term “by default” when processing personal data, refers to making choices regarding configuration values or processing options that are set or prescribed in a processing system, such as a software application, service or device, or a manual processing procedure that affect the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility.
42. The controller should choose and be accountable for implementing default processing settings and options in a way that only processing that is strictly necessary to achieve the set, lawful purpose is carried out by default. Here, controllers should rely on their assessment of the necessity of the processing with regards to the legal grounds of Article 6(1). This means that by default, the controller shall not collect more data than is necessary, they shall not process the data collected more than is necessary for their purposes, nor shall they store the data for longer than necessary. The basic requirement is that data protection is built into the processing by default.
43. The controller is required to predetermine for which specified, explicit and legitimate purposes the personal data is collected and processed.13 The measures must by default be appropriate to ensure that only personal data which are necessary for each specific purpose of processing are being processed. The EDPS “Guidelines to assess necessity and proportionality of measures that limit the
13 Art. 5(1)(b), (c), (d), (e) GDPR.
right to data protection of personal data” can be useful also to decide which data is necessary to process in order to achieve a specific purpose.14 15 16
44. If the controller uses third party software or off-the-shelf software, the controller should carry out a risk assessment of the product and make sure that functions that do not have a legal basis or are not compatible with the intended purposes of processing are switched off.
45. The same considerations apply to organisational measures supporting processing operations. They should be designed to process, at the outset, only the minimum amount of personal data necessary for the specific operations. This should be particularly considered when allocating data access to staff with different roles and different access needs.
46. Appropriate “technical and organisational measures” in the context of data protection by default is thus understood in the same way as discussed above in subchapter 2.1.1, but applied specifically to implementing the principle of data minimisation.
47. The aforementioned obligation to only process personal data which are necessary for each specific purpose applies to the following elements.
2.2.2 Dimensions of the data minimisation obligation
48. Article 25 (2) lists the dimensions of the data minimisation obligation for default processing, by stating that the obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility.
2.2.2.1 “amount of personal data collected”
49. Controllers should consider both the volume of personal data, as well as the types, categories and level of detail of personal data required for the processing purposes. Their design choices should take into account the increased risks to the principles of integrity and confidentiality, data minimisation and storage limitation when collecting large amounts of detailed personal data, and compare it to the reduction in risks when collecting smaller amounts and/or less detailed information about data subjects. In any case, the default setting shall not include collection of personal data that is not necessary for the specific processing purpose. In other words, if certain categories of personal data are unnecessary or if detailed data isn’t needed because less granular data is sufficient, then any surplus personal data shall not be collected.
50. The same default requirements apply to services independent of what platform or device in use, only the necessary personal data for the given purpose can be collected.
14 EDPS. “Guidelines on assessing the necessity and proportionality of measures that limit the right to data protection”. 25 February 2019. edps.europa.eu/sites/edp/files/publication/19-02- 25_proportionality_guidelines_en.pdf
15 See also EDPS. “Assessing the necessity of measures that limit the fundamental right to the protection of personal data: A Toolkit” https://edps.europa.eu/data-protection/our-work/publications/papers/necessity- toolkit_en
16 For more information on necessity, see Article 29 Working Party. “Opinion 06/2014 on the notion of legitimate interests of the data controller under Article 7 of Directive 95/46/EC”. WP 217, 9 April 2014. ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp217_en.pdf
2.2.2.2 “the extent of their processing”
51. Processing17 operations performed on personal data shall be limited to what is necessary. Many processing operations may contribute to a processing purpose. Nevertheless, the fact that certain personal data is necessary to fulfil a purpose does not mean that all types of, and frequencies of, processing operations may be carried out on the data. Controllers should also be careful not to extend the boundaries of “compatible purposes” of Article 6(4), and have in mind what processing will be within the reasonable expectations of data subjects.
2.2.2.3 “the period of their storage”
52. Personal data collected shall not be stored if it is not necessary for the purpose of the processing and there is no other compatible purpose and legal ground according to Article 6(4). Any retention should be objectively justifiable as necessary by the data controller in accordance with the accountability principle.
53. The controller shall limit the retention period to what is necessary for the purpose. If personal data is no longer necessary for the purpose of the processing, then it shall by default be deleted or anonymized. The length of the period of retention will therefore depend on the purpose of the processing in question. This obligation is directly related to the principle of storage limitation in Article 5(1)(e), and shall be implemented by default, i.e. the controller should have systematic procedures for data deletion or anonymization embedded in the processing.
54. Anonymization18 of personal data is an alternative to deletion, provided that all the relevant contextual elements are taken into account and the likelihood and severity of the risk, including the risk of re- identification, are regularly assessed.19
2.2.2.4 “their accessibility”
55. The controller should limit who has access and which types of access to personal data based on an assessment of necessity, and also make sure that personal data is in fact accessible to those who need it when necessary, for example in critical situations. Access controls should be observed for the whole data flow during the processing.
56. Article 25(2) further states that personal data shall not be made accessible, without the individual’s intervention, to an indefinite number of natural persons. The controller shall by default limit accessibility and give the data subject the possibility to intervene before publishing or otherwise making available personal data about the data subject to an indefinite number of natural persons.
57. Making personal data available to an indefinite number of persons may result in even further dissemination of the data than initially intended. This is particularly relevant in the context of the Internet and search engines. This means that controllers should by default give data subjects an
17 According to Art. 4(2) GDPR, this includes collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.
18 Article 29 Working Party. “Opinion 05/2014 on Anonymisation Techniques”. WP 216, 10 April 2014. ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf
19 Please see Art. 4(1) GDPR, Recital 26 GDPR, Article 29 Working Party “Opinion 05/2014 on Anonymisation Techniques”. Please also see the subsection on “storage limitation” in section 3 of this document, referring to the need for the controller to ensure the effectiveness of the implemented anonymisation technique(s).
opportunity to intervene before personal data is made available on the open Internet. This is particularly important when it comes to children and vulnerable groups.
58. Depending on the legal grounds for processing, the opportunity to intervene could vary based on the context of the processing. For example, to ask for consent to make the personal data publicly accessible, or to have privacy settings so that data subjects themselves can control public access.
59. Even in the event that personal data is made available publicly with the permission and understanding of a data subject, it does not mean that any other controller with access to the personal data may freely process it themselves for their own purposes – they must have their own legal basis.20
3 IMPLEMENTING DATA PROTECTION PRINCIPLES IN THE PROCESSING OF PERSONAL DATA USING DATA PROTECTION BY DESIGN AND BY DEFAULT
60. In all stages of design of the processing activities, including procurement, tenders, outsourcing, development, support, maintenance, testing, storage, deletion, etc., the controller should take into account and consider the various elements of DPbDD which will be illustrated by examples in this chapter in the context of implementation of the principles.21 22 23
61. Controllers need to implement the principles to achieve DPbDD. These principles include: transparency, lawfulness, fairness, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. These principles are outlined in Article 5 and Recital 39 of the GDPR. To have a complete understanding of how to implement DPbDD, the importance of understanding the meaning of each of the principles is emphasised.
62. When presenting examples of how to operationalize DPbDD we have made lists of key DPbDD elements for each of the principles. The examples, while highlighting the specific data protection principle in question, may overlap with other closely related principles as well. The EDPB underlines that the key elements and the examples presented hereunder are neither exhaustive nor binding, but are meant as guiding elements for each of the principles. Controllers need to assess how to guarantee compliance with the principles in the context of the concrete processing operation in question.
63. While this section focuses on the implementation of the principles, the controller should also implement appropriate and effective ways to protect data subjects’ rights, also according to Chapter III in the GDPR where this is not already mandated by the principles themselves.
64. The accountability principle is overarching: it requires the controller to be responsible choosing the necessary technical and organisational measures.
20 See Case of Satakunnan Markkinapörssi Oy and Satamedia Oy v. Finland no. 931/13.
21 More examples can be found in Norwegian Data Protection Authority. “Software Development with Data Protection by Design and by Default”. 28 November 2017. www.datatilsynet.no/en/about- privacy/virksomhetenes-plikter/innebygd-personvern/data-protection-by-design-and-by-default/?id=7729
22 https://www.cnil.fr/en/cnil-publishes-gdpr-guide-developers
23 https://www.aepd.es/sites/default/files/2019-12/guia-privacidad-desde-diseno_en.pdf
3.1 Transparency
24
65. The controller must be clear and open with the data subject about how they will collect, use and share personal data. Transparency is about enabling data subjects to understand, and if necessary, make use of their rights in Articles 15 to 22. The principle is embedded in Articles 12, 13, 14 and 34. Measures and safeguards put in place to support the principle of transparency should also support the implementation of these Articles.
66. Key design and default elements for the principle of transparency may include:
• Clarity – Information shall be in clear and plain language, concise and intelligible.
• Semantics – Communication should have a clear meaning to the audience in question.
• Accessibility – Information shall be easily accessible for the data subject.
• Contextual – Information should be provided at the relevant time and in the appropriate form.
• Relevance – Information should be relevant and applicable to the specific data subject.
• Universal design – Information shall be accessible to all data subjects, include use of machine readable languages to facilitate and automate readability and clarity.
• Comprehensible – Data subjects should have a fair understanding of what they can expect with regards to the processing of their personal data, particularly when the data subjects are children or other vulnerable groups.
• Multi-channel – Information should be provided in different channels and media, not only the textual, to increase the probability for the information to effectively reach the data subject.
• Layered – The information should be layered in a manner that resolves the tension between completeness and understanding, while accounting for data subjects’ reasonable expectations.
24 Elaboration on how to understand the concept of transparency can be found in Article 29 Working Party. “Guidelines on transparency under Regulation 2016/679”. WP 260 rev.01, 11 April 2018. ec.europa.eu/newsroom/article29/document.cfm?action=display&doc_id=51025 – endorsed by the EDPB
25 The French Data Protection Authority has published several examples illustrating best practices in informing users as well as other transparency principles: https://design.cnil.fr/en/.
3.2 Lawfulness
67. The controller must identify a valid legal basis for the processing of personal data. Measures and safeguards should support the requirement to make sure that the whole processing lifecycle is in line with the relevant legal grounds of processing.
68. Key design and default elements for lawfulness may include:
• Relevance – The correct legal basis shall be applied to the processing.
• Differentiation26 – The legal basis used for each processing activity shall be differentiated.
• Specified purpose – The appropriate legal basis must be clearly connected to the specific purpose of processing.27
• Necessity– Processing must be necessary and unconditional for the purpose to be lawful.
• Autonomy – The data subject should be granted the highest degree of autonomy as possible with respect to control over personal data within the frames of the legal basis.
• Gaining consent – consent must be freely given, specific, informed and unambiguous.28 Particular consideration should be given to the capacity of children and young people to provide informed consent.
• Consent withdrawal – Where consent is the legal basis, the processing should facilitate withdrawal of consent. Withdrawal shall be as easy as giving consent. If not, then the consent mechanism of the controller does not comply with the GDPR.29
• Balancing of interests – Where legitimate interests is the legal basis, the controller must carry out a weighted balancing of interest, giving particular consideration to the power imbalance, specifically children under the age of 18 and other vulnerable groups. There shall be measures and safeguards to mitigate the negative impact on the data subjects.
• Predetermination – The legal basis shall be established before the processing takes place.
• Cessation – If the legal basis ceases to apply, the processing shall cease accordingly.
• Adjust – If there is a valid change of legal basis for the processing, the actual processing must be adjusted in accordance with the new legal basis.30
26 EDPB. “Guidelines 2/2019 on the processing of personal data under Article 6(1)(b) GDPR in the context of the provision of online services to data subjects”. Version 2.0, 8 October 2019. edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines-art_6-1-b- adopted_after_public_consultation_en.pdf
27 See section on purpose limitation below.
28 See Guidelines 05/2020 on consent under Regulation 2016/679. https://edpb.europa.eu/our-work- tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en
29 See Guidelines 05/2020 on consent under Regulation 2016/679, p. 24. https://edpb.europa.eu/our-work- tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en
30 If the original legal basis is consent, see Guidelines 05/2020 on consent under Regulation 2016/679. https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under- regulation-2016679_en
• Allocation of responsibility – Whenever joint controllership is envisaged, the parties must apportion in a clear and transparent way their respective responsibilities vis-à-vis the data subject, and design the measures of the processing in accordance with this allocation.
Example
A bank plans to offer a service to improve efficiency in the management of loan applications. The idea behind the service is that the bank, by requesting permission from the customer, is able to retrieve data about the customer directly from the public tax authorities. This example does not consider processing of personal data from other sources.
Obtaining personal data about the data subject’s financial situation is necessary in order to take steps at the request of the data subject prior to entering into a loan contract.31 However, gathering personal data directly from the tax administration is not considered necessary, because the customer is able to enter into a contract by providing the information from the tax administration him or herself. Although the bank may have a legitimate interest in acquiring the documentation from the tax authorities directly, for example to ensure efficiency in the loan processing, giving banks such direct access to the personal data of applicants presents a risks related to the use or potential misuse of access rights
When implementing the principle of lawfulness, the controller realizes that in this context, they cannot use the “necessary for contract” basis for the part of the processing that involves gathering personal data directly from the tax authorities. The fact that this specific processing presents a risk of the data subject becoming less involved in the processing of their data is also a relevant factor in assessing the lawfulness of the processing itself. The bank concludes that this part of the processing has to rely on another legal basis of processing. In the particular Member State where the controller is located, there are national laws that permits the bank to gather information from the public tax authorities directly, where the data subject consents to this beforehand.
The bank therefore presents information about the processing on the online application platform in such a manner that makes it easy for data subjects to understand what processing is mandatory and what is optional. The processing options, by default, do not allow retrieval of data directly from other sources than the data subject herself, and the option for direct information retrieval is presented in a manner that does not deter the data subject from abstaining. Any consent given to collect data directly from other controllers is a temporary right of access to a specific set of information.
Any given consent is processed electronically in a documentable manner, and data subjects are presented with an easy way of controlling what they have consented to and to withdraw their consent.
The controller has assessed these DPbDD requirements beforehand and includes all of these criteria in their requirements specification for the tender to procure the platform. The controller is aware that if they do not include the DPbDD requirements in the tender, it may either be too late or a very costly process to implement data protection afterwards.
3.3 Fairness
69. Fairness is an overarching principle which requires that personal data should not be processed in a way that is unjustifiably detrimental, unlawfully discriminatory, unexpected or misleading to the data
31 See Article 6(1)(b) GDPR.
subject. Measures and safeguards implementing the principle of fairness also support the rights and freedoms of data subjects, specifically the right to information (transparency), the right to intervene (access, erasure, data portability, rectify) and the right to limit the processing (right not to be subject to automated individual decision-making and non-discrimination of data subjects in such processes).
70. Key design and default fairness elements may include:
• Autonomy – Data subjects should be granted the highest degree of autonomy possible to determine the use made of their personal data, as well as over the scope and conditions of that use or processing.
• Interaction – Data subjects must be able to communicate and exercise their rights in respect of the personal data processed by the controller.
• Expectation – Processing should correspond with data subjects’ reasonable expectations.
• Non-discrimination – The controller shall not unfairly discriminate against data subjects.
• Non-exploitation – The controller should not exploit the needs or vulnerabilities of data subjects.
• Consumer choice – The controller should not “lock in” their users in an unfair manner. Whenever a service processing personal data is proprietary, it may create a lock-in to the service, which may not be fair, if it impairs the data subjects’ possibility to exercise their right of data portability in accordance with Article 20.
• Power balance – Power balance should be a key objective of the controller-data subject relationship. Power imbalances should be avoided. When this is not possible, they should be recognised and accounted for with suitable countermeasures.
• No risk transfer – Controllers should not transfer the risks of the enterprise to the data subjects.
• No deception – Data processing information and options should be provided in an objective and neutral way, avoiding any deceptive or manipulative language or design.
• Respect rights – The controller must respect the fundamental rights of data subjects and implement appropriate measures and safeguards and not impinge on those rights unless expressly justified by law.
• Ethical – The controller should see the processing’s wider impact on individuals’ rights and dignity.
• Truthful – The controller must make available information about how they process personal data, they should act as they declare they will and not mislead the data subjects.
• Human intervention – The controller must incorporate qualified human intervention that is capable of uncovering biases that machines may create in accordance with the right to not be subject to automated individual decision making in Article 22.32
• Fair algorithms – Regularly assess whether algorithms are functioning in line with the purposes and adjust the algorithms to mitigate uncovered biases and ensure fairness in the processing. Data subjects should be informed about the functioning of the processing of personal data based on algorithms that analyse or make predictions about them, such as work performance, economic situation, health, personal preferences, reliability or behaviour, location or movements.33
32 See Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679. https://ec.europa.eu/newsroom/article29/document.cfm?action=display&doc_id=49826
33 See Recital 71 GDPR.
3.4 Purpose Limitation
34
71. The controller must collect data for specified, explicit, and legitimate purposes, and not further process the data in a manner that is incompatible with the purposes for which they were collected.35 The design of the processing should therefore be shaped by what is necessary to achieve the purposes. If any
34 The Article 29 Working Party provided guidance for the understanding of the principle of purpose limitation under Directive 95/46/EC. Although the Opinion is not adopted by the EDBP, it may still be relevant as the wording of the principle is the same under the GDPR. Article 29 Working Party. “Opinion 03/2013 on purpose limitation”. WP 203, 2 April 2013. ec.europa.eu/justice/article-29/documentation/opinion- recommendation/files/2013/wp203_en.pdf
35 Art. 5(1)(b) GDPR.
further processing is to take place, the controller must first make sure that this processing has purposes compatible with the original ones and design such processing accordingly. Whether a new purpose is compatible or not, shall be assessed according to the criteria in Article 6(4).
72. Key design and default purpose limitation elements may include:
• Predetermination – The legitimate purposes shall be determined before the design of the processing.
• Specificity – The purposes shall be specified and explicit as to why personal data is being processed.
• Purpose orientation – The purpose of processing should guide the design of the processing and set processing boundaries.
• Necessity – The purpose determines what personal data is necessary for the processing.
• Compatibility – Any new purpose must be compatible with the original purpose for which the data was collected and guide relevant changes in design.
• Limit further processing – The controller should not connect datasets or perform any further processing for new incompatible purposes.
• Limitations of reuse – The controller should use technical measures, including hashing and encryption, to limit the possibility of repurposing personal data. The controller should also have organisational measures, such as policies and contractual obligations, which limit reuse of personal data.
• Review – The controller should regularly review whether the processing is necessary for the purposes for which the data was collected and test the design against purpose limitation.
Example
The controller processes personal data about its customers. The purpose of the processing is to fulfil a contract, i.e. to be able to deliver goods to the correct address and obtain payment. The personal data stored is the purchase history, name, address, e-mail address and telephone number.
The controller is considering buying a Customer Relationship Management (CRM) product that gathers all the customer data about sales, marketing and customer service in one place. The product gives the opportunity of storing all phone calls, activities, documents, emails and marketing campaigns to get a 360-degree view of the customer. Moreover, the CRM is capable of automatically analysing the customers’ purchasing power by using public information. The purpose of the analysis is to better target advertising activities. Those activities do not form part of the original lawful purpose of the processing.
To be in line with the principle of purpose limitation, the controller requires the provider of the product to map the different processing activities that use personal data to the purposes relevant for the controller.
After receiving the results of the mapping, the controller assesses whether the new marketing purpose and the targeted advertisement purpose are compatible with the original purposes defined when the data was collected, and whether there is a sufficient legal basis for the respective processing. If the assessment does not return a positive answer, the controller shall not proceed to use the respective functionalities. Alternatively, the controller could choose to forego the assessment and simply not make use of the described functionalities of the product.
3.5 Data Minimisation
73. Only personal data that is adequate, relevant and limited to what is necessary for the purpose shall be processed.36 As a result, the controller has to predetermine which features and parameters of processing systems and their supporting functions are permissible. Data minimisation substantiates and operationalises the principle of necessity. In the further processing, the controller should periodically consider whether processed personal data is still adequate, relevant and necessary, or if the data shall be deleted or anonymized.
74. Controllers should first of all determine whether they even need to process personal data for their relevant purposes. The controller should verify whether the relevant purposes can be achieved by processing less personal data, or having less detailed or aggregated personal data or without having to process personal data at all37. Such verification should take place before any processing takes place, but could also be carried out at any point during the processing lifecycle. This is also consistent with Article 11.
75. Minimising can also refer to the degree of identification. If the purpose of the processing does not require the final set of data to refer to an identified or identifiable individual (such as in statistics), but the initial processing does (e.g. before data aggregation), then the controller shall delete or anonymize personal data as soon as identification is no longer needed. Or, if continued identification is needed for other processing activities, personal data should be pseudonymized to mitigate risks for the data subjects’ rights.
76. Key design and default data minimisation elements may include:
• Data avoidance – Avoid processing personal data altogether when this is possible for the relevant purpose.
• Limitation – Limit the amount of personal data collected to what is necessary for the purpose
• Access limitation – Shape the data processing in a way that a minimal number of people need access to personal data to perform their duties, and limit access accordingly.
• Relevance – Personal data should be relevant to the processing in question, and the controller should be able to demonstrate this relevance.
• Necessity – Each personal data category shall be necessary for the specified purposes and should only be processed if it is not possible to fulfil the purpose by other means.
• Aggregation – Use aggregated data when possible.
• Pseudonymization – Pseudonymize personal data as soon as it is no longer necessary to have directly identifiable personal data, and store identification keys separately.
• Anonymization and deletion – Where personal data is not, or no longer necessary for the purpose, personal data shall be anonymized or deleted.
• Data flow – The data flow should be made efficient enough to not create more copies than necessary.
• “State of the art” – The controller should apply up to date and appropriate technologies for data avoidance and minimisation.
36 Art. 5(1)(c) GDPR.
37 Recital 39 GDPR so states: “…Personal data should be processed only if the purpose of the processing could not reasonably be fulfilled by other means.”
3.6 Accuracy
77. Personal data shall be accurate and kept up to date, and every reasonable step shall be taken to ensure that personal data that is inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay.38
78. The requirements should be seen in relation to the risks and consequences of the concrete use of data. Inaccurate personal data could be a risk to the data subjects’ rights and freedoms, for example when leading to a faulty diagnosis or wrongful treatment of a health protocol, or an incorrect image of a person can lead to decisions being made on the wrong basis either manually, using automated decision-making, or through artificial intelligence.
79. Key design and default accuracy elements may include:
• Data source – Sources of personal data should be reliable in terms of data accuracy.
• Degree of accuracy – Each personal data element should be as accurate as necessary for the specified purposes.
• Measurably accurate – Reduce the number of false positives/negatives, for example biases in automated decisions and artificial intelligence.
• Verification – Depending on the nature of the data, in relation to how often it may change, the controller should verify the correctness of personal data with the data subject before and at different stages of the processing (e.g. to age requirements).
• Erasure/rectification – The controller shall erase or rectify inaccurate data without delay. The controller shall in particular facilitate this where the data subjects are or were children and later want to remove such personal data.39
• Error propagation avoidance – Controllers should mitigate the effect of an accumulated error in the processing chain.
38 Art. 5(1)(d) GDPR.
39 Cf. Recital 65.
• Access – Data subjects should be given information about and effective access to personal data in accordance with the GDPR articles 12 to 15 in order to control accuracy and rectify as needed.
• Continued accuracy – Personal data should be accurate at all stages of the processing, tests of accuracy should be carried out at critical steps.
• Up to date – Personal data shall be updated if necessary for the purpose.
• Data design – Use of technological and organisational design features to decrease inaccuracy, for example present concise predetermined choices instead of free text fields.
Example 1
An insurance company wishes to use artificial intelligence (AI) to profile customers buying insurance as a basis for their decision making when calculating the insurance risk. When determining how their AI solutions should be developed, they are determining the means of processing and shall consider data protection by design when choosing an AI application from a vendor and when deciding on how to train the AI.
When determining how to train the AI, the controller should have accurate data to achieve precise results. Therefore, the controller should ensure that the data used to train the AI is accurate.
Granted that they have a valid legal basis to train the AI using personal data from a large subset of their existing customers, the controller chooses a pool of customers that is representative of the population to also avoid bias.
The customer data is then collected from the respective data handling system, including data on the type of insurance, for example health insurance, home insurance, travel insurance, etc. as well as data from public registries they have lawful access to. All data are pseudonymized prior to transfer to the system dedicated to the training of the AI model.
To ensure that the data used for AI training is as accurate as possible, the controller only collects data from data sources with correct and up-to date information.
The insurance company tests whether the AI is reliable and provides non-discriminatory results both during its development and finally before the product is released. When the AI is fully trained and operative, the insurance company uses the results to support the insurance risk assessments, yet without solely relying on the AI to decide whether to grant insurance, unless the decision is made in accordance with the exceptions in Article 22 (2) GDPR.
The insurance company will also regularly review the results from the AI, to maintain the reliability and when necessary adjust the algorithm.
3.7 Storage limitation
80. The controller must ensure that personal data is kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data is processed.40
It is vital that the controller knows exactly what personal data the company processes and why. The purpose of the processing shall be the main criterion to decide in how long personal data shall be stored.
81. Measures and safeguards that implement the principle of storage limitation shall complement the rights and freedoms of the data subjects, specifically, the right to erasure and the right to object.
82. Key design and default storage limitation elements may include:
• Deletion and anonymization – The controller should have clear internal procedures and functionalities for deletion and/or anonymization.
• Effectiveness of anonymization/deletion – The controller shall make sure that it is not possible to re-identify anonymized data or recover deleted data, and should test whether this is possible.
• Automation – Deletion of certain personal data should be automated
• Storage criteria – The controller shall determine what data and length of storage is necessary for the purpose.
• Justification – The controller shall be able to justify why the period of storage is necessary for the purpose and the personal data in question, and be able to disclose the rationale behind, and legal grounds for the retention period.
• Enforcement of retention policies – The controller should enforce internal retention policies and conduct tests of whether the organization practices its policies.
• Backups/logs – Controllers shall determine what personal data and length of storage is necessary for back-ups and logs.
• Data flow – Controllers should beware of the flow of personal data, and the storage of any copies thereof, and seek to limit their “temporary” storage.
40 Art. 5(1)(c) GDPR.
3.8 Integrity and confidentiality
83. The principle of integrity and confidentiality includes protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures. The security of personal data requires appropriate measures designed to prevent and manage data breach incidents; to guarantee the proper execution of data processing tasks, and compliance with the other principles; and to facilitate the effective exercise of individuals’ rights.
84. Recital 78 states that one of the DPbDD measures could consist of enabling the controller to “create and improve security features”. Along with other DPbDD measures, Recital 78 suggests a responsibility on the controllers to continually assess whether it is using the appropriate means of processing at all times and to assess whether the chosen measures actually counter the existing vulnerabilities. Furthermore, controllers should conduct regular reviews of the information security measures that surround and protect personal data, and the procedure for handling data breaches.
85. Key design and default integrity and confidentiality elements may include:
• Information security management system (ISMS) – Have an operative means of managing policies and procedures for information security.
• Risk analysis – Assess the risks against the security of personal data by considering the impact on individuals’ rights and counter identified risks. For use in risk assessment; develop and maintain a comprehensive, systematic and realistic “threat modelling” and an attack surface analysis of the designed software to reduce attack vectors and opportunities to exploit weak points and vulnerabilities.
• Security by design – Consider security requirements as early as possible in the system design and development and continuously integrate and perform relevant tests.
• Maintenance – Regular review and test software, hardware, systems and services, etc. to uncover vulnerabilities of the systems supporting the processing.
• Access control management – Only the authorized personnel who need to should have access to the personal data necessary for their processing tasks, and the controller should differentiate between access privileges of authorized personnel.
o Access limitation (agents) – Shape the data processing in a way that a minimal number of people need access to personal data to perform their duties, and limit access accordingly.
o Access limitation (content) – In the context of each processing operation, limit access to only those attributes per data set that are needed to perform that operation.
Moreover, limit access to data pertaining to those data subjects who are in the remit of the respective employee.
o Access segregation – Shape the data processing in a way that no individual needs comprehensive access to all data collected about a data subject, much less all personal data of a particular category of data subjects.
• Secure transfers – Transfers shall be secured against unauthorized and accidental access and changes.
• Secure storage – Data storage shall be secure from unauthorized access and changes. There should be procedures to assess the risk of centralized or decentralized storage, and what categories of personal data this applies to. Some data may need additional security measures than others or isolation from others.
• Pseudonymization – Personal data and back-ups/logs should be pseudonymized as a security measure to minimise risks of potential data breaches, for example using hashing or encryption.
• Backups/logs – Keep back-ups and logs to the extent necessary for information security, use audit trails and event monitoring as a routine security control. These shall be protected from unauthorised and accidental access and change and reviewed regularly and incidents should be handled promptly.
• Disaster recovery/ business continuity – Address information system disaster recovery and business continuity requirements to restore the availability of personal data following up major incidents.
• Protection according to risk – All categories of personal data should be protected with measures adequate with respect to the risk of a security breach. Data presenting special risks should, when possible, be kept separated from the rest of the personal data.
• Security incident response management – Have in place routines, procedures and resources to detect, contain, handle, report and learn from data breaches.
• Incident management – Controller should have processes in place to handle breaches and incidents, in order to make the processing system more robust. This includes notification procedures, such as management of notification (to the supervisory authority) and information (to data subjects).
3.9 Accountability
41
86. The principle of accountability states that the controller shall be responsible for, and be able to demonstrate compliance with all of the abovementioned principles.
87. The controller needs to be able to demonstrate compliance with the principles. In doing so, the controller may demonstrate the effects of the measures taken to protect the data subjects’ rights, and why the measures are considered to be appropriate and effective. For example, demonstrating why a measure is appropriate to ensure the principle of storage limitation in an effective manner.
88. To be able to process personal data responsibly, the controller should have both the knowledge of and the ability to implement data protection. This entails that the controller should understand their data protection obligations of the GDPR and be able to comply with these obligations.
4 ARTICLE 25(3) CERTIFICATION
89. According to Article 25(3), certification pursuant to Article 42 may be used as an element to demonstrate compliance with DPbDD. Conversely, documents demonstrating compliance with DPbDD may also be useful in a certification process. This means that where a processing operation by a controller or a processor has been certified as per Article 42, supervisory authorities shall take this into account in their assessment of compliance with the GDPR, specifically with regards to DPbDD.
90. When a processing operation by a controller or processor is certified according to Article 42, the elements that contribute to demonstrating compliance with Article 25(1) and (2) are the design processes, i.e. the process of determining the means of processing, the governance and the technical and organizational measures to implement the data protection principles The data protection certification criteria are determined by the certification bodies or certification scheme owners and then approved by the competent supervisory authority or by the EDPB. For further information about certification mechanisms, we refer the reader to the EDPB Guideline on Certification42 and other relevant guidance, as published on the EDPB website.
41 See Recital 74, where controllers are required to demonstrate the effectiveness of their measures.
42 EDPB. “Guidelines 1/2018 on certification and identifying certification criteria in accordance with Articles 42 and 43 of the Regulation”. Version 3.0, 4 June 2019. edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_201801_v3.0_certificationcriteria_annex2_en.pdf
91. Even where a processing operation is awarded a certification in accordance with Article 42, the controller still has the responsibility to continuously monitor and improve compliance with the DPbDD- criteria of Article 25.
5 ENFORCEMENT OF ARTICLE 25 AND CONSEQUENCES
92. Supervisory authorities may assess compliance with Article 25 according to the procedures listed in Article 58. The corrective powers are specified in Article 58(2) and include the issuance of warnings, reprimands, orders to comply with data subjects’ rights, limitations on or ban of processing, administrative fines, etc.
93. DPbDD is further a factor in determining the level of monetary sanctions for breaches of the GDPR, see Article 83(4).43 44
6 RECOMMENDATIONS
94. Although not directly addressed in Article 25, processors and producers are also recognized as key enablers for DPbDD, they should be aware that controllers are required to only process personal data with systems and technologies that have built-in data protection.
95. When processing on behalf of controllers, or providing solutions to controllers, processors and producers should use their expertise to build trust and guide their customers, including SMEs, in designing /procuring solutions that embed data protection into the processing. This means in turn that the design of products and services should facilitate controllers’ needs.
96. It should be kept in mind when implementing Article 25 that the main design objective is the effective implementation of the principles and protection of the rights of data subjects into the appropriate measures of the processing. In order to facilitate and enhance the adoption of DPbDD, we make the following recommendations to controllers as well as producers and processors:
• Controllers should think of data protection from the initial stages of planning a processing operation, even before the time of determination of the means of processing.
• Where the controller has a Data Protection Officer (DPO), the EDPB encourages the active involvement of the DPO to integrate DPbDD in the procurement and development procedures, as well as in the whole processing life-cycle.
• A processing operation may be certified. The ability to get a processing operation certified provides an added value to a controller when choosing between different processing software, hardware, services and/or systems from producers or processors. Therefore, producers should strive to demonstrate DPbDD in the life-cycle of their development of a processing solution. A certification seal may also guide data subjects in their choice between different goods and services. Having the ability to get a processing certified can serve as a competitive advantage for producers, processors and controllers, and even enhances data subjects’ trust in the
43 Article 83(2)(d) GDPR stipulates that in determining the imposition of fines for breach of the GDPR “due regard” shall be taken of “the degree of responsibility of the controller or processor taking into account technical and organisational measures implemented by them pursuant to Articles 25 and 32“.
44 More information on fines can be found in Article 29 Working Party. “Guidelines on application and setting of administrative fines for the purposes of the Regulation 2016/679”. WP 253, 3 October 2017. ec.europa.eu/newsroom/just/document.cfm?doc_id=47889 – endorsed by the EDPB.
processing of their personal data. If no certification is offered, controllers should seek to have other guarantees that producers or processors comply with the requirements of DPbDD.
• Controllers, processors and producers, should consider their obligations to provide children under 18 and other vulnerable groups with specific protection in complying with DPbDD.
• Producers and processors should seek to facilitate DPbDD implementation in order to support the controller’s ability to comply with Article 25 obligations. Controllers, on the other hand, should not choose producers or processors who do not offer systems enabling or supporting the controller to comply with Article 25, because controllers will be held accountable for the lack of implementation thereof.
• Producers and processors should play an active role in ensuring that the criteria for the “state of the art” are met, and notify controllers of any changes to the “state of the art” that may affect the effectiveness of the measures they have in place. Controllers should include this requirement as a contractual clause to make sure they are kept up to date.
• The EDPB recommends controllers to require that producers and processors demonstrate how their hardware, software, services or systems enable the controller to comply with the requirements to accountability in accordance with DPbDD, for example by using key performance indicators to demonstrate the effectiveness of the measures and safeguards at implementing the principles and rights.
• The EDPB emphasizes the need for a harmonized approach to implement principles and rights in an effective manner and encourages associations or bodies preparing codes of conduct in accordance with Article 40 to also incorporate sector-specific guidance on DPbDD.
• Controllers should be fair to data subjects and transparent on how they assess and demonstrate effective DPbDD implementation, in the same manner as controllers demonstrate compliance with the GDPR under the principle of accountability.
• Privacy-enhancing technologies (PETs) that have reached the state-of-the-art maturity can be employed as a measure in accordance with the DPbDD requirements if appropriate in a risk based approach. PETs in themselves do not necessarily cover the obligations of Article 25. Controllers shall assess whether the measure is appropriate and effective in implementing the data protection principles and the rights of data subjects.
• Existing legacy systems are under the same DPbDD-obligations as new systems. If legacy systems do not already comply with DPbDD, and changes cannot be made to comply with the obligations, then the legacy system simply does not meet GDPR-obligations and cannot be used to process personal data.
• Article 25 does not lower the threshold of requirements for SMEs. The following points may facilitate SMEs’ compliance with Article 25:
o Do early risk assessments
o Start with small processing – then scale its scope and sophistication later
o Look for producer and processor guarantees of DPbDD, such as certification and adherence to code of conducts
o Use partners with a good track record
o Talk with DPAs
o Read guidance from DPAs and the EDPB
o Adhere to codes of conduct where available
o Get professional help and advice
For the European Data Protection Board The Chair
(Andrea Jelinek)
EDPB Breach Notification
Having regard to Article 70(1)(e) and (l) of the Regulation 2016/679/EU of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC, (hereinafter “GDPR”),
Having regard to the EEA Agreement and in particular to Annex XI and Protocol 37 thereof, as amended by the Decision of the EEA joint Committee No 154/2018 of 6 July 20181,
Having regard to Article 12 and Article 22 of its Rules of Procedure,
Having regard to the Article 29 Working Party Guidelines on Personal data breach notification under Regulation 2016/679, WP250 rev.01,
HAS ADOPTED THE FOLLOWING GUIDELINES
0 PREFACE
1. On 3 October 2017, the Working Party 29 (hereinafter “WP29”) adopted its Guidelines on Personal data breach notification under Regulation 2016/679 (WP250 rev.01)2, which were endorsed by the European Data Protection Board (hereinafter “EDPB”) at its first Plenary meeting3. This document is a slightly updated version of those guidelines. Any reference to the WP29 Guidelines on Personal data breach notification under Regulation 2016/679 (WP250 rev.01) should, from now on, be interpreted as a reference to these EDPB Guidelines 9/2022.
2. The EDPB noticed that there was a need to clarify the notification requirements concerning the personal data breaches at non-EU establishments. The paragraph concerning this matter has been revised and updated, while the rest of the document was left unchanged, except for editorial changes. The revision concerns, more specifically, paragraph 73 in Section II.C.2 of this document.
INTRODUCTION
3. The GDPR introduced the requirement for a personal data breach (henceforth “breach”) to be notified to the competent national supervisory authority4 (or in the case of a cross-border breach, to the lead authority) and, in certain cases, to communicate the breach to the individuals whose personal data have been affected by the breach.
4. Obligations to notify in cases of breaches existed for certain organisations, such as providers of publicly-available electronic communications services (as specified in Directive 2009/136/EC and Regulation (EU) No 611/2013)5. There were also some Member States that already had their own
1 References to “Member States” made throughout this document should be understood as references to “EEA Member States”.
2 WP29 Guidelines on Personal data breach notification under Regulation 2016/679 (WP250 rev.01) (last revised and updated on 6 February 2018), available at https://ec.europa.eu/newsroom/article29/items/612052.
3 See https://edpb.europa.eu/news/news/2018/endorsement-gdpr-wp29-guidelines-edpb_en.
4 See Article 4(21) GDPR.
5 See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32009L0136 and http://eur- lex.europa.eu/legalcontent/EN/TXT/?uri=CELEX%3A32013R0611
national breach notification obligation. This might included the obligation to notify breaches involving categories of controllers in addition to providers of publicly available electronic communication services (for example in Germany and Italy), or an obligation to report all breaches involving personal data (such as in the Netherlands). Other Member States might had relevant Codes of Practice (for example, in Ireland6). Whilst a number of EU data protection authorities encouraged controllers to report breaches, the Data Protection Directive 95/46/EC7, which the GDPR replaced, did not contain a specific breach notification obligation and therefore such a requirement was new for many organisations. The GDPR makes notification mandatory for all controllers unless a breach is unlikely to result in a risk to the rights and freedoms of individuals8. Processors also have an important role to play and they must notify any breach to their controller9.
5. The EDPB considers that the notification requirement has a number of benefits. When notifying the supervisory authority, controllers can obtain advice on whether the affected individuals need to be informed. Indeed, the supervisory authority may order the controller to inform those individuals about the breach10. Communicating a breach to individuals allows the controller to provide information on the risks presented as a result of the breach and the steps those individuals can take to protect themselves from its potential consequences. The focus of any breach response plan should be on protecting individuals and their personal data. Consequently, breach notification should be seen as a tool enhancing compliance in relation to the protection of personal data. At the same time, it should be noted that failure to report a breach to either an individual or a supervisory authority may mean that under Article 83 GDPR a possible sanction is applicable to the controller.
6. Controllers and processors are therefore encouraged to plan in advance and put in place processes to be able to detect and promptly contain a breach, to assess the risk to individuals 11, and then to determine whether it is necessary to notify the competent supervisory authority, and to communicate the breach to the individuals concerned when necessary. Notification to the supervisory authority should form a part of that incident response plan.
7. The GDPR contains provisions on when a breach needs to be notified, and to whom, as well as what information should be provided as part of the notification. Information required for the notification can be provided in phases, but in any event controllers should act on any breach in a timely manner.
8. In its Opinion 03/2014 on personal data breach notification12, WP29 provided guidance to controllers in order to help them to decide whether to notify data subjects in case of a breach. The opinion considered the obligation of providers of electronic communications regarding Directive 2002/58/EC and provided examples from multiple sectors, in the context of the then draft GDPR, and presented good practices for all controllers.
9. The current Guidelines explain the mandatory breach notification and communication requirements of the GDPR and some of the steps controllers and processors can take to meet these obligations. They
6 See https://www.dataprotection.ie/docs/Data_Security_Breach_Code_of_Practice/1082.htm
7 See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:31995L0046
8 The rights enshrined in the Charter of Fundamental Rights of the EU, available at http://eurlex.europa.eu/legal- content/EN/TXT/?uri=CELEX:12012P/TXT
9 See Article 33(2) GDPR. This is similar in concept to Article 5 of Regulation (EU) No 611/2013 which states that a provider that is contracted to deliver part of an electronic communications service (without having a direct contractual relationship with subscribers) is obliged to notify the contracting provider in the event of a personal data breach.
10 See Articles 34(4) and 58(2)(e) GDPR.
11 This can be ensured under the monitoring and review requirement of a DPIA, which is required for processing operations likely to result in a high risk to the rights and freedoms of natural persons (Article 35(1) and (11).
12 See WP29 Opinion 03/2014 on Personal Data Breach Notification http://ec.europa.eu/justice/data- protection/article29/documentation/opinion-recommendation/files/2014/wp213_en.pdf
also give examples of various types of breaches and who would need to be notified in different scenarios.
I. PERSONAL DATA BREACH NOTIFICATION UNDER THE GDPR
A. Basic security considerations
10. One of the requirements of the GDPR is that, by using appropriate technical and organisational measures, personal data shall be processed in a manner to ensure the appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage13.
11. Accordingly, the GDPR requires both controllers and processors to have in place appropriate technical and organisational measures to ensure a level of security appropriate to the risk posed to the personal data being processed. They should take into account the state of the art, the costs of implementation and the nature, the scope, context and purposes of processing, as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons14. Also, the GDPR requires all appropriate technological protection an organisational measures to be in place to establish immediately whether a breach has taken place, which then determines whether the notification obligation is engaged 15.
12. Consequently, a key element of any data security policy is being able, where possible, to prevent a breach and, where it nevertheless occurs, to react to it in a timely manner.
B. What is a personal data breach?
1. Definition
13. As part of any attempt to address a breach the controller should first be able to recognise one. The GDPR defines a “personal data breach” in Article 4(12) as:
14. What is meant by “destruction” of personal data should be quite clear: this is where the data no longer exists, or no longer exists in a form that is of any use to the controller. “Damage” should also be relatively clear: this is where personal data has been altered, corrupted, or is no longer complete. In terms of “loss” of personal data, this should be interpreted as the data may still exist, but the controller has lost control or access to it, or no longer has it in its possession. Finally, unauthorised or unlawful processing may include disclosure of personal data to (or access by) recipients who are not authorised to receive (or access) the data, or any other form of processing which violates the GDPR.
15. What should be clear is that a breach is a type of security incident. However, as indicated by Article 4(12), the GDPR only applies where there is a breach of personal data. The consequence of such a breach is that the controller will be unable to ensure compliance with the principles relating to the
13 See Articles 5(1)(f) and 32 GDPR.
14 Article 32; see also Recital 83 GDPR.
15 See Recital 87 GDPR.
processing of personal data as outlined in Article 5 GDPR. This highlights the difference between a security incident and a personal data breach – in essence, whilst all personal data breaches are security incidents, not all security incidents are necessarily personal data breaches16.
16. The potential adverse effects of a breach on individuals are considered below.
2. Types of personal data breaches
17. In its Opinion 03/2014 on breach notification, WP29 explained that breaches can be categorised according to the following three well-known information security principles17:
• “Confidentiality breach” – where there is an unauthorised or accidental disclosure of, or access to, personal data.
• “Integrity breach” – where there is an unauthorised or accidental alteration of personal data.
• “Availability breach” – where there is an accidental or unauthorised loss of access 18 to, or destruction of, personal data.
18. It should also be noted that, depending on the circumstances, a breach can concern confidentiality, integrity and availability of personal data at the same time, as well as any combination of these.
19. Whereas determining if there has been a breach of confidentiality or integrity is relatively clear, whether there has been an availability breach may be less obvious. A breach will always be regarded as an availability breach when there has been a permanent loss of, or destruction of, personal data.
20. The question may be asked whether a temporary loss of availability of personal data should be considered as a breach and, if so, one which needs to be notified. Article 32 GDPR, “security of processing”, explains that when implementing technical and organisational measures to ensure a level of security appropriate to the risk, consideration should be given, amongst other things, to “the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and
16 It should be noted that a security incident is not limited to threat models where an attack is made on an organisation from an external source, but includes incidents from internal processing that breach security principles.
17 See WP29 Opinion 03/2014.
18 It is well established that “access” is fundamentally part of “availability”. See, for example, NIST SP80053rev4, which defines “availability” as: “Ensuring timely and reliable access to and use of information,” available at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf. CNSSI-4009 also refers to: “Timely, reliable access to data and information services for authorized users”. See https://rmf.org/wpcontent/uploads/2017/10/CNSSI-4009.pdf. ISO/IEC 27000:2016 also defines “availability” as “Property of being accessible and usable upon demand by an authorized entity”: https://www.iso.org/obp/ui/#iso:std:isoiec:27000:ed-4:v1:en
services,” and “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident”.
21. Therefore, a security incident resulting in personal data being made unavailable for a period of time is also a type of breach, as the lack of access to the data can have a significant impact on the rights and freedoms of natural persons. To be clear, where personal data is unavailable due to planned system maintenance being carried out this is not a ‘breach of security’ as defined in Article 4(12) GDPR.
22. As with a permanent loss or destruction of personal data (or indeed any other type of breach), a breach involving the temporary loss of availability should be documented in accordance with Article 33(5) GDPR. This assists the controller in demonstrating accountability to the supervisory authority, which may ask to see those records19. However, depending on the circumstances of the breach, it may or may not require notification to the supervisory authority and communication to affected individuals. The controller will need to assess the likelihood and severity of the impact on the rights and freedoms of natural persons as a result of the lack of availability of personal data. In accordance with Article 33 GDPR, the controller will need to notify unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. Of course, this will need to be assessed on a case-by-case basis.
23. It should be noted that although a loss of availability of a controller’s systems might be only temporary and may not have an impact on individuals, it is important for the controller to consider all possible consequences of a breach, as it may still require notification for other reasons.
3. The possible consequences of a personal data breach
24. A breach can potentially have a range of significant adverse effects on individuals, which can result in physical, material, or non-material damage. The GDPR explains that this can include loss of control over their personal data, limitation of their rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, and loss of confidentiality of personal data protected by professional secrecy. It can also include any other significant economic or social disadvantage to those individuals20.
25. Accordingly, the GDPR requires the controller to notify a breach to the competent supervisory authority, unless it is unlikely to result in a risk of such adverse effects taking place. Where there is a
19 See Article 33(5) GDPR.
20 See also Recitals 85 and 75 GDPR.
likely high risk of these adverse effects occurring, the GDPR requires the controller to communicate the breach to the affected individuals as soon as is reasonably feasible21.
26. The importance of being able to identify a breach, to assess the risk to individuals, and then notify if required, is emphasised in Recital 87 of the GDPR:
27. Further guidelines on assessing the risk of adverse effects to individuals are considered in section IV.
28. If controllers fail to notify either the supervisory authority or data subjects of a data breach or both even though the requirements of Articles 33 and/or 34 GDPR are fulfilled, then the supervisory authority is presented with a choice that must include consideration of all of the corrective measures at its disposal, which would include consideration of the imposition of the appropriate administrative fine22, either accompanying a corrective measure under Article 58(2) GDPR or on its own. Where an administrative fine is chosen, its value can be up to 10,000,000 EUR or up to 2 % if the total worldwide annual turnover of an undertaking under Article 83(4)(a) of the GDPR. It is also important to bear in mind that in some cases, the failure to notify a breach could reveal either an absence of existing security measures or an inadequacy of the existing security measures. The WP29 Guidelines on administrative fines state: “The occurrence of several different infringements committed together in any particular single case means that the supervisory authority is able to apply the administrative fines at a level which is effective, proportionate and dissuasive within the limit of the gravest infringement”. In that case, the supervisory authority will also have the possibility to issue sanctions for failure to notify or communicate the breach (Articles 33 and 34 GDPR) on the one hand, and absence of (adequate) security measures (Article 32 GDPR) on the other hand, as they are two separate infringements.
II. ARTICLE 33 – NOTIFICATION TO THE SUPERVISORY AUTHORITY
A. When to notify
1. Article 33 requirements
29. Article 33(1) GDPR provides that:
30. Recital 87 GDPR states23:
21 See also Recital 86 GDPR.
22 For further details, please see WP29 Guidelines on the application and setting of administrative fines, available here: http://ec.europa.eu/newsroom/just/document.cfm?doc_id=47889
23 Recital 85 GDPR is also important here.
2. When does a controller become “aware”?
31. As detailed above, the GDPR requires that, in the case of a breach, the controller shall notify the breach without undue delay and, where feasible, not later than 72 hours after having become aware of it. This may raise the question of when a controller can be considered to have become “aware” of a breach. The EDPB considers that a controller should be regarded as having become “aware” when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised.
32. However, as indicated earlier, the GDPR requires the controller to implement all appropriate technical protection and organisational measures to establish immediately whether a breach has taken place and to inform promptly the supervisory authority and the data subjects. It also states that the fact that the notification was made without undue delay should be established taking into account in particular the nature and gravity of the breach and its consequences and adverse effects for the data subject24. This puts an obligation on the controller to ensure that they will be “aware” of any breaches in a timely manner so that they can take appropriate action.
33. When, exactly, a controller can be considered to be “aware” of a particular breach will depend on the circumstances of the specific breach. In some cases, it will be relatively clear from the outset that there has been a breach, whereas in others, it may take some time to establish if personal data have been compromised. However, the emphasis should be on prompt action to investigate an incident to determine whether personal data have indeed been breached, and if so, to take remedial action and notify if required.
24 See Recital 87 GDPR.
34. After first being informed of a potential breach by an individual, a media organisation, or another source, or when it has itself detected a security incident, the controller may undertake a short period of investigation in order to establish whether or not a breach has in fact occurred. During this period of investigation the controller may not be regarded as being “aware”. However, it is expected that the initial investigation should begin as soon as possible and establish with a reasonable degree of certainty whether a breach has taken place; a more detailed investigation can then follow.
35. Once the controller has become aware, a notifiable breach must be notified without undue delay, and where feasible, not later than 72 hours. During this period, the controller should assess the likely risk to individuals in order to determine whether the requirement for notification has been triggered, as well as the action(s) needed to address the breach. However, a controller may already have an initial assessment of the potential risk that could result from a breach as part of a data protection impact assessment (DPIA)25 made prior to carrying out the processing operation concerned. However, the DPIA may be more generalised in comparison to the specific circumstances of any actual breach, and so in any event an additional assessment taking into account those circumstances will need to be made. For more detail on assessing risk, see section IV.
36. In most cases these preliminary actions should be completed soon after the initial alert (i.e. when the controller or processor suspects there has been a security incident which may involve personal data.) – it should take longer than this only in exceptional cases.
37. The controller should therefore have internal processes in place to be able to detect and address a breach. For example, for finding some irregularities in data processing the controller or processor may use certain technical measures such as data flow and log analysers, from which is possible to define events and alerts by correlating any log data26. It is important that when a breach is detected it is reported upwards to the appropriate level of management so it can be addressed and, if required, notified in accordance with Article 33 and, if necessary, Article 34. Such measures and reporting mechanisms could be detailed in the controller’s incident response plans and/or governance arrangements. These will help the controller to plan effectively and determine who has operational responsibility within the organisation for managing a breach and how or whether to escalate an incident as appropriate.
38. The controller should also have in place arrangements with any processors the controller uses, which themselves have an obligation to notify the controller in the event of a breach (see below).
25 See WP29 Guidelines WP248 on DPIAs here: http://ec.europa.eu/newsroom/document.cfm?doc_id=44137
26 It should be noted that log data facilitating auditability of, e.g., storage, modifications or erasure of data may also qualify as personal data relating to the person who initiated the respective processing operation.
39. Whilst it is the responsibility of controllers and processors to put in place suitable measures to be able to prevent, react and address a breach, there are some practical steps that should be taken in all cases.
• Information concerning all security-related events should be directed towards a responsible person or persons with the task of addressing incidents, establishing the existence of a breach and assessing risk.
• Risk to individuals as a result of a breach should then be assessed (likelihood of no risk, risk or high risk), with relevant sections of the organisation being informed.
• Notification to the supervisory authority, and potentially communication of the breach to the affected individuals should be made, if required.
• At the same time, the controller should act to contain and recover the breach. Documentation of the breach should take place as it develops.
40. Accordingly, it should be clear that there is an obligation on the controller to act on any initial alert and establish whether or not a breach has, in fact, occurred. This brief period allows for some investigation, and for the controller to gather evidence and other relevant details. However, once the controller has established with a reasonable degree of certainty that a breach has occurred, if the conditions in Article 33(1) GDPR have been met, it must then notify the supervisory authority without undue delay and, where feasible, not later than 72 hours27. If a controller fails to act in a timely manner and it becomes apparent that a breach did occur, this could be considered as a failure to notify in accordance with Article 33 GDPR.
41. Article 32 GDPR makes clear that the controller and processor should have appropriate technical and organisational measures in place to ensure an appropriate level of security of personal data: the ability to detect, address, and report a breach in a timely manner should be seen as essential elements of these measures.
3. Joint controllers
42. Article 26 GDPR concerns joint controllers and specifies that joint controllers shall determine their respective responsibilities for compliance with the GDPR28. This will include determining which party will have responsibility for complying with the obligations under Articles 33 and 34 GDPR. The EDPB recommends that the contractual arrangements between joint controllers include provisions that determine which controller will take the lead on, or be responsible for, compliance with the GDPR’s breach notification obligations.
4. Processor obligations
43. The controller retains overall responsibility for the protection of personal data, but the processor has an important role to play to enable the controller to comply with its obligations; and this includes breach notification. Indeed, Article 28(3) GDPR specifies that the processing by a processor shall be governed by a contract or other legal act. Article 28(3)(f) states that the contract or other legal act shall stipulate that the processor “assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor”.
44. Article 33(2) GDPR makes it clear that if a processor is used by a controller and the processor becomes aware of a breach of the personal data it is processing on behalf of the controller, it must notify the controller “without undue delay”. It should be noted that the processor does not need to first assess the likelihood of risk arising from a breach before notifying the controller; it is the controller that must make this assessment on becoming aware of the breach. The processor just needs to establish whether
27 See Regulation No 1182/71 determining the rules applicable to periods, dates and time limits, available at: http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:31971R1182&from=EN
28 See also Recital 79 GDPR.
a breach has occurred and then notify the controller. The controller uses the processor to achieve its purposes; therefore, in principle, the controller should be considered as “aware” once the processor has informed it of the breach. The obligation on the processor to notify its controller allows the controller to address the breach and to determine whether or not it is required to notify the supervisory authority in accordance with Article 33(1) and the affected individuals in accordance with Article 34(1). The controller might also want to investigate the breach, as the processor might not be in a position to know all the relevant facts relating to the matter, for example, if a copy or backup of personal data destroyed or lost by the processor is still held by the controller. This may affect whether the controller would then need to notify.
45. The GDPR does not provide an explicit time limit within which the processor must alert the controller, except that it must do so “without undue delay”. Therefore, the EDPB recommends the processor promptly notifies the controller, with further information about the breach provided in phases as more details become available. This is important in order to help the controller to meet the requirement of notification to the supervisory authority within 72 hours.
46. As is explained above, the contract between the controller and processor should specify how the requirements expressed in Article 33(2) should be met in addition to other provisions in the GDPR. This can include requirements for early notification by the processor that in turn support the controller’s obligations to report to the supervisory authority within 72 hours.
47. Where the processor provides services to multiple controllers that are all affected by the same incident, the processor will have to report details of the incident to each controller.
48. A processor could make a notification on behalf of the controller, if the controller has given the processor the proper authorisation and this is part of the contractual arrangements between controller and processor. Such notification must be made in accordance with Article 33 and 34 GDPR. However, it is important to note that the legal responsibility to notify remains with the controller.
B. Providing information to the supervisory authority
1. Information to be provided
49. When a controller notifies a breach to the supervisory authority, Article 33(3) GDPR states that, at the minimum, it should:
50. The GDPR does not define categories of data subjects or personal data records. However, the EDPB suggests categories of data subjects to refer to the various types of individuals whose personal data has been affected by a breach: depending on the descriptors used, this could include, amongst others, children and other vulnerable groups, people with disabilities, employees or customers. Similarly, categories of personal data records can refer to the different types of records that the controller may process, such as health data, educational records, social care information, financial details, bank account numbers, passport numbers and so on.
51. Recital 85 GDPR makes it clear that one of the purposes of notification is limiting damage to individuals. Accordingly, if the types of data subjects or the types of personal data indicate a risk of particular damage occurring as a result of a breach (e.g. identity theft, fraud, financial loss, threat to professional secrecy), then it is important the notification indicates these categories. In this way, it is linked to the requirement of describing the likely consequences of the breach.
52. Where precise information is not available (e.g. exact number of data subjects affected) this should not be a barrier to timely breach notification. The GDPR allows for approximations to be made in the number of individuals affected and the number of personal data records concerned. The focus should be directed towards addressing the adverse effects of the breach rather than providing precise figures.
53. Thus, when it has become clear that here has been a breach, but the extent of it is not yet known, a notification in phases (see below) is a safe way to meet the notification obligations.
54. Article 33(3) GDPR states that the controller “shall at least” provide this information with a notification, so a controller can, if necessary, choose to provide further details. Different types of breaches (confidentiality, integrity or availability) might require further information to be provided to fully explain the circumstances of each case.
55. In any event, the supervisory authority may request further details as part of its investigation into a breach.
2. Notification in phases
56. Depending on the nature of a breach, further investigation by the controller may be necessary to establish all of the relevant facts relating to the incident. Article 33(4) GDPR therefore states:
57. This means that the GDPR recognises that controllers will not always have all of the necessary information concerning a breach within 72 hours of becoming aware of it, as full and comprehensive details of the incident may not always be available during this initial period. As such, it allows for a notification in phases. It is more likely this will be the case for more complex breaches, such as some types of cyber security incidents where, for example, an in-depth forensic investigation may be necessary to fully establish the nature of the breach and the extent to which personal data have been compromised. Consequently, in many cases the controller will have to do more investigation and follow-up with additional information at a later point. This is permissible, providing the controller gives reasons for the delay, in accordance with Article 33(1) GDPR. The EDPB recommends that when the controller first notifies the supervisory authority, the controller should also inform the supervisory authority if the controller does not yet have all the required information and will provide more details later on. The supervisory authority should agree how and when additional information should be provided. This does not prevent the controller from providing further information at any other stage, if it becomes aware of additional relevant details about the breach that need to be provided to the supervisory authority.
58. The focus of the notification requirement is to encourage controllers to act promptly on a breach, contain it and, if possible, recover the compromised personal data, and to seek relevant advice from the supervisory authority. Notifying the supervisory authority within the first 72 hours can allow the controller to make sure that decisions about notifying or not notifying individuals are correct.
59. However, the purpose of notifying the supervisory authority is not solely to obtain guidance on whether to notify the affected individuals. It will be obvious in some cases that, due to the nature of the breach and the severity of the risk, the controller will need to notify the affected individuals without delay. For example, if there is an immediate threat of identity theft, or if special categories of personal data29 are disclosed online, the controller should act without undue delay to contain the breach and to communicate it to the individuals concerned (see section III). In exceptional circumstances, this might even take place before notifying the supervisory authority. More generally, notification of the supervisory authority may not serve as a justification for failure to communicate the breach to the data subject where it is required.
60. It should also be clear that after making an initial notification, a controller could update the supervisory authority if a follow-up investigation uncovers evidence that the security incident was contained and no breach actually occurred. This information could then be added to the information already given to the supervisory authority and the incident recorded accordingly as not being a breach. There is no penalty for reporting an incident that ultimately transpires not to be a breach.
61. It should be noted that a phased approach to notification is already the case under the existing obligations of Directive 2002/58/EC, Regulation 611/2013 and other self-reported incidents.
3. Delayed notifications
62. Article 33(1) GDPR makes it clear that where notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay. This, along with the concept of notification in phases, recognises that a controller may not always be able to notify a breach within that time period, and that a delayed notification may be permissible.
63. Such a scenario might take place where, for example, a controller experiences multiple, similar confidentiality breaches over a short period of time, affecting large numbers of data subjects in the same way. A controller could become aware of a breach and, whilst beginning its investigation, and before notification, detect further similar breaches, which have different causes. Depending on the circumstances, it may take the controller some time to establish the extent of the breaches and, rather than notify each breach individually, the controller instead organises a meaningful notification that represents several very similar breaches, with possible different causes. This could lead to notification to the supervisory authority being delayed by more than 72 hours after the controller first becomes aware of these breaches.
64. Strictly speaking, each individual breach is a reportable incident. However, to avoid being overly burdensome, the controller may be able to submit a “bundled” notification representing all these breaches, provided that they concern the same type of personal data breached in the same way, over a relatively short space of time. If a series of breaches take place that concern different types of personal data, breached in different ways, then notification should proceed in the normal way, with each breach being reported in accordance with Article 33.
29 See Article 9 GDPR.
65. Whilst the GDPR allows for delayed notifications to an extent, this should not be seen as something that regularly takes place. It is worth pointing out that bundled notifications can also be made for multiple similar breaches reported within 72 hours.
C. Cross-border breaches and breaches at non-EU establishments
1. Cross-border breaches
66. Where there is cross-border processing30 of personal data, a breach may affect data subjects in more than one Member State. Article 33(1) GDPR makes it clear that when a breach has occurred, the controller should notify the supervisory authority competent in accordance with Article 55 of the GDPR31. Article 55(1) GDPR says that:
67. However, Article 56(1) GDPR states:
68. Furthermore, Article 56(6) GDPR states:
69. This means that whenever a breach takes place in the context of cross-border processing and notification is required, the controller will need to notify the lead supervisory authority32. Therefore, when drafting its breach response plan, a controller must make an assessment as to which supervisory authority is the lead supervisory authority that it will need to notify33. This will allow the controller to respond promptly to a breach and to meet its obligations in respect of Article 33. It should be clear that in the event of a breach involving cross-border processing, notification must be made to the lead supervisory authority, which is not necessarily where the affected data subjects are located, or indeed where the breach has taken place. When notifying the lead authority, the controller should indicate, where appropriate, whether the breach involves establishments located in other Member States, and in which Member States data subjects are likely to have been affected by the breach. If the controller has any doubt as to the identity of the lead supervisory authority then it should, at a minimum, notify the local supervisory authority where the breach has taken place.
2. Breaches at non-EU establishments
70. Article 3 GDPR concerns the territorial scope of the GDPR, including when it applies to the processing of personal data by a controller or processor that is not established in the EU. In particular, Article 3(2) GDPR states34:
30 See Article 4(23) GDPR.
31 See also Recital 122 GDPR.
32 See WP29 Guidelines for identifying a controller or processor’s lead supervisory authority, available at http://ec.europa.eu/newsroom/document.cfm?doc_id=44102
33 A list of contact details for all European national data protection authorities can be found at: https://edpb.europa.eu/about-edpb/about-edpb/members_en
34 See also Recitals 23 and 24 GDPR.
71. Article 3(3) GDPR is also relevant and states35:
72. Where a controller not established in the EU is subject to Article 3(2) or Article 3(3) GDPR and experiences a breach, it is therefore still bound by the notification obligations under Articles 33 and 34 GDPR. Article 27 GDPR requires a controller (and a processor) to designate a representative in the EU where Article 3(2) GDPR applies.
73. However, the mere presence of a representative in a Member State does not trigger the one-stop- shop system.36 For this reason the breach will need to be notified to every supervisory authority for which affected data subjects reside in their Member State. This (These) notification(s) shall be the responsibility of the controller.37
74. Similarly, where a processor is subject to Article 3(2) GDPR, it will be bound by the obligations on processors, of particular relevance here, the duty to notify a breach to the controller under Article 33(2) GDPR.
D. Conditions where notification is not required
75. Article 33(1) GDPR makes it clear that breaches that are “unlikely to result in a risk to the rights and freedoms of natural persons” do not require notification to the supervisory authority. An example might be where personal data are already publically available and a disclosure of such data does not constitute a likely risk to the individual. This is in contrast to existing breach notification requirements for providers of publically available electronic communications services in Directive 2009/136/EC that state all relevant breaches have to be notified to the competent authority.
76. In its Opinion 03/2014 on breach notification 38 , WP29 explained that a confidentiality breach of personal data that were encrypted with a state of the art algorithm is still a personal data breach, and has to be notified. However, if the confidentiality of the key is intact – i.e., the key was not compromised in any security breach, and was generated so that it cannot be ascertained by available technical means by any person who is not authorised to access it – then the data are in principle unintelligible. Thus, the breach is unlikely to adversely affect individuals and therefore would not
35 See also Recital 25 GDPR.
36 See WP29 Guidelines for identifying a controller or processor’s lead supervisory authority, available at http://ec.europa.eu/newsroom/document.cfm?doc_id=44102
37 In line with guidelines 3/2018 on the territorial scope of the GDPR (Article 3), available at https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32018-territorial-scope-gdpr- article-3-version_en, the EDPB considers the function of a representative in the Union as not compatible with the role of an external data protection officer (“DPO”), therefore the responsibility to notify the supervisory authority in case of a personal data breach remains that of the controller in line with Article 27(5) GDPR. A representative can however be involved in the notification process if this has been explicitly stipulated in the written mandate.
38 WP29, Opinion 03/2014 on breach notification, http://ec.europa.eu/justice/data- protection/article29/documentation/opinion-recommendation/files/2014/wp213_en.pdf
require communication to those individuals 39. However, even where data is encrypted, a loss or alteration can have negative consequences for data subjects where the controller has no adequate backups. In that instance communication to data subjects would be required, even if the data itself was subject to adequate encryption measures.
77. WP29 also explained this would similarly be the case if personal data, such as passwords, were securely hashed and salted, the hashed value was calculated with a state of the art cryptographic keyed hash function, the key used to hash the data was not compromised in any breach, and the key used to hash the data has been generated in a way that it cannot be ascertained by available technological means by any person who is not authorised to access it.
78. Consequently, if personal data have been made essentially unintelligible to unauthorised parties and where the data are a copy or a backup exists, a confidentiality breach involving properly encrypted personal data may not need to be notified to the supervisory authority. This is because such a breach is unlikely to pose a risk to individuals’ rights and freedoms. This of course means that the individual would not need to be informed either as there is likely no high risk. However, it should be borne in mind that while notification may initially not be required if there is no likely risk to the rights and freedoms of individuals, this may change over time and the risk would have to be re-evaluated. For example, if the key is subsequently found to be compromised, or a vulnerability in the encryption software is exposed, then notification may still be required.
79. Furthermore, it should be noted that if there is a breach where there are no backups of the encrypted personal data then there will have been an availability breach, which could pose risks to individuals and therefore may require notification. Similarly, where a breach occurs involving the loss of encrypted data, even if a backup of the personal data exists this may still be a reportable breach, depending on the length of time taken to restore the data from that backup and the effect that lack of availability has on individuals. As Article 32(1)(c) GDPR states, an important factor of security is the “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident”.
80. However, a failure to comply with Article 33 GDPR will exist where a controller does not notify the supervisory authority in a situation where the data has not actually been securely encrypted. Therefore, when selecting encryption software controllers should carefully weigh the quality and the proper implementation of the encryption offered, understand what level of protection it actually provides and whether this is appropriate to the risks presented. Controllers should also be familiar with the specifics of how their encryption product functions. For instance, a device may be encrypted once it is switched off, but not while it is in stand-by mode. Some products using encryption have “default keys” that need to be changed by each customer to be effective. The encryption may also be considered currently adequate by security experts, but may become outdated in a few years’ time,
39 See also Article 4(1) and (2) of Regulation 611/2013.
meaning it is questionable whether the data would be sufficiently encrypted by that product and provide an appropriate level of protection.
III. ARTICLE 34 – COMMUNICATION TO THE DATA SUBJECT
A. Informing individuals
81. In certain cases, as well as notifying the supervisory authority, the controller is also required to communicate a breach to the affected individuals.
Article 34(1) GDPR states:
82. Controllers should recall that notification to the supervisory authority is mandatory unless there is unlikely to be a risk to the rights and freedoms of individuals as a result of a breach. In addition, where there is likely a high risk to the rights and freedoms of individuals as the result of a breach, individuals must also be informed. The threshold for communicating a breach to individuals is therefore higher than for notifying supervisory authorities and not all breaches will therefore be required to be communicated to individuals, thus protecting them from unnecessary notification fatigue.
83. The GDPR states that communication of a breach to individuals should be made “without undue delay,” which means as soon as possible. The main objective of notification to individuals is to provide specific information about steps they should take to protect themselves40. As noted above, depending on the nature of the breach and the risk posed, timely communication will help individuals to take steps to protect themselves from any negative consequences of the breach.
84. Annex B of these Guidelines provides a non-exhaustive list of examples of when a breach may be likely to result in high risk to individuals and consequently instances when a controller will have to notify a breach to those affected.
B. Information to be provided
85. When notifying individuals, Article 34(2) GDPR specifies that:
86. According to this provision, the controller should at least provide the following information:
• a description of the nature of the breach;
• the name and contact details of the data protection officer or other contact point;
• a description of the likely consequences of the breach; and
• a description of the measures taken or proposed to be taken by the controller to address the breach, including, where appropriate, measures to mitigate its possible adverse effects.
87. As an example of the measures taken to address the breach and to mitigate its possible adverse effects, the controller could state that, after having notified the breach to the relevant supervisory authority, the controller has received advice on managing the breach and lessening its impact. The controller should also, where appropriate, provide specific advice to individuals to protect themselves from
40 See also Recital 86 GDPR.
possible adverse consequences of the breach, such as resetting passwords in the case where their access credentials have been compromised. Again, a controller can choose to provide information in addition to what is required here.
C. Contacting individuals
88. In principle, the relevant breach should be communicated to the affected data subjects directly, unless doing so would involve a disproportionate effort. In such a case, there shall instead be a public communication or similar measure whereby the data subjects are informed in an equally effective manner (Article 34(3)(c) GDPR).
89. Dedicated messages should be used when communicating a breach to data subjects and they should not be sent with other information, such as regular updates, newsletters, or standard messages. This helps to make the communication of the breach to be clear and transparent.
90. Examples of transparent communication methods include direct messaging (e.g. email, SMS, direct message), prominent website banners or notification, postal communications and prominent advertisements in print media. A notification solely confined within a press release or corporate blog would not be an effective means of communicating a breach to an individual. The EDPB recommends that controllers should choose a means that maximizes the chance of properly communicating information to all affected individuals. Depending on the circumstances, this may mean the controller employs several methods of communication, as opposed to using a single contact channel.
91. Controllers may also need to ensure that the communication is accessible in appropriate alternative formats and relevant languages to ensure individuals are able to understand the information being provided to them. For example, when communicating a breach to an individual, the language used during the previous normal course of business with the recipient will generally be appropriate. However, if the breach affects data subjects who the controller has not previously interacted with, or particularly those who reside in a different Member State or other non-EU country from where the controller is established, communication in the local national language could be acceptable, taking into account the resource required. The key is to help data subjects understand the nature of the breach and steps they can take to protect themselves.
92. Controllers are best placed to determine the most appropriate contact channel to communicate a breach to individuals, particularly if they interact with their customers on a frequent basis. However, clearly a controller should be wary of using a contact channel compromised by the breach as this channel could also be used by attackers impersonating the controller.
93. At the same time, Recital 86 GDPR explains that:
94. Controllers might therefore wish to contact and consult the supervisory authority not only to seek advice about informing data subjects about a breach in accordance with Article 34, but also on the appropriate messages to be sent to, and the most appropriate way to contact, individuals.
95. Linked to this is the advice given in Recital 88 GDPR that notification of a breach should “take into account the legitimate interests of law-enforcement authorities where early disclosure could unnecessarily hamper the investigation of the circumstances of a personal data breach”. This may mean that in certain circumstances, where justified, and on the advice of law-enforcement authorities, the controller may delay communicating the breach to the affected individuals until such time as it
would not prejudice such investigations. However, data subjects would still need to be promptly informed after this time.
96. Whenever it is not possible for the controller to communicate a breach to an individual because there is insufficient data stored to contact the individual, in that particular circumstance the controller should inform the individual as soon as it is reasonably feasible to do so (e.g. when an individual exercises their Article 15 right to access personal data and provides the controller with necessary additional information to contact them).
D. Conditions where communication is not required
97. Article 34(3) GDPR states three conditions that, if met, do not require notification to individuals in the event of a breach. These are:
• The controller has applied appropriate technical and organisational measures to protect personal data prior to the breach, in particular those measures that render personal data unintelligible to any person who is not authorised to access it. This could, for example, include protecting personal data with state-of-the-art encryption, or by tokenization.
• Immediately following a breach, the controller has taken steps to ensure that the high risk posed to individuals’ rights and freedoms is no longer likely to materialise. For example, depending on the circumstances of the case, the controller may have immediately identified and taken action against the individual who has accessed personal data before they were able to do anything with it. Due regard still needs to be given to the possible consequences of any breach of confidentiality, again, depending on the nature of the data concerned.
• It would involve disproportionate effort41 to contact individuals, perhaps where their contact details have been lost as a result of the breach or are not known in the first place. For example, the warehouse of a statistical office has flooded and the documents containing personal data were stored only in paper form. Instead, the controller must make a public communication or take a similar measure, whereby the individuals are informed in an equally effective manner. In the case of disproportionate effort, technical arrangements could also be envisaged to make information about the breach available on demand, which could prove useful to those individuals who may be affected by a breach, but the controller cannot otherwise contact.
98. In accordance with the accountability principle controllers should be able to demonstrate to the supervisory authority that they meet one or more of these conditions 42. It should be borne in mind that while notification may initially not be required if there is no risk to the rights and freedoms of natural persons, this may change over time and the risk would have to be re-evaluated.
99. If a controller decides not to communicate a breach to the individual, Article 34(4) GDPR explains that the supervisory authority can require it to do so, if it considers the breach is likely to result in a high risk to individuals. Alternatively, it may consider that the conditions in Article 34(3) GDPR have been met in which case notification to individuals is not required. If the supervisory authority determines that the decision not to notify data subjects is not well founded, it may consider employing its available powers and sanctions.
41 See WP29 Guidelines on transparency, which will consider the issue of disproportionate effort, available at http://ec.europa.eu/newsroom/just/document.cfm?doc_id=48850
42 See Article 5(2) GDPR.
IV. ASSESSING RISK AND HIGH RISK
A. Risk as a trigger for notification
100. Although the GDPR introduces the obligation to notify a breach, it is not a requirement to do so in all circumstances:
• Notification to the competent supervisory authority is required unless a breach is unlikely to result in a risk to the rights and freedoms of individuals.
• Communication of a breach to the individual is only triggered where it is likely to result in a high risk to their rights and freedoms.
101. This means that immediately upon becoming aware of a breach, it is vitally important that the controller should not only seek to contain the incident but it should also assess the risk that could result from it. There are two important reasons for this: firstly, knowing the likelihood and the potential severity of the impact on the individual will help the controller to take effective steps to contain and address the breach; secondly, it will help it to determine whether notification is required to the supervisory authority and, if necessary, to the individuals concerned.
102. As explained above, notification of a breach is required unless it is unlikely to result in a risk to the rights and freedoms of individuals, and the key trigger requiring communication of a breach to data subjects is where it is likely to result in a high risk to the rights and freedoms of individuals. This risk exists when the breach may lead to physical, material or non-material damage for the individuals whose data have been breached. Examples of such damage are discrimination, identity theft or fraud, financial loss and damage to reputation. When the breach involves personal data that reveals racial or ethnic origin, political opinion, religion or philosophical beliefs, or trade union membership, or includes genetic data, data concerning health or data concerning sex life, or criminal convictions and offences or related security measures, such damage should be considered likely to occur43.
B. Factors to consider when assessing risk
103. Recitals 75 and 76 of the GDPR suggest that generally when assessing risk, consideration should be given to both the likelihood and severity of the risk to the rights and freedoms of data subjects. It further states that risk should be evaluated on the basis of an objective assessment.
104. It should be noted that assessing the risk to people’s rights and freedoms as a result of a breach has a different focus to the risk considered in a DPIA)44. The DPIA considers both the risks of the data processing being carried out as planned, and the risks in case of a breach. When considering a potential breach, it looks in general terms at the likelihood of this occurring, and the damage to the data subject that might ensue; in other words, it is an assessment of a hypothetical event. With an actual breach, the event has already occurred, and so the focus is wholly about the resulting risk of the impact of the breach on individuals.
43 See Recital 75 and Recital 85 GDPR.
44 See WP Guidelines on DPIAs here: http://ec.europa.eu/newsroom/document.cfm?doc_id=44137
105. Accordingly, when assessing the risk to individuals as a result of a breach, the controller should consider the specific circumstances of the breach, including the severity of the potential impact and the likelihood of this occurring. The EDPB therefore recommends the assessment should take into account the following criteria45:
• The type of breach
106. The type of breach that has occurred may affect the level of risk presented to individuals. For example, a confidentiality breach whereby medical information has been disclosed to unauthorised parties may have a different set of consequences for an individual to a breach where an individual’s medical details have been lost, and are no longer available.
• The nature, sensitivity, and volume of personal data
107. Of course, when assessing risk, a key factor is the type and sensitivity of personal data that has been compromised by the breach. Usually, the more sensitive the data, the higher the risk of harm will be to the people affected, but consideration should also be given to other personal data that may already be available about the data subject. For example, the disclosure of the name and address of an individual in ordinary circumstances is unlikely to cause substantial damage. However, if the name and address of an adoptive parent is disclosed to a birth parent, the consequences could be very severe for both the adoptive parent and child.
108. Breaches involving health data, identity documents, or financial data such as credit card details, can all cause harm on their own, but if used together they could be used for identity theft. A combination of personal data is typically more sensitive than a single piece of personal data.
109. Some types of personal data may seem at first relatively innocuous, however, what that data may reveal about the affected individual should be carefully considered. A list of customers accepting regular deliveries may not be particularly sensitive, but the same data about customers who have requested that their deliveries be stopped while on holiday would be useful information to criminals.
110. Similarly, a small amount of highly sensitive personal data can have a high impact on an individual, and a large range of details can reveal a greater range of information about that individual. Also, a breach affecting large volumes of personal data about many data subjects can have an effect on a corresponding large number of individuals.
• Ease of identification of individuals
111. An important factor to consider is how easy it will be for a party who has access to compromised personal data to identify specific individuals, or match the data with other information to identify individuals. Depending on the circumstances, identification could be possible directly from the personal data breached with no special research needed to discover the individual’s identity, or it may be extremely difficult to match personal data to a particular individual, but it could still be possible under certain conditions. Identification may be directly or indirectly possible from the breached data, but it may also depend on the specific context of the breach, and public availability of related personal details. This may be more relevant for confidentiality and availability breaches.
45 Article 3.2 of Regulation 611/2013 provides guidance the factors that should be taken into consideration in relation to the notification of breaches in the electronic communication services sector, which may be useful in the context of notification under the GDPR. See http://eur- lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:173:0002:0008:en:PDF
112. As stated above, personal data protected by an appropriate level of encryption will be unintelligible to unauthorised persons without the decryption key. Additionally, appropriately- implemented pseudonymisation (defined in Article 4(5) GDPR as “the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person”) can also reduce the likelihood of individuals being identified in the event of a breach. However, pseudonymisation techniques alone cannot be regarded as making the data unintelligible.
• Severity of consequences for individuals
113. Depending on the nature of the personal data involved in a breach, for example, special categories of data, the potential damage to individuals that could result can be especially severe, in particular where the breach could result in identity theft or fraud, physical harm, psychological distress, humiliation or damage to reputation. If the breach concerns personal data about vulnerable individuals, they could be placed at greater risk of harm.
114. Whether the controller is aware that personal data is in the hands of people whose intentions are unknown or possibly malicious can have a bearing on the level of potential risk. There may be a confidentiality breach, whereby personal data is disclosed to a third party, as defined in Article 4(10), or other recipient in error. This may occur, for example, where personal data is sent accidentally to the wrong department of an organisation, or to a commonly used supplier organisation. The controller may request the recipient to either return or securely destroy the data it has received. In both cases, given that the controller has an ongoing relationship with them, and it may be aware of their procedures, history and other relevant details, the recipient may be considered “trusted”. In other words, the controller may have a level of assurance with the recipient so that it can reasonably expect that party not to read or access the data sent in error, and to comply with its instructions to return it. Even if the data has been accessed, the controller could still possibly trust the recipient not to take any further action with it and to return the data to the controller promptly and to co-operate with its recovery. In such cases, this may be factored into the risk assessment the controller carries out following the breach – the fact that the recipient is trusted may eradicate the severity of the consequences of the breach but does not mean that a breach has not occurred. However, this in turn may remove the likelihood of risk to individuals, thus no longer requiring notification to the supervisory authority, or to the affected individuals. Again, this will depend on case-by-case basis. Nevertheless, the controller still has to keep information concerning the breach as part of the general duty to maintain records of breaches (see section V, below).
115. Consideration should also be given to the permanence of the consequences for individuals, where the impact may be viewed as greater if the effects are long-term.
• Special characteristics of the individual
116. A breach may affect personal data concerning children or other vulnerable individuals, who may be placed at greater risk of danger as a result. There may be other factors about the individual that may affect the level of impact of the breach on them.
• Special characteristics of the data controller
117. The nature and role of the controller and its activities may affect the level of risk to individuals as a result of a breach. For example, a medical organisation will process special categories of personal data, meaning that there is a greater threat to individuals if their personal data is breached, compared with a mailing list of a newspaper.
• The number of affected individuals
118. A breach may affect only one or a few individuals or several thousand, if not many more. Generally, the higher the number of individuals affected, the greater the impact of a breach can have. However, a breach can have a severe impact on even one individual, depending on the nature of the personal data and the context in which it has been compromised. Again, the key is to consider the likelihood and severity of the impact on those affected.
• General points
119. Therefore, when assessing the risk that is likely to result from a breach, the controller should consider a combination of the severity of the potential impact on the rights and freedoms of individuals and the likelihood of these occurring. Clearly, where the consequences of a breach are more severe, the risk is higher and similarly where the likelihood of these occurring is greater, the risk is also heightened. If in doubt, the controller should err on the side of caution and notify. Annex B provides some useful examples of different types of breaches involving risk or high risk to individuals.
120. The European Union Agency for Network and Information Security (ENISA) has produced recommendations for a methodology of assessing the severity of a breach, which controllers and processors may find useful when designing their breach management response plan46.
V. ACCOUNTABILITY AND RECORD KEEPING
A. Documenting breaches
121. Regardless of whether or not a breach needs to be notified to the supervisory authority, the controller must keep documentation of all breaches, as Article 33(5) GDPR explains:
122. This is linked to the accountability principle of the GDPR, contained in Article 5(2) GDPR. The purpose of recording non-notifiable breaches, as well notifiable breaches, also relates to the controller’s obligations under Article 24 GDPR, and the supervisory authority can request to see these records. Controllers are therefore encouraged to establish an internal register of breaches, regardless of whether they are required to notify or not47.
123. Whilst it is up to the controller to determine what method and structure to use when documenting a breach, in terms of recordable information there are key elements that should be included in all cases. As is required by Article 33(5) GDPR, the controller needs to record details concerning the breach, which should include its causes, what took place and the personal data affected. It should also include the effects and consequences of the breach, along with the remedial action taken by the controller.
124. The GDPR does not specify a retention period for such documentation. Where such records contain personal data, it will be incumbent on the controller to determine the appropriate period of retention in accordance with the principles in relation to the processing of personal data48 and to meet a lawful basis for processing49. It will need to retain documentation in accordance with Article 33(5)
46 ENISA, Recommendations for a methodology of the assessment of severity of personal data breaches, https://www.enisa.europa.eu/publications/dbn-severity
47 The controller may choose to document breaches as part of if its record of processing activities which is maintained pursuant to Article 30 GDPR. A separate register is not required, provided the information relevant to the breach is clearly identifiable as such and can be extracted upon request.
48 See Article 5 GDPR.
49 See Article 6 and also Article 9 GDPR.
GDPR insofar as it may be called to provide evidence of compliance with that Article, or with the accountability principle more generally, to the supervisory authority. Clearly, if the records themselves contain no personal data then the storage limitation principle50 of the GDPR does not apply.
125. In addition to these details, the EDPB recommends that the controller also document its reasoning for the decisions taken in response to a breach. In particular, if a breach is not notified, a justification for that decision should be documented. This should include reasons why the controller considers the breach is unlikely to result in a risk to the rights and freedoms of individuals 51 . Alternatively, if the controller considers that any of the conditions in Article 34(3) GDPR are met, then it should be able to provide appropriate evidence that this is the case.
126. Where the controller does notify a breach to the supervisory authority, but the notification is delayed, the controller must be able to provide reasons for that delay; documentation relating to this could help to demonstrate that the delay in reporting is justified and not excessive.
127. Where the controller communicates a breach to the affected individuals, it should be transparent about the breach and communicate in an effective and timely manner. Accordingly, it would help the controller to demonstrate accountability and compliance by retaining evidence of such communication.
128. To aid compliance with Articles 33 and 34 GDPR, it would be advantageous to both controllers and processors to have a documented notification procedure in place, setting out the process to follow once a breach has been detected, including how to contain, manage and recover the incident, as well as assessing risk, and notifying the breach. In this regard, to show compliance with GDPR it might also be useful to demonstrate that employees have been informed about the existence of such procedures and mechanisms and that they know how to react to breaches.
129. It should be noted that failure to properly document a breach can lead to the supervisory authority exercising its powers under Article 58 GDPR and, or imposing an administrative fine in accordance with Article 83 GDPR.
B. Role of the Data Protection Officer
130. A controller or processor may have a Data Protection Officer (DPO)52, either as required by Article 37 GDPR, or voluntarily as a matter of good practice. Article 39 of the GDPR sets a number of mandatory tasks for the DPO, but does not prevent further tasks being allocated by the controller, if appropriate.
131. Of particular relevance to breach notification, the mandatory tasks of the DPO includes, amongst other duties, providing data protection advice and information to the controller or processor, monitoring compliance with the GDPR, and providing advice in relation to DPIAs. The DPO must also cooperate with the supervisory authority and act as a contact point for the supervisory authority and for data subjects. It should also be noted that, when notifying the breach to the supervisory authority, Article 33(3)(b) GDPR requires the controller to provide the name and contact details of its DPO, or other contact point.
132. In terms of documenting breaches, the controller or processor may wish to obtain the opinion of its DPO as to the structure, the setting up and the administration of this documentation. The DPO could also be additionally tasked with maintaining such records.
133. These factors mean that the DPO should play an key role in assisting the prevention of or preparation for a breach by providing advice and monitoring compliance, as well as during a breach
50 See Article 5(1)(e) GDPR.
51 See Recital 85 GDPR.
52 See WP Guidelines on DPOs here: http://ec.europa.eu/newsroom/just/item-detail.cfm?item_id=50083
(i.e. when notifying the supervisory authority), and during any subsequent investigation by the supervisory authority. In this light, the EDPB recommends that the DPO is promptly informed about the existence of a breach and is involved throughout the breach management and notification process.
VI. NOTIFICATION OBLIGATIONS UNDER OTHER LEGAL INSTRUMENTS
134. In addition to, and separate from, the notification and communication of breaches under the GDPR, controllers should also be aware of any requirement to notify security incidents under other associated legislation that may apply to them and whether this may also require them to notify the supervisory authority of a personal data breach at the same time. Such requirements can vary between Member States, but examples of notification requirements in other legal instruments, and how these inter-relate with the GDPR, include the following:
• Regulation (EU) 910/2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS Regulation)53.
135. Article 19(2) of the eIDAS Regulation requires trust service providers to notify their supervisory body of a breach of security or loss of integrity that has a significant impact on the trust service provided or on the personal data maintained therein. Where applicable—i.e., where such a breach or loss is also a personal data breach under the GDPR—the trust service provider should also notify the supervisory authority.
• Directive (EU) 2016/1148 concerning measures for a high common level of security of network and information systems across the Union (NIS Directive)54.
136. Articles 14 and 16 of the NIS Directive require operators of essential services and digital service providers to notify security incidents to their competent authority. As recognised by Recital 63 of NIS55, security incidents can often include a compromise of personal data. Whilst NIS requires competent authorities and supervisory authorities to co-operate and exchange information that context, it remains the case that where such incidents are, or become, personal data breaches under the GDPR, those operators and/or providers would be required to notify the supervisory authority separately from the incident notification requirements of NIS.
• Directive 2009/136/EC (the Citizens’ Rights Directive) and Regulation 611/2013 (the Breach Notification Regulation).
137. Providers of publicly available electronic communication services within the context of Directive 2002/58/EC56 must notify breaches to the competent national authorities.
53 See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG
54 See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.194.01.0001.01.ENG
55 Recital 63: “Personal data are in many cases compromised as a result of incidents. In this context, competent authorities and data protection authorities should cooperate and exchange information on all relevant matters to tackle any personal data breaches resulting from incidents.”
56 On 10 January 2017, the European Commission proposed a Regulation on Privacy and Electronic Communications which will replace Directive 2009/136/EC and remove notification requirements. However, until this proposal is approved by the European Parliament the existing notification requirement remains in
138. Controllers should also be aware of any additional legal, medical, or professional notification duties under other applicable regimes.
B. Examples of personal data breaches and who to notify
The following non-exhaustive examples will assist controllers in determining whether they need to notify in different personal data breach scenarios. These examples may also help to distinguish between risk and high risk to the rights and freedoms of individuals.
Example | Notify the supervisory
authority |
Notify the data
subject |
Notes/recommendations |
i A controller stored a | No. | No. | As long as the data are |
backup of an archive | encrypted with a state of | ||
of personal data | the art algorithm, backups | ||
encrypted on a USB | of the data exist the unique | ||
key. The key is | key is not compromised, | ||
stolen during a | and the data can be | ||
break-in. | restored in good time, this | ||
may not be a reportable | |||
breach. However if it is later | |||
compromised, notification | |||
is required. | |||
ii A controller maintains an online service. As a result of a cyber attack on that service, personal data of individuals are exfiltrated. | Yes, report to the supervisory authority if there are likely consequences to individuals. | Yes, report to individuals depending on the nature of the personal data affected and if the severity of the likely consequences to individuals is high. | |
The controller has customers in a single Member State. | |||
iii A brief power | No. | No. | This is not a notifiable breach, but still a recordable incident under Article 33(5).
Appropriate records should be maintained by the controller. |
outage lasting | |||
several minutes at a
controller’s call |
|||
centre meaning | |||
customers are | |||
unable to call the | |||
controller and | |||
access their records. | |||
iv A controller suffers a ransomware
attack which results |
Yes, report to the supervisory authority,
if there are likely |
Yes, report to individuals, depending
on the nature of the |
If there was a backup available and data could be restored in good time, this would not need to be reported to the supervisory authority or to individuals as there would have been no permanent loss of availability or confidentiality. However, if the supervisory authority
became aware of the |
in all data being | consequences to | personal data affected | |
encrypted. No back- | individuals as this is a loss | and the possible effect | |
ups are available
and the data cannot |
of availability. | of the lack of availability
of the data, as well as |
|
be restored. On
investigation, it becomes clear that |
other likely consequences. | ||
the ransomware’s | |||
only functionality |
was to encrypt the | incident by other means, it | ||
data, and that there | may consider an | ||
was no other | investigation to assess | ||
malware present in | compliance with the | ||
the system. | broader security | ||
requirements of Article 32. |
v An individual phones a bank’s call centre to report a data breach. The individual has received a monthly statement for someone else.
The controller undertakes a short investigation (i.e. completed within 24 hours) and establishes with a reasonable confidence that a personal data breach has occurred and whether it has a systemic flaw that may mean other individuals are or might be affected. |
Yes. | Only the individuals affected are notified if there is high risk and it is clear that others were not affected. | If, after further investigation, it is identified that more individuals are affected, an update to the supervisory authority must be made and the controller takes the additional step of notifying other individuals if there is high risk to them. |
vi A controller operates an online marketplace and has customers in multiple Member States. The marketplace suffers a cyber-attack and usernames, passwords and purchase history are published online by the attacker. | Yes, report to lead supervisory authority if involves cross-border processing. | Yes, as could lead to high risk. | The controller should take action, e.g. by forcing password resets of the affected accounts, as well as other steps to mitigate the risk.
The controller should also consider any other notification obligations, e.g. under the NIS Directive as a digital service provider. |
vii A website hosting company acting as a data processor identifies an error in the code which controls user authorisation. The effect of the flaw
means that any user |
As the processor, the website hosting company must notify
its affected clients (the controllers) without undue delay. Assuming that the website hosting |
If there is likely no high risk to the individuals they do not need to be notified. | The website hosting company (processor) must consider any other notification obligations (e.g. under the NIS Directive as a digital service provider).
If there is no evidence of this vulnerability being |
can access the account details of any other user | company has conducted its own investigation the affected controllers should be reasonably confident as to whether each has suffered a breach and therefore is likely to be considered as having “become aware” once they have been notified by the hosting company (the processor). The controller then must notify the supervisory
authority |
exploited with any of its controllers a notifiable breach may not have occurred but it is likely to be recordable or be a matter of non-compliance under Article 32. | |
viii Medical records in a hospital are unavailable for the period of 30 hours due to a cyber- attack. | Yes, the hospital is obliged to notify as high- risk to patient’s well- being and privacy may occur. | Yes, report to the affected individuals. | |
ix Personal data of a large number of students are mistakenly sent to the wrong mailing list with 1000+ recipients. | Yes, report to supervisory authority. | Yes, report to individuals depending on the scope and type of personal data involved and the severity of possible consequences. | |
x A direct marketing e-mail is sent to recipients in the “to:” or “cc:” fields, thereby enabling each recipient to see the email address of other recipients. | Yes, notifying the supervisory authority may be obligatory if a large number of individuals are affected, if sensitive data are revealed (e.g. a mailing list of a psychotherapist) or if other factors present high risks (e.g. the mail contains the initial passwords). | Yes, report to individuals depending on the scope and type of personal data involved and the severity of possible consequences. | Notification may not be necessary if no sensitive data is revealed and if only a minor number of email addresses are revealed. |