Data protection by designAs 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:
- Identify when GDPR laws apply to our work
- Discuss data privacy requirements with our teams and stakeholders to ensure that the necessary measures are put in place
- Verify the measures are suitable after (or during) implementation
Personal dataPersonal 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 requirementsOnce 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:
- 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
- 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 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
- 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.
- 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 considerationsIn 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.
ConclusionsIn 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.
Share this post: