text: The general legal framework for the EU staff acting as whistleblowers is set out in the

text: Articles 22

text: a, 22b and 22c of the staff regulation, which according to Article 11 of Conditions of Employment of Other Civil servants of the EU apply by analogy to servants engaged under contract. 2

text: Article 27(2)

text: (a) and (b) of

text: Regulation (EC) No 45/2001

text: (the 'Regulation').

text: Article 10(1) of the Regulation. 6 Article 4(1) of the Regulation.

text: Article 2

text: (a) of the Regulation. 8

text: Article 29

text: Working Party Opinion 4/2007 on the concept of personal data,

text: WP 136

text: , adopted on 20 June 2007.

text: Article 29

text: Working Party Opinion on the application of EU data protection rules to internal whistleblowing schemes in the fields of accounting, internal accounting controls, auditing matters, fight against bribery, banking and financial crime,

text: WP 117

text: , adopted on 1 February 2006, pg. 14 14 Articles 7, 8 and 9 of the Regulation. 15

text: Article 4(1)

text: (e) of the Regulation. 16

text: Article 29

text: Working Party Opinion 1/2006,

text: WP 117

text: , pg. 12.

text: See Article 22 of the Regulation.

title: Whistleblowing Procedure

text: July 2016

text: Executive Summary

text: Whistleblowing serves the purpose of shining the light on corruption. A key challenge to prevent and fight corruption is to detect and expose bribery, fraud, theft, and other acts of wrongdoing in the work place. Whistleblowing is a tool to make visibility to that kind of unethical behaviour.

text: Whistleblowers believe that they are acting in the public interest when reporting an activity observed of serious matter. Unfortunately whistleblowers commonly face retaliation in the form of harassment, firing, blacklisting, threats and their disclosures are routinely ignored. Confidentiality is therefore crucial and the most effective way to encourage staff to report concerns is to ensure them that their identity will be protected.

text: These Guidelines provides practical guidance to the EU institutions and bodies both before and after implementation of a whistleblowing procedure to ensure that they comply with the data protection obligations as set out in

text: Regulation (EC) No 45/2001

text: 1 | P a g e List of Recommendations Below is a list of the recommendations detailed in the guidelines. The EDPS will use these as checklists in assessing your compliance with the obligations laid out in the Regulation. 1. Implement defined channels for internal and external reporting and specific rules where the purpose is clearly specified (p. 4-5).

text: 2. Ensure confidentiality of the information received and protect the whistleblowers' identity and all other persons involved (p. 4-5).

text: 3. Apply the principle of data minimisation: only process personal information, which are adequate, relevant and necessary, for the particular case (p. 6).

text: 4. Identify what personal information means in this context and which are the affected individuals to determine their right of information, access and rectification. Restrictions to these rights are allowed, as long as the EU institutions are able to provide documented reasons before taking such a decision (p. 6-7).

text: 5. Apply the two-step procedure to inform each category of individuals concerned about how their data will be processed (p. 7-8).

text: 6. Ensure when responding to right of access requests that personal information of other parties is not revealed (p. 8-9).

text: 7. Assess the appropriate competence of the recipient (internal or external) and then limit the transfer of personal information only when necessary for the legitimate performance of tasks covered by the competence of the recipient (p. 9).

text: 8. Define proportionate conservation periods for the personal information processed within the scope of the whistleblowing procedure depending on the outcome of each case (p. 9- 10).

text: 9. Implement both organisational and technical security measures based on a risk assessment analysis of the whistleblowing procedure in order to guarantee a lawful and secure processing of personal information (p. 10-11). 2 | P a g e 1. INTRODUCTION 1 Whistleblowing procedures are intended to provide safe channels for anyone who becomes aware and reports potential fraud, corruption, or other serious wrongdoings and irregularities. Whistleblowers believe that they are acting in the public interest when reporting an activity observed that is of a serious nature. 2 The Staff Regulations “SR” as well as the Conditions of Employment of Other Servants “CEOS” contain an obligation for staff members and other persons working for the EU institutions and bodies (“EU institutions”) to report in writing any reasonable suspicion of illegal activities to the hierarchy or to the European Anti-Fraud Office (“OLAF”) directly. Some EU institutions have also adopted internal rules about whistleblowing by their staff members. As the whistleblowing arrangements serves as a detection mechanism to bring cases to the attention of OLAF, the duty to report concerns only serious wrongdoings and irregularities. The scope of these Guidelines is limited to the initial stage when EU institutions receive a report and not when it has been referred or sent directly to OLAF. 3 Whistleblowing procedures contain the processing of sensitive personal information. EU institutions are required to manage whistleblowing reports and ensure the protection of the personal information of the whistleblowers, the alleged wrongdoers, the witnesses and the other persons appearing in the report. These Guidelines explain and give hypothetical examples on how to apply the data protection principles in this specific context, which may affect individuals' private lives. The Guidelines also show that the data protection principles can be used to strengthen the whistleblowing procedures. The application of data protection principles will, inter alia, help creating reliable channels by reinforcing security aspects of the procedure. 4 External parties that enter into a contract with the EU institutions or contact the EU institutions (such as consultants, contractors, researchers etc.) should be informed that it is possible to report suspected fraud, corruption or other serious wrongdoings and irregularities. 5 This processing operation is likely to present specific risks and therefore is subject to prior checking by the European Data Protection Supervisor (“EDPS”). 2. SAFE CHANNELS FOR REPORTING FRAUD - ENSURE CONFIDENTIALITY 6 The most effective way to encourage staff to report concerns are to ensure them that their identity will be protected. Therefore, clearly defined channels for internal and external reporting and the protection of the information received should be in place. The identity of the whistleblower who report serious wrongdoings or irregularities in good faith should be treated with the utmost confidentiality as they should be protected against any retaliation. Their identity should never be revealed except in certain exceptional circumstances if the whistleblower authorises such a disclosure, if this is required by any 4 | P a g e subsequent criminal law proceedings, or if the whistleblower maliciously makes a false statement. In the latter case, these personal data can only be disclosed to judicial authorities. A statement is maliciously made if the whistleblower report activities that he/she knows are not true. If an EU institution becomes aware of the fact that a whistleblower knew that the allegation made by him/her was unsubstantiated, the responsibility lies on the institution to prove the maliciousness of the allegations. 7 The person against whom an allegation has been made should be protected in the same manner as the whistleblower, since there is a risk of stigmatisation and victimisation within their organisation. They will be exposed to such risks even before they are aware that they have been incriminated and the alleged facts have been analysed to determine whether or not they can be substained. 8 Therefore, internal access to the information processed as part of the investigation of the allegations must be granted strictly on a need to know basis, that is, subject to the necessity to have access. Persons in charge of the management of reports could for example be subject to a reinforced obligation of secrecy. Personal information must also be stored securely (see security measures below). 9 Any whistleblowing- related personal information retained for statistical purposes should be made anonymous. EU institutions (especially smaller ones) should be particularly cautious with any information that may result in indirect identification. For instance, retaining both the type of whistleblowing cases together with the nationality of the whistleblower could lead to indirect identification and should therefore be avoided. Example 1: An EU Agency has explicit recommendations to its staff on how to guarantee the confidentiality of whistleblowers and the alleged wrongdoers during the initial assessment of a case. The EDPS stresses that the vulnerability of the involved parties is the same regardless of whether the case is ongoing or closed. The protection of whistleblowers and the alleged wrongdoers should therefore be considered also after the closure of a case. 3. AVOID ABUSE OF THE PROCEDURE - SPECIFY THE PURPOSE

