Introducing New IT Systems Into a Sarbanes-Oxley Compliant Environment

November 2006

When introducing a new system into a Sarbanes-Oxley compliant infrastructure, companies need to identify whether established controls will affect the new system's functionality, the best time to implement the system during the year, and whether controls need to be automated.

Alain Valiquette, CISA
IT Auditor
Inco Ltd.

Introducing a new system into an IT environment that is compliant with the U.S. Sarbanes-Oxley Act of 2002 must be a carefully planned process. To optimize this process, organizations should identify whether the new system conforms to established internal controls. Internal auditors can add value to the implementation project by helping organizations identify the impact of the new system on existing controls, the most appropriate time during the fiscal year to implement the new system, and the benefits of automating preventive controls. In addition, auditors can augment compliance activities by recommending practices that will help the company implement controls that reduce identified risks and seize new compliance opportunities.

CONFORMING TO ESTABLISHED INTERNAL CONTROLS

It is not uncommon for an organization to spend most of its development effort working around legacy controls to meet Sarbanes-Oxley requirements. Having survived Sarbanes-Oxley for a number of years, management has learned that having controls A, B, and C helps to ensure compliance. Their logic is that if they keep these controls, the company will meet compliance in the future. It also is possible that management is comfortable with the existing controls and is resistant to change. As a result, management might ask for new systems to incorporate the old system's internal controls.

Although incorporating the old system's controls might ensure compliance with Sarbanes-Oxley, this may not be an effective use of the organization's resources and time. For example, to make sure a proper segregation of duties exists, a company may produce an employee printout every quarter and manually check the financial application's access list to look for conflicting duties — a process that is extremely time consuming. The same company may later decide to purchase a new financial system that features an assessment module that automatically detects proper segregation of duties. Although the new financial system has a rich set of tools to ensure that incompatible duties are identified quickly, the company continues to check the list manually.

To prevent controls from driving business needs, internal auditors should recommend that companies evaluate the impact of the new system on compliance activities using a risk management approach. Risk management refers to the identification of vulnerabilities that may affect or are affecting a company. Identifying vulnerabilities enables the company to reduce risks appropriately to an acceptable level. Because of their expertise, auditors might be asked to conduct the risk assessment.

When identifying risks, auditors should focus on the following primary risk management steps:

Identifying events, including any positive and negative incidences that affect the achievement of objectives.
Assessing risks, such as evaluating the incidences based on their impact and likelihood of achieving desired objectives.
Selecting a risk response that is based on the optimal approach for reducing risks to an acceptable level.

In the previous example, a risk assessment may have identified a missed opportunity to provide a greater level of assurance by converting a manual control to a more reliable automated system control. For more information on risk assessment, auditors should refer to chapter 3 of the Committee of Sponsoring Organizations of the Treadway Commission's Internal Control–Integrated Framework, which discusses the risk assessment process.

THE RIGHT TIME TO IMPLEMENT THE SYSTEM

Sometimes a company may have to implement a system later in the year. Although implementing the system before the end of the fiscal year may be necessary to satisfy a business need or meet a new business goal, doing so may not give the company enough time to test the system for Sarbanes-Oxley compliance. This is especially true in companies where compliance tests are conducted during the last quarter of the fiscal year. For instance, when a control fails, corrective action must be in place and operating effectively for a minimum period of time before it can be retested.

The necessary length of time a control must be operating depends on the frequency of the control's operation. The more often a control is used, the shorter the amount of time management has to gather the necessary evidence to determine whether the control is operating effectively. For example, a control with an operational quarterly frequency cannot be implemented in the month of October because it must be operating for at least two quarters before it can be retested. In this case, the cutoff point for implementing the control is quarter three. For more information on suggested time periods for control testing, refer to Table 1.

Frequency of Control	Suggested Time Period of Operation Prior to The Reporting Date
Multiple times a day	25 times over a multiple day period
Daily	20 days
Weekly	5 weeks
Monthly	2 months
Quarterly	2 quarters

Table 1. Suggested time period for testing operational controls, taken from PricewaterhouseCoopers' Sarbanes-Oxley Act: Section 404 Practical Guidance for Management.

Because implementing corrective actions before the deadline can lead to noncompliance, auditors should recommend that organizations identify and assess the impact of proposed changes to existing Sarbanes-Oxley controls as early as possible during the project's lifecycle. This will enable the new system to be implemented with ample time for retesting. In addition, auditors can recommend that the new system's activation date be delayed until the beginning of the following fiscal year. This will give the organization a full year to meet compliance requirements. Finally, auditors can advise the organization to shorten the control's frequency to meet the operational testing timeline constraints outlined in Table 1 above.

AUTOMATING INTERNAL CONTROLS

One of the goals of the project team implementing a new system is to deliver a product that is on time, on budget, and that meets user expectations. Although building effective internal controls is usually not a high priority on the team's list, it is a big part of Sarbanes-Oxley compliance work.

