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.
For the legally compliant use of pseudonymisation, the following criteria must be considered in documented form.
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:
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 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.
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.
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.
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:
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.
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.
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.
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.
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.
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:
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.
In the event that a re-identification of data subjects on the basis of the pseudonymised data is planned, the following requirements must be observed and documented. The SRP supports:
If the pseudonymisation is only used as a technical-organisational measure with protective function, no separate information beyond the general information about the data processing is required. If further processing is to be carried out for compatible purposes, the following two purposes have to be distinguished:
The information and notification obligations towards the data subjects also relate to the right to object or in a consent scenario.
In the event of an unintentional or unlawful reversal of a pseudonymisation, a response plan must be drawn up. The SRP supports. The response plan shall include the following elements:
The response plan can be integrated into an existing process (for example, Incident Response Plan) at the controller or processor.
Explanation: According to recital 85 sentence 1, the reversal of a pseudonymisation can constitute a data breach which, in the event of a risk associated with the breach for the data subjects concerned, must be reported to a supervisory authority or, in the event of a probable high risk, also to the data subjects. Controllers and processors should therefore document any necessary steps in a response plan in the event that a pseudonymisation is reversed. The response plan does not have to be created separately for the pseudonymisation, but can generally exist for data protection incidents at the controller or processor, but must explicitly address the reversal of a pseudonymisation.
The intervals shall be defined and documented at which the necessity of processing of pseudonymised data has to be assessed. The SRP provides advice and support in this regard. Such a review should in general take place at least every two years. The assessment shall be documented. If, in the course of this review, it is determined that processing is no longer necessary, the pseudonymised data must be deleted or made anonymous in accordance with data protection regulations.
Explanation: Since pseudonymised data make it possible to re-identify data subjects, such processing activity is also subject to the principle of storage limitation under Art. 5 para. 1 lit. e GDPR. If pseudonymised data are no longer required for the specified purpose of processing, they must be deleted. Consequently, it is necessary to establish a regular cycle for an assessment of necessity by the controller or processor in order to determine the necessity of the processing.
If, despite a pseudonymisation, a high risk for rights and freedoms of data subjects2 can still be identified within the scope of a processing activity and if pseudonymisation is the only protective measure, the competent supervisory authority pursuant to Art. 36 GDPR must be consulted. In such circumstances, the SRP must be consulted.
Explanation: Controllers must consult the supervisory authority in advance of any processing if it emerges from a data protection impact assessment pursuant to Art. 35 GDPR and when the processing would pose a high risk to the data subjects, unless measures are taken to contain it. If there is a high risk for those data subjects and pseudonymisation is the only protective measure, there is a legal obligation to consult the competent supervisory authority.
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".
Processes and measures taken shall be documented in such a way that
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.
The technical implementation takes place only in consultation with the SRP. The SRP shall consult the specialist managers when selecting and evaluating the appropriate pseudonymisation method. The specialist managers must also consult the SRP on planned changes to the technical implementation.
For the implementation of a pseudonymisation different procedures can be used. For example, an allocation table can be used in which one or more pseudonyms are allocated to each date in plain text. Alternatively, various cryptographic methods can be used for pseudonymisation, each of which converts a plain text date into one or more pseudonyms. The reversibility of pseudonymisation can be controlled/restricted here by establishing access controls concerning used cryptographic keys and, if necessary, other parameters.
When selecting the pseudonymisation to be used, the test steps of the inventory (in particular, subsections 2.1.2.1 to 2.1.2.6) must be followed.
Regardless of the other requirements, an ID must be used as a pseudonym that does not allow any conclusions to be drawn about the input data or the natural person concerned.
Application scenarios and challenges:
Explanation: The postal code is used as the ID; the data also contains individual information about the date of birth. With a sufficiently small number of data sets, the natural person can be re-identified by comparing all data sets with identical birth data.
Explanation: Pseudonymised data could be re-identified by an easily understandable chronological or alphabetical sequence.
With regard to the technical procedures used, the relevant current technical guidelines of a general nature must also be taken into account, in particular the relevant guidelines of the BSI ("TR02102 Cryptographic procedures: Recommendations and key lengths") if, for example, procedures are used that use hash functions as a basis. Transformation procedures used for pseudonymisation must also be replaced by current procedures - especially for pseudonymised data used over a long period of time - in order to guarantee a maximum of security.
The choice of the specific pseudonymisation method must be based on the inventory and coordinated with the SRP; accordingly, the technical implementation is also subject to regular evaluation, cf. 2.1.9.2.
When using calculation methods to determine pseudonyms (in particular for pseudonymous users), it must be ensured that these have the following properties:
Explanation: Software to create pseudonyms should use available crypto libraries instead of reimplementing the algorithms. This is why Open Source implementations are useful.
Explanation: A homonym error occurs if identity data of different persons falsely lead to the same pseudonyms.
Explanation: The reasonable should also be determined on the basis of the specific circumstances. In particular, the value of the re-identified data for unauthorised parties should be considered. The risk analysis carried out can be used for this purpose. This information is important for the determination of the reasonable effort, as it allows conclusions to be drawn about the expected technical and professional resources of unauthorised parties: The higher the value of the data, the greater the effort that can be justified from the point of view of unauthorised parties.