Log inskip to content

June 2007
M T W T F S S
 123
45678910
11121314151617
18192021222324
252627282930 

Upcoming Events

  • No events.

Just as with the Y2K crisis of seven years ago, IT workers are being called upon to don superhero suits and save the enterprise from impending technology trouble. But this time, IT will be sifting through the complexities of the federal Sarbanes-Oxley Act of 2002

Public Companies over 75 million already need to comply by 12/15/2007...

Will your SMB be Ready?


Calendar

June 2007
M T W T F S S
« May   Jul »
 123
45678910
11121314151617
18192021222324
252627282930  
Google
Email Newsletter icon, E-mail Newsletter icon, Email List icon, E-mail List icon Sign up for our Email Newsletter

June 7th, 2007

The Dangers of Testing with Real Data

Do you test using real production data? Beware using sensitive data for any application development or testing purposes, since lost or stolen information can trigger costly data notifications, regulatory sanctions, and customer fallout.

Do you test applications using real, production data?

Anecdotally, many developers and QA testers say they prefer to build and test applications using the real thing: actual customer data.

Such practices, however, can violate a number of data privacy regulations. For example, the 1996 Health Insurance Portability and Accountability Act (HIPAA) mandates companies restrict access to people’s personal health data on a “need to know” basis. Likewise, the Sarbanes-Oxley Act of 2002 requires companies to control access and track changes to systems handling corporate financial information. In addition, over 30 states have passed data breach notification laws requiring companies to notify consumers if their personal information may have been compromised. This includes such things as a person’s name and address, date of birth, social security number, and credit card and bank account numbers.

These regulations make no distinction between production and testing environments. Simply put, the requirements are the same whether an attacker hacks into your e-commerce application, or accesses a database in the testing environment. Given such risks, many companies have decided developers — as well as quality assurance (QA) personnel and database administrators (DBAs) — simply don’t have a “need to know,” and thus shouldn’t have access to any sensitive information. Beyond helping protect sensitive data, the company and its customers, this also protects developers: they’re not culpable in the event of a data leak or security breach.

To ensure applications perform appropriately once they launch, however, developers still need access to “good enough” data to build and test their applications. Accordingly, many organizations are creating homegrown scripts, or purchasing off-the-shelf software, to transform sensitive production data into safe but usable test data.   READ MORE

Comments are closed.