text: 10 The scope of the procedure must be limited in order to avoid abuse of the procedure. The purpose of the whistleblowing procedure must be clearly specified in the internal rules/policy of EU institutions. Internal rules or a policy should explicitly describe in which circumstances whistleblowing channels must be used and in which circumstances they should not. In general whistleblowing channels should not be used when staff may wish to exercise their statutory rights i.e. by lodging a request or complaint to the appointing authority under Art 90 of the SR or for harassment claims and personal disagreements when staff may address themselves to the HR, Mediation Service, confidential counsellor, or lodge a request for assistance under Art. 24 of the SR.

text: 11 The internal rules or a policy should furthermore describe that sensitive information, such as racial or ethnic origin, political opinions, religious or philosophical beliefs, trade- 5 | P a g e union membership, and data concerning health or sex life not relevant for the case should be avoided. This will help avoiding the collection of excessive data personal information (see below).

text: 12 In principle, whistleblowing should not be anonymous. Whistleblowers should be invited to identify themselves not only to avoid abuse of the procedure but also to allow their effective protection against any retaliation. This will also allow a better management of the file if further information would be necessary. 4. AVOID PROCESSING EXCESSIVE PERSONAL INFORMATION

text: 13 EU institutions may sometimes come into possession of personal information, which is clearly of no interest or relevance to the allegations. Any such information should not be further processed. This is particularly important for special categories of information. All investigators should be made aware of this rule. Example 2: A whistleblower reports that a colleague has committed a fraudulent activity. Within his statement, the whistleblower happens to disclose information about his colleague’s health situation. It is clear to the institution that this information is completely irrelevant to the reported wrongdoing, and therefore it should not be further processed or returned to the sender.

text: 14 A good practice is to implement a general recommendation, for example in the internal rules of procedure, to the persons handling the files reminding them of the rules of data quality and recommend them to ensure the respect of the rules. 5. IDENTIFY WHAT PERSONAL INFORMATION MEANS IN THIS CONTEXT

text: 15 Personal information is defined as any information that relates to an identified or identifiable natural person. Personal information does not only include information about an individual's private life and family life, but also information regarding an individual's activities, such as his or her working relations and economic or social behaviour . This needs to be considered, for instance, when determining the scope of the data subject's right of access. In most cases, personal information includes identification data (contact details e.g.) but also information that relates to the behaviour of an individual. Example 3: The report of the whistleblower includes information that identifies the alleged wrongdoer and witnesses. The report itself is also personal information of the whistleblower since it relates to his or her behaviour (as a whistleblower). 6 | P a g e

text: 16 The same piece of information may relate to different individuals at the same time. The whistleblower report may contain personal information of witnesses and third parties (persons merely quoted in the file), the persons against whom the allegations have been made and the whistleblower himself.

text: 17 On the other hand, the mere fact that a name is mentioned in a document does not necessarily make all the information contained in that document "data relating to that person". In many situations, information can be considered to relate to an individual only when it's about that individual. Example 4: An EU institution might produce a report considering whether to refer the case to OLAF or not. The analysis may refer to the whistleblower as a source but the whole report is not personal information relating to the whistleblower. 6. INFORM EACH CATEGORY OF INDIVIDUALS

text: 18 Information on whistleblowing procedures should be provided to the individuals in a very prominent way, which will require a two-step procedure. While placing a data protection statement on the website (or within a public or internal-facing document) is certainly a positive step, the EDPS considers that this is not sufficient, as the information could be overlooked. All individuals affected by a particular whistleblowing procedure should also be directly provided with a specific data protection statement as soon as practically possible, for example by email. Affected individuals will usually include whistleblowers, witnesses, third parties (members of staff or others that are merely quoted) and the person(s) against whom the allegations has been made. 6.1. Information to the whistleblower (Article 11 of the Regulation)

text: 19 In this context, it is important to inform about possible recipients or categories of recipients of the whistleblower's personal information. In addition, the data protection statement should also inform the persons about the consequences of abusive use (if the whistleblower maliciously makes a false statement) of the whistleblowing procedure, for instance disciplinary measures. 6.2. Information to the alleged wrongdoer (Article 12 of the Regulation)

text: 20 In certain cases, informing the person against whom an allegation has been made at an early stage may be detrimental to the case. In these cases, provision of specific information might need to be deferred. Deferral of information should be decided on a case by case basis. The reasons for any restrictions should be documented, and made available to the EDPS if requested in the context of a supervision and enforcement action. These reasons should prove, for instance, that there is a high risk that giving access would hamper the procedure or undermine the rights and freedom of the others. The reasons should be documented before the decision to apply any restriction or deferral is taken. 7 | P a g e 6.3. Information to witnesses (Article 11 of the Regulation)

text: 21 Specific information to witnesses should be provided as soon as practically possible, for instance before they are being interviewed by the institution. 6.4. Information to third parties (Article 12 of the Regulation)

text: 22 Depending on the case, informing all the third parties mentioned in a whistleblowing report might involve a disproportionate effort. The assessment whether it is disproportionate or not to inform third parties must be carried out on a case-by-case basis. Moreover, in certain cases, informing individuals would be an additional processing operation that could be more intrusive than the initial one. Example 5: a) A whistleblower attaches to the report a list of the clients (200 people) of a hotel to prove that the alleged wrongdoer was in the hotel at a certain date. The 199 other clients have no link with the case and their information are not processed further by the institution. They should not be informed. b) A whistleblower provides together with the report an USB key containing exchanges of emails with the alleged wrongdoer and a few other staff members. The institution conducts a preliminary analysis and processes the information of the other staff members. The members of staff concerned should be informed. 7. ASSESS THE INDIVIDUAL'S RIGHT OF ACCESS AND LIMITATIONS

