Five ways to prepare for a SOX audit

DBAs, prepare for the inevitable Sarbanes-Oxley (SOX) audit with these five best practices for compliancy.

For those of you who have not yet had the pleasure of being audited for the Sarbanes-Oxley Act (SOX), the experience can be about as pleasant as a trip to the dentist. But it doesn't have to be that painful. Just like when visiting the dentist, a little proactive maintenance and preparation can go a long way toward making the experience a lot less stressful. Ignore your teeth and you will ultimately pay the price (unless you enjoy the sound of drilling into bone).

This article highlights five steps you can take now to make the experience of preparing for a SOX audit a little less daunting.

What is Sarbanes-Oxley?

Before you prepare for an audit, you should understand what you are preparing for. The Sarbanes-Oxley Act first became law in 2002, shortly after questionable accounting practices were uncovered during the stock market boom of the 1990s -- although most folks will remember 2004 as the first year for mandatory compliance. The purpose of SOX is simple: to protect the public from fraudulent and misleading accounting practices by regulating financial reporting practices.

Actually putting SOX into practice, however, is not so straightforward. In fact, many organizations still have no idea how to become compliant or how to prepare for an audit. Compliancy has hence become a multi-billion-dollar industry, and the expense of compliancy is a huge burden for public companies of all sizes.

SOX and the DBA

At this point you might be thinking, "I'm in IT -- let the accountants and the CFO deal with SOX compliance." This attitude will definitely get you into serious trouble! At first glance SOX may appear to be an accounting concern, but make no mistake about it -- IT is definitely at the heart of the issue. Think about it. Most accounting functions rely heavily upon applications that run on computers. Couple this with the fact that financial data is stored in databases, and DBAs in particular will find themselves under close watch and scrutiny for compliance.

Sections 302 and 404 of the act have the most relevance for IT governance. In a nutshell, these sections require that all company officers guarantee the accuracy of their financial reports. This in turn requires that all company data used to generate these reports be subject to formal auditing procedures to ensure against incorrect or illegal modifications. Since financial reports rely on the use of a company's IT systems, the security and integrity of these systems is of utmost relevance. It seems logical then that security and change management are, and will continue to be, the most scrutinized aspects of database support. After all, the database is the primary repository for the company's most valued information.

Why should I care?

If you work for or ever plan to work for a publicly traded company, chances are pretty good that you will someday face a SOX audit. If you work for a privately owned company, don't rest too easy just yet. Many privately owned companies are also adopting and even embracing SOX (or other) compliance. You simply cannot avoid it. As a DBA, you will someday be responsible for a database that houses sensitive data, whether it be SOX-regulated financial data (payroll, general ledger, accounts payable, accounts receivable), medical data (now regulated by HIPAA) or just personal information regulated by the Privacy Act.

Let somebody else worry about it? I think not. Sarbanes-Oxley is intended to regulate the internal controls used for corporate information. It is the legal obligation of the CEO to guarantee that the data used to produce reports is accurate and has not been manipulated in any way. While it starts with the CEO, it only rolls downhill from there. The CEO in turn will rely on the CIO to ensure that the IT processes and controls are compliant, and the CIO will in turn rely on the IT managers, who ultimately will rely on you, the DBA, to ensure that the data is controlled and safe.

Types of audits

It is imperative that you first understand the difference between an internal and external audit. In essence, an internal audit is used to prepare the organization for an external audit. Believe it or not, I have found that most internal audits tend to be longer, more detailed and even more thorough than their external counterparts. External auditors tend to individualize their interpretations of SOX, and each auditor will focus on different aspects of IT compliance. Hence, my theory is that the internal auditor has to prepare an organization for each and every possible external auditor interpretation that they might (or might not) face.

If a company is lucky enough, external auditors may even use some of the findings from the internal audit, if they believe it is valid.

1. Prepare for the audit

Having worked in a DBA and/or management role at Fortune 500 corporations and having serviced many public companies of all sizes as a remote DBA provider, I have been personally involved in a number of audits, and no two were ever the same. The audit experience and what you will need to do to provide for it is really dependent on the individual auditor, their approach, and how they incorporate the act itself into best practices and procedures.

So, what is a DBA to do? I can sum it up in just one word: prepare! You may not realize it, but by reading this article you have already taken the first step, which is to research and understand the importance and relevance of SOX for IT.

Here are the remaining four steps you can take right now.

2. Document, document, document!

