Frequently, major personal data breaches do not occur in the most important systems of an organisation, but in secondary systems or systems considered less important but which hold a large amount of information or may be the gateway to other systems. This is the case of test, pre-production or development environments, where sometimes personal data are processed without having applied the appropriate technical and organisational measures according to the risk to the rights and freedoms of data subjects, or which are forgotten and exposed to the Internet and end up being the gateway to other environments with personal data.
Systems engineering establishes the convenience of working with several different environments, usually development, pre-production and production. In general, it is advisable to work in the development environment, test in the pre-production environment and finally deploy applications and services in the production environment. From a data protection point of view, this differentiation must be taken into account and the exposure of actual personal data (and/or data in production systems) in the development and testing phases should be limited due to the risk it may pose to the rights and freedoms of individuals.
It is still common to find development and pre-production environments in which the technical and organisational measures aimed at implementing the measures and guarantees established in the GDPR are relaxed, or which are exposed to the Internet without security measures or abandoned and disused so that the security measures soon become obsolete. But it should also not be forgotten that in some cases actual personal data is used for debugging tests in maintenance and/or development work.
With the entry into effect of the GDPR, and the publication of the Spanish national law (LOPDGDD), the situation regarding the use of personal data for testing in general, and in particular in development environments, can be briefly summarised as follows.
First, the GDPR, in Article 32 “Security of processing”, provides that the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk to the rights and freedoms of data subjects. The controller and processor must then determine the appropriate security measures with regard to the use of actual personal data in pre-production and test environments. Furthermore, they must establish these measures taking into account the level of risk specifically in relation to data protection, just as they must take into account the risks to the organisation, exactly as in any production environment.
In the same way, the European Data Protection Supervisor (EDPS) in its “Guidelines on the protection of personal data in IT governance and IT management of EU institutions” states:
80 In the testing phase, sampling of real personal data should be avoided, as such data cannot be used for purposes for which it was not collected and using it in testing environments may result in making personal data available to unauthorised individuals.
81 Where possible, artificially created test data should be used, or test data which is derived from real data so that its structure is preserved but no actual personal data is contained in it. Different such techniques have been applied successfully.
82 Where thorough and cautious analysis shows that generated test data cannot provide sufficient assurance for the validity of the tests, a comprehensive decision must be taken and documented, which defines which real data shall be used in the test, as limited as possible, the additional technical and organisational safeguards which are established in the testing environment. Special categories of data can only be used in real data testing with the explicit consent of the individuals concerned.
And it is used as an example:
Example: In case of bugs in system operation, the use of actual personal data for code debugging should be avoided. In any case, if needed, an authorisation from the data controller needs to be obtained and both the authorisation process and the debugging actions need to be recorded and auditable. The amount of personal data used for testing should anyhow be minimised and a strict “need to know” policy applied.
According to the principle of data minimisation and the principle of data protection by design and by default, the use of personal data in development and pre-production environments, or any other testing environment, should be avoided where possible.
In addition, software testing with personal data constitutes, or is part of, processing of personal data and the controller must comply with all obligations under the GDPR.
Although not always possible, in many cases the use of synthetic data avoids the processing of personal data in development testing. There are services, some of them free and open source, for the generation of synthetic data of all kinds that are well known in the industry.
Therefore, where the use of personal data in pre-production environments is strictly necessary, it should be documented by a necessity and proportionality analysis, and in any case the necessary technical and organisational measures must be implemented in accordance with Article 32 of the GDPR and in accordance with the risk of the processing.
The risk in the pre-production environment could be the same as the risk of processing in the production environment. However, this risk may also be higher because it is common to have additional processors in development work, to use cloud systems from different providers than in production environments, to have greater uncertainty about the reliability of the code, to carry out tests with new technologies, etc. For all these reasons, testing environments should have technical and organisational measures of equal importance and, in any case, appropriate to the specific privacy risks regardless of the context in which they are processed, because as pointed out by the Article 29 Working Group, now the EDPB, in its statement on the role of the risk approach in the data protection regulatory framework (WP218): "... Data subjects should have the same level of protection, regardless of the size of the organisation or the amount of data it processes. Therefore, the Working Group considers that all controllers should act in accordance with the law, although this can be done in a scalable manner". i.e. the context, in which a given data processing takes place, does not exempt controllers from their obligations to provide data subjects with the appropriate level of protection in each case regardless of that context (development, pre-production or production), and this includes the analysis of necessity, proportionality and the applicable legal bases, in addition to the other obligations required by data protection law.
Failure to apply technical and organisational measures appropriate to the level of risk to rights and freedoms in all environments is a breach of Article 32 of the GDPR and may even entail a breach of other principles such as the principles of purpose, necessity and proportionality.
In relation to issues of breaches and personal data, more material can be found on the AEPD Innovation and Technology page, in particular:
- Personal data breaches: Ransomware and risk management
- Personal data breaches: online productivity platforms
- Personal data security breaches: Top 5 technical measures to be taken into account
- Data breach: communication to the data subject
- Data breaches: protect yourself against the loss or theft of a portable device
- Personal data breaches: what they are and how to respond
- Personal data breaches: protect yourself against ransomware