text: 23 When considering access rights, institutions should consider the status of the requester and the current stage of the investigation. The level and sensitivity of information held (and any associated risks in disclosure) will vary depending on whether the request is made by: - the person against whom an allegation has been made - the whistleblower - a witness - third parties

text: 24 Institutions must carry out a case-by-case assessment of each individual case and document the reasons underlying their decision. This should take into account the type of information held and whether any exceptions of the Regulation are applicable.

text: 25 When access is granted to the personal information of any concerned individual, the personal information of third parties such as informants, whistleblowers or witnesses should be removed from the documents except in exceptional circumstances if the whistleblower authorises such a disclosure, if this is required by any subsequent criminal law proceedings or if the whistleblower maliciously makes a 8 | P a g e false statement. If a risk remains of third party identification, access should be deferred. The

text: Article 29

text: Working Party recommended that: "Under no circumstances can the person accused in a whistleblower’s report obtain information about the identity of the whistleblower …except where the whistleblower maliciously makes a false statement. Otherwise, the whistleblower’s confidentiality should always be guaranteed". This is especially important to guarantee that individuals are protected from any potential risks involved in disclosing their personal information. Example 6: An EU employee accused of serious wrongdoings asks the institution for all personal information held on him in relation to the accusations. Much of this information is included in testimonies given by the whistleblower. Even if the whistleblowers name is deleted from these documents, their identity would be obvious through reference to the specific events, situations and contexts described. Thus, the institution should defer release of this information with regard to the protection of the data subject or of the rights and freedoms of others (

text: Article 20(1)

text: (c)). 8. LIMIT TRANSFERS

text: 26 Different obligations apply depending on whether the recipients are an EU institution (in this context when an institution transfers data to OLAF), or someone subject to Directive 95/46 (such as a national court or other types of recipients). The requirements for transferring data must be assessed on a case-by-case basis. In particular, personal information should be transferred only when necessary for the legitimate performance of tasks covered by the competence of the recipient. 9. DEFINE CONSERVATION PERIODS DEPENDING ON THE OUTCOME OF THE CASE

text: 27 Personal information must not be kept for a longer period than necessary having regard to the purpose of the processing. Therefore, different conservation periods should apply depending on the information in the report and how the case is dealt with.

text: 28 Firstly, as mentioned above, personal information that is not relevant to the allegations should not be further processed (see paragraph 4).

text: 29 Secondly, when an initial assessment is carried out but it is clear that the case should not be referred to OLAF or is not within the scope of the whistleblowing procedure the report should be deleted as soon as possible (or referred to the right channel if it for example concerns alleged harassment). In any case, personal information should be deleted promptly and usually within two months of completion of the preliminary assessment , since it would be excessive to retain such sensitive information. 9 | P a g e

text: 30 Thirdly, if it is clear after the initial assessment that a report should be transferred to OLAF the EU institution should carefully follow what actions OLAF takes. If OLAF starts an investigation it is not necessary for the EU institutions to keep the information for a longer period. In case OLAF decides not to start an investigation, the information should be deleted without delay.

text: 31 In case a longer retention period is envisaged, access to the personal information should still be limited (see security measures below). It is a good practice to separate these reports from the main case management system/daily system in use. Example 7: An EU institution has received several whistleblowing reports through the whistleblowing channel. One report concerns alleged harassment and is therefore directly referred to the unit dealing with these cases. Two other reports are likely to concern fraud and therefore transferred to OLAF which starts an investigation in one of the cases. The institution applies a conservation period of 5 years on the report where OLAF does not start an investigation. In this situation the EDPS consider that a period of 5 years is excessive and the report should be deleted as soon as possible. 10. IMPLEMENT ADEQUATE SECURITY MEASURES

text: 32 The controller should implement appropriate technical and organisational measures to ensure a level of security appropriate to the risks represented by the processing and the nature of the personal information to be processed. This is not only a clear legal requirement, as previously mentioned the confidentiality regarding all the procedure is of the utmost importance to encourage staff to report any concerns they may have. Furthermore, security measures need to reflect the sensitive nature of the personal information being processed. In this context it is essential to put in place appropriate security measures in order to effectively prevent personal information from being accessed by non-authorised persons and to guarantee its integrity.

text: 33 The need for these security measures has to be analysed in light of the risks regarding the whistleblowing procedure whatever it is a manual or an automatic one: an information security risk assessment. Once the risks to the personal information involved are determined a subsequent analysis can be performed to determine which measures to implement taking into account, also, the cost of these security measures and their viability. As risks evolve over time, it is necessary for the EU institution to review its analysis, the selection of security measures and their effectiveness regularly.

text: 34 Detailed advice on information on information security risk management can be found in the EDPS ‘Guidance on Security Measures for Personal Data Processing - Article 22 of Regulation 45/2001’. 10 | P a g e Example 8: Of special relevance for whistleblowing files: a) Staff that can have access to the personal information must be strictly limited on a need to know-basis. Staff with access must be subject to reinforced obligation of secrecy and access to the whistleblowing reports must be monitored whatever in electronic or paper form. b) From a technical point of view, the common requirements of access control needs to be fully implemented: effectively limit and control who has access to whistleblowing cases, log accesses and review regularly both the accesses and the access rights. c) Encryption needs to be specially considered due to the high needs of confidentiality of this information. Notwithstanding the use of encryption, safeguard mechanisms need to be implemented to allow the access to the information when needed (keys shared, record and safe keeping of passwords...). 11. BE ACCOUNTABLE!