Since most DBAs (and most IT folks in general) hate to document anything, this is probably the last thing you want to hear. Heed my warning now, every audit will start with documentation. You will be asked to provide documentation for everything from users and passwords, to lists of applications that access data, to what is being monitored, to processes and procedures used for administering and protecting the database. Think of just about anything you do on a financial database, and you will most likely be asked to explain and provide documentation for it.

Don't delay! Start documenting everything today!

A great place to start is with security. Document your security policies and procedures, application access types, privileged accounts (and why they are needed), password policies, etc. Write scripts to query and report on database users, roles and privileges. And don't forget to document the procedures used for running and checking them.

After security, focus on documenting change management policies. Do you have a documented change management policy? If not, now might be a good time to write one! Does your policy address data changes as well as structural changes? Who approves the changes? Who makes the changes? Who verifies changes? Where are they tracked? Are they reviewed? By whom?

Additional questions you may want to consider preparing documentation for include:

  • Do you have an archiving strategy? Is it documented?
  • Do you have a recovery strategy? Is it documented?
  • Do you monitor for violations and/or security breaches? Is it documented?

I could go on and on, but hopefully you get the idea.

3. Research, learn and put best practice frameworks into practice

You absolutely must have a best practice framework in place to pass a SOX audit. Frameworks such as COBIT (Control Objectives for Information Technology) and ITIL (Information Technology Infrastructure Library) are a great place to start. If your organization has not implemented these yet, time is wasting. Don't be lazy but rather be proactive. Do not wait for the rest of the IT department to adopt or mandate these frameworks. Be a leader and research them yourself, learn what makes the most sense for your role, and at a minimum, recommend implementation of these best practices in the database group if not the entire organization.

Focus your efforts first on change management strategies, release management, incident and problem management.

4. Get ready to prove it!

It is an auditor's job to be inquisitive. An audit is really an inquisition, complete with hundreds of questions you will be expected to answer. But answering is not enough -- you must be able to back what you say with hard evidence. You can etch this in stone: An auditor will never take your word for anything! You must provide evidence for all your answers, especially those related to security and change controls.

Here are some sample questions you can expect to be asked:

  • Do you know who has access to the data? How do you know? Prove it!
  • Do you know when the data is changed? How do you know? Prove it!
  • Have you implemented database level auditing? How do you review it? Prove it!
  • What monitors do you have in place? How often are they checked? Prove it!
  • Do you ensure that data changes are legitimate? How do you know? Prove it!
  • Do you apply security patches regularly? Prove it!
  • Do you ensure that the data is secure? How do you know? Prove it!
  • Is your data recoverable? How do you know? Prove it!
  • Do you have an off-site disaster recovery policy? When did you last test it? Prove it!

As you can see by this line of questioning, it is imperative that you have sufficient evidence for each and every answer you give. So don't wait for the question to be asked -- start preparing by gathering up your evidence now. Better yet, put processes in place or find tools to help you automate the evidence-gathering process so that you don't have to scramble to find it or produce it later.

5. Perform a self-analysis of your gaps

If you have already been through an audit and have access to the report, this step is already facilitated for you, as you most likely have a laundry list of items to address before the next audit. If you have not been through an audit, you are still likely to uncover a lot of gaps if you follow the first four steps described in this article. Analyze each gap, document it and put a plan together to address it. Approach your boss with this analysis and obtain his sponsorship to support you in addressing the gaps. The most important thing is to not wait until the SOX man cometh to start addressing these gaps. Nothing will get you into more trouble or cause you more stress than the wait-and-see approach.

What are you waiting for?

I will not deny it, SOX compliancy can be a royal pain in the rear, and most IT folks would rather ignore it. But don't be foolish. Compliancy issues are reality and they are not going away anytime soon. Do not delay. Take my advice and champion an effort to start working on these five steps. Understand SOX, document everything, follow best practices, be ready to prove that you do, address your gaps and, ultimately, become the hero of your IT organization!

About the author

Michael Hillenbrand directs and manages the AES Select Outsourcing group at Access Enterprise Solutions. As director, Michael is responsible for defining processes and procedures, assisting with sales and marketing efforts, defining and governing service levels, and ensuring continued quality and success for AES Select customers.

Michael began his career as a DBA with US Steel then moved on to manage the corporate Oracle DBA team at Alcoa. For the last 10 years Michael has been leading remote support efforts. Having been in a leadership role throughout most of his 20+ year career, Michael has hired and managed over 50 DBAs and supported well over 100 clients. Michael's specialties include best practices (ITIL Foundations Certified), quality improvement and daily operations. Michael also has a strong background in database support, including Oracle (OCP Certified), SQL Server and DB2.

Dig Deeper on Oracle governance, risk and compliance