Finally, the controllers restrict the handling of the pseudonymised data to the extent this is necessary to mitigate any remaining risk of reversal of pseudonymisation. 38 This includes the measures taken to secure any pseudonymised data, pseudonymisation secrets or other additional information stored on devices used by data subjects, see paragraph 110 . Adopted - version for public consultation 31 ANNEX – EXAMPLES OF THE APPLICATION OF PSEUDONYMISATION Section 2.3 highlighted the benefits of pseudonymisation in light of some of the relevant GDPR principles and GDPR provisions (data protection by design and default, processing for research and statistical purposes, security of processing, processing for the purpose of the legitimate interests of the controller, further processing and transfer of pseudonymised data). The ten following sections intend to illustrate by way of real-world scenarios the use and benefits of pseudonymisation. These examples are listed in Table 1 in function of the GDPR provisions that pseudonymisation helps implement. Note that Member State law may require modifications to the setups described here in some cases. GDPR Article GDPR Provisions Example numbers Art. 5(1)(c) Data minimisation 1, 2 and 3 Art. 5(1)(b) Purpose limitation Art. 5(1)(f) Confidentiality Art. 5(1)(d) Accuracy 4 Art. 89(1) Safeguard for processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes 5 Art. 32(1) Security of processing 6 Art. 6(1)(f) Lawfulness of processing for the purposes of legitimate interests 7 Art. 6(4) Processing for a purpose other than that for which the personal data have been collected (further processing) 7 and 8 Art. 46 Transfers subject to appropriate safeguards 9 Art. 5(1)(a) Fairness 10 Table 1: Examples of use and benefits of pseudonymisation Example 1: Data minimisation and confidentiality in internal analysis Context and purpose of processing A Company provides an app that dispenses medical advice based on the description of symptoms entered into the app by users. It has tasked one of its divisions to perform quality control. In the course of quality control, it is established (using data collected with explicit consent of the app users) whether the dispensed advice conforms with established medical knowledge, and it is established whether and which patients need to be notified in critical cases of inappropriate advice given by the app. User id, med data, feedback, device token Device token, notification User Pseudonym, med data, feedback Pseudonym, notification Operating division Quality control Adopted - version for public consultation 32 In order to meet the last purpose, the analysed data need to retain a link to the data subjects. Notifications to patients are not directly issued by the quality control division, but by regular operation staff. Problem to be solved Preserve the link between data and data subjects while ensuring compliance with the data minimisation principle, Art. 5(1)(c) GDPR, and data protection by default, Art. 25(2) GDPR, in particular with regard to access to data allowing attribution of data to data subjects, as well as reducing confidentiality risks thereby contributing to compliance with Art. 5(1)(f) GDPR. Original Data Records containing: the user id, the device token, the symptoms recorded by the app, the advice dispensed, the user feedback (optional). Pseudonymisation domain Quality control division. Pseudonymised Data Records containing: a pseudonym based on the user-id, (categorized) symptoms recorded by the app, the advice dispensed, the user feedback. Additional information Table linking user-id and pseudonym Lookup table linking user id and device token. Processing of pseudonymised data The quality control division is provided with the (pseudonymised) extract of data received by the backend of the app. The members of the division are not involved in, and have no further access to data stemming from service provision. It performs the analysis. If the need arises to inform a data subject, it conveys the pseudonym, and the message to the operative division. The operative division has access to the additional information. Hence, it is able to identify the users, and convey the messages to them employing a notification service and the device token. Example 2: Separation of functions allowing for data minimisation, purpose limitation, and confidentiality Case id, employee pseudo, verif. result Document request Business data, employee identity + qualifications Case id, Business data employee pseudo, qualif. Case id, employee pseudo, qualif., verif. req. Verif. centre Assistance Agency Business Employee docs sample sample Adopted - version for public consultation 33 Context and purpose of processing An agency is tasked with paying out subsidies to businesses according to criteria applying to both the businesses themselves, and their employees. Interested businesses submit applications containing data that prove that they meet those criteria, e.g. data on turnover and employee qualification. The agency verifies that the criteria are met. For a random sample of applicants, it requests further documents proving identity and qualifications of employees. Problem to be solved Minimise access to employee data while retaining the ability to check the identity of the employees — in randomly chosen cases or in cases of special concern (suspicion of fraud) — in order to comply with the data minimisation principle, Art. 5(1)(c) GDPR, and data protection by default, Art. 25(2), with regard to access to data allowing attribution of data to employees, as well as reducing confidentiality risks and the risk that the received data about an employee is used outside the context of the application it is contained in. Original data The bulk of the data processed is non-personal business data. Data concerning the employees contain information about their identity (name, demographics), and professional qualifications. Pseudonymisation domain The Assistance agency. Pseudonymisation The Agency sets up a separate organisational unit, which serves as a verification centre with the sole task of safeguarding the identity of the employees by handling the pseudonymisation and, if called upon in individual cases, the verification of the integrity of the applications. The verification centre receives the applications, stores all attributes describing the civil identity of the employees (names, date of birth, etc.) in a lookup table connecting this data with the application registration number and a pseudonym, replaces all those attributes by the pseudonym and turns over the result to the Agency. For each application, new pseudonyms are randomly chosen in order to prevent the linkage of data records across applications. Pseudonymised data − Data concerning the qualification of the employees − Pseudonyms for employees Additional information Lookup table linking employee pseudonyms with identifying data. Processing of pseudonymised data The agency assesses the applications. In randomly chosen cases or in cases of special concern, it turns over the pseudonym of an employee and the data concerning their qualification to the Verification centre for verification. The Verification centre uses the lookup table to establish the civil identity of the employees and directs an inquiry to the business requesting additional documents for verification of identity and qualifications claimed. Adopted - version for public consultation 34 Variant (using commitments) It is possible to avoid the establishment of the additional Verification centre by using cryptographic means. The Agency provides the businesses with a web app that allows the businesses to perform the pseudonymisation themselves. The pseudonyms include cryptographic commitments 39 of the employee documentation. In randomly chosen cases or in cases of special concern, the agency (or possibly a dedicated organisational unit thereof) requests the original documents proving identity and qualification of certain employees chosen by the Agency from the respective business. The binding property of the commitment assures that the Agency has full control over which documents to request, and the business is not able to substitute data of one employee for that of another . Example 3: Data minimisation and purpose limitation in the course of external analysis 39 Roughly speaking, a cryptographic commitment is a cryptographic protocol that allows one party (called the prover) to commit to holding some data by sending a message m which is derived from the data to another party (called the verifier) while hiding its content from the verifier. The verifier may ask the prover to disclose the original data, and is able to ascertain whether the message m has actually been computed starting from the original data as presented. One says that the prover is bound to the data. For a simple (but not verifiably strong) commitment, it suffices to compute m as the cryptographic hash of the input data extended by a secret random nonce of sufficient entropy. Assistance Agency Business Business data, employee qualifications, employee pseudonym, commitment to employee docs Document request Employee docs, opening of commitment sample Practice Register Practice data, temp patient pseudo, patient medical data Data flow for Storage Trust centre Adopted - version for public consultation 35 Context and purpose of processing A Register collects data about dental implants for purposes of quality control. The Register uses the data to analyse the quality of the implants, and provide a summary of the results to the companies providing the material for making them. It also provides feedback to the practices on the quality of the care provided. Moreover, the stored data may be retrieved by subsequent caregivers upon consent by the data subjects. (Persons working for the register have no access to medical data beyond what is stored in the register.) Problem to be solved Retain the link between data and data subjects while ensuring compliance with the data minimisation principle, Art. 5(1)(c) GDPR, and data protection by default, Art. 25(2) — in particular with regard to access to data allowing attribution of data to data subjects — as well as strengthening purpose limitation, and reducing confidentiality risks. Nobody accessing data in the register should be able to attribute it to the data subjects and use them for incompatible purposes, e.g., to address data subjects for advertising purposes. Original Data − Data identifying patient − Information about the implant, the operation, and other medical data about the patient − Data about the dental practice Pseudonymisation domain Register Pseudonymised data − Patient pseudonym − Information about the implant, the operation, and other medical data about the patient − Data about the dental practice Additional information − Lookup table collating patient identifying data with pseudonyms − Original medical data together with patient identifying data held by the dentists’ practices Pseudonymisation process Dentists transmit medical data and data relating to their practice accompanied with a temporary patient pseudonym to the Register. They also transmit those temporary pseudonyms together with patient Practice Register temp request id, data request Data flow for retrieval temp request id, medical data Trust centre Adopted - version for public consultation 36 identifying data to a designated Trust Centre 40 for safeguarding. The Trust Centre assigns a permanent patient pseudonym (either an existing pseudonym if the Trust Centre has a record for the patient on file, or a newly generated one), stores the new entry (if any) in the lookup table and transmits the permanent pseudonym along with the temporary pseudonym to the Register. The Register stores the data it received from the dentist together with the patient pseudonym it received from the Trust Centre. All parties delete the temporary patient pseudonym. When patients opt to allow dentists and other medical practitioners treating them subsequently to retrieve data relating to them, those practitioners send the data request by the same procedure to the Registry. The registry is able to lookup all data relating to the patient, and transmit the retrieved data back to the requesting practice. Processing of pseudonymised data The Register is able to link all cases relating to a given patient, or a given practice. Data from a given practice is analysed to provide aggregated data on the quality of care provided by this practice. Data relating to a given practice can be conveyed using the procedure described above to any subsequent practitioner treating that patient. All medical data, including data on the implants used, are analysed to obtain findings regarding the quality of those implants. Additional safeguards particularly pertinent in this scenario 1 The original data are kept confidential by the controllers who collected them, under obligation of professional secrecy. 2 The Trust Centre safeguards the lookup table connecting the civil identity of the data subjects with pseudonyms used for long-term storage. 3 All participating entities are bound by contract or another legal act to execute the protocols for the exchange of data faithfully. Example 4: Safeguarding identity – confidentiality and accuracy A medical laboratory wants to notify test results to its users via a mobile message. For this purpose, it enrols users' mobile phone numbers (applying the necessary confirmation procedure). Before medical analysis is carried out, the laboratory transforms the identity and contact data of the patients and those relating to the date, time and scope of the test into a pseudonym. Those pseudonyms are coded as barcode or a QR codes, which is attached to test tubes containing the patients’ samples. The pseudonymi sation procedure assures that even samples pertaining to data subjects with very similar identity and contact data carry widely differing pseudonyms. Personal and contact data in intelligible format are kept separately by the laboratory. The analysis is carried out using only the pseudonyms to label the case. Afterwards, the procedure for notifying the results of the examination to the customer can be automated with lower risk of human errors and potential identity exchanges (for example in case of homonymy or in presence of similarities in contact data) and the accuracy of the data is reinforced. The richer the number of attributes that 40 Here, a trust centre is an entity that performs security critical processing operations under contract with the relying parties. Adopted - version for public consultation 37 are transformed into a pseudonym, the less likely it is that test results are inappropriately assigned to data subjects, and the lower is the likelihood of negative impacts on data subjects. Example 5: Secondary use for research Context and purpose of processing A Data Centre (established by a consortium of universities as a separate organisational unit at one of its members) collects data about the health and medical treatment of participants of a large longitudinal research project as well as data about occupational exposure to health hazards. The Data Centre receives health data from participating university hospitals, collects the data about occupational exposure to health hazards from a Labour agency that this agency has previously collected from employers. The centre provides the results of queries on the data to individual studies upon approval of the request by the data access board. It also co-ordinates access to original medical records for quality control purposes and informs patients of any significant unanticipated risks that studies may have identified. Problem to be solved Collect and link data from independent sources, maintain the link to records at the contributing institutions and to data subjects, while preventing attribution of the data to data subjects by the employees of the data centre and the research groups in compliance with Art. 89(1) GDPR. Original Data − Data directly identifying the patient / employee − Medical data − Data about occupational exposure to health hazards Pseudonymisation domain Data centre Research groups at participating universities. Members of these groups have no access to health records relating to the care of patients at their respective university’s hospital. Pseudonymised data − Different pseudonyms at various stages of processing − Medical data Hospitals Labour agency Result Query SubjID, T-HR- ID, T-MedID Research group Data Centre Trust Centre Adopted - version for public consultation 38 − Data about occupational exposure to health hazards Additional information − Original data maintained at the source institutions (hospitals, employers, labour agency) − Similar data about data subjects held by other medical service providers or by institutions with insight into the employment situation of the data subject provided it is linkable to the above mentioned original data without using directly identifying data − Pseudonym lookup tables held by the Trust Centre Pseudonymisation process For performing the main pseudonymisation processes the consortium employs a Trust Centre. When data subjects sign-up for participation in the project at one of the members of the consortium, they are assigned a medical data ID (MedID), which is computed from data in the Electronic Health Record all members of the consortium that have treated the patient have access to. The hospital collects the human resources ID (HR-ID) used by the Labour agency, transmits it to the Trust Centre together with the MedID and then erases it. Hospitals transmit medical data together with a temporary pseudonym T-Med-ID to the Data centre, and the MedID together with the same temporary pseudonym to the Trust Centre. The Trust Centre requests data about occupational exposure to health hazards from the Labour agency using the HR-ID, which the Labour Agency subsequently transmits to the Data Centre. Again temporary pseudonyms (T-L-ID) are used for this transmission, which are also transmitted to the Trust Centre together with the HR-ID included in the request. The Trust Centre generates a data subject ID (SubjID) for each data subject and maintains a lookup table connecting MedID, HR-ID and SubjID. The SubjID is then combined with the temporary pseudonyms and send on to the Data Centre, which replaces the temporary pseudonyms with the data subject ID (SubjID) in all incoming data and links all data it obtains that contain the same SubjID. Processing of pseudonymised data The Data Centre provides the collected data to research groups upon approval of the request by the data access board. As part of the decision about access to data, the data access board seeks contractual guarantees from the receiving institution that all members of the research group are prevented by technical and organisational safeguards from access to any additional information that would allow attribution of the pseudonymised data to data subjects. Moreover, the institution commits to proceed with any further processing of the data it receives only upon approval by the data access board. Study groups do not receive the raw data stored in the Data Centre, but only the result of queries on the data executed within a secure processing environment. If access to the original data is requested to assure the quality and integrity of research, or if the data subject needs to be informed about hitherto unknown and significant individual risks, then the pseudonymisation process is reversed at the Trust Centre in order to Adopted - version for public consultation 39 enable the necessary processing for those purposes. (The corresponding data flow is depicted with red arrows in the graphic above.) The hospital which submitted the last set of medical data relating to the data subject is responsible for contact with this individual. Additional safeguards particularly pertinent in this scenario Employees working in the Data Centre have no access to medical data from treatment at their institution, which is assured by separating it using organisational and technical means. The Trust Centre is an independent service provider working under contract with and taking instructions only from the consortium’s board. Example 6: Reduction of confidentiality risks Context and purpose of processing A large university hospital seeks to optimise its service portfolio and billing procedures by analysing treatment data. Problem to be solved Allow the analysis of highly sensitive medical data by non-medical administrative staff operating in a mid-level security environment. The ability to provide feedback to care managers on a case specific basis needs to be retained in case irregularities are found in the data. Original Data Per case: − diagnoses, − length of stay, − resources spent on the care of the patient, − diagnostic procedures and therapeutic interventions applied, − patient and case ID, − patient identifying data. Pseudonymisation domain All entities not having legal access to original treatment data identifying the patients Pseudonymised Data Per case: − diagnoses, − length of stay, − resources spent on the care of the patient, − diagnostic procedures and therapeutic interventions applied, − encrypted patient and case ID. High security zone Mid-level security zone Adopted - version for public consultation 40 Additional information − Encryption key − Original hospital records Pseudonymisation process For transmission to a database which operates outside the medical network zone, attributes relevant to the analysis are selected omitting highly individual documents (like discharge letters) and attributes which allow employees outside the medical departments to identify the patients directly. The selected attributes are transmitted together with the encrypted patient and case id for all records not presenting particular confidentiality risks e.g. due to the notoriety of a case, public interest in the patient, or affiliation of the patient with the hospital. Processing of pseudonymised data The analysis of the pseudonymised data is performed relying exclusively on the data in the dedicated database. Only non-medical personnel that has no access to the hospital information system is allowed to work with the database. Pseudonymisation contributes to the security of the data: A person accessing the database without authorisation and without prior knowledge of the health status of the selected patients will not be able to draw conclusions about the health status of any individual. Accordingly, a placement of the database in a mid-level security environment can be considered adequate. Example 7: Risk reduction as a factor in the balancing of interests, and ascertainment of compatibility of purposes Context and purpose of processing A Company provides various services to the public, which are provisioned by web services, and service interfaces placed in a de- militarized zone of the company network. Those services have varying sensitivity, and include online counselling in the course of which information might be revealed that indicates behaviour that, if known, could lead to the data subject being ostracised and severely disadvantaged in public, including very serious discrimination and severe bodily harm (Example: paedophilia). The company employs a web application firewall (WAF), an intrusion detection system and various system logs for detecting attacks against the security of its systems and services. In the case of a security incident, the Company intends to grant access to logged data to an external Computer Security Incident Response Team (CSIRT) for forensic analysis. For purposes acc. to Rec. 49, the Company : web services with WAF and IDS External computer security incident response team Attack patterns Indexed by pseudonymised communication meta-data Other CSIRT customers Attack patterns Anonymous Clear meta-data upon request ? → ! Adopted - version for public consultation 41 CSIRT will also use the data for security services it extends to other customers. Problem to be solved Generally, the grant of access to the data by the Company to the CSIRT, and its subsequent processing by the CSIRT can be considered to be based on legitimate interests, Rec. 49 Due to the sensitivity of some of the services, and the data processed therein, however, those interests may in turn be overridden by the interests of the data subject provided the processed data can be attributed to the data subjects. Likewise, in view of possible consequences of the intended further processing for data subjects, the purposes pursued by transmission to the CSIRT may not be compatible to the purposes of the original processing (online counselling). Original Data Traffic and content data (e.g. queries that triggered the WAF). Pseudonymisation domain CSIRT Pseudonymised Data Filtered traffic and content data with identifying information removed or transformed (in particular IP addresses, access tokens, and login credentials). Pseudonymisation process After real time analysis, data is filtered, identifying information (IP addresses, access tokens, login credentials) transformed by a keyed cryptographic one-way function (provided the information contains sufficient entropy) or removed (otherwise), and the resulting data sets collected in a centralised log repository from which they are extracted for transmission to the CSIRT. Moreover, during the extraction process any content data still contained in the repository is reduced to fragments that do not permit the derivation of any information concerning data subjects beyond the fact that a query they have issued via their browser in the course of the use of Company’s services contained those fragments. Additional information − Original log data. − Cryptographic key. Processing of pseudonymised data The CSIRT analyses the data describing the security incident. In this process, it is able to link various log entries by the filtered and transformed traffic data (e.g., by time, source, and destination), including likewise transformed access tokens or other credentials. The CSIRT may request to obtain those IP addresses in the clear that are clearly linked to the attack and not to legitimate users of the services. The CSIRT anonymises the data to produce information about attack methodology or source, and transmits this information to other customers. Effect Under these conditions, the pseudonymised data transmitted to the CSIRT do no longer permit attribution of the data to specific data subjects by the CSIRT (with the possible exception of persons involved in the attack). Considering those measures, the Company and the CSIRT may consider the risk reduction achieved by pseudonymisation in their assessment whether Art. 6(1)(f) GDPR is a suitable legal basis for their data processing (insofar as it is not already covered by the legal basis Adopted - version for public consultation 42 that allowed the data collection). Moreover, the Company can do likewise in its assessment of compatibility of purposes in light of Art. 6(4)(e) GDPR. Example 8: Risk reduction justifying further processing Context and purpose of processing A Company operates a large web-shop for a variety of products. Data about customers’ purchases is stored and presented in customer accounts. The Company intends to extract data from the underlying database to find correlations between the products or services purchased. Problem to be solved Due to the wide spectrum of products and services offered by the Web- Shop, purchase records may allow significant conclusions to be drawn regarding the data subjects, and may allow an evaluation of personal aspects relating to the economic situation, health, personal preferences, interests, or behaviour of data subjects. In order to be considered compatible to the purpose for which the personal data were initially collected, and avoid profiling of the customers acc. to the criteria in Art. 4(4) GDPR, the data has to be processed in a manner that the analysts can no longer attribute it to specific data subjects. Original data − User profile − purchase history Pseudonymisation domain Team of Analysts Pseudonymised data Purchase history with all individualised entries removed (e.g., clothing with lettering chosen by the customer) Additional information Original customer account. Pseudonymisation procedure The Company extracts the purchase history omitting all individualised entries and directly identifying attributes, and assigns the analysis to an Organisational Unit of Analysts with no access to further customer data. Processing of pseudonymised data The Analysts perform the desired analysis, and summarise the results in aggregate form. Afterwards, the Organisational Unit erases all personal data it holds. Effect The processing performed in this way is unlikely to affect data subjects. The controller can use this effect of pseudonymisation in its assessment of compatibility of purposes according to Art. 6(4) GDPR. Taking also into account the other factors mentioned in Art. 6(4) GDPR and depending on the particularities of the concrete case, the assessment may arrive at the conclusion that the purpose of the analysis can be considered compatible with the purpose for which the personal data were initially collected. Company Customer contact data purchases Purchase histories Customer Web-Shop Analysts Adopted - version for public consultation 43 Example 9: Supplementary measure Context and purpose of the processing A Company that belongs to a group of undertakings controlled by another company outside the EEA would like to use a personnel survey to improve work conditions and talent retention. The company has performed a careful assessment of the rules and requirements placed on it by Member State law according to Art. 88 GDPR, and put in place all necessary safeguards to guarantee lawfulness of the processing, including voluntariness of participation. Like all members of the group, the Company avails itself of the services of a Service Provider, which is located in a third country outside the EEA. Problem to be solved The export of personal data has to conform to the requirements of Chapter V of GDPR. Even though the Company and its Service Provider have concluded a contract containing standard data protection clauses acc. to Art. 46(2)(c) GDPR, their transfer impact assessment identified that the Service Provider would not be able to comply with certain provisions of the clauses because of conflicting requirements in its domestic legal system that go beyond what is necessary and proportionate in a democratic society. Original Data − Traffic data stemming from the interaction with the online questionnaire. − Questionnaire response with closed-ended answers mostly regarding personal outlook, attitudes and assessments of the work environment, but also including a very small number of coarse demographic attributes about gender, age group, time spent in the employment of the Company, and current role. The selection of those attributes is carefully calibrated to ensure that there are at least 5 (or no) employees in each category formed by any combination of them. No other attributes describing characteristics of the data subjects that can be observed by a third party are contained in the questionnaire response. Pseudonymisation domain Service Provider, and any other non-EEA entity User agent and traffic data, session id, quest. response Encrypted session id, NATted traffic data, questionnaire response Employee Proxy Service Provider User agent and traffic data, session id, fb. request Encrypted session id, NATted traffic data, fb. request Encrypted session id, feedback Session id, feedback Employee Proxy Service Provider Questionnaire Feedback Adopted - version for public consultation 44 Pseudonymisation procedure The Service Provider operates a server that provides an online questionnaire, which the Company offers to a section of its personnel (not including middle and upper management) through a proxy operated by itself. Employees use dedicated and company supplied disposable browser instances to interact with the online questionnaire. All interactions of an employee with the questionnaire form one session, which is assigned a unique session identifier chosen from a sufficiently large pool and displayed to the employee. The proxy replaces all data describing the user agent with dummy data, substitutes client IP and port by NAT, encrypts the session id in http requests 41 , and decrypts them in http responses. 42 Pseudonymised data − Encrypted session id substituting all client traffic data with the exception of the client network address, which is transformed by Network Address Translation. − Questionnaire response. Additional information − Encryption key − Original client traffic data at the time of processing Processing of pseudonymous data The Service Provider collates all questionnaire responses by pseudonymous session id. Upon receipt of all questionnaire responses, the Service Provider performs the requested analysis. It submits recommendations to the Company and provides the aggregated survey results derived from the responses it received to demonstrate the basis for its recommendations. Moreover, it provides individual feedback to all employees who have indicated that they wished to receive it, and consented to the processing involved. In order to receive it, employees have to note down the session id assigned to them when they fill out the questionnaire, and enter it into the feedback form. The form is provided through the proxy in the same way as the questionnaire encrypting and decrypting the session id as needed. After the performance of the task, all personal data received is deleted. Effect The carefully controlled environment in which the questionnaire is filled out assures that the interaction with the questionnaire cannot be attributed to any other online activity by the respective employee. Moreover, the questionnaire responses by itself do not allow attribution to specific natural persons either. Hence, even if authorities of the third country obtain the data records held by the Service Provider, they will not be able to attribute the data to the corresponding data subjects. Hence, upon careful analysis, including that the pseudonymisation measures have been effective to achieve their stated purpose, the preconditions of Art. 46 GDPR can be considered to be fulfilled in this example. 41 The transformation of the session id can also be effected by creating random substitutes and storing them in lookup tables. 42 In order to protect the identity of employees with unusual working hours either batch processing can be employed (in which case the granularity of the submission time is reduced) or the data collection is limited to usual working hours (e.g., by shutting down the service providing the dedicated browser used for submission). Adopted - version for public consultation 45 Example 10: Granting access rights to pseudonymised data A Company is using the services of an Identity Provider for identification and authentication of customers. The Company does not keep information about the legal identity of their customers, but stores all data labelled with the pseudonym assigned to the customer by the Identity Provider. When a customer asserts her rights to access or data portability, the Company does not attempt to ascertain the legal identity of the customer 43 , but — after due information of its customers about this process — uses the communication channel that already exists between the data subject and the controller via the Identity Provider. Upon authentication of the data subject, the latter can deliver the authentic pseudonym to the Company, which in turn provides the customer with a copy of her or his data. Note that Art. 11(2) GDPR applies, and Art. 15 and 20 do not apply if data subjects are not in the position to provide the pseudonym that relates to them, and substantiate this relationship, e.g., in the case that they deregistered from the Identity Provid er’s service. Note further that this example also shows the use of pseudonymisation as part of the implementation of the fairness principle. GLOSSARY Additional information Additional information is information whose use enables the attribution of → pseudonymised data to identified or identifiable persons. Attribution of pseudonymised data to data subjects Process that establishes that → pseudonymised data relate to an already identified person, or links the data to other information with reference to which the data subjects could be identified. Consistent pseudonymisation Two sets of data are considered to be pseudonymised consistently if data contained in those sets and relating to the same person can be linked on the basis of the pseudonyms they contain. Direct identifier A direct identifier is a data element (or set thereof) that has been assigned or is being used to distinguish the data subject it refers to from all others in the given context without requiring the use of → additional information. Examples are passport or social security numbers, or the set consisting of first and last name as well as date of birth. Pseudonym Identifier that is added to data in the course of the → pseudonymising transformation and set in such a way that it can be attributed to data subjects only using → additional information. Pseudonymised data Result of applying the → pseudonymising transformation to some personal data. Cannot be attributed to a specific data subject without → additional information. 43 The WP29 Guidelines on the right to data portability, endorsed by the EDPB, state: “The ability for the data controller to request additional information to assess one’s identity cannot lead to excessive demands and to the collection of personal data which are not relevant or necessary to strengthen the link between the individual and the personal data requested.” Adopted - version for public consultation 46 Pseudonymisation domain Environment in which the controller or processor wishes to preclude → attribution of data to specific data subjects. May incorporate persons acting under the authority of the controller or processor, respectively, other natural or legal persons, public authorities, agencies or other bodies, and their respective technological and informational resources. Does not include persons authorised to process additional data allowing the attribution of the → pseudonymised data to data subjects. Pseudonymisation secrets Data that is used in the application of the → pseudonymising transformation or is created during that process. Usually tables matching → pseudonyms with identifiers of data subjects or cryptographic keys. Allows the computation of pseudonyms from certain identifying attributes. Part of → additional information. Pseudonymising controller or processor Controller or processor that uses pseudonymisation as a safeguard and modifies original data according to Art. 4(5) GDPR. Pseudonymising transformation Procedure that modifies original data in a way that the result cannot be attributed to a specific data subject without → additional information.