Using Unmasked Production Data For Testing Leaves Your At Risk For Data Breaches

When information is accessed without authorization, we’re talking about a data breach. Data breaches can hurt consumers and businesses. Laws and regulations like GDPR, PCI and HIPAA are in place to protect consumers
from their data being used unlawfully. They require organizations to take
security measures and reassess privacy procedures so the consumer data that they use and store is protected properly.

Internal dangers

Not securing data properly, every organization risks not complying with data privacy laws, exposure of privacy-sensitive data to unauthorized users, image loss because of bad publicity when data is leaked, etc. That’s why data protection has to be in place.

In the first instance, organizations try to protect data from external dangers such as hackers and thieves. However, the 2020 Data Breach Investigations Report by Verizon shows that 30% of data breaches
involved internal actors. In 22% of the occasions, errors were causal events and 8% were misuse by authorized users. These numbers show that not only external but also internal there are significant risks of data breaches. Risks should, and can be, reduced by managing your data properly.

The risk of test data

Test data, for example, is data that is (internally) used for testing and
development purposes within an organization. Many organizations still let their test teams use copies of production data for these activities. Thus many DTAP environments are filled with critical and privacy-sensitive data. In most cases that means that the vast majority of the team has access to this data. Of course, you know and trust your employees, but keep in mind that leaks can happen accidentally as well.

What can you do?

The most obvious solution might be to make sure teams don’t have access to (all) the critical data. That sounds harder than it is. Test and development teams need proper data for their test work. Proper test data is data that is representative of production. It doesn’t have to be (a full copy of) the production data itself:

1. If you mask or anonymize your test data, you don’t have to worry about it anymore. In fact, according to recital 26, the GDPR is not applicable to anonymous data. So when your teams are working with anonymous data, you don’t have to worry about a data breach anymore.
2. If you extract smaller subsets out of the production data, containing only those test cases that are needed for the test work, you significantly reduce the risk of a data breach. After all, they don’t have access to all the (masked or not) data, only to a small part of it.

A safe test data architecture

By building and using a test data architecture that contains masked and subsetted test data, you reduce the risk of data being leaked – on purpose or not. The lead image for this article shows a schematic overview of what such a test data architecture can look like.

It includes the creation of a so-called ‘Master TDM’ or a ‘Gold copy’; a full – masked – copy of production. This Master TDM is compliant with privacy regulations and can be copied or subsetted into the downstream environments for QA and Dev.

Don’t Use Unmasked Production Data For Testing

The conclusion of this article is pretty simple: don’t use unmasked production data for testing if you don’t want to risk data breaches and the associated fines and image damage.

Of course, not every employee can work with only masked data or only a subset of it. Some need timely access to all production data in order to do their work effectively. In these cases, you should focus on training employees, make them feel responsible and behave accordingly. Make them aware of the risks of data loss and keep it clear for everyone in the organization who has access to which data and when.