September Issue of the Taos Newsletter: Sarbanes-Oxley (SOX)

Sarbanes-Oxley (SOX)

By Chris Motta, Senior Director, Information Technology, Redback

In mid-September Chris Motta, Senior Director, Information Technology at Redback Networks, presented a talk at Taos on his experience with the Sarbanes Oxley IT Audit process. What follows are the highlights of his presentation. Chris is responsible for all of Redback’s IT business applications and infrastructure. Redback has contracted Taos to help them achieve Sarbanes-Oxley (SOX) compliance, and Taos is currently assisting them with project management and technical writing support.

What is Sarbanes-Oxley?

The Sarbanes-Oxley Act of 2002 (SOX) is a congressionally mandated act for the documentation and attestation of the financial statements of publicly held companies. SOX is different from previous financial attestations in that it goes beyond the financial statements and auditable results and into the underlying tools and processes which generate those reports. Failure to comply can lead to criminal penalties for corporate officers. Executives must attest and assess the effectiveness of internal controls of financial reporting. “You cannot just make your numbers look good, you have to prove that the process by which you generated your numbers is also valid and reliable.”

Sarbanes Oxley has two areas of focus that must be documented:

• Financial Processes and related SEC disclosures
• IT infrastructure that supports the financial business processes

The IT department is responsible for documenting the system controls for everything that relates to a financial system. That includes anything from the ERP components to their Oracle implementation, and more. What makes compliance so complicated is that these controls can even cover Excel spreadsheets if the spreadsheets contain numbers that eventually roll up to become part of the corporate financials.

Chris stated that, “In this valley, identifying and documenting all of the systems and processes is particularly challenging because we have so many Start Ups that do not have an underlying infrastructure or discipline. There’s a lot of angst out there about trying to get control of their processes, and now it is the responsibility of the IT Department to address their documentation issues.”

A typical Sarbanes-Oxley IT project can be summarized as follows:

• Inventorying and documenting the key processes surrounding the corporate financials
• Making sure that key controls are in place that will ensure that the processes are followed
• Development and execution of tests to demonstrate that the processes work as they are documented
• Auditor review of documentation and controls
• Auditor testing of processes and controls to verify stated operation and effectiveness
• Gap analysis and findings/recommendations for improving controls if deficiencies are found

The Time Factor

After a couple of reprieves from the SEC last year, the need to meet SOX compliance within the next twelve months is becoming real for most public companies. In speaking with other companies, Chris found that some were caught off guard by the need to do SOX for IT infrastructure as well as financial applications. Chris stated that, “What they didn’t realize is that there’s a huge IT component that is underlying the financial systems, and that has to be in compliance as well. A company can say that their financial numbers are okay, but SOX forces them to ask how the numbers were derived.”

Unfortunately, many companies are finding out too late that the IT components must be covered as well. Chris told us that it’s not uncommon to hear stories where the external auditors arrive for the final audit and say, “We need to look at your IT systems.” When that happens, things just fall apart, and the company needs to adjust their SOX project because they did not expect that the IT Department was to be included. Those companies that fail their audit have to enter a statement in their financial publications stating that they failed, which is not something most management teams want to publicize. The rumor out there is that 25-30% of the companies audited will get a failing grade. Redback is already one step ahead of the rest because they have included the IT infrastructure in their SOX readiness project.

Who Gets Involved

There are many roles within a SOX project and audit. When asked about the “Ideal SOX Team,” Chris surmised that this would include the following:

• Technical writer(s)
• Technical staff (subject matter experts) for the IT infrastructure components
• A Financial Business Applications Functional Expert (preferably specific to each of the company’s financial systems, for example, ERP system, Oracle, Great Plains, and so on)

Ideally you could find a technical expert that is very good at documentation, but Chris feels that is a rare find, especially as the documentation effort includes a lot of investigation; talking to many people to research exactly what processes are in place for a given system.

Due to resource constraints, many companies are bringing in SOX consultants. Redback is using two consultants from Taos: a Senior Technical Consultant, and Technical Writer. Chris stated that “Because of the amount of effort and the short timeline, almost everybody that I’ve talked to has had to bring in outside consultants to help them with the documentation effort. Bringing in outside consultants also allows you to do some of testing before the auditors arrive.”

IT Categories That Must Be Documented

The systems for which you need to document key controls will vary from company to company, depending on how these systems tie to your financial reporting. At RedBack, the controls they are primarily concerned with are Oracle, UNIX, and Windows. Within these primary controls, there are seven major areas that RedBack is documenting in order to meet SOX compliance, including:

• System security which includes both physical and operational
• Network security which includes both availability and access authorization
• Account authorization, creation, and modification for all key system
• Data integrity and backup methodology
• Controls monitoring

• Business applications configuration and setup

• Change control procedures for business applications and infrastructure

Addressing these areas can often uncover issues that would lead to complications with SOX compliance. Chris illustrates, “You know you definitely have a problem if you have someone that has authorization to do inventory, cash disbursements and general ledger access without controls. This is a huge conflict of interest because an employee can bypass a process and essentially fill out false expense reports and pay himself or herself, without being tracked."

Separation of duties within financial systems is one of the key areas companies struggle with, and becomes more difficult the smaller a company is. Another difficult area for companies to deal with is disaster recovery. SOX compliance in this area is somewhat unclear. Redback originally thought that disaster recovery testing was part of SOX compliance and that you would have to prove that your disaster recovery plan was in place and, effective. After working with auditors and prioritizing areas to focus on, Redback discovered that disaster recovery was not a primary concern for compliance, though as SOX evolves, that could change.

Testing and verifying that the controls work is very important, and once tested, Change Management must be in place to ensure that they are working. Chris told us that somebody has to check all controls and make sure that they work. At some point, controls need to have manual verification. Many companies are relaxed about periodic reviews of their key processes and authorization lists. With so many teams short staffed, this often gets forgotten. You need to make sure that when changes to a process occur, they are well communicated, documented, and approved. For example, if a director’s signing authority level was $5,000 and somebody accidentally changed it to $10,000, someone could approve something that they shouldn’t have been allowed to. Process breakdown is one example of a way to fail SOX audits. Change control processes for all aspects of your systems: OS, Network, Applications, and so on, are key controls that must be documented and tested.

Key Issues in Attaining SOX Compliance

Sarbanes-Oxley compliance is no easy task. There are a lot of issues out there preventing this from being a smooth process. Chris’ top six issues are:

• Lack of Existing Documentation in Finance or IT

A lack of documentation around financial reporting systems is a big issue. Many processes are not documented, as companies were not required do so. Process documentation is required for SOX compliance and is also considered “Best Practice.”

• Discrepancies Between Documentation and the “Real World”

It may seem obvious, but you must write how it is done not how it should be done. Redback had an instance where one person wrote documentation around how they wanted the process to work. Internal auditors identified differences between what was documented and what was being done.

• Lack of Resources Needed to Meet SOX Compliance (both internal and external)

Many companies are doing their own SOX readiness work. With reduced work forces and the slow economy, companies do not have time to do all of the SOX readiness work. Additionally, there is high demand for consultants from external auditing firms and they are unable to provide enough people to cover all the requests. Chris admitted, “It normally wouldn’t take us six months to get an external auditor to come in and look at our IT stuff, but lately it’s been like pulling teeth - They just don’t have enough people on hand.”

• Significant gaps in best practices and actual practices

In the perfect world, your IT organization would be in complete compliance with COBIT. The Information Systems Audit and Control Foundation (ISACF) developed the Control Objectives for Information and related Technology to serve as a framework of IS security and control practices for information technology control. In reality, few companies have the time or the resources to make that happen in time for their SOX audit.

• Sarbanes Requirements Being a “Moving Target”

SOX legislation is very general and it has taken auditors quite some time to break it down into detailed requirements. Even now, interpretation varies from auditor to auditor and is constantly evolving. Since it is the first year, everyone is learning!

• Difficulty in motivating employees to assist in Sarbanes work

Some companies realize the benefits of SOX compliance and are freeing up their IT staff to work on SOX readiness. It can be a difficult concept to sell and executives often do not see the ROI. CIOs should but do not take advantage of SOX compliance needs, though they should realize that SOX can be a tool to get funds to make IT process improvements.

SOX, Ever-Changing

It is also important that you work closely with the SOX auditors. It is next to impossible for everyone to cover every possible control. Prioritizing the importance of areas based on your auditor’s advice is a useful way to maximize efficiency.

Using external consultants that have experience with SOX can help you to meet SOX requirements, and to streamline your IT processes to meet “Best Practice.” SOX is new and companies are doing this for the first time. In some cases, small public companies have decided that meeting SOX compliance will be a big and expensive problem, so they are going private. For larger companies it may be worth it to establish internal SOX departments to keep up on rule changes, expansions of scope, and (potentially) more frequent reporting deadlines.