Data protection: privileged data processing procedures
The new, harmonised EU basic data protection regulation came into force on 24 May 2016 and is to be applied from 24 May 2018 without any further transitional period. All companies operating in the EU, regardless of their registered office, are already subject to the legislation, and legal compliance in Switzerland is already underway. For us, this is a reason to examine the basic data protection regulation in more detail in a series of articles.
Privileged procedures
With the documentation of the Technical and Organisational Measures ("TOMs"), the means by which adequate protection is achieved are recorded for a data processing. The Data Protection Ordinance describes a series of procedures which are legally privileged, i.e. which are to be applied as part of the technical and organisational measures if possible. These are these:
- the use of anonymous data,
- the use of pseudonymised data,
- the use of statistical data,
- the use of encrypted data.
This order of precedence cannot be interpreted in a completely linear way, as there are of course possible combinations. In the following, we will deal with these listed procedures from the perspective of data protection. As a rule, all procedures are much more difficult to implement correctly and securely than they may appear on the surface. However, in the context of an article on data protection, these technical aspects lead too far here, which is why we are assuming a professional and error-free technical implementation here for once. (If only it would be that easy to implement.
Anonymization
Anonymization is the process of removing from a database those characteristics that allow the data held to be assigned to specific persons. Where this can be implemented, this is a great procedure. This is because anonymisation means that the data is no longer related to a person and is therefore no longer subject to the provisions of the Data Protection Act. Because as we stated in part 1 of this series of articles, only data relating to an identified or identifiable natural person is subject to data protection, nothing else. For this we have as a basis a list of all crime cases of the last 10 years. The anonymisation of the perpetrator for his protection means that the information that makes him identifiable is systematically removed from this list of crime cases. The first, obvious measure, therefore, is to delete those attributes from the database that allow a direct assignment to a person. These could be, for example, the name and address of the perpetrator, but the database has not yet been made truly anonymous. It remains to be checked whether indirect identification is still possible. Anonymisation only applies if the person cannot be identified even with considerable effort, for example by using other sources of information. Perhaps newspaper articles have been published about the crime, which nevertheless make it possible to re-identify the person. Or there could be further - at first glance perhaps inconspicuous - information on the perpetrator stored, the combination of which in many cases makes it possible to restrict the group of people in question to the person in question. Accordingly, irreversible anonymisation is usually not easy to implement or is even impossible due to the requirements.
Pseudonymisation
Pseudonymisation is the process of removing personal identifying features from data and storing them separately. It is therefore a kind of partial anonymisation. The key for reconversion is stored in a separate location, as shown in the example in the Anonymisation section. Pseudonymisation would mean that the name and name of the perpetrator would be deleted from the database in the same way as anonymisation. A unique sequence number would be used for this. A translation table would then be kept in a second data memory, listing the surname and first name for each sequence number. This key table must then be stored separately from the data and protected. Pseudonymization is therefore not as effective as anonymization. However, the effort required to identify persons increases. For this reason, this procedure is legally privileged if full anonymization is not possible.
Statistical data
Statistical data are understood to be data aggregations from individual case data. To stay with the above-mentioned example of crime statistics, this would mean that the starting point for updating data is always an individual case, but the data is only stored as a sum of incidents, e.g. the number of burglaries per month. Such an aggregation also results in partial anonymisation with the same advantages under data protection law. It should be noted here that if the number of cases is low, the sum of a single case in the statistics remains an individual case. This means that identification of the person is potentially possible again.
Example: Insufficient protection of voting secrecy in statistics
I have provided a vivid example of this problem when introducing a E-voting system for the Swiss abroad This not only affected data protection legislation but also laws on political rights. The secrecy of the vote must be maintained during a vote or election, i.e. it must not be possible to trace who voted for which candidate or who agreed or disagreed with which proposal.
On voting Sunday, the local authorities were to record the votes cast by "their Swiss abroad" separately by e-voting so that the public could be informed transparently about the use of this voting channel - also because of the many concerns about the possibility of manipulation. Unfortunately, in practice it turned out that individual small municipalities had so few registered Swiss abroad that only a few votes were regularly cast by Swiss abroad. As a result, it was possible in part to read directly from the statistics how the Swiss abroad in question had voted. The problem was finally solved by no longer crediting these votes to the communes, but to a separate, cross-communal constituency for Swiss abroad.
Encryption
The encryption of data is a method to increase the protection of data. In a first step, data is usually protected from access by third parties using firewalls, authorization concepts, and so on. By using encryption, this access can be restricted even more specifically to only a few, specific persons. In particular, the use of encryption can also prevent access by internal system administrators and other IT personnel, for example, or at least restrict it to a few people. At the same time, this introduces an additional security hurdle for potential attackers if the other protective measures could be circumvented, but any encryption method is only as secure as the key(s) used and their storage. It is therefore often difficult to achieve truly effective protection. This is because "pragmatic" implementation often results primarily in so-called security-by-obscurity, i.e. a nice sedative pill with the effectiveness of placebos. You feel better, but not really because of the ingredients, the encryption of data also has significant disadvantages. On the one hand, there is usually a loss of performance, i.e. all processing is necessarily longer and the system slows down. On the other hand, recovery scenarios for restoring a service after a failure can also be made more difficult and slowed down as a result. From a data protection point of view, the encryption of as much personal data as possible is actually always welcome. However, from a cost efficiency point of view, i.e. the additional protection factor per invested capital, is often not justified. Accordingly, encryption is usually used very selectively, where it can effectively counteract really considerable risks.
So which procedure to use where?
The presented procedures, which are privileged under data protection law, represent a toolbox to increase the protection of persons. All of them are desirable, the complete anonymization the ideal solution. Which procedures are to be used is decided on the basis of the risk assessment in the data protection impact assessment.
Our series of articles on the topic
- In the lead-in article we drew attention to the need for action.
- In part 1 of the series we introduce the different actors and set the framework.
- In Part 2, we examined the principles of data protection based on four pillars.
- Part 3 explained the specific requirements for the processing of special categories of personal data and for profiling, which is considered as particularly critical.
- This part 4 highlighted legally privileged, desirable processing methods.
- Part 5 of the series concludes with a framework for the pragmatic and appropriate implementation of data protection in your IT project.
About the author
Stefan Haller is an IT expert specialized in risk management, information security and data protection at linkyard. He supports companies and public authorities in risk analysis in projects, the design and implementation of compliance requirements in software solutions as well as in the creation of IT security and authorization concepts. He is certified in risk management and has carried out numerous security audits as an internal auditor on the basis of the ISO standard 27001 for more than 10 years. Do you have questions about the implementation in your company? stefan.haller@linkyard.ch | +41 78 746 51 16
