The GDPR Countdown Has Begun for Companies Serving EU Citizens
Is it just me or does this sound cryptic?
Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC.
Are you nodding your head? Let me translate. This legalese from the EU General Data Protection Regulation (GDPR) complexly states the new data protection legislation was voted in on April 2016. The legislation has been published in the Official Journal, making it a valid law in all 28 EU countries, and it’s coming into full force two years from today on May 25, 2018.
Mark the date on your calendar. Create a monthly reminder. The countdown has begun—the clock cannot be reversed. Is your IT organization ready? Two years will pass before you notice. Should your company fail to comply with GDPR legislation, massive fines (up to 4 percent of your company’s global turnover) will be imposed.
Improving Data Protection Under GDPR Standards
Changes in data protection standards under the GDPR require companies serving EU citizens to significantly improve their data privacy practices. While companies’ production databases are well protected, what can be said of testing and development environments?
Multiple copies of production data; access by third-party personnel (outsourcers, software and development partners, subcontractors—beware); and less diligent audits, among other factors, create high risk for a data breach. It doesn’t take a hacker. If databases are cloned and sensitive data is copied without any control onto portable devices to be accessed from home or unsecure networks by the aforementioned parties, your company is asking for trouble.
Why get into the trouble in the first place? Testing environments should be free of real data!
Management of test data is difficult enough with a quality data privacy solution in place. But if your company doesn’t have any sufficient data protection tools or processes in place, it won’t survive the impact of the GDPR. With only two years to go before the GDPR is in full force, your company needs to think fast. Let me use the example of data masking to put into perspective the importance of implementing a quality data protection solution able to handle the demands of the GDPR.
Implementing a Data Protection Solution: An Example with Data Masking
Often, when you analyze databases and files used in testing, you discover hundreds, if not thousands, of sensitive columns and fields that could compromise citizens’ rights to privacy. Earlier this year, I worked with an IT organization serving insurance companies. Their tally was some 1500 sensitive columns, 346 of which were distinct column names. How many disguise rules do you think the company needed to “pseudonymize” 1500 sensitive columns with 346 distinct column names?
Traditional approaches to data masking based on columns and fields work well in demo applications, but real life is more complex than that, especially under the GDPR. Even copy and paste isn’t a solution. You need to think in terms of data categories, instead of going down to columns and fields.
To answer the question of how many disguise rules the company needed to psuedonymize the columns, my customer had 22 distinct categories of sensitive data, and insurance companies typically have more than customers in other verticals. Therefore, we had to create only 22 Rules, as opposed to 346 (if not 1500) with traditional approaches.
If you can create rules per category, it will make your life much easier (and just think of maintenance once the rules are ready). I call such an approach “the Magic of Data Elements.”
There is, of course, no magic in IT (or is there?), and at the end of the day, rules will have to be applied to hundreds or thousands of columns. However, think about how test environments are created. Typically, they are periodically refreshed from production by means of related extracts (no sane person would test with full volume production data, unless it’s a load test). Application and database experts prepare such extracts containing hundreds of related tables. If disguise rules can be applied to these related extracts, they cover all relevant columns. The secret to the magic is to define proper associations between data elements and physical column names.
The Difference Between Embracing and Neglecting Data Protection
This “magical” method of data elements will work well to help companies comply with strict standards set by the GDPR, at least with regard to data masking. It makes masking data efficient and accurate, leaving little room for error. But imagine what this process would entail without using data elements. Would a company be more at risk of breaking data privacy laws through error and lack of data protection? Most likely.
Remember, the clock is ticking towards May 25, 2018. If your company isn’t prepared to meet the demands of the GDPR, Murphy’s law will be proven again. But why should it be proven in your organization, or any organization for that matter? Take steps before it’s too late and start a test data privacy project now.
Read how to start a test data privacy project here.
Photo: Flickr: Julian Lim
Latest posts by Marcin Grabinski (see all)
- The GDPR Clock Is Ticking: Two-tier Access to a Lookup Table - August 23, 2016
- The GDPR Clock Is Ticking: Accessing a Data Lookup Table - August 9, 2016
- The GDPR Clock Is Ticking: Creating a Data Lookup Table - July 19, 2016