In a world where superior customer engagement and other market imperatives depend on having the right code in production sooner rather than later, continuous software delivery is a competitive necessity

But you can’t get code into production unless you properly test it. And you can’t properly test code without appropriate test data.

And that’s where the regulators come in.

Solving for Personally Identifiable Information
Production data is rife with personally identifiable information (PII) and other compliance-sensitive content. That data is typically well-protected by various security measures and access controls in the production environment itself. But putting that data (or, more precisely, a sample set of that data) in a test environment exposes it to significant security and compliance risks.

For one thing, test/QA engineers aren’t account managers or clinicians. So, from a regulatory perspective, there are certain kinds of data they shouldn’t be allowed to see. For another, test/QA environments are typically not secured in the same way as production. Worse yet, test/QA is often performed by contractors — and may even occur offshore. This creates unacceptable security risks and throws up big red flags for regulatory auditors.

To protect PII while enabling thorough and effective testing of new code, companies use synthetic data and other masking/obfuscation techniques. That’s what regulators demand and expect.

Yet another roadblock?
Unfortunately, most companies generate test data on a very ad hoc basis. At some point in each project, someone realizes they’re going to need some test data — and they set about creating it. But without a global mechanism for determining what needs to be masked and actually performing that masking, the undertaking becomes iffy and time-consuming. Not all the data that needs to be masked gets masked. A couple of developers may independently decide that the best thing to do is write a one-off script. And if the script doesn’t work well, the team may just cross their fingers and opt to forego masking altogether.

Hence the title of this blog. Of course regulators don’t actually hate continuous delivery. Most of them probably don’t even know what it is. But their mission — enforcing the diligent protection of sensitive data — can be a serious obstacle to continuous delivery for companies that don’t get their act together when it comes to test data management.

The solution: Continuous compliant delivery
The only way to reconcile the requirements of regulatory auditors with the need of the business for continuous delivery is to adopt a well-managed enterprise-wide mechanism for test data creation. Such a mechanism accelerates every code promotion workflow across every project, while also providing an auditable means of enforcing PII masking/obfuscation policies. Enterprise test data management also reduces devops costs by eliminating the need to re-invent the data-masking wheel on every project.

So, no, regulators don’t hate continuous delivery. But they could — if companies sacrifice compliance for speed. The best way to avoid that sacrifice is to embrace enterprise-class masking discipline for test data.

About the Author/Aruna Ravichandran

Aruna Ravichandran is vice president of DevOps Solution Marketing and Management at CA Technologies, responsible for cross-portfolio solution marketing for DevOps across all product lines. Before joining CA Technologies, Aruna held several management positions in product marketing and engineering at Juniper Networks and HP. Aruna earned an MBA and master’s degree in Computer Engineering from Santa Clara University and holds a bachelor of science degree in computer science from Bangalore Institute of Technology. Ravichandran is  on twitter @aruna13 and on Linked in