text: 35 Accountability means that organisations must respect their data protection obligations and be able to demonstrate that they do so. 36 Accountability is not specific to personal information within a whistleblowing procedure, but applies to all operations that process personal information. 37 Any organisation that collects, uses and stores (collectively known as processing) personal information is responsible and accountable for complying with data protection rules. 38 In general, institutions must be transparent and explicit about how they process the personal information related to whistleblowing procedures. They must document their policies and make users aware of them. The right to privacy also exists in the workplace and people must be made aware of the procedure. Institutions cannot assume that staff will know. 39 The best way for an institution to be accountable is for it to consider the data protection implications of new processes at the design stage (data protection by design). Different processing operations and different technologies require different safeguards. By involving their data protection officer (DPO) early in the process, he or she will be able to offer valuable advice and guidance. 40 The questions listed below outline the main issues to consider: a. Confidentiality: How do you protect the persons involved? b. Specify the purpose: When to use the whistleblowing channel? c. Avoid excessive information: What information is necessary for the allegations made? d. Identify the meaning of personal information: What is personal information in this specific report? e. Inform each category of individuals: Who are affected by this specific report? f. Different conservation periods should apply: How long do I need to keep the report? 11 | P a g e g. Conduct an information security risk assessment: What are the risks your whistleblowing cases may suffer and how are you going to protect yourself from them? 41 To demonstrate accountability also implies documentation of the procedure and its implementation. The following should be documented: a. a policy or internal rules or decision on whistleblowing; b. limitations to the right of access should be documented, not only on which grounds it is based but also the reasoning why it applies to this specific situation; c. any deferral of information to the individual; d. the risk assessment conducted for this specific procedure. 12. FLOWCHARTS WHISTLEBLOWING PROCEDURES 12.1. Handling whistleblowing reports Does the report concerns Delete the report or transfer it fraud, corruption or other to the appropriate channel. serious wrongdoings? No Yes Is all the information in the Do not further process the report necessary? excessive information. No Yes Start the initial assessment based Start the initial assessment. on the remaining information. 12 | P a g e 12.2. Ensuring individuals' rights Right of access requests The whistleblower The alleged wrongdoer Who made the request? Other persons What information relates to the Consider content, purpose and result requester? Are any exemptions under Article Partly access or no access 20 of the regulation applicable? Yes No Remove all personal information/any information Access may be granted relating to other persons than the requester How to inform the individuals properly When implementing the Place a general privacy statement on whistleblowing procedures the website Are any exemptions under

text: Article 20 of the regulation

text: applicable? The When receiving a report assessment must be done separately for all persons whose information is processed No Yes Inform all the affected Specific information individuals through a is deferred specific privacy statement 13 | P a g e FURTHER READING Examples of EDPS Opinions 2014-0828 - Opinion on the European Ombudsman's Whistleblowing Procedure 2015-0061 - Opinion on the European Research Council Executive Agency's procedure on handling internally and reporting potential fraud and irregularities 2015-0349 - Opinion on the whistleblowing procedure of the General Secretariat of the Council of the European Union 2015-0569 - Opinion on the whistleblowing procedure of the European Fisheries Control Agency Other documents Protection of whistleblowers - recommendation CM/Rec(2014)7 and explanatory memorandum - Council of Europe Whistleblowing in Europe, legal protection for whistleblowers in the EU - Transparency National International principles for whistleblower legislation - Transparency National 14 | P a g e


text: These Guidelines focus on the processing of personal data through mobile applications developed and distributed under the control of EU institutions and bodies. As these mobile applications could process personal data, including sensitive categories, respecting data protection principles is very important. Mobile applications use the specific functions of smart mobile devices like portability, variety of sensors (camera, microphone, location detector…) and increase their functionality to provide great value to their users. However, their use entails specific data protection risks due to the easiness of collecting great quantities of personal data and a potential lack of data protection safeguards. These guidelines are intended to provide practical advice and instructions to the EU institutions on the processing of personal data in mobile applications to ensure that they comply with the data protection obligations set out in the Data Protection Regulation No 45/2001 applicable to the EU institutions. While these Guidelines are in principle aimed at the EU institutions, anyone or any organisation interested in data protection and mobile applications might find them useful; the

text: Regulation (EC) No. 45/2001

text: is similar in many respects to the Data Protection

text: Directive (EC) 95/46

text: and to the new General Data Protection Regulation (

text: Regulation (EU) 2016/679

text: ), both of them applicable to EU Member States, as well as in the EEA. Other countries that look to the EU data protection model can find them useful, too.

text: Summary of recommendations

text: These guidelines focus on specific aspects of data protection and mobile applications. These specific elements must be considered together with aspects applying to IT systems in general which are laid out in the ‘Guidelines on the protection of personal data in IT governance and IT management of EU institutions’. The mobile application must collect only those data that are strictly necessary to perform the lawful functionalities as identified and planned. The requirements of valid consent apply to mobile applications. Users have to be given the option to change their wishes and revoke their decision at any time. An essential element of consent is the information provided to the user. The type and accuracy of the information provided needs to be such as to put users in control of the data on their smart mobile device to protect their own privacy. Some mobile applications use third party components or services that need to be used and managed accordingly to the Regulation. The design and operation of the planned mobile application must follow an information security risk assessment.

text: Prior to investing in a mobile application, a data protection compliance analysis must be performed which could also lead the EU institution not to use a mobile application to support a certain task but rather use alternative solutions. Actively involving the Data Protection Officer, and where relevant the Data Protection Coordinators or Contacts, early in the process of design of any new mobile application, will allow them to offer advice, suggest improvements and generally help the EU institution to ensure compliance with the Regulation.

text: Regulation (EC) No 45/2001 of 18 December 2000

text: on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data, OJ L 8, 12.01.2001, p. 1. 2 In the exercise of the powers conferred under Articles

text: and

text: (d) of the Regulation. 3 Through e.g. GPS signals and Wi-Fi spots positions. Sensors providing, e.g., movement (direction, speed and acceleration), video and audio capture, proximity detection. 5 Such as Wi-Fi, Bluetooth, Near Field Communication techniques and protocols.

text: Application Programming Interfaces 7 http://ec.europa.eu/justice/data-protection/article-29/documentation/opinionrecommendation/files/2013/wp202_en.pdf 8 https://secure.edps.europa.eu/EDPSWEB/webdav/site/mySite/shared/Documents/Supervision/Guidelines/16- 11-07_Guidelines_Web_services_EN.pdf 9 https://secure.edps.europa.eu/EDPSWEB/webdav/site/mySite/shared/Documents/Supervision/Guidelines/15- 12-17_Mobile_devices_EN.pdf

text: https://secure.edps.europa.eu/EDPSWEB/edps/EDPS/Publications/Strategy2015 11 The process covered web services and mobile applications.

text: These considerations are made at the time of drafting these guidelines and may change in time.

text: Even if a mobile application processes personal data only on the device, the obligations of

text: Article 5(3) of Directive 2002/58/EC

text: (ePrivacy) still apply. 14 In consultation when the present document was published. 15 https://secure.edps.europa.eu/EDPSWEB/webdav/site/mySite/shared/Documents/Supervision/Guidelines/16- 03-21_Guidance_ISRM_EN.pdf

text: Directive

text: of the European Parliament and of the Council of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications), OJ L 201, 31.7.2002, p. 37. 17 See footnote 8. 18 See footnote 7

text: More information on the minimum information required and information to users in general can be found in the EDPS ‘Guidelines on European institutions and bodies’ accountability for the protection of personal data processed through IT systems’ (see footnote 14).

