Life after GDPR: Data protection for software testers8 min read

The General Data Protection Regulation (GDPR) may seem like a thing of the past. Despite the original proposals being released in January 2012, there was still the much-anticipated mad panic earlier this year. As the implementation date loomed closer many of us worked frantically to ensure we were compliant. Then on May 25th, the new legislation came into force and – except for a short period of being inundated with consent and privacy policy emails from every company and their dog – we then all promptly decided to forget about GDPR! “If the GDPR is a thing of the past, why should I care about it?” I hear you ask. The reality is that GDPR is not a thing of the past. Since the law came into force across the European Union (and in reality the entire world), the GDPR now sets a new baseline standard for how companies must manage personal data. What’s more, the penalties for non-compliance are significant. Maximum fines are currently capped at 20 million euros or 4% of a corporation’s (or corporate group’s) global turnover, whichever is greater! As a result, there is now as much need as ever for us to consider data protection in everything that we do. It is no longer good enough to leave data protection as an afterthought. In order to remain compliant and avoid heavy fines and damage to reputation, we must design and build our systems with GDPR at the front of our minds. This is where data protection by design comes in.

Data protection by design

As stipulated in the GDPR, data protection must be very high by default. This means that when building new systems or modifying existing systems we must take all reasonable measures to secure the personal data that we process. GDPR article 4(2) defines data processing as “any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction”. So as software testers what can we do to ensure our products are GDPR compliant and avoid our employers from incurring massive fines? What we must do is begin to adopt the following key behaviours:

1. Identify when GDPR laws apply to our work
2. Discuss data privacy requirements with our teams and stakeholders to ensure that the necessary measures are put in place
3. Verify the measures are suitable after (or during) implementation

In order to achieve these, we must first understand what is meant by Personal Data and Special Category Data. Secondly, we must understand the key data protection requirements that the GDPR requires Data Controllers to implement. For clarity, as defined by article 4(7) a data controller is an organisation that determines the purposes and means of the processing of personal data. The data controller has overall control of the processing activity. A data processor, as defined by article 4(8), is an organisation that performs data processing under the instruction of a data controller. But what actually is “personal data”?

Personal data

Personal data does not simply refer to data that can be used to identify a specific individual, such as a person’s name or email address. It also includes any data that relates to that identifiable individual. The reason being that even non-identifying data can be used collectively to identify an individual. For example, your address, year of birth and employer’s name may not individually identify you. However, if all three pieces of data were combined then they could be used to identify you.

The GDPR also goes one step further by distinguishing Special Category Data. This is information such as sexual preference, ethnic origin and political preference. This information may not be useful in identifying an individual but is very sensitive in nature. The GDPR, therefore, requires that this information is treated with the utmost care.

Data privacy requirements

Once you have identified what categories of data your system is processing you must then consider what rules apply to this data. The GDPR data protection requirements can broadly be grouped into the following four categories and related sub-categories:

Minimisation

• Purpose – Only collect personal data if there’s a legitimate business purpose for it (e.g. a customer’s delivery address, in order to send them goods purchased)
• Retention – Only keep personal data for as long as it is needed (e.g. if you run a competition, once the winners have been announced and there is no longer a need to keep the personal data about entrants, then it should be deleted)
• Erasure requests – All stored personal data must be deleted (or anonymised) upon request by the individual

Security

• Rest – Appropriate safeguards must be taken to protect personal data when stored (e.g. on servers, databases, personal computers or removal storage media)
• Transit – The same level of safeguarding is also required when personal data is in transit, both internally and externally

Access control

• Access requests – All stored personal data must be made available to the individual upon request (also referred to as a Data Subject Access Request or DSAR)
• Access limitation – Personal data must only be accessible to the people and systems that have a genuine need to access it
• Access control – Processes should be in place to both grant access to personal data and remove it when it is no longer required
• Proactive monitoring – Access to personal data must be logged and monitored to identify abnormal or malicious activity

Transparency

• Consent – Consent to process personal data must be obtained from an individual when there is no other lawful basis to do so. Other lawful reasons to process data include contractual, legal obligation, vital interest, legitimate interest and public interest.
• Privacy policy – A privacy policy explaining how data protection principles are being applied must be published and made available to individuals
• Clear communication – Messaging to individuals should be clear and transparent and in language that they can understand
• Audit – Any changes or updates to personal data must be logged and this must be made available to the individual upon request

Other considerations

In addition to the above requirements here are some additional things to consider:

• Data Processors – The rules outlined above apply both to data controllers and data processors. Data processors are third-parties that process personal data on behalf of a data controller. Therefore, if an organisation is processing data on your behalf then you are required to have a data processing agreement to set out the obligations of both parties and ensure that the data processor is compliant with the GDPR.
• Outside the EU – Even if an organisation is based outside of the European Union you may still be subject to  the GDPR. If an organisation has any economic activity within the EU, then the law still  applies. For example, if a US based company but take orders from customers inside the  EU, then the GDPR applies to the personal data that is held on those European customers.
• Non-customers – When thinking about personal data, in-terms of GDPR, it can be easy to focus on customers and end-users. However, the rules apply to any individuals whose data your are processing. This can include staff, recruitment candidates, contractors and others.
• Test data – The GDPR applies equally to production environments as it does to test rigs. This means that if you require to use an individual’s real personal data then all of the data protection requirements need to be applied. This would mean securing the data, controlling access to it, being transparent with the individual about how you are using their data, erasing the data on the individual’s request and so forth. If this is not practical, then it may be simpler to avoid using any personal data for testing purposes. This will means that data refreshes from production would need to be sanitised, and tests would have to rely on fictitious data instead.

Conclusions

In summary, the GDPR is here to stay. As software testers, it is vital that we have a good handle on the main concepts and remain vigilant whenever we are working with personal data. One way to do this to extend or embellish our existing processes with additional data protection in mind. This may include adding a data protection section to test plan templates, adding new requirements to master lists of non-functional requirements, or including GDPR conditions to the definition of done. What’s more, for anyone using the Refinement Playing Cards that I introduced in a previous blog post: Do you want to play a game?, I have now published a new Data Protection card. Go ahead, add it to your deck. Many thanks to Aoife McGrath and Juran Irving for their excellent feedback and legal support when writing this article.