Four Steps Towards GDPR Compliance with Better Test Data Privacy
Organizations around the world have spent the past two years awaiting the impacts of the General Data Protection Regulation (GDPR) when it goes into full effect on May 25, 2018. Research from 2017 showed 88 percent of U.S. companies and 67 percent of EU businesses were well-briefed on the GDPR, but only 38 percent of all respondents had a comprehensive plan in place for compliance.
If your organization still hasn’t established new measures to improve data privacy and comply with the GDPR, you’re cutting it close to overcoming significant compliance hurdles, including:
- Design and implementation of internal processes
- Securing customer consent to use their personal data
- Handling the process of data withdrawal if requested by the customer
- Ensuring data quality
- Cost of implementation
- Data complexity
But the GDPR’s looming deadline shouldn’t dissuade you from overcoming these hurdles and striving for GDPR compliance—now is the time to start ramping up efforts to reach compliance as quickly as you can, as noncompliant organizations face fines of €20 million or four percent of global annual turnover, whichever is higher.
Start Your Test Data Privacy Project
Compliance doesn’t just mean safeguarding production data, though—you need to start test data privacy projects to improve data protection in more vulnerable testing, development and quality assurance environments. I explored the details of a test data privacy project in a , but you can get an overview of the four phases you should focus on here.
Analysis is the first phase and cornerstone of a test data privacy project, as it allows you to identify and document your data model as well as the functional model components of the application.
Data model analysis helps you:
- Document the data components of an application system
- Understand the environment’s data
- Determine the elements considered sensitive
- Define data elements’ association to other data objects
Functional model analysis helps you:
- Determine what business rules and logic apply to sensitive or private data
- Outline expectations of how affected data should be changed
- Understand data validations
- Understand checks done against sensitive data fields
As a technical consultant, I strongly recommend completing analysis without overlapping subsequent phases involving the design and development of disguise rules.
You should design your test data privacy project around the framework of details identified and documented during analysis. The design phase will include two significant parts: disguise preprocessing and rules design.
During disguise preprocessing, consideration needs to be given to translate (lookup) tables and key files. Translate tables are the core of a test data privacy project. Their design, contents and access paths determine how data is disguised. Consider execution consistency, reversibility, uniqueness and the need to select data from a specific range.
Once you understand the possible range of value domains for each sensitive field and the business rules that might apply, determine a fictionalization strategy according to the different disguise techniques available. Multiple disguise techniques exist, including encryption, translation, data generation and date aging.
Use of each technique is dependent on the data element upon which it may act. One of the challenges to face is knowing how to disguise the data while still being able to recognize it as useful and meaningful.
The techniques illustrated in Figure 1 can be applied in various combinations allowing for data integrity to be maintained, as well as consistency and usability. Some techniques apply better to certain types of fields.
The activities outlined during the development phase of your test data privacy project are fundamental to building the solution:
- Create data elements and source data identifiers.
- Create translate tables.
- Write, test and deploy custom functions and adapters.
- Create privacy rules.
- Verify rule coverage.
These can be grouped into multiple logical higher-level milestones within a work breakdown structure to organize the development effort according to the scope of the project, application environments, platforms, available resources and skill sets.
Development should be carefully examined during planning and reviewed after the completion of analysis and design. The development phase gives the project manager the most flexibility to organize the workload as needed and to enable better execution and control of the project.
It is critical to prepare for delivery of the solution generated from your test data privacy project by making sure appropriate access to documentation, human and technical resources are readily available. The delivery phase involves, in addition to the data privacy implementation group, the integration of a multi-disciplinary team including but not limited to:
- Quality Assurance
- Technical Support
During the delivery phase of your test data privacy project, everything comes together—processes are created, automation is implemented, documentation is completed. Delivery is reaping the fruits planted during analysis and design and grown in development.
Unprepared for the GDPR?
With the GDPR just around the corner, companies have a small window of time to improve data privacy. Following these phased best practices through a test data privacy project will help you stay focused on the goals you need to achieve for compliance.
If you’re ready to start a test data privacy project, Compuware can help. Learn more about our Test Data Privacy solution that leverages the strengths of Compuware Topaz for Enterprise Data and Compuware File-AID for a consistent, familiar and secure method to easily access, analyze, edit, compare, move and transform data across all environments.
Latest posts by Marcin Grabinski (see all)
- Four Steps Towards GDPR Compliance with Better Test Data Privacy - March 22, 2018
- 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