Continue in 2 seconds

Sarbanes-Oxley is an IT Responsibility and Business Opportunity

  • December 01 2004, 1:00am EST
More in
How did this newly minted legislation work its way from the confines of the boardroom into the trenches of the data center?

Several months ago, you thought that Sarbanes-Oxley was something that CEOs and CFOs had to worry about to keep themselves from cooking the books and going to jail. Think again.

Today, you flunked your first audit associated with Sarbanes-Oxley. To add insult to injury, you now have a few months to rectify your deficiencies. With limited resources, you can't afford to spend additional cycles on compliance at the expense of day-to-day operations.

You're not alone. Many IT professionals are learning the hard way that Sarbanes-Oxley has as much to do with IT as it does with determining the quarterly profit margin. How did this newly minted legislation work its way from the confines of the boardroom into the trenches of the data center? Over the past year as companies scrambled to meet compliance deadlines, Sarbanes-Oxley has been an evolving and interpretive piece of legislation.

As companies prepare for compliance, procedures and policies associated with corporate reporting have been diligently defined and documented. As part of this process, an internal audit is conducted - either by an inside or outside entity - in order to assess compliance readiness and withstand future scrutiny from the federal government. At the start of the audit, core business processes that are fundamental to the financials of the company processes are identified. For example, business processes can include general ledger, accounts receivable and quote to cash reporting, among others. After all of the processes are identified, the audit team then delves deeper into the integrity of each of these processes.

Eventually, as layers of the onion are peeled away, a critical question gets asked: What about the IT infrastructure supporting each of these processes? Auditors have limited or no knowledge about the internal workings of the IT organization. At the same time, the IT organization isn't well-versed on the finer points of federal compliance minutia and what it means to become compliant. At the start of this IT-auditor relationship, it's usually the blind leading the blind.

Fortunately, there's a lot that IT professionals can do to educate themselves about compliance and adopt practical and preemptive IT compliance strategies - all before the auditor comes knocking on the door. IT organizations can also use the requirements associated with this legislation as a springboard to improve some major IT headaches that can streamline operations, reliability and security.

Compliance 101

It's ironic that while Sarbanes-Oxley has become so vital to the IT organization, the actual legislation doesn't explicitly say anything about IT. The only portion that is relevant to IT is section 404 that discusses "internal controls." In a vague nutshell, companies are required to:

  • Define "internal controls" over financial reporting.
  • Test and assess these controls internally.
  • Support external audits of controls.
  • Document compliance efforts.
  • Report any "material weaknesses."

As a result, auditors and IT professionals have no standard or baseline from which to guide or define their compliance activities. From this ambiguity, some standards and clarity are beginning to emerge: COSO and COBIT. COSO stands for the Committee of Sponsoring Organizations of the Treadway Commission, established in the 1980s as a consortium of professional financial and accounting associations to address fraudulent reporting. The COSO committee has created a framework of the same name that offers guidelines for risk assessment, control activities, communications and monitoring of business processes. Many companies are looking to COSO as a compliance framework to define and manage internal controls.
Unfortunately, COSO doesn't specify any controls for IT. Enter COBIT. COBIT has emerged as a standard from the COSO practice and helps translate COSO into actions that are applicable to the IT organization. Generally, COBIT encompasses the following four areas:

  • Plan and organize. Define strategic IT plans and architecture, assess risks, manage projects, manage human resources, ensure compliance with external requirements.
  • Acquire and implement. Identify automated solutions, acquire and maintain technology infrastructure and application software, manage changes.
  • Deliver and support. Define and manage service levels, manage performance and capacity, ensure systems security, manage problems and incidents.
  • Monitor and evaluate. Monitor processes, assess internal control adequacy, provide for independent audit.

There are other standards and frameworks, such as ITIL and Six Sigma, that companies can leverage when defining compliance controls. There's no mandate that requires adoption of one standard over another, and companies can also opt to create their own control framework. However, auditors are increasingly viewing the COBIT framework as a useful template when assessing an IT department's internal controls.

Define and Establish Change Controls

You don't initially have to adopt an exhaustive COBIT framework as an approach to Sarbanes-Oxley compliance. You can define similar, yet general IT controls that address the areas you identify as key to the financial infrastructure. They should encompass:

  • Financial transaction flow.
  • Potential for fraud or data corruption.
  • IT infrastructure control over financial systems.

