A Cost-effective Approach for Sarbanes-Oxley-regulated Application Systems With Minimal IT Control Assurance 

Download Article Article in Digital Form

A fine-tuning scoping methodology will help provide senior management with greater latitude in deciding whether an application system is deemed in scope for the purpose of an IT control assessment, as mandated by the US Sarbanes-Oxley Act and equivalent regulations/legislation. The proposed approach will assist in reducing reliance on IT automated controls (ITAC) when it makes business sense to do so. This article assumes that baseline data exist regarding the application system and controls deemed in scope.

Many complexities are involved when managing large internal controls programs such as those mandated by legal requirements. Many suggested approaches have been provided to perform comprehensive IT risk assessments so that the scope of the program is focused on areas with the highest risk of financial data integrity. Frequently, compliance assessment teams struggle with the IT-related components of internal control assessments and call their IT auditor/control specialists to evaluate a balanced approach. A typical scoping process within an organization’s program is:

  1. Senior management defines the scope in terms of materiality, identifies the scope of accounts from the balance sheet and profit and loss (P&L) statement, and then identifies the scope of business locations and business processes that impact these accounts. This step generally does not involve IT auditors/specialists.
  2. For a given business process and location, a controls assessment team maps business processes, identifies control activities and then highlights key controls over financial reporting. Control activities are considered either manual or ITAC. Whenever a key control is an application control (such as an automated report or an automated workflow
  3. in commercial off-the-shelf software), the supporting application system and underlying IT infrastructure are required to be in scope.
  4. The IT auditor/control specialist performs an IT risk assessment to identify the extent of IT work for both the specific application system control and the underlying IT general controls (ITGC), prior to evaluating the control design and operating effectiveness to ascertain control assurance.
  5. The IT auditor/control specialist performs the IT assessment (design assessment and operating effectiveness testing) and reports the findings to the senior management team and to the controls assessment team for remediation and evaluation of the control deficiencies in isolation and aggregation.

Here are the issues caused by such a mechanical approach to scoping:

  • Cost—The number of application systems in scope can be extensive because of the scoping approach, with some application systems supporting only a few key controls over financial reporting. As a result, excessive resources are consumed to assess the IT controls for a wide spectrum of IT assets.
  • Compliance—The approach does not take into consideration that application systems with only a few application controls may be considered legacy application systems. Such legacy systems are prone to control deficiencies, and there could be little management support to invest in remediation efforts for those if deficiencies were identified. Senior management may be focused on retiring these legacy systems and implementing a brand-new, enterprisewide application instead. As a result, legacy systems deemed in scope are more likely to be the source of deficiencies.

Who wants to spend time testing controls and reporting deficiencies that will remain in the deficiency listing for a long time? Unfortunately, the usual methodologies, i.e., what was described previously, do not necessarily address such a problem. Also, in accordance with the Pareto principle,1 it could be that 20 percent of the application systems in scope are causing 80 percent of the problems. Therefore, it would be beneficial to come up with a method for identifying easy opportunities for improvement and to build the business case for a compliant and cost-effective control design.

Targeting the source of the “Noise”

Here are the proposed steps to identify the target applications for further analysis:

  1. Obtain a current list of application systems deemed in scope and the key application system controls that were identified. Whenever possible, break down application system controls into the following types:
    • Automated control
    • IT-dependent control
    • Application-system-specific access/segregation of duties (SoD) control
  2. Evaluate the effectiveness of ITGC for each application system. This can be performed either by reviewing the results of past testing or by performing an abbreviated assessment focused on key areas.
  3. Qualify the pervasiveness of the application system relative to the financial statements, i.e., how critical the application system is to the integrity of financial statements as a whole. For instance, an enterprise resource planning (ERP) system would be qualified as “high relative pervasiveness,” while an application system supporting only one particular business process for one business location would be qualified as “low relative pervasiveness.”
  4. Present the data in a table such as the example in figure 1. The analysis will then focus on target applications with the following attributes:
    • Low number of application controls, particularly those with few automated controls
    • Low pervasiveness to the financial statements
    • Overall effectiveness of ITGC. It is key to note that controls failure in key areas (e.g., change control, SoD) can impact the overall effectiveness and prevent the team from testing related ITAC using the “test of one” assumption.2

Figure 1

In figure 1, the target applications are App1 and App2 because they meet the criteria. App3 was not selected based on its “medium” pervasiveness to financial reporting. As further explanation, a number of application controls is deemed “low” based on a comparison to the number of ITGC for the environment. As an example, if there are, on average, 20 ITGC, “low” would probably mean anything between one and 10 application controls.

Following is a look at the target applications identified from the cost and compliance angles:

  • Cost—For applications systems in which ITGC are deemed ineffective, resources will be required to remediate the deficiencies. Also, the testing of the application system controls for those will not meet the requirements for the “test of one” sample, and, therefore, the application system controls will need to be tested like manual controls— increasing dramatically the time needed to assess operating effectiveness.
  • Compliance—For App1 and App2 in figure 1, the application systems are not pervasive to financial reporting; therefore, it is unlikely that the impact of ITGC would be considered significant. However, management will be under pressure to remediate these because, if not acted upon within a reasonable time frame, their ranking could be escalated.

