Manage Learn to apply best practices and optimize your operations.

Some benefit from Sarbanes-Oxley; others struggle with SOX compliance

SOX compliance requirements can lead to process improvements and data governance for larger firms, but smaller shops still struggle with Sarbanes-Oxley.

The first decade of the 21st century saw a spate of new regulations in key IT categories. From privacy and security rules like California’s SB1386 and the USA Patriot Act, to hybrids like HIPAA and the Gramm-Leach-Bliley Act that targeted health care and finance respectively, IT departments had to change processes and add controls to prove compliance.

The biggest governance regulation of them all, of course, was the Sarbanes-Oxley Act of 2002 (SOX), which attempts to provide better corporate governance and financial transparency for publicly traded companies and debt. Some private firms and foreign entities also attempted to meet SOX compliance requirements, hoping to curry favor with their publicly traded partners or to facilitate mergers and acquisitions.

The United States still passes thousands of new “final rules” annually, multinational firms still deal with conflicting requirements (particularly on privacy, security and governance) in different jurisdictions, and billions have been spent on SOX.

In 2003, the year I founded the IT Compliance Institute, a publication aimed at chief financial officers ran a survey asking its readers about the anticipated effect of the Sarbanes-Oxley Act on a variety of roles. The overwhelming majority of readers -- more than 80% -- concluded that SOX compliance requirements would have little or no impact on IT budgets and operations. I was dubious about that finding, so in 2004 I conducted a survey with Robert Frances Group Inc. aimed at CIOs. Perhaps it was the intervening time that made the difference, but the results were unambiguous: 100% of the CIOs I talked to anticipated a major, long-lasting impact on IT. They were right.

As a refresher, the SOX requirements that caused the most pain for IT were:

  • Section 302: Corporate responsibility for financial reporting.
    • Is our financial data accurate?
    • Do we have transaction-level detail if required?
    • Do we understand all the processes involved?
    • Can we close the books on time, and do we trust the results?

  • Section 404: Annual management assessment of internal controls.
    • How does our control structure operate?
    • Who is accountable?
    • Is it monitored?
    • Is it documented?

  • Section 409: Real-time disclosure of material changes.
    • ”Each issuer reporting … shall disclose to the public on a rapid and current basis such additional information concerning material changes in the financial conditions or operations of the issuer, in plain English, which may include trend and qualitative information and graphic presentations, as the Commission determines, by rule, is necessary or useful for the protection of investors and in the public interest.”

  • Section 802: Retention of relevant records for audits/reviews.

Now that we’ve had some time to evaluate SOX implementations, it should be instructive to revisit the issue from an IT perspective and see what we’ve learned that may help with the thousands of minor new final rules passed each year, and the few major regulations on the horizon.

Lessons learned from eight years of SOX compliance requirements

A cost/benefit analysis of SOX on IT should parallel the costs and benefits to the enterprise at large. The general consensus from several surveys is that Sarbanes-Oxley compliance results in more efficient and transparent business processes, but respondents vary widely in their assessment of whether the benefits outweigh the costs.

As expected, large firms spend a smaller percentage of their budgets -- IT and overall -- on SOX compliance than smaller firms. There are economies of scale, and some requirements apply across the board, putting the smaller firms at a competitive disadvantage. In particular, it is still too difficult for small shops to deal with separation/segregation of duties, which require that different people have access to applications and data throughout the lifecycle to provide adequate controls against fraud. In small shops, one person may have multiple roles at different times, making compliance a thorny issue.

The general consensus is that Sarbanes-Oxley compliance results in more efficient and transparent business processes, but respondents vary in their assessment of if the benefits outweigh the costs.

I recently spoke with a CIO whose experience is, sadly, not unique. His team is in a relatively small enterprise that rolls up through two larger firms to a major public company. The team members thought they were done with SOX and in maintenance mode after putting financial controls in place. The work was a drag on productivity, but it was manageable. Then, a change in risk-based management strategies at a parent firm led to a re-examination of SOX compliance efforts. That, in turn, led to a broader interpretation of required controls. Developers in this shop now spend approximately 15% of their time on reporting projects, leading to missed development opportunities and morale drain. (Of course, SOX is sometimes used as an excuse to avoid new projects that have a low priority or a low probability of success even when there was no legitimate SOX connection. But in this case, the drain on resources makes it impossible to keep up with compliance and new development requests).

Best practices for SOX compliance requirements include adopting the COBIT IT governance framework from ISACA as a starting point for compliance, as it is widely accepted by the auditors and has evolved with ongoing use. For firms that have made an investment in the IT Infrastructure Library, it is straightforward to map from ITIL to COBIT using commercially available guides. (Disclaimer -- I participated as a volunteer external reviewer in the RISK IT project for ISACA -- a sister effort to COBIT -- and my experience with the organization’s development process has me sold on the quality of the product.)

There have been some clear benefits to IT in disaster recovery (DR) tools and technologies -- these projects now get management support as risk mitigation strategies. For many shops, concerns about SOX 302, 404 and 409 have directly led to DR investment.

Recommendations for meeting SOX compliance requirements

As usual, there is no end in sight to new regulatory mandates that affect IT. There is the Dodd-Frank Wall Street Reform and Consumer Protection Act (signed on July 21), which focuses on Wall Street reform, and European Union privacy and environmental rules that will find their way into U.S. IT shops either as a result of EU clients, or migration of these requirements into U.S. law. As a result, IT will require new controls to meet emerging requirements. The good news is that a successful SOX implementation should reduce the impact of most of these new regulations on IT.

The basic principles of a successful SOX strategy -- simplify, integrate, monitor, manage and disclose -- remain valid.

For each new regulation, start by factoring the individual requirements, map them to existing controls, and, wherever possible, use a commercial product to benefit from the following common items:

  • Data model/user view
  • Access/retention model
  • Risk management approach

Building on the data and access/retention models used in a SOX implementation, new financial and environmental reporting regulations will be simpler and less expensive than if they are viewed as standalone projects. Lessons learned from SOX don’t have to be relearned, they just need to be applied judiciously to these new regulations.

Adrian Bowles has more than 25 years of experience as an analyst, practitioner and academic in IT with a focus on IT strategy and management. He is the founder of SIG411 LLC, an advisory services firm in Westport, Conn., and director of the Sustainability Leadership Council.

Dig Deeper on SOX and other public company compliance requirements

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.