text: See sections 4.1.2 and 4.1.3.

text: See footnote 14 22 https://secure.edps.europa.eu/EDPSWEB/webdav/site/mySite/shared/Documents/Supervision/Papers/14-07- 14_transfer_third_countries_EN.pdf 23 See footnote 9.

text: ‘OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted.’ - https://www.owasp.org/index.php/Main_Page 25 European Union Agency for Network and Information Security: http://www.enisa.europa.eu/

text: E.g. https://www.enisa.europa.eu/activities/Resilience-and-CIIP/critical-applications/smartphone-security- 1/smartphone-secure-development-guidelines or https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks 27 Data actually processed by the mobile application during its normal operations. 28 Synthetic data are data generated to meet specific needs like protecting the confidentiality of personal data.

text: https://www.owasp.org/index.php/Man-in-the-middle_attack Transport Layer Security (TLS): ‘The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.’ See for example RFC 7525 ‘Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)’ (https://tools.ietf.org/html/rfc7525) or the reports by ENISA ‘on cryptographic protocols’ (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/study-oncryptographic-protocols) or on ‘Algorithms, key size and parameters (2014)’ (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-size-andparameters-report-2014)

identifier: EDPS riktlinjer (2016)

amnesord:
Technologies
Mobile Devices & Apps

publisher: Europeiska datatillsynsmannen

sprak: en

title: Mobile Applications

serie: riktlinjer

text: Guidelines on the protection of personal data processed by

type: rubrik

text: mobile applications

text: provided by European Union institutions

text: November 2016

type: stycke

text: EXECUTIVE SUMMARY

text: 2 | P a g e

text: 1. Introduction

text: 1.1. The Guidelines

text: 1 When individuals use a mobile application developed by an EU institution, body or agency (‘EU institution’), the EU institution is responsible for ensuring compliance with the data protection principles, in particular with Regulation 45/2001 (‘the Regulation’) in order to guarantee the rights to privacy and to the protection of the personal data of those individuals.

text: 2 As the independent supervisory authority competent for the processing of personal data by the EU institutions, the European Data Protection Supervisor (EDPS) may among other tasks issue Guidelines on specific issues related to the processing of personal data . The present Guidelines are the result of a process where the EU institutions have been consulted.

text: 3 These guidelines provide practical advice and instruction to the EU institutions as controllers on the application of the Regulation to the development and the operation of mobile applications developed by the EU institutions. They are aimed at DPOs and DPCs within each EU institution, as well as IT and IT security staff, mobile applications business owners and other administrative services concerned with the design or operation of mobile applications.

text: 4 While the purpose of these guidelines is to make it easier for EU institutions to fulfill their obligations, they do not take away any of the responsibility of the EU institutions applying them. The measures recommended in these guidelines are not intended to be exhaustive or exclusive. They are flexible enough to allow the EU institutions to start the expected process on accountability, and to be future oriented by considering expected legislative changes. EU institutions may choose alternative, equally effective, measures other than the ones presented in this paper taking into account their specific needs. Their effectiveness will need to be justified in writing.

text: 1.2. Technical background

text: 5 Mobile applications are software applications running on smart devices, in particular mobile ones like smartphones and tablets. Most of them are designed for wide-ranging and targeted interaction with web resources. They may also process location data and other contextual information collected by many sensors found in any smart device. Mobile applications are also able to exchange information via many network interfaces with other connected devices.

text: 3 | P a g e

text: 6 The operating systems (OS) running on these smart devices interact with those sensors and interfaces through software libraries and data structures (hereafter called APIs ). The mobile applications use the API to read information from sensors and exchange data with basic services. 7 The Article 29 Data Protection Working Party provided guidance on this topic in their ‘Opinion 02/2013 on apps on smart devices’ . The Opinion targets commercial mobile applications, and provides a comprehensive analysis with recommendations to all parties involved in the development and operation of mobile applications, including developers, OS and device manufacturers, and mobile applications stores. The general recommendations of this opinion are also valid for mobile applications provided by EU Institutions and are taken into account in the present Guidelines. 8 The EU institutions have started developing mobile applications for smart mobile devices to access their web services and provide new services. 9 This document focuses on the responsibilities of the EU institutions for the development and operation of mobile applications. As well as ensuring compliance, personal data protection is essential in order to obtain users’ acceptance of the services, and thus foster the use of EU institutions’ mobile applications.

text: 2. Scope, methodology and structure of the Guidelines

text: 2.1. Scope

text: 10 These Guidelines provide advice on compliance with data protection rules in the context of the use of mobile applications developed and provided by the EU institutions. They address, in particular the development and operation of mobile applications to interact with the institutions’ online information resources.

text: 11 This document does not focus on:  EU institutions’ web services,  the use of mobile devices by EU institutions’ staff for professional purposes.

text: 12 Those topics are dealt with in other EDPS thematic guidelines, such as the EDPS ‘Guidelines on the protection of personal data processed through web services provided by EU institutions’ and the ‘Guidelines on the protection of personal data in mobile devices used by European institutions’ , respectively.

text: 4 | P a g e

text: 2.2. Methodology

text: 13 This document fits into action 8 of the EDPS Strategy 2015-2019 , aiming to promote data protection culture, and at increasing the accountability towards data protection requirements in the institutions through specific guidance. In particular, the EDPS has identified a need for specific guidance in protecting personal data when the processing operations are ‘technology intensive’. 14 The process leading to these Guidelines was designed as a structured open dialogue with the EU institutions. The core steps/elements of this process are:  a survey as a fact-finding exercise for collecting facts and reaching a better understanding of the EU institutions’ position on the subject-matter;  a workshop held on the topic and based on an orientation document preliminarily sent to the participants of the workshop, where the EDPS also presented the survey results;  the review of best practices on mobile applications;  the preliminary draft of the Guidelines sent to EU institutions for their feedback; and  taking into account such feedback, the finalisation of the Guidelines.

text: 2.3. Structure

text: 15 This document is structured as follows:  Section 1 and 2 introduce the Guidelines and describe scope, methodology and structure.  Section 3 presents some specific risk associated to mobile applications.  Section 4.1 outlines the general principles of data protection applied to the processing of personal data by mobile applications.  Section 4.2 covers mobile applications specific security issues.

text: Text in italics and inside a box represents examples and clarifications to the content of the text above. Rx: Recommendations come in boxes like this. Text with further advice and detail may precede or/and follow the box.

text: 3. Specific risk factors linked to mobile applications

