Regulatory Compliance and Database Administration

Bookmark and Share

It is impossible to have missed the sweeping changes being thrust upon the data world due to regulatory compliance. But even if you’ve noticed, chances are that the sheer volume of regulations was too mind-boggling to fully digest. With that in mind, this month’s column will offer a brief introduction to the regulatory landscape and its impact on database administration.

There are many industry and governmental regulations driving the need to improve data protection, management, and administration. One of the more visible governmental regulations is the Sarbanes-Oxley Act (SOX), officially known as the U.S. Public Accounting Reform and Investor Protection Act of 2002. The goal of SOX is to regulate corporations in order to reduce fraud and to improve disclosure and financial reporting. The impact and cost of the law on IT and database management is significant. Section 404 of SOX specifies that the CFO must guarantee the processes used to produce financial reports. Those processes are typically computer programs that access data in a database, and DBAs create and manage that data as well as many of those processes.

Consider also the HealthInsurancePortabilityandAccountabilityAct, commonly referred to as HIPAA. This legislation mandates that health care providers protect individual’s health care information, going so far as to state that the provider must be able to document everyone who even so much as looked at their information. HIPAA audits frequently require the examination of the processes used to create, document and review exception reports and logs. When confronted with a HIPAA audit, organizations can be required to produce a list of exceptions to policy, such as, “When were patient records accessed during off hours and by whom?”  Without database auditing software, it is impossible to produce a list of users who looked at a specific row or set of rows in any database.

Other compliance related legislation includes the Gramm-Leach-Bliley (GLB) Act (also known as the Financial Modernization Act of 1999) and the E-Government Act, passed in 2002 as a response to terrorist threats. Title III of the act is named the Federal Information Security Management Act (FISMA), which states that federal agencies, contractors, and any entity that supports them, must maintain security commensurate with potential risk.

SOX, HIPAA, GLB, and FISMA are examples of governmental regulations. But there are industry regulations that can be just as daunting in terms of compliance. The most visible industry regulation is certainly PCI-DSS, which stands for Payment Card Industry (PCI) Data Security Standard (DSS). It was developed by the major credit card companies to help prevent credit card fraud, hacking and other security issues. A company processing, storing, or transmitting credit card numbers must be PCI-DSS compliant or they risk losing the ability to process credit card payments.

Regulatory compliance holds an important sway over upper level management at most medium- to large-size organizations because of its potent impact. Business executives are keenly aware of the need to comply, although they are not always aware of all the details that involves. This is so because failure to comply can result in prosecution which may involve huge fines and even. Regulatory compliance can impose upon C-level executives the need to be able to prove that corporate data (and therefore, database systems) are protected and that processes and procedures enacted upon the data are accurate and required.

Ensuring compliance requires a collaborative effort between business users, IT, and your legal department. This can prove to be a challenge because these three disparate groups are quite distinct and rarely communicate collectively. IT talks to legal only when they have to – and that is usually just to get approval on contract language for software purchase. IT and business communicate regularly (at least they should), but perhaps not as effectively as they might. But all three are required:

  • Business: must understand the legal requirements imposed on their data and systems as dictated in regulations
  • Legal: must be involved to interpret the legal language of the regulations and ensure that the business is taking proper steps to protect itself
  • IT: must be involved to implement the policies and procedures to enact the technology to support the regulatory mandates

Organizations need to map and categorize their business data in accordance with how each data element is impacted by regulations. We need to be able to answer questions like: Which data elements are under the control of which regulation? And what does the regulation require in the way we manage that data?

Once mapped, controls and policies need to be enacted that enforce compliance with the pertinent regulations. This can require better protection and security, enforce longer data retention periods, impose stricter privacy sanctions, mandate improved data quality practices, and so on. 

Why Should DBAs Care About Compliance?

Compliance starts with the CEO, but it works its way down into the trenches, and impacts database administration. The CEO relies on the CIO to ensure that IT processes are compliant; the CIO relies on the IT managers, one of whom (the DBA manager) controls the database systems; and the DBA Manager relies on DBAs to ensure that data is protected and controlled.

The impact of regulatory compliance upon database administration is various. The DBA is not responsible for developing and enforcing compliance, but his job is impacted based upon compliance-related projects and responsibilities. The primary impact of compliance on the DBA is in investigating, installing, and managing the technology that supports compliance, particularly regarding data and the DBMS.

Compliance-related tasks that impact database administration include metadata management, data quality, database and data access auditing, data masking and obfuscation, long-term data retention and database archiving, as well as closer tracking of traditional DBA tasks such as change management, and backup and recovery.

Indeed, as regulatory compliance better protects citizen’s data, it creates more work for DBAs.

(This column was adapted from Craig S. Mullins' soon-to-be-published second edition of “Database Administration: The Complete Guide to DBA Practices and Procedures.”)