One of the biggest challenges for IT security engineers is containing sensitive data. Pinpointing where your company's PII, PHI, and PCI data resides within various production datacenters, collocations, public/private clouds, and DR environments is a major task. The difficulty increases when employees copy and move sensitive data for various purposes. Software developers are notorious for this; they sometimes take a shortcut by using production data in development environments.
Most systems development practices center on a life cycle that includes development, testing, QA, staging, and production. On enterprise networks, these stages are segregated into completely separate network and server environments. When changes or upgrades need to be made to a production application, they are validated first in one or more developer environments. It's usually during this testing period when developers borrow a copy of production data to use for testing.
If your developers are in the habit of using production data in environments other than where it is intended, it is a security issue for two reasons. First, the data could contain sensitive information about customers, partners, and employees. Because it's being copied and deployed in multiple environments, tracking this data can become nearly impossible.
The second issue is that many networks are designed to provide added layers of IT security for production environments while lessening security on others. This is because it is assumed that the data being stored and processed in these environments is not sensitive in nature. It will be easier for hackers to break into these less secure test environments and poach any production data that is being copied over there.
The solution to this problem is twofold. First, IT security admins must train developers to break their habit of using real data in environments other than production. Instead, mock or test data should be created and used for testing purposes. It might take a while longer to get clean test data, but in the end, it's well worth the extra effort. Second, production data must be locked down to the point where only a handful of trusted employees can access it. Very few people should have direct access to this data; this makes it much easier to track down if breaches occur.
Once these two simple goals are accomplished, security administrators can breathe a bit easier knowing that their production data isn't floating around in an insecure test environment.