text: A survey (December 2013) commissioned by the UK’s Information Commissioner’s Office found that 62% of persons who have downloaded a mobile application are worried about the way mobile applications use personal data and that 49% of mobile applications users have decided not to download a mobile application due to privacy concerns.

text: 5 | P a g e

text: 16 The use of mobile applications introduces specific issues to take into account when managing risks, which include :  More and more sensitive data are collected.

text: Mobile applications can collect large quantities of personal information from their many sensors, including location, biometric and other sensitive data. This information, processed together with the records of users’ interaction with the web service, could also be used to build users’ profiles and pose risks to their fundamental rights.  Potential lack of data protection safeguards in view of the seamless interaction users expect from the smart mobile device. It is more difficult, in the mobile context, to adequately inform users about the processing of their personal data than in the desktop environment (besides other factors, because of a smaller display size).  Lack of information about data protection and security features of a mobile application. Users are not adequately informed about the use of encrypted communications by the mobile application, whereas in many browsers the use of encryption (https) is usually visually displayed though icons, specific colour background etc.  Lack of control over the underlying software layers: Device and operating system (OS) manufacturers provide the software layer interacting with the hardware (including sensors) and the APIs enabling the processing of the smart device data by the mobile applications. These components define the granularity of the mobile application developers’ control over personal data processing and the configuration capabilities of services provided through the mobile application. Some mobile OSs do not offer the capability of defining in sufficient precision what personal data a mobile application may use. Since, at least for commercial mobile applications, they very often process categories of data that are not necessary for the specific purpose of the mobile application, this limitation heavily reduces users’ control over their personal data and puts into question the validity of their consent, unless the developer of the EU institution’s mobile application mitigates this problem by designing such features at the mobile application level.  Security measures strongly depend on the OS and the security services it provides. In general, smartphones and tablets’ standard environments still offer lower security than traditional computers. Unlike the applications running on desktop computers, mobile applications operate in changing environments usually not under control of the EU institution. They may use insecure third party services or even compromised, malicious access points or ‘jailbroken’, ‘rooted’ devices out of the control of the vendor.  Use of external contractors who may have a poor data protection culture and practices: Current commercial mobile applications do not always provide adequate

text: 6 | P a g e

text: safeguards to protect personal data. They may lack transparency and information to data subjects, along with specific privacy policies. In addition, they may not obtain free, specific, unambiguous and informed consent. They may disregard data protection principles such as purpose specification and limitation or data minimisation. Security measures could also be inadequate.

text: 4. Obligations, recommendations and best practices

text: 4.1. General principles for personal data processed by mobile applications

text: R1:Assess whether the mobile application processes personal data and which. 17 Personal data are processed when the mobile application interacts with a web service, or even when it just interacts with the smart device . Examples of such interactions are providing contact details to subscribe to a newsletter or location data to find the closest centre providing the services sought or registering contact details in the agenda or saving data downloaded from a web service on local storage. 18 The general principles, obligations and recommendations given in the EDPS ‘Guidelines on the protection of personal data in IT governance and IT management of EU institutions’ apply to the development and operation of mobile applications, too.

text: All processing operations done through a mobile application must be lawful and the information to users must be complete. 19 Some obligations of major concern for mobile applications, in the light of the specific risks outlined in section 3, are further developed as follows. 20 The EU institution should take decisions on the design and operation of the planned mobile application based on an information security risk assessment (see EDPS ‘Guidance on Security Measures for Personal Data Processing - Article 22 of Regulation 45/2001’) .

text: 21 The EU institution should analyse the compliance of its intended processing before implementing the mobile application during the feasibility check, business case design or an equivalent early definition stage of the project. The compliance analysis must be open with respect to its outcome: it could also lead the EU institution to not use a mobile application to support a certain task but rather to choose an alternative solution. It is important to involve the DPO as early as possible to provide knowledgeable advice on data protection matters.

text: 7 | P a g e

text: 4.1.1. Necessity and proportionality, purpose specification and limitation

text: R2:The mobile application must collect only those data that are strictly necessary to perform the lawful functionalities as originally identified and planned. 22 What the mobile application will do with the user’s personal data needs to be clearly communicated to users before the installation of the mobile application. E.g. through the mobile application description provided at the mobile application store or in an EU institution website page about the mobile application. 23 No processing for further incompatible purposes must be performed by the mobile application. Where the EU institution’s internal rules provide for a change of purpose, this needs to be clearly communicated to the user before it becomes effective. 24 The mobile application must not communicate personal data to the EU institution or a third party unless this transfer is necessary for the purpose of the mobile application. Transfers should clearly be indicated in the information about the mobile application.

text: 4.1.2. Managing consent

text: For a detailed analysis of the considerations to take into account in light of Regulation 45/2001 and Article 5(3) of the ePrivacy Directive and the recommendations to be followed in relation to the consent and information to users please see the EDPS ‘Guidelines on the protection of personal data processed through web services provided by EU institutions’ and the Article 29 ‘Opinion 02/2013 on apps on smart devices’ . R3:Adequately inform users and obtain their consent before installing any application on user’s smart mobile device.

text: 25 All requirements of valid consent apply to mobile applications. Users have to be given the option to change their wishes and revoke their decision at any time. 26 Consent needs to be collected before any reading or storing of information from/onto the smart mobile device is done. All essential elements of valid consent should be present at that time. That also means obtaining valid consent before installing the mobile application. E.g. through a setup page inside the mobile application. 27 An essential element of consent is the information provided to the user. The type and accuracy of the information provided needs to be such as to put users in control of the data on their smart mobile device to protect their own privacy. 28 In particular the consent should be:

text: 8 | P a g e

text:  Specific: The information provided to the user should highlight the type of data processed through the mobile applications, along with any related purposes.  Expressed through an active choice: The procedure and tools used to obtain consent should allow users to express their wishes, with no margin of doubt about what their decision is. As such, those procedures and tools need to make sure that users actively confirm that they have been informed clearly and comprehensively about the way that their data will be processed, and that they fully consent to this.  Freely given. Users should be given the opportunity to make a real choice, e.g. without being put under pressure or presented with a ‘take it or leave it’ approach. 29 Mobile applications must provide the users with:  Real choices on personal data processing: The mobile application must ask for granular consent for every category of personal data it processes and every relevant use. If the OS does not allow a granular choice, the mobile application itself must implement this. In this case, the mobile application must clearly inform the user before the installation that, despite the OS settings, the user will have the opportunity of choosing what category of personal data to consent to through adequate functionalities directly provided by the mobile application;  Functionalities to revoke their consent: The mobile application must feature functionalities to revoke users’ consent for each category of personal data processed and each relevant use. The mobile application must also provide functionalities to delete users’ personal data where appropriate.

