how to make incremental steps in SOX

Incremental improvements, a.k.a. baby steps to compliance

If you pay close attention during SOX walkthroughs with auditors, you can get a good idea of the areas on which your company's change management process should focus. Fortunately, many SOX goals are best practice audit/control items anyway, since SOX is just providing organizations the impetus to put process improvements in place.

So how can organizations respond to SOX action items while making efficient use of scarce development, operations, and change management resources? Here are a few examples of how incremental improvements can help smooth the process by which your organization answers SOX requirements.

First, does your current system provide end-to-end traceability through your change control system? The philosophy and implementation of change management varies greatly between organizations. Some companies focus on managing change beginning with the inception of an idea through its implementation. They track the change through its eventual removal from production when the change becomes outdated. Other organizations will jump into and out of the change process at convenient points, typically at control transfer junctions.

Looking under the hood

Regardless of how your company has managed change traditionally, everyone involved in chain management system should constantly examine the process stream to find ways to increase the level of service provided to the company. The person or groups responsible for change management will be held responsible for the process chain sooner than later anyway, so why not get a jump on the work?

To get your evaluation of the change process started, let me ask you a simple question: How does work originate in your organization?

For this discussion, let's assume your internal information systems customers create requests for enhancements through a work request system, and your company’s help desk creates service tickets for the application problems. If the application problem can’t be solved, an additional work request may be created to address the problem in addition.

Of course, requests come in for new application development as well and, depending upon scope, the project management office ramps up its project portfolio system to help manage the undertaking

At this moment, you may be asking yourself, what does this have to do with change management as it relates to Sarbanes-Oxley? The answer is traceability. In this example, you may have four different systems tracking work on the same project: A work request system, a service ticket system, a bug tracking system and a portfolio management system.

Auditing continuity in the change process

So, with that many groups working together on a project, is the change management system prepared to contribute to the continuity of the changes your organization makes? Put another way, if you were an auditor looking at changes promoted into your production systems, how could you quickly determine that the changes were made according to the processes that control change throughout your organization?

As a starting point to answering those questions, determine whether the change requests contain work request, service ticket, bug tracking or portfolio identification numbers. If not, you as the auditor would have to do a lot of manual matching in order to line up change requests with work tracking, incident reports, and the like.

Next, do the company's change requests facilitate easy access to related project collateral? For example, how difficult is it to locate the documents associated with a change? Documents like the requirements package, test scripts, user acceptance testing signoffs, and other paperwork generated by the work requests?

Can users easily attach the documents to the change request or provide a link to the location of the documents? Will the links remain constant over the auditable life of the change request?

Finally, does my change management system make it easy to troubleshoot production problems? The most frequent question asked when system engineers respond to problems is: What has changed? Ideally it should be easy for engineers to search change requests by server, application, or affinity group. Once changes are located, engineers need to be able to drill down to the configuration items associated with a change, or even examine source code. At each step in the research, engineers should easily be able to identify the people involved in a change, so they can contact them if needed.

The payoff: Speedy access to information

The answers you give to the questions raised above can help decrease the amount of time required to access information. The primary reason access time matters is lower access time translates to reduces costs. Perhaps more importantly, quick access to information reduces risk.

Good auditors care about issues that contribute to control and stability, especially in the financial systems on which SOX focuses. A good change management system contributes to production integrity by controlling the production promotion processes, and contributes to SOX compliance by streamlining access to information about the change process.