When dissecting these controls associated with the financial infrastructure, companies typically gravitate toward the obvious suspects such as change management, role definition, and backup and recovery as core IT components that require improvement during the compliance process. However, change management is undoubtedly the area that gives auditors the greatest angst. This shouldn't come as a surprise to an IT organization. Poor or weak change management practices have a direct correlation on the security and integrity of data supporting critical financial processes. Gartner, Inc. reported that approximately 40 percent of downtime is caused by operational errors, another 40 percent is caused by application errors (most often misconfigurations) and the remaining 20 percent is caused by actual platform problems, including the network, operating system or hardware (source: Tearing Down the Wall, Theresa Lanowitz, Gartner, 2002).
Whether you're using COBIT or creating your own approach to compliance, you'll need to identify specific change management control points for the IT infrastructure and financial systems. To do so, you should solicit input from a number of sources:

  • Talk to your compliance team and auditors about their high-level concerns: potentials for fraud and which kinds of information they are concerned about. Compliance or financial professionals are detached from IT operations and are probably unable to speak with authority about precise IT control points. As a result, you can help translate their concerns into specific change control points within the IT infrastructure.
  • Talk to application/IT experts about reasonable change control points related to the concerns you've identified. These might include essential security processes, configuration files for critical applications or files supporting authentication.
  • Review your IT best practices to define policies and assess ways to monitor and enforce them.

Change control points may be files, processes or individual actions. Many will be common to all kinds of companies, and some change audit controls will be specific to your environment.
Your list of control points will undoubtedly change over time as regulations or audit guidelines evolve, industry best practices adapt to new technologies or threats, auditors gain new insight into IT and the IT infrastructure itself changes.

It's probably more important to get started with an initial set of change control points than to spend a long time creating a comprehensive, "final" list of controls. In addition, defining the high priority change control points before the auditor arrives can help facilitate the first compliance discussion and satisfy initial compliance requirements.

Who Changed What?

There's one silver lining that results from a Sarbanes-Oxley compliance initiative. Companies are forced to tackle the sticky issue of change management. It doesn't matter if you're a large company with a sophisticated Remedy or Peregrine change management system or one that's executing change activities from spreadsheets and e-mail. "Change" is inevitably the first area the auditors will dig into. For years, most companies recognized that their change management process and controls required greater attention. However, the change management problem was put on the back burner for lack of time and budget, and conflicting priorities from senior management. With compliance, companies are now receiving the additional budget and executive attention to finally confront lurking change management issues.

Typically, the validation or execution phase of the change management process requires the most improvement. During this phase when the actual work is done, it's difficult to correlate actual changes with an approved change request. Inversely, observed or detected changes sometimes cannot be correlated with an approved change request. The latter is very common, often perpetrated by well-intentioned individuals who notice something that requires attention and then decide to make the change, forgoing the change management approval process. Auditors are also taking aim at the processes for making emergency changes because these usually forgo the standard approval process.

To tackle these common change management issues during the validation phase, companies are incorporating four graduated levels of monitoring:

  • Phase I -- Activity Reporting. Track all user and application activity across the infrastructure, such as all changes across all servers. This method is the easiest to enact and can help meet initial compliance requirements.
  • Phase II -- Compliance Reporting. Track all user and application activity specific to the specific control points. For example, if you've identified a critical security file as a control point that should not change, then you should monitor only this component and report violations.
  • Phase III -- Active Enforcement. The next progressive step within compliance is to define objectives or policies associated with control points and actively enforce them. For example, you might decide that only application specialists can change the application configuration files or that account changes require a specific individual's approval.

Closed-Loop Change Management

Companies are also extending their service or change management systems via closed-loop change management. Today's current service and change management systems are outstanding solutions for the front end of the change management process to request, budget, approve and assign changes. However, once a change is assigned, there's little visibility into or control over the actual change execution. For example, a change request is created and assigned to Bob to patch the operating system on an Exchange server between 6 p.m. and 8 p.m. on a Friday. However, how do you know that the work was actually completed? Did Bob or someone else conduct the work? Did Bob follow the change request's instructions and complete the change between 6 p.m. and 8 p.m.? Did he follow established policies when making the change?

Closed-loop change management is a strategy for extending current tools and processes to cover the complete change management life cycle, from request through execution to review and completion. Closed-loop change management tracks actual changes for comparison to approved changes. Policies for how and when changes can be made are established, based on skill sets, application, time, required approvals and standard operations procedures. The goal is to more accurately verify approved changes, detect or prevent unapproved changes and, over time, standardize how changes are performed.

The Auditors Will Be Back

After companies certify that they've achieved compliance, they'll need to demonstrate ongoing adherence and commitment. Over time, auditors are also going to learn more about the interrelationship between the technology infrastructure and financial reporting systems. As a result, compliance will become a standard issue for the IT organization and should be built into day-to-day operations.

By leveraging emerging standards such as COBIT, IT organizations can begin the process of defining a compliance framework that is being utilized more and more by compliance auditors. Initial compliance efforts shouldn't be exhaustive at the expense of day-to-day operations. By taking a practical approach and implementing gradual levels of monitoring based upon defined control points, companies can meet their immediate compliance requirements.

Most importantly, companies should take advantage of the compliance process because IT operations may be the unknowing benefactor. Many companies have always wanted to fix their change management vulnerabilities, but didn't have the mindshare, sense of urgency or budget to tackle the problem. Sarbanes-Oxley may be the best event-driven opportunity to get the job done.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access