text: 4.1.3. Providing information to users in an effective way

text: R4:Provide appropriate information to the users so that they can take informed decisions. 30 The size of the smart mobile device screen and the seamless interaction mobile users expect to have with their device should not prevent users from being provided with the information they are entitled to under the Regulation. 31 The mobile application should therefore feature:  A layered notice, where the initial notice to the user contains the essential information and further information is progressively available through subsequent links. The information should be easily accessible and highly visible.  Contextual real-time information can be provided through icons and images to show when certain categories of personal data (e.g. location or biometrics) are processed or certain measures are being implemented (e.g. security measures

text: 9 | P a g e

text: like the use of encryption). Video and audio could also be used to inform and raise users’ awareness.

text: 4.1.4. Providing mobile applications and choice of the supported hardware and OSs

text: R5:Evaluate the privacy capacities of target OSs and hardware. 32 When planning to deliver a mobile application and deciding for which hardware and operating systems (specifically which version) it shall be available, the EU institution needs to perform an assessment taking into account the nature of the personal data processed and the specific risks of any processing operations performed through mobile applications in smart mobile devices. The assessment also needs to take into account the targeted OSs’ data protection and security features and practices.

text: If the mobile application is planned to process health data, and the OS does not allow enough granularity of choice for the user to decide what services/information the mobile application has access to, the EU institution might decide not to deliver a mobile application for that OS.

text: 4.1.5. Mobile application distribution and mobile application stores obligations

text: R6:Evaluate the data protection impact of using a mobile application store to distribute a mobile application. 33 Mobile applications are usually distributed via mobile application stores, which are often owned by the same market operators as those providing the OSs and the mobile devices. 34 The EU institution should take into account that these mobile application stores are third party services (see section 4.1.6), controllers of their own for the personal data they manage and subject to all relevant obligations. The EU institution must give mobile application users all necessary information about controllers’ respective responsibilities before they install the mobile application . 35 If the EU institution decides to distribute mobile applications through its own means, the following obligations need to be considered:  enable the provision of the necessary information to prospective users before the mobile application installation, in order to obtain informed consent (see also consent related issues above in this section);  ensure integrity of mobile applications against malicious or accidental unauthorised changes aimed at installing malicious mobile applications;  make mobile applications new functionalities and bug fixes rapidly available for download;  the distribution is reliable, which involves checking the security of the means chosen and providing users with information on the checks performed.

text: 10 | P a g e

text: 4.1.6. Third party components or services in mobile applications

text: R7:Assess the data processing features of a third party component or of a third party service before integrating it into a mobile application.

text: Where third party components or services are used within the EU institution’s mobile applications, the EU institution should assess how these tools collect and process personal data, including transfers from the mobile applications to servers operated by a third party. The EU institution should also take account of general considerations regarding the use of third parties in IT systems management, as explained in the EDPS ‘Guidelines on European institutions and bodies’ accountability for the protection of personal data processed through IT systems’ . Third party components include software development kits (SDKs), programming frameworks and libraries, either for generally making the development of mobile applications easier, or for specific purposes, such as displaying photos or maps, or communicating via social media. Third party services may receive data from the mobile application and process it, e.g. to perform analytics on the usage of the mobile application or they may host specific content for the mobile application on central servers. 36 If third party servers operated outside the EU and the EEA are used, it is imperative to take into account the applicable rules regarding data transfers to third countries. 37 For detailed technical and practical guidance on transfers of personal data to third countries and international organisations by EU institutions, see also the EDPS Position Paper of 14 July 2014 ‘on the transfer of personal data to third countries and international organisations by EU institutions and bodies’ .

text: 4.2. Security

text: 4.2.1. Security of processing

text: R8:Apply appropriate information security risk management to the development, distribution and operation of mobile applications. 38 One fundamental principle of data protection is security. Through an information security risks management process the EU institution needs to identify the relevant risks to the personal data processed through the mobile applications provided and then to take appropriate organisational and technical measures to protect that personal data. Detailed advice on information on information security risk management can be found in the EDPS ‘Guidance on Security Measures for Personal Data Processing - Article 22 of Regulation 45/2001’ . 39 The security measures produced by the information security risk management process will constitute part of the non-functional requirements of the mobile application being

text: 11 | P a g e

text: considered. This process needs to be performed as soon as possible to guarantee the better security with the lowest cost: data protection, or security, by design. 40 It is then very important to implement these security measures with the right technology. For that reason, it is important to stay abreast of new developments in threats and vulnerabilities, and their most effective countermeasures. This can be done in various ways including:  having security consultancy for the development of mobile applications;  using information sources like the OWASP community where the most common current threats and vulnerabilities for all kind of applications are described, together with possible countermeasures; or  using guidelines from ENISA .

text: 41 If external contractors are used, the EU institution needs to ensure that the processor has put in place the appropriate technical and organisational security measures that the processor applies to protect personal data.

text: 4.2.2. Data breaches

text: R9:Adopt internal procedures for the handling of security and data breaches that foresee in particular the notification of the occurrence of such events by the controller to the DPO.

text: A data breach in one of its mobile applications should be reported internally according to the EU institution’s policy on the handling of security and data breaches. The DPO should assess and document the breach and the measures taken in reaction for future assessment and verification and consider whether it is appropriate to inform the EDPS. The EDPS response to such data breaches will obviously depend on a number of factors including the seriousness of the breach, the type and volume of data involved, the numbers of users affected, the location of the recipients, etc. 42 Data breach notification to the users is highly recommended. Accountability requires that the users should be adequately and promptly informed on incidents concerning their data, on how to protect themselves and on the incident follow-up insofar as it relates to possible risks for them.

text: 4.2.3. Secure development, operation and testing

text: R10: The EU institution should have documented secure development policies and processes for mobile applications, including operation and security testing procedures following best practices. 43 An integrated security testing approach plays an essential role in the development phase (with security static code analysis and dynamic approaches such as penetration testing).

text: 12 | P a g e

text: 44 Adequate and up-to-date training on mobile application secure development, operation and security testing should be provided to the IT staff involved. 45 The EU institution can benefit from existing relevant best practices and guidelines . 46 No ‘production’ data must be used for testing in the implementation or acceptance phases. Where the simple production of random test data sets is insufficient in a specific context, more sophisticated techniques for creating synthetic data need to be used, which mimic the structure of real world data but do not contain any personal data. The generation of synthetic data is often based on an analysis of the structure and other specific features of anonymised data sets from the real world. Synthetic data should enable the creation of realistic datasets without compromising the privacy of the users.

