Rebecca Edwards

16 August 2018

1 Comment

What SOX means to the DBA

The responsibilities of a database administrator can seem endless, so why should that already heavy workload be burdened with legislation compliance? Surely, legal stuff can be dealt with by lawyers?

Unfortunately, this is no longer the case. With legislation like the GDPR, PCI, CCPA, Sarbanes-Oxley (SOX) and HIPAA, the requirements for protecting and preserving the integrity of data are more critical than ever, and part of that responsibility falls with you, the DBA.

Introduced in 2002, SOX is a US federal law created in response to several high-profile corporate accounting scandals (Enron and WorldCom, to name a few). The public and shareholders alike were in an uproar about the fraudulent activities that came to light and companies everywhere were subsequently expected to raise standards to address their concerns. Corporations needed to change the way they worked from the top down and, by law, that means the DBA too.

So what does that mean for a DBA?

For DBAs this meant introducing new procedures around protecting data, creating backup and recovery processes, and ensuring the auditing, encryption and restricted access of regulated data. Importantly, SOX isn’t like many of the other regulations where protecting personally identifiable information (PII) is the main goal. Instead, financial data is the primary focus when trying to maintain compliance.

This information will likely need to be made public sooner or later, so data breaches are not the biggest problem. You need to ensure that data doesn’t get inserted, updated or deleted without being recorded or, worse still, without your knowledge. It’s about ensuring shareholders have a transparent view into the company.

These prerequisites might sound simple but in practice they can be quite difficult to meet. Keeping track of who changed what, when, where, and how across all activities can seem daunting. There is also the concern that it will have an impact on performance and disk space.

One approach may appear to be reducing who has access to the data. If we reduce the number of people who have access, after all, we reduce the work needed to track those interactions.

A development team might protest, however, that it is absolutely critical they have access to real data in order to accurately test their changes and work effectively. And they’re correct. Generated data as a solution does not tend to test well and can slow down your release processes. Striking a balance between data protection and data performance is the challenge.

Compliance with performance

The worry that processes in place to ensure compliance can bottleneck the development process is a very real one. So how can you have the best of both worlds?

The solution is to provision and mask copies of production databases with realistic, workable data, and this idea of masking and provisioning going hand in hand is called out in the recent Data Masking report from Gartner:

“Test data (or copy data) virtualization is a technology that is increasingly popular, when used in combination with SDM (Static Data Masking), to speed up the provisioning of and updates to target environments, in addition to significantly reducing the amount of storage required by these environments.”

So while compliance does have an impact on database development, it doesn’t mean it has to slow it down.