Test data management and regulatory compliance

Test data management plays a crucial role in ensuring the success of testing any application. Most of us spend a lot of time searching for an accurate test data satisfying the test case pre-requirements. A pre-requisite before procuring test data, would be to sit down during the planning phase with the entire team and document all the scenarios that are to be covered during the course of the test execution. This would eliminate the chances of missing out on any critical/non-critical scenarios in the future. Test data may be contained in a database table or any kind of file or even spreadsheet. It can also be of any format for example xml test data, system test data or even SQL test data, etc. Generation of test data involves a sanity, accuracy and integrity check of the test data in all related database tables. This means before test case execution the existing data is extracted from the database and therefore edited or conditioned to fulfill the test case requirements. Test data can also be categorized to ensure complete functional test coverage. Testers can also be creative, use their own skill and judgments to create different data sets instead of relying on standard production data while testing.

Sensitive personal, financial, and health information are governed by a variety of industry and governmental data privacy regulations like PCI, HIPAA, GLBA and SOX. They should be considered by Project managers when deciding upon test data and test environment.  It is essential that organizations protect their applications and databases from business users, production teams, DBAs, developers, and offshore and outsourced test teams, while allowing them to do their jobs. Basic security measures like authentication, authorization, and access control are not good enough to meet these various requirements. Organizations should consider advanced security measures like data encryption, auditing, data masking and real time monitoring to ensure data privacy and protection. Payment Card Industry Data Security Standard (PCI DSS) mandates strong data security measures. The top four PCI requirements that need attention are:

Requirement 3: Protect stored cardholder data. Sensitive data wherever it may be production or non-production, off-line or on-line, on-site or off-site, disk, tapes or devices. Recommended approaches to protect databases include data masking for non-production, data-at-rest and data-in-motion encryption for production environments. (Requirements and Security Assessment Procedures, 2013)

Requirement 11: Regularly test security systems and processes. All organizations dealing with credit card numbers regularly test their systems from a data privacy point-of-view. Recommended approaches include auditing, monitoring, and encryption. (Requirements and Security Assessment Procedures, 2013)

Requirement 8: Assign a unique ID to each person with computer access. Therefore, some organizations need to consider integrating application users with database user to keep track of who accesses private data. Recommended approaches include auditing and monitoring of sessions across applications and databases. (Requirements and Security Assessment Procedures, 2013)

Requirement 10: Track and monitor all access to network resources and cardholder data. Only authorized users can access networks. In addition, cardholder data needs to be monitored based on who is accessing or changing such information. To meet PCI DSS requirements, organizations must take steps to ensure they are protecting cardholder data with controls such as data masking, encryption and monitoring. (Requirements and Security Assessment Procedures, 2013)

HIPAA mandates all patient records be protected in all environments. All protected health information (PHI)-related data residing on any database needs complete data protection. The key requirements from a database point of view are in Section: 164.308 for administrative safeguards and Section: 164.312 for technical safeguards. (Security Standards: Administrative Safeguards, 2007)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s