text: 4.2.4. Vulnerability management

text: R11: Adopt and implement a vulnerability management process appropriate to the development and distribution of mobile applications. 47 The EU institution needs to regularly test the mobile applications developed for vulnerabilities that may endanger the personal data processed through them but also the smart mobile devices of the users installing the mobile applications. 48 The EU institution must have a process in place to react to reports on security issues of its mobile applications, whether directly from users or via the media or other channels. 49 In addition, the EU institution needs to monitor and address the vulnerabilities present in the components used to develop its own mobile applications, e.g. libraries, frameworks, etc. The manageability of those components, e.g. the frequency of upgrades, need to be considered when choosing a particular component or other. 50 The vulnerability management process shall ensure that updated mobile applications are provided as early as possible and that users are alerted to the need to install the updates. 51 The OSs and the physical mobile devices will reach their end-of-life and will no longer be supported by their vendors. It is important for the EUIs to consider which OSs versions are supported by their mobile applications.

text: 4.2.5. Protection of personal data in transit and at rest

text: 52 When personal data are sent over public or not-trusted networks such as the Internet they need to be protected against the risks raised by those networks.

text: 13 | P a g e

text: The EU institution needs to take into account threats such as ‘man in the middle’ attacks , or unsecure Wi-Fi hot-spots with no or weak encryption.

text: 53 Mobile applications should use encryption to protect these communications through an adequate encryption layer (like TLS ) configured properly, together with a secure management of the relevant cryptographic keys .

text: E.g. never ’hard code’ or store cryptographic keys in the device where an attacker could recover them, such as plain text data files or property files.

text: 54 Personal data also needs to be protected when stored in the smart mobile device, e.g. through effective encryption of the personal data.

text: 14 | P a g e

text: Annex I. Glossary

text: Accountability

text: Principle intended to ensure that controllers are more generally in control and in the position to ensure and demonstrate compliance with data protection principles in practice. Accountability requires that controllers put in place internal mechanisms and control systems that ensure compliance and provide evidence – such as audit reports – to demonstrate compliance to external stakeholders, including supervisory authorities.

text: Consent

text: In data protection terminology, consent refers to a freely given, specific and informed indication of the wishes of a data subject, by which he/she agrees to personal data relating to him/her being processed. Consent is an important element in data protection legislation, as it is one of the conditions that can legitimise processing of personal data. If it is relied upon, the data subject must unambiguously have given his/ her consent to a specific processing operation, of which he/she shall have been properly informed. The obtained consent can only be used for the specific processing operation for which it was collected, and may in principle be withdrawn without retroactive effect.

text: Data controller

text: Under the Regulation, the data controller is the institution or body that determines the purposes and means of the processing of personal data. The data controller is also responsible for the security measures protecting the data.

text: Data minimization

text: The principle of ’data minimization’ means that a data controller should limit the collection of personal information to what is directly relevant and necessary to accomplish a specified purpose. They should also retain the data only for as long as is necessary to fulfil that purpose. In other words, data controllers should collect only the personal data they really need, and should keep it only for as long as they need it.

text: Data security

text: According to Article 22 of the Regulation, the data controller shall implement appropriate technical and organisational measures to ensure an appropriate level of security in relation to the risks represented by the processing and the nature of the personal data to be protected.

text: Mobile application

text: A computer program designed to run on a smart mobile device such as smartphones or tablet computers. Although they are capable of processing and storing information locally, most mobile applications are connected to web services.

text: Mobile application store

text: A digital distribution platform for mobile applications. They are typically online stores, where users can browse through these different mobile application categories, view information about each mobile application, and acquire the mobile application. Most important mobile application stores are controlled by their owner and prospective mobile applications need to pass an approval process.

text: Personal data

text: According to Article 2 (a) of the Regulation: ‘Any information relating to an identified or identifiable natural person, referred to as "data subject" - an identifiable person is someone who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his or her physical, physiological, mental, economic, cultural or social identity’.

text: 15 | P a g e

text: Processing (of personal data)

text: According to Article 2 (b) of the Regulation, processing of personal data refers to ‘any operation or set of operations which is performed upon personal data, whether or not by automatic means, such as collection, recording, organisation, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blocking, erasure or destruction.’

text: Right of information

text: Everyone has the right to know that their personal data are processed and for which purpose. The right to be informed is essential because it determines the exercise of other rights. The right of information refers to the information that shall be provided to a data subject whether or not the data have been obtained from the data subject.

text: 16 | P a g e

text: Annex II. References

text: Article 29 Data Protection Working Party Opinion 02/2013 on apps on smart devices: http://ec.europa.eu/justice/data-protection/article-29/documentation/opinionrecommendation/files/2013/wp202_en.pdf

text: EDPS Guidelines on the protection of personal data processed through web services provided by EU institutions:

text: EDPS Guidelines on the protection of personal data in mobile devices used by European institutions: https://secure.edps.europa.eu/EDPSWEB/webdav/site/mySite/shared/Documents/Supervision /Guidelines/15-12-17_Mobile_devices_EN.pdf

text: EDPS Strategy 2015-2019: https://secure.edps.europa.eu/EDPSWEB/edps/EDPS/Publications/Strategy2015

text: EDPS Guidelines on the protection of personal data in IT governance and IT management of EU institutions:

text: EDPS Guidance on Security Measures for Personal Data Processing - Article 22 of Regulation 45/2001: https://secure.edps.europa.eu/EDPSWEB/webdav/site/mySite/shared/Documents/Supervision /Guidelines/16-03-21_Guidance_ISRM_EN.pdf

text: EDPS Position Paper of 14 July 2014 on the transfer of personal data to third countries and international organisations by EU institutions and bodies: https://secure.edps.europa.eu/EDPSWEB/webdav/site/mySite/shared/Documents/Supervision /Papers/14-07-14_transfer_third_countries_EN.pdf

text: OWASP webpage: https://www.owasp.org/index.php/Main_Page. ‘OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted.’

text: European Union Agency for Network and Information Security: http://www.enisa.europa.eu/

text: ENISA Smartphone Secure Development Guidelines: https://www.enisa.europa.eu/publications/smartphone-secure-development-guidelines

text: Projects/OWASP Mobile Security Project - Top Ten Mobile Risks: https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_- _Top_Ten_Mobile_Risks

text: RFC 7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS): https://tools.ietf.org/html/rfc7525

text: ENISA Study on cryptographic protocols: https://www.enisa.europa.eu/publications/studyon-cryptographic-protocols

text: ENISA Algorithms, key size and parameters report 2014: https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014

text: 17 | P a g e