To help organizations build effective controls, internal auditors need to counsel management early during the project's implementation, possibly during the planning phase. Implementing effective controls after the project is in place could result in more work, which is expensive in terms of money, people, and time. Therefore, the auditor should work with the system implementation team to identify existing manual controls and locate features or optional modules available within the new system that could replace the manual controls with automated system-based preventive controls.

Examples of automated system-based controls include:

Third-party security controls that enhance the security of an organization by enforcing compliance with security policies and regulations or by automating patch management activities.
Segregation of duty controls, which automate the task of analyzing the relationships among various job functions.
Baseline configuration controls, which automate the task of analyzing current system settings against a baseline template, such as identifying changes to a system or deviations from a policy.
Source code library management controls, which manage changes to application data, perform auditing and versioning, and control the promotion of the application from development to production.

Using automated, system-based controls has several advantages. System-based controls are more reliable than manual controls, as well as less expensive and less difficult to audit. In addition, manual controls are subject to greater scrutiny than an automated control, thus increasing the amount of time and money needed to assess whether the manual control is working properly. For more information on system-based controls, refer to section 3 of Deloitte's 2005 Lean and Balanced — How to Cut Costs Without Compromising Compliance report. According to Deloitte, automated controls are less prone to error, manipulation, or other potential performance problems that are associated with people-based controls.

General Controls Versus Application Controls
Furthermore, it is important for auditors to understand the interdependence between general controls and application controls, because it is likely that the introduction of a new system may cause general control deficiencies that adversely affect the effective operation of application controls. Although application controls may continue to function if general controls are inadequate, the risk that they are circumvented is increased, which is unacceptable from a Sarbanes-Oxley compliance perspective. For example, an enterprise resource planning system has a three-way match process that acts as an application control. The three-way match process will continue to function effectively as long as its settings are not changed. If the general controls that oversee all program changes are weak and allow changes to the three-way match settings to go undetected, the application will not be as efficient and effective because it is not operating as originally intended by the vendor.

The relationship between general controls and application controls is such that general controls are needed to support the functioning of application controls, and both are needed to ensure complete and accurate information processing. This point is illustrated in the PricewaterhouseCoopers's Sarbanes-Oxley Act: Section 404 Practical Guidance for Management July 2004 report. For instance, for an automated application control, the number of items that should be tested is generally minimal (i.e., one to a few items), assuming that the IT general controls have been tested and found to be effective. If IT general controls are not designed properly or are found to be ineffective when tested, application controls become unreliable and a greater number of samples will be required to test the controls. This increase in sample size costs money and takes time.

Consequently, it is important for internal auditors to understand how the organization's IT general controls operate and which IT general controls affect the use of application controls. In addition, auditors should establish a working relationship with financial auditors to evaluate the impact of the new system on existing controls and reexamine how control changes impact specific IT general control components, such as the system's development, processes, and controls, as well as its change, security, and computer operations.

MOVING FORWARD

The involvement of internal auditors is key before, during, and after the implementation phase of new systems. Internal auditors can help organizations determine whether existing controls are driving business needs, Sarbanes-Oxley compliance is impeding the progress of a company, and the maturity of the internal control portfolio is increasing. To maximize the effectiveness of the implementation process, auditors should participate in the design and development stages of projects and provide advice on appropriate internal controls. In addition, auditors need to understand the relationship between IT general controls and application controls to determine the best way to test controls. This results in the introduction of new systems in an environment that seizes and capitalizes on existing opportunities and helps to achieve compliance with Sarbanes-Oxley and other U.S. and international regulations more effectively.

Alain Valiquette is an IT auditor with Inco Ltd., a nickel mining company, and currently manages the company's IT portion of its Sarbanes-Oxley compliance work. Valiquette has been in the IT business for more than 20 years and specializes in Internet technologies and database development.

Introducing New IT Systems Into a Sarbanes-Oxley Compliant Environment
This article has been pretty usefull for our day to day duties, however I'd like to know whether you´ve got a more updated version of this information due that this one corresponds to 2006. As per my understanding, the table 1 refers better when you are in a remediation process rather than testing your controls. If you consider that frequency of the control you might also take into consideration the risk associated due that it'd not be the same a a low risk control with a high risk level control
Posted By: daniel gutierrez
2011-11-24 1:08 PM

COMMENT ON THIS ARTICLE

Internal Auditor is pleased to provide you an opportunity to share your thoughts about the articles posted on this site. Some comments may be reprinted elsewhere, online, or offline. We encourage lively, open discussion and only ask that you refrain from personal comments and remarks that are off topic. Internal Auditor reserves the right to edit/remove comments.

To make something bold:
<strong>Text to bold</strong>

To make something italic:
<em>Text to italicize</em>

To make a hyperlink:
<a href="URL">Text to link</a>