Why IT change management is more important than ever

Recent proposed guidance from the Public Company Accounting Oversight Board (PCAOB) will place a greater emphasis on change management within information systems. There are numerous studies, including our own, that show IT change management as a problem area. It is worth making the investment to fix your change management process because it will enable cost savings with your Sarbanes-Oxley compliance program.

PCAOB Release number 2006-007, a proposed replacement for Audit Standard number 2, was released in December and the final version is expected soon. Appendix B of this Release spells out a new process called “benchmarking.” The term benchmarking is not new to the audit profession, but it is only now being applied to internal controls work. The concept is simple. Benchmarking allows you to establish a baseline performance metric for your automated controls and then, in future years, your auditors do not necessarily need to retest the effectiveness of that automated control.

Instead of testing controls every year, they can test them perhaps every few years. This has obvious cost savings for your audit program.

Paragraph B31 states: “If general controls over program changes, access to programs, and computer operations are effective and continue to be tested, and if the auditor verifies that the automated application control has not changed since the auditor established a baseline, the auditor may conclude that the automated application control continues to be effective without repeating the prior year's specific tests of the operation of the automated application control.”

If you can show that the software surrounding that automated control has not changed, then you may be able to convince your auditors to skip the current year and reschedule testing for future years. Alternatively, you may be able to convince them to reduce their testing scope for most years. Benchmarking criteria

There are certain criteria that must be met in order to use a benchmarking strategy. The new proposed audit standard number 5 (PCAOB Release number 2006-007) describes these as risk factors. The criteria are:

• Is the automated control encapsulated in a concise area, or does it involve numerous systems and pieces of software? Obviously, if we can identify a specific object/area which handles the automated control, then it is easier to demonstrate to the auditors that the control has not changed.

• What is the overall frequency of changes in that system? Systems which are more stable are less risky and are better suited to a benchmarking strategy.

• Change control. The third criteria spelled out in the proposed standard is the reliability of your IT change-management system. The better control you have, the easier it is to convince an auditor that changes are managed in a thorough and appropriate way. More control, less risk.

Real life, real time

In addition to all the other reasons for having an excellent change-control system, you now have one more. Let's explain how this technique might work in real life.

The first step, whether done internally or by your external auditors, is to gather data about the IT general controls that affect the targeted automated control. Answer the following:

• Which system is it in?

• Which exact piece of software executes the automated control?

• Has the business owner for that application clearly accepted responsibility for the control?

• What is our rate of change for that software?

• Is a control built in and provided by a vendor or developed in house?

Once you have this data, you should assign a risk score for the automated control. This is nothing new; use the same techniques you used for assessing risk and on other areas of your controls work. You should now have an entry in your risk matrix that lists this automated control, and its risk score relative to these factors.

Modify your documentation for the automated control to list exactly which components within your IT environment provide the automated logic. The program name, the folder it resides in, business owner, batch job names that run off the software, etcetera, all should be listed in your documentation.

Test plan

Next, develop a new test plan for that automated control. You will likely keep your previous test plan around, the one that extensively tested the effectiveness of the control. But now we will create a new test plan that has a reduced level of scope. A first step in this new test plan will determine if the software/systems involved have changed. A test step should tell the tester to go to your version control library or another change logging system to determine if the objects have been modified since the previous test.

Note: As you select sample data for validating change control, choose test data that includes the software/systems used for automated controls. Conduct two tests at once.

If the objects with the automated feature have not changed, then you are done. The control passed and no further testing is required. Short and simple! Once you have determined that the automated control has not changed, there's nothing else to look for. It was tested before and worked fine, and now you know that the control has not changed; therefore the control is still effective.

If the software/systems housing the automated control have changed, then you cannot reap the benefit of the benchmarking technique. You must conduct more extensive tests to validate that the control is still working.

Saving on Sarbox

In my opinion, the benchmarking technique will save a substantial amount of money in your Sarbanes-Oxley compliance program. But you must have effective IT change management in order to utilize the program and achieve the benefits. This is one more reason to apply diligence in the design and use of your change-management process!