With respect to the target applications with weak IT assurance, management does not seem to have many options available:

  • Option 1—Postpone the pain, i.e., do not immediately remediate the ITGC deficiencies and then bear the increased cost of performing the testing of automated controls, which may not be prohibitive considering the number of controls. In this scenario, management hopes to postpone funding for remediation.
  • Option 2—Allocate resources to solve the deficiencies, and aim for effective ITGC. However, management should be made aware that remediation initiatives related to ITGC are complex and that success is not always guaranteed because of the number of “moving parts” involved—for instance, additional staff may be required to satisfy SoD, third-party software may need to be acquired to support monitoring activities, or enhancements may need to be carried out to produce satisfying audit logs.

“Option 3”—Control Reevaluation Consideration

An alternative option should be contemplated, whereby the application system controls are substituted to a strong manual control. This alternative strategy is the core of this article and relies on the team’s ability to think from the perspective of the business and articulate the decisions in terms of costs/benefits. The selling point is that in instances such as described previously, i.e., weak IT controls with limited use of automated controls, it is often cheaper and more effective to implement key manual controls rather than rely on automation. This will sound counterintuitive to many readers, and of course, this method is not recommended in areas in which IT systems are relied on pervasively. Here are the proposed steps to reach a decision regarding the control design and the trade-offs between automation and manual operation:

  1. For a given target application, review existing high-level documentation of the environment that relies on the application system. This includes reviewing the financials, processes, list of control activities and systems involved. Identify the names of key business stakeholders (such as general manager, controller, process owners and IT manager).
  2. Determine the materiality threshold for the environment supported by the target application. As a rule of thumb, use a prorated calculation of the overall materiality threshold. For example, if the overall materiality is US $10 million for a significant deficiency and the environment that the target application supports represents 10 percent of the business, the threshold to consider would be a US $1 million annual misstatement.
  3. Schedule a workshop with representation from both the business and the controls assessment team. The business representatives should have sufficient authority to make decisions in line with their accountabilities. The control assessment team should represent skills for the entire controls area—both business process and IT controls. An important point is to articulate in advance the goal of the workshop in order to maximize attendance and chances of success. At the end of the day, a decision is needed regarding the design of key controls so that costs and compliance profiles will be improved.
  4. Start the workshop by restating the objective, describing the problem in terms of costs and compliance, and outlining the three options available along with the costs and benefits of each.
  5. Walk through the process whereby the target application is involved (one application at a time) for the key controls. Then, hypothetically assume that, for whatever reason, the application system cannot be relied on, i.e., that the data lack integrity—regardless of the cause (processing error, unauthorized access to database, etc.). In most cases, it may turn out that, for the hypothetical failure of the target application to result in a significant deficiency, it would require a combination of operational breakdowns that would go unnoticed for a prolonged period of time.

The discussion may reveal new mitigating controls that were not identified before. Also, the participants may realize that it could be quite easy for the business to implement a reasonableness check that would validate, on a regular basis, that the target application output is within range of acceptable value, i.e., within the agreed-on materiality threshold. Whatever existed as an informal control could then be turned into a strong key control—with the corresponding audit ability requirements. The business may initially be reluctant to accept the extra burden of operating a new manual key control, but will certainly recognize that the proposed “third option” is cheaper and/or more compliant than options 1 and 2 (noted previously).


A cost- and risk-effective approach is derived from a holistic view of the objective and from evaluating options for conformance based on the business control environment and culture. If workshops were completed successfully for App1 and App2 of figure 1 and the business agreed to implement a total of three new manual key controls to replace the three application controls, ITGC testing would no longer be required, saving approximately the cost of testing 40 controls. Remediation would be still encouraged, but with decreased pressure from the controls assessment team. (Note: from a strict financial reporting standpoint only—there may be other rationale to drive remediation efforts.) Implementing the new manual controls is likely to cost less than remediation of ITGC deficiencies. As a result, senior management can now allocate resources to where they are the most needed in the organization—to the benefit of the organization’s stakeholders.


1 The Pareto Principle (also known as the 80/20 rule) states that for many events, roughly 80 percent of the effects come from 20 percent of the causes. The principle is named after Italian economist Vilfredo Pareto, who observed in 1906 that 80 percent of land in Italy was owned by 20 percent of the population. Koch, Richard; The 80/20 Principle:  The Secret of Achieving More With Less, Random House, USA, 1998
2 Rajamani, Baskaran; “Certifying Automated Information Technology Controls: Common Challenges and Suggested Solutions,” Deloitte, www.deloitte.com/view/en_CA/ca/services/ceocfocertification/article/c1fcfa9d452fb110VgnVCM100000ba42f00aRCRD.htm

is an independent technology risk consultant with a track record of removing unnecessary complexity from highly regulated organizations and delivering cost reductions while ensuring that operational and technological risks are managed at an acceptable level. In his past role with MDS Inc., a global life sciences corporation, Jegousse was able to reduce significantly the ongoing costs of regulatory compliance and improve the organization’s posture toward internal and external audits.

Enjoying this article? To read the most current ISACA® Journal articles, become a member or subscribe to the Journal.

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

© 2011 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.