2.1.1 Designate the person responsible for the entire process
From an organisational point of view, the controller or the processor must appoint a Specialist Responsible for Pseudonymisation (SRP). The responsibilities and duties of the controller laid down in the GDPR are not transferred. This SRP coordinates the individual organisational responsibilities before, during and after the pseudonymisation process.
Explanation: Here, the term SRP does not mean the controller in the sense of the GDPR, but (untechnically) the person internally responsible for the organisation and the proper process of pseudonymisation. The pseudonymisation of personal data is usually part of a more general processing activity (according to the record of processing activities).
The SRP can also take on other specialist responsibilities or take overall responsibility for the respective data processing. In any case, the responsibility of this person or department is to be documented as SRP regardless of other responsibilities. The appointment of a data protection officer as SRP is not permitted.
Explanation: The SRP is not to be equated with the data protection officer of the controller or processor. In contrast to the SRP, the data protection officer is not responsible for the lawfulness of data processing. His/her legal duties are defined in Art. 39 GDPR and are characterised by giving advice and to monitor. In the area of pseudonymisation, the data protection officer can advise on the planning and implementation of the pseudonymisation and also monitor compliance with the legal requirements for pseudonymisation and this CoC. Due to the allocation of organisational responsibility for the SRP, an identity of the data protection officer and the SRP would not be compatible with the legal requirements.
The SRP must possess the technical and organisational expertise required for pseudonymisation. If a department has been designated as SRP, the department must have the necessary specialist knowledge in (partial) totality if and to the extent that it is ensured from an organisational point of view that this department always exercises responsibility in an appropriate (partial) totality.
2.1.2 Assemssment and documentation of the criteria necessary to determine the pseudonymisation method
For the legally compliant use of pseudonymisation, the following criteria must be considered in documented form.
188.8.131.52 Type and risk class of personal data processed
The type and risk class of the data processed must be specified in order to ensure pseudonymisation in conformity with data protection regulations. Based on this risk assessment, the selection of the adequate, GDPR compliant pseudonymisation procedure must take place.
Explanation: In principle, there can be different categories of data:
- Personal data pursuant to Art. 4 No. 1 GDPR
- Special categories of personal data pursuant to Art. 9 para. 1 GDPR
The categories of data processed can be found in the record of processing activities.
Within the framework of the risk assessment of the processed data, assessments from risk analyses or a data protection impact assessment can also be applied.
The data category used does not represent a suitable criterion for a risk assessment in itself and can at best be used as an indication. Rather, other aspects must also be taken into account within the framework of risk assessment. This is for example
- the purpose and context of the processing (see below 184.108.40.206. and 220.127.116.11.); for example, identical personal data may be used in the context of contract performance or to track user activities;
- the category of data subjects; e.g. children or members of certain population groups without immediately triggering the scope of application of Art. 9 (1) GDPR;
- the number of persons concerned (see 18.104.22.168 below) or the combination of the different data categories.
22.214.171.124 Intended processing purposes
The purposes for which the data are to be processed must be specified.
Explanation: There may be more than one purpose of processing. Purposes cannot easily be changed in the aftermath of data collection, so that these should be documented as comprehensively as possible. However, purposes must also be sufficiently precise to allow the purpose limitation principle to be respected. Examples for a processing purpose may include data processing for billing purposes, for checking the network utilisation of a mobile phone provider, for product development purposes or for the processing of data for research purposes. Research purposes should be specified in the documentation to the extent that the research context or the research objective can actually be comprehended in terms of whether an actual, future processing is subject to the intended research purpose and therefore a risk assessment can also be adequately derived. The description of the purpose also has an influence on the assessment under data protection law as to whether data processing for the intended purposes still falls within the scope of the relevant statutory provision and, on the other hand, it must be examined whether pseudonymisation changes this assessment in some way.
126.96.36.199 Context of pseudonymisation
The context of pseudonymisation shall be documented.
Explanation: The context of processing refers to the legal context for pseudonymisation. Pseudonymisation can be used, for example, in the course of its enabling function within the framework of Art. 6 para. 1 lit. f and Art. 6 para. 4 GDPR or as purely technical and organisational measures pursuant to Art. 32 GDPR or within the framework of Art. 25 GDPR.
Documentation is necessary because this context also influences the choice of the appropriate pseudonymisation procedure.
188.8.131.52 Expected number of processed records
It shall be checked and documented how many records will be processed.
Explanation: There must be an overview over whether only a few data sets or a large number of data are pseudonymised. When checking the number of data records to be processed, it is relevant whether the data records are static or dynamic, i.e. whether they are a fixed number of data that is pseudonymised or whether the data record is continuously enriched with further data. Classical list procedures for pseudonymisation using tables are for example not suitable for a large amount of data.
184.108.40.206 Suitable pseudonymmisation types
The different types of pseudonyms required shall be documented.
Explanation: Different types of pseudonyms, for example, are particularly suitable for certain purposes, although they may be completely unsuitable for other purposes.
A distinction can be made between the following types of pseudonyms:
- Personal pseudonyms that replace identity data such as name, ID number or mobile phone number
- Role pseudonyms where one or more persons are assigned to a pseudonym (e.g. IP number)
- Relationship pseudonyms where a person uses a different pseudonym for each (communication) relationship, e.g. different nicknames, role relationship
- Role-relationship pseudonyms that are a combination of the two pseudonym types
- Changing pseudonyms where, for example, a new pseudonym is used for each transaction or each entry. Used, for example, in online banking
Considering the purpose and context of the processing, those types of pseudonyms are to be preferred which are suitable for the respective purpose and at the same time protect the persons concerned as far as possible against unwanted identification. The SRP supports the selection of the appropriate type of pseudonymisation. The weighing carried out for the decision for or against a relevant type of pseudonymisation must be documented.
Explanation: In general, the risk of reversal of personal pseudonyms is higher than that of role or relation pseudonyms. This is related to the connection of a pseudonym with a person standing behind it. Depending on the purpose and context of the processing, the use of personal pseudonyms may be necessary. On the other hand, there is a lower risk of reversal of persons with role-relationship pseudonyms and changing pseudonyms than with the abovementioned person pseudonyms.
220.127.116.11 Determination of the appropriate pseudonymisation method and the time of pseudonymisation
Different methods are available for pseudonymisation
The strength of the applied method must be examined, determined and documented taking into account all objective factors, risks to the rights and freedoms of the parties concerned as well as the costs of identification and the time required for this when using the technologies available at the time of processing as well as foreseeable technological developments. When using calculation methods, a state-ofthe-art transformation procedure must be used (for technical requirements, see 2.2.1.).
Furthermore, pseudonymisation procedures shall be designed in such a way that simple and efficient selection and deletion of the data is possible, insofar as the processing purpose no longer exists or the legal basis for the processing is no longer applicable.
Explanation: The principle of data minimisation must always be observed. The principles of privacy by design must also be taken into account. As a result, the technical design must provide the appropriate framework conditions from the beginning. Compliance with these principles thus avoids the per se inadmissible continuous storage of pseudonymised data that is difficult to reidentify. In addition, such pseudonymisation methods are to be preferred which simply enable the subsequent anonymisation of data
The pseudonymisation has to be made in the processing process as early as possible.
Explanation: Personal data must be limited to what is necessary for the purposes of processing (cf. Art. 5 para. 1 lit. c GDPR). If the pseudonymisation has been identified as suitable processing by the controller or processor, its technical implementation should be carried out promptly. Likewise, pseudonymisation should also be carried out as early as possible in multi-stage data processing, especially if non-pseudonymised data are not required at the upstream processing stages.
18.104.22.168 Planned disclosure of pseudonymised data
It must be documented whether pseudonymised data are to be transmitted to third parties. The data controller or processor must take appropriate measures to ensure that the data passed on is only processed by the recipient(s) for the purposes specified beforehand. The controller or processor shall ensure that the transfer of the pseudonymised data to the recipient is covered by a legal basis. In addition, the controller or processor must take appropriate measures to prevent the recipient from inadmissibly reidentifying data subjects.
Explanation: Since pseudonymised data also have a personal reference, the general data protection requirements apply to the processing, including the purpose limitation pursuant to Art. 5 para. 1 lit. b GDPR. The data provider as well as the recipient must agree on a purpose before passing on pseudonymised data. The purpose of the processing can be confirmed by the recipient in text form or in writing (e.g. as part of a contract) as an appropriate measure. Since only the pseudonymised transfer of data falls within the scope of this CoC, the identification of data subjects within the scope of data transfer must be omitted. The CoC therefore formulates an obligation for the data provider to take appropriate security measures in this regard before passing on the data to the recipient. This includes, for example, an obligation to check on the part of the receiver with regard to obvious identification possibilities, since a detailed knowledge of the possibilities of linking the data on the receiver side cannot be assumed. The controller or processor should in any case obtain supplementary confirmation in text form or in writing (e.g. as part of a contract) that an identification does not take place by the recipient.
Insofar as an audit has shown that the recipient could obviously carry out a reidentification, appropriate supplementary protective measures should be implemented as far as this appears necessary due to the expected risks for the data subjects.
Regarding the legal basis for disclosure, in particular in cases where consent has been obtained for the collection of personal data, the fact of disclosure to another body in pseudonymised form must be covered. If not, another legal basis would be required.
22.214.171.124 Planned processing of pseudonymised data in the third country
It shall be documented whether pseudonymised data are to be processed outside the EEA. In the event of the transfer of personal data to a third country, the data controller or processor must ensure that the requirements of Chapter V of the GDPR regarding the guarantee of an appropriate level of data protection are met. When collecting personal data, the data subject must be made aware of the transfer of such data to a third country, even if pseudonymised data are transferred.
Explanation: The GDPR places special requirements on the processing of personal data in a third country outside the EU or the EEA. These requirements are regulated in Chapter V of the GDPR and include, for example, the transfer of personal data on the basis of an adequacy decision by the EU Commission or other suitable guarantees according to Art. 46 GDPR. The fact that the data to be transfersed are pseudonymised shall not exempt the data exporting body from complying with the requirements of Chapter V. After all, a data subject can also be re-identified in a third country using the key to pseudonymisation.
126.96.36.199 Planned/ foreseeable frequency of re-identification?
The planned or foreseeable frequency of re-identification of data subjects shall be specified in documented form.
Explanation: The chosen processing purposes have an influence on the question of whether a re-identification of the persons concerned must be carried out promptly and in the short term. In the area of network monitoring, for example, it may be necessary to identify a workstation infected with malicious code on the basis of pseudonyms at short notice.
The planned or expected frequency of re-identification of data sets shall be defined. It must also be documented for which planned or expected reasons or for which purposes such re-identification will take place (e.g. to safeguard the rights of the data subjects). In addition to the reasons and purposes, it must also be documented what delay of tolerance exists in the event of re-identification, i.e. what the maximum delay may be until sufficient re-identification of a data set.
Explanation: Pseudonymisation methods differ, among other things, in their efficiency and manageability with regard to the re-identifications that have to be carried out. Similarly, the frequency of expected re-identifications also interacts with an appropriate allocation of functions as defined in Section 2.1.3. The documentation to be prepared here should enable the SRP to create a binding basis for consideration. On the other hand, it should enable the SRP to evaluate the hypothesis and planning presented here over time. Such an evaluation would have to take into account, for example, whether a possibly very high, expected re-identification rate actually occurs in practice. It would also be necessary to consider, for example, whether the delay tolerance could be adhered to or whether other pseudonymisation methods are now also able to adhere to these tolerances due to new technical developments.
2.1.3 Risk-adequate concept for rights and roles
Regarding access to pseudonymised data and the combinations thereof required for the respective activity, possible existing translation tables and keys for the re-identification of a person and other information, an appropriate rights and role concept shall be provided. The more sensitive the processed data or the higher the expected risks for the rights and freedoms of the data subjects, the more effective such a separation should be.
Explanation: According to the legal definition of pseudonymisation, additional information that enables the identification of data subjects must be kept separately and identification must be prevented by technical and organisational measures. An existing rights and role concept can represent such a technical-organisational measure. Depending on the risk of the data and the context of the processing, different models are suitable within such a rights and roles concept:
"All-in-one-hand”-model: Here, the controller or processor has both the pseudonymised data and the possibility at any time to reverse the processed pseudonyms or to re-identify the data subject. A possibility of re-identification can be asigned to a person, a department or a legal entity. In these cases, at least internal requirements should exist, which would result in permissible and impermissible circumstances for carrying out a reidentification as well as possible documentation obligations regarding reidentifications. As the expected risks increase, these internal requirements should also be supplemented by an appropriate internal rights and role concept based on the need-to-know principle (cf. mixed models).
Trustee model: In the classic trustee model, the trustee is a legal entity outside the controller or processor acting as a "third party". It is therefore a trust center that is independent of data collection and usage in terms of location and organisation. A trustee can, for example, be entrusted with the storage of keys for the reidentification of data subjects. The processing of pseudonyms by the third party is also a possibility, while any keys and raw data remain with the controller or processor.
Key management is the most common scenario in which a trustee can be involved in various ways. The method chosen within the trustee model should always be based on the documented risks for the data subjects:
- Ex ante: The trustee shall re-identify the data subjects for purposes or circumstances defined prior to the commencement of processing.
- Ad hoc: The trustee re-identifies the data subjects on the basis of previously defined consideration criteria, but not according to previously defined purposes and circumstances.
- Ex post: The trustee is informed of any re-identifications that have taken place, together with the reason (e.g. as an individual case or via statistics). The trustee can evaluate this information and take appropriate measures based on it, e.g. training or disciplinary measures.
Mixed models: Mixed models are also conceivable. Here, for example, the separation of the information necessary for re-identification can also take place within the organisation of the controller or processor, in which the information is subjected to a rights and role concept.
This can also include, for example, distributing information across several hierarchical levels or independent departments. The departments usually responsible for such issues (internal audit or compliance or legal department, (IT) security or data protection officer) could also be suitable for this purpose anyway. Particularly in large organisations, the establishment of a trustworthy "third party" of its own, which offers the separate administration of data and/or secrets or keys internally, is also an option.
Such mixed models are conceivable, for example, particularly in cases where the processing comprises several processing steps and several pseudonymisation stages, for each of which different risks to the data subjects have been documented.
2.1.9 . Documentation and regular evaluation of the process, the considerations made, and the measures actually taken
For each section of Chapter 2.1, the measures taken as well as the influencing factors for determining an appropriate pseudonymisation method (Section 2.1.2) are to be documented. Insofar as the determination of the measures taken is to be preceded by an assessment, such assessments shall also be documented.
The documentation shall be prepared by the SRP. The SRP can, however, fall back on documentation from other technical experts and third parties. Here it must be ensured that modifications of the documentation are exclusively transparent; in particular regarding the aspects "what", "by whom" and "when".
188.8.131.52 Documentation of processes and other measures taken
Processes and measures taken shall be documented in such a way that
- the SRP is capable
- to evaluate the process or measure in terms of effectiveness;
- to verify the implementation of the processes or the measures taken;
- to evaluate compliance with the processes or measures taken, as well as,
- the SRP and all persons entrusted with implementation are able to
- understand the process or the measure and to implement it according to the defined specifications.
184.108.40.206 Documentation of considerations
Considerations must be documented, including a statement of reasons. It must be ensured that the conclusions reached within the framework of the consideration - e.g. determination of the appropriate pseudonymisation method or an applied risk classification - can also be easily understood by third parties. These considerations shall be reviewed regularly, in particular regarding the state of the art and conformity with the intended purpose, and these reviews shall also be documented. References to further documentation are permissible, as far as it concerns referenced methods or correspondingly documented consideration results of this section and the reference shows the concrete title, storage or storage location and version of the referenced document.
Explanation: The documentation to be prepared in accordance with this section fulfils a number of objectives. The documentation forces the controller or processor to systematically process the requirements of this Code. Insofar as the SRP makes use of the services of other specialist managers, the SRP shall have an information base which is always comprehensible also for him/herself. This documentation also enables the SRP to review the original assumptions on a regular basis and adjust them if necessary. Such an evaluation is necessary to the extent that the GDPR requires processing in accordance with the current state of technology. It is therefore likely that measures taken or considerations made on the basis of documented information will have to be modified as the technical status quo progresses. The documentation also enables both the SRP and any compliance departments to carry out conformity checks.