JOnline: How the New Standards and Regulations Affect an Auditor's Assessment of Compliance With Internal Controls 

Download Article

Many companies subject to the US Sarbanes-Oxley Act of 2002 are quickly realizing that IT plays a vital role in the financial reporting process. In fact, most of today's successful companies rely heavily on their IT systems to generate reliable financial reporting information.

For companies under its authority, Sarbanes-Oxley declares that management is legally responsible for establishing, evaluating and monitoring the effectiveness of internal control over the financial reporting process. As part of complying with Sarbanes-Oxley, auditors are assigned new responsibilities for assessing a client's internal controls related to the financial reporting process. For most companies, the IT function is crucial to achieving this objective. Auditors are finding it necessary to revise the procedures used to assess and evaluate their clients' internal control structures.

A judgmental approach to assessing the effect IT has on the auditor's study and evaluation of internal controls and the nature and extent of substantive testing may no longer be adequate. Such an approach allows auditors too much leeway to decide whether to perform tests of controls or bypass such tests and only perform substantive tests. SAS 941 provides auditors with much-needed guidance regarding the effect of IT on internal controls. The standard requires tests of controls in certain situations, regardless of the level of control risk2 set by the auditor. The evaluation of internal controls is not complete until the auditor obtains a sufficient understanding of the controls' design and determines whether critical internal controls are present in the automated environment, in operation and working as intended. Public Company Accounting Oversight Board (PCAOB) Standard No. 23 upholds SAS 94 and discusses the IT control objectives to consider in assessing internal controls for US Securities and Exchange Commission registrants.

This article uses a flowchart approach (Figure 1) to illustrate how auditors can integrate the new regulations into their assessment and evaluation of a client's IT controls. The flowchart encompasses initial audit planning, a preliminary assessment of the internal control structure and testing of controls.

Figure 1

Phase One: Plan the Audit and Assess the Internal Control Structure4

The initial audit planning provides a basic understanding of the client's financial reporting process, the level of IT involvement in this process and a fundamental understanding of the internal controls. Sarbanes-Oxley recommends the Committee of Sponsoring Organizations (COSO) of the Treadway Commission's Internal Control—Integrated Framework as a control framework for public firms under its regulations. Therefore, the auditor can use the COSO framework to assist in assessing the client's internal controls. According to COSO, internal control consists of five interrelated components: control environment, risk assessment, control activities, information and communication, and monitoring. This article will refer primarily to the first three components: control environment, risk assessment and control activities.

When planning the audit, the auditor must first assess the scope of the audit, which is one of the most important activities of the entire process.5

Planning the Scope

A critical first step in assessing the scope is to identify the technology that is critical in the financial reporting process. This means that the auditor must identify the key information processing applications relevant in initiating, recording, processing and reporting financial information. Thus, not all IT controls are relevant. The auditor must identify only those IT controls that affect the financial reporting objective. A control framework should guide the auditor in this identification process. The COSO framework is a general control model that focuses on controls for financial processes and may assist the auditor in planning the financial audit process. However, as a firm's reliance on IT becomes more extensive, it is crucial to demonstrate how IT controls support the COSO framework. Control Objectives for Information and related Technology6 (COBIT) is a generally accepted standard for IT security and control practices that provides a reference framework for management, users, and IS audit, control and security practitioners. Therefore, COBIT should be integrated into the COSO framework to provide a quality internal control structure (ICS) and guidance to the auditor when assessing the ICS for a complex IT environment. Examples of how this is accomplished are provided throughout this paper.

Although the exact controls relevant for each client may differ, the IT Governance Institute (ITGI) recommends that the scope of the audit generally include the following:7

  • Controls over initiating, recording, processing and reporting significant accounts, and disclosures and related assertions embodied in the financial statements
  • Controls over the selection and application of accounting policies that are in conformity with generally accepted accounting principles
  • Antifraud programs and controls
  • Controls, including general IT controls, on which other controls are dependent
  • Controls over significant nonroutine and nonsystematic transactions, such as accounts involving judgments and estimates
  • Controls over the period-end financial reporting process, including controls over procedures used to enter transaction totals into the general ledger; to initiate, record and process journal entries in the general ledger; and to record recurring and nonrecurring adjustments to the financial statements (e.g., consolidating adjustments, report combinations and reclassifications) According to Sarbanes-Oxley, the scope of the review

should include applications that process large volumes of transactions, large monetary-value items, complex transactions and highly sensitive financial databases.8

Understand the IT Control Environment

Auditors must understand the various IT support systems, including networks, databases and operating systems, that support the financial reporting process. However, they must first gather information concerning the IT control environment, which is part of the overall control environment discussed in COSO. The company-level control environment is the foundation for a company's internal controls and includes the integrity and competence of the entity's people. To assess the control environment, auditors should examine management's philosophy and operating style, including how it assigns authority and responsibility and how it organizes and develops its people.

The overall company control environment has a pervasive effect on the reliability of financial reporting. An important step in understanding the IT control environment is to examine the IT organizational structure and the IT governance structure. The IT organizational structure outlines the authority and responsibility of IT personnel. This structure should support controls, such as adequate separation of duties, and provide assurance that the IT objectives will be achieved.

Effective IT governance helps ensure that IT supports the organization's goals, optimizes the organization's investment in IT and mitigates IT-related risks. The IT governance process includes the information systems' strategic plan, the IT risk management process, compliance and regulatory management, IT policies, collaboration, information sharing, operating style, and procedures and standards.9

Assessing the Complexity and Sophistication of the IT Systems

SAS 9410 requires the auditor to determine the sophistication of the IT environment that can materially affect the assertions for the financial reporting process. The auditor should obtain or prepare IT department background schedules including:

  • The location of the IT department
  • Name of the IT manager
  • Number of human resources by level and type
  • Duties and responsibilities of key personnel
  • Changes in key IT personnel
  • Identification of types of computers used
  • Computer network configuration diagrams
  • Identification of accounting software packages employed
  • A catalog of recently purchased IT systems

The IT background information documentation described can aid in determining the sophistication of the IT systems. A complex IT environment may render it impossible to set detection risk to an acceptable level and only rely on substantive tests. Complex systems or applications may require the auditor to obtain evidence about the design and operation of controls to reduce the level of assessed control risk.

Potential examples of sophisticated or complex IT systems include:

  • Orders for merchandise are automatically initiated, recorded and processed, based on predetermined rules.
  • Receipt of goods triggers payment for the related payables, and no paper documentation is maintained.
  • Services provided to users automatically initiate invoices, process the billing transactions and record the amounts received in the records.
  • Application programs containing algorithms or formulas that make complex calculations, such as automatically computing commissions, reorder points, loan reserves and pension funding calculations.
  • Firm personnel using relational database software write a bill of materials application. A bill of materials specifies the quantities of parts, materials and subassemblies used in specific products, and it is used to cost inventory parts and calculate inventory usage. Incorrect design of program logic can result in a number of inaccuracies or other serious problems that affect the financial reporting objective, such as inaccurate costing of inventory and the computation of incorrect material and labor variances.
  • Automated reasoning systems (ARSs) in the areas of auditing/internal control, tax or financial accounting employ complex heuristical “if/then” rules to make decisions (i.e., an ARS that automatically prepares journal entries to record exchanges of similar or dissimilar assets or one that automatically computes earnings per share calculations).
  • Enterprise resource planning (ERP) software integrates all of a firm's transaction processing systems, both accounting information and management information system applications. Such systems require users to activate or turn on edit routines or program checks in applications programs, and the possibility of override usually exists.
  • Intercompany systems significantly share information. Such intercompany systems often electronically link firms' web-based e-business applications, ERP applications and trading partners' networks.
  • Automated systems where audit evidence is only available in electronic form
  • Other complex, emerging IT

If the IT control environment, including the IT systems, is too complex for the firm to audit, management should be informed that the firm is withdrawing from the engagement. On the other hand, the firm may decide that the skills of an IT audit specialist are needed to assess the effect of IT on the audit, understand the IT controls, or design and perform tests of IT controls. The auditor should collaborate with the IT audit specialist, and one of the first steps should be to perform initial analytical procedures. These procedures examine relationships among various types of data and may reveal material inconsistencies. Reviewing procedures pertaining to IT budgets, IT operating data and evaluating material variances among key cost ratios in the IT department are examples of analytical tests.

One of the last steps in initial audit planning is to set an acceptable level of audit risk and form a preliminary assessment of inherent risk.11 The steps suggested will aid the auditor in understanding the level of IT used throughout the client’s firm, which is critical in this assessment. Finally, based on the results of the planning steps, the auditor can devise a preliminary audit program and begin the preliminary assessment of the ICS.

Based upon the preliminary audit program, the auditor begins the review, documentation and assessment of internal controls. Knowledge of the internal controls points to the types of material errors or misstatements that can occur in financial statement assertions (i.e., existence or occurrence, completeness, rights and obligations, valuation or allocation, and presentation and disclosure). The auditor employs a variety of fact-gathering techniques, such as review of records, policy manuals and documents; observation of activities; and interviews with key personnel. The extent of the assessment should be sufficient to provide an understanding of the strengths and weaknesses in the ICS. In an IT environment, a heavy reliance on COBIT is helpful during this assessment since IT affects control activities relevant to the planning of the audit.12

Figure 2

Risk Assessment

At this time, the auditor should conduct a risk assessment consisting of the following steps:13

  • Determine the significant IT control objectives that must be achieved by the IT unit. The COBIT framework should be employed to determine the appropriate IT control objectives for each particular company's circumstances. Figure 2 shows how COBIT can be employed in a risk assessment. The 34 COBIT control objectives that every organization's IT function must achieve within each of the COSO components are presented in the figure.14
  • Identify the exposure points to the significant automated IT financial reporting systems. These exposure points are holes or openings in the systems that are open to exploitation by hackers, employees, vendors, customers and other parties.
  • Ascertain the potential internal and external risks or threats at the exposure points, and make a list of the risks unique to the organization. For example, SAS 94 identifies "generic" risks that IT poses to a firm’s ICS. These risks are: reliance on systems or programs that are inaccurately processing data, processing inaccurate data, or both; unauthorized access to data that may result in destruction of data or improper changes to data, including the recording of unauthorized or nonexistent transactions or inaccurate recording of a transaction; unauthorized changes to data in master files; unauthorized changes to systems or programs; failure to make necessary changes to systems or programs; inappropriate manual intervention; and potential loss of data. These risks are by no means allinclusive.
  • A firm's IT resources are subject to other significant threats not identified in SAS 94. An auditor should be familiar with the four threat categories, presented in Figure 3, and the individual threats within each category relevant to all IT environments. Information about actual relevant threats to a firm's IT environment can be obtained from several sources, including prior period working papers; current developments affecting the firm's industry, operations and market; and recent threat surveys conducted by the Computer Security Institute, the Federal Bureau of Investigations (FBI) or the Big Four public accounting firms.
  • From the list of generic risks determined in the above step, identify the relevant or big risks, the annualized rate of occurrence (ARO) and the expected loss (EL) from one occurrence of the threat. The total annual loss from a particular threat is ARO x EL. Information about occurrence rates can also be obtained from the organizations mentioned in the above step.

Figure 3

Controls Activities

After identifying the relevant risks, the next step in the COSO framework is to identify control activities to mitigate these risks. Two major categories of control activities related to information processing are IT general/security controls and IT application controls. As the IT business processes become more aligned with other business processes within the company, IT general/security and application controls are becoming more integrated within these processes. IT general/security controls should provide an environment that supports the proper functioning of IT application controls and enhances the integrity of the resulting information. As manual controls are increasingly replaced with automated application controls, general controls become more important.

IT general/security controls concern all IT-level services and include controls over systems development, access to programs and data, program change, data center and networks, and computer operations. The effectiveness of IT general/security controls may be assessed by testing reports produced by IT, studying IT policy manuals, making inquiries, and observing and inspecting documents. The COBIT framework should be used to provide guidance on the specific IT controls that should be considered for compliance with COSO and, ultimately, Sarbanes-Oxley. Referring back to figure 2, under the Acquire and Implement domain of COBIT (equivalent to COSO's program development and program change general control objective), a high-level IT objective provides reasonable assurance that the technology infrastructure is acquired so that it provides the appropriate platforms to support financial reporting applications. A general control that should be implemented to attain this objective is to ensure that “documented procedures exist and are followed. This ensures that infrastructure systems, including network devices and software, are acquired based on the requirements of the financial applications they are intended to support.” 15

Application controls are embedded in information processing applications that integrate financial and operational business processes, such as enterprise resource planning (ERP) systems, which are becoming commonplace in large businesses. ERP application controls automate activities such as segregation of duties, authorization, recording, validity, completeness and reporting. They are also embedded in nonintegrated legacy processing applications, such as payroll programs, accounts receivable/payable programs, purchasing programs and inventory programs. These automated checks may be tested by using computer-assisted audit techniques, such as those discussed in the testing of controls section of this paper. The application control objectives referenced in COBIT for the most part can be enabled through the use of built-in application control functionality.16 This functionality is found in integrated ERP systems. For organizations that do not utilize integrated ERP software, this functionality may require a combination of manual and automated control procedures to satisfy the control objective.

The auditor is now ready to form a preliminary assessment concerning the adequacy of the control activities. If it appears that control activities provide a basis for reliance, the auditor should identify the specific controls required to mitigate frequently occurring risk exposures. Then, particular controls placed into the financial reporting applications must be identified. Next, the auditor must determine if the control activities implemented are the critical controls. Finally, the auditor must document each major control strength and weakness so control risk can be assessed. Knowledge of the control activities points to the types of material errors or misstatements that can occur in financial statement assertions.

The auditor's next step is to assess and set the level of control risk. The level of control risk can be expressed numerically (e.g., 100 percent, 70 percent or 25 percent) or subjectively (e.g., high, moderate or low). A high or maximum level of control risk is assessed when the control activities cannot be relied upon; the auditor may choose to assess and evaluate other procedures, such as the compensating controls previously discussed. A risk level below the maximum is assessed when the control activities appear to be sufficiently sound and adequate for providing reasonable assurance that the financial reporting objective can be achieved.

If the IT environment is not complex, a risk level below the maximum may be set when the control activities appear to be sufficiently sound and adequate to provide reasonable assurance that the financial reporting objectives can be achieved. When the level is within an acceptable range, the auditor should determine if it is cost-effective to conduct tests of controls (must be tested for public companies). That is, even though initial control risk is within an acceptable range, the auditor may choose not to test controls because of the costs involved. Other reasons to bypass testing of controls include:

  • Substantive tests are more economical to complete.
  • The prior year's control risk was set at a low level.

On the other hand, if the IT environment is complex, according to SAS 94, the auditor needs to be satisfied that conducting only substantive tests is effective in reducing detection risk to an acceptable level.17 For example, when considering the areas of fixed assets and long-term debt, where corroborating evidence is relatively easy to obtain, financial statement assertions may be achieved more efficiently by performing substantive tests are opposed to tests of controls. Once the design of IT controls has been assessed and documented, the initial level of control risk is set, and the auditor has decided to test the design and effectiveness of controls, the auditor proceeds to the controls testing phase.

Phase Two: Testing of Controls

Controls tests should be performed to gather evidence concerning the effective and consistent functioning of the actual control activities. Their results document the basis for the auditor's conclusions concerning the level of control risk. If the client is a private company and the IT system is not complex, control risk is usually set high. Therefore, it is possible to bypass the testing of controls and rely on substantive testing.

Under the auditing standards (SAS 48, 55 and 78) relevant to computer-based systems issued prior to SAS 94, a large percentage of auditors assessed control risk at the maximum level and performed only substantive tests of account balances and classes of transactions to gather evidence about financial statement assertions. SAS 94 recognizes that this approach may not be viable in complex IT environments. When the evidence of a firm's initiation, recording and processing of transactions exists only in electronic form, the auditor's ability to obtain the desired assurance from substantive tests is significantly diminished. SAS 94 does not change the requirement to perform substantive tests on significant amounts but states “that it is not practical or possible to restrict detection risk to an acceptable level by performing only substantive tests.” 18 Now, when assessing the effectiveness of the design and operation of controls in complex IT environments, it is necessary for the auditor to test these controls, regardless of the size of the firm or the level at which control risk is set.

Once a determination has been made about the complexity of the IT systems, the auditor can determine the nature, timing and type of the tests. This enables the auditor to design efficient tests to determine the operational effectiveness of controls.

The nature of the tests of controls may consist of observing the application of controls, relying on internal audit, performing technical tests, relying on control self-assessments and reprocessing transactions. Once again, COBIT can be used as an aid in the testing phase. In the control activities section, when providing assurance that proper infrastructure acquisitions have been made, a general control example is to ensure that documentation procedures exist and have been followed. According to COBIT, this control can be tested by examining the documentation for IT projects recently implemented, to determine if infrastructure requirements were considered during the acquisition process.19 In the complex IT environments, such as those mentioned previously, logical and physical data flow diagrams, systems flowcharts and decision tables should be used to document control activities. SAS 94, Sarbanes-Oxley and PCAOB Standard No. 2 support the use of these documentation tools.

In designing efficient tests of IT controls, the auditor should consider the need to obtain evidence supporting the effective operation of controls directly and indirectly related to the assertions. The techniques used to test automated IT controls incorporated into ERP and non-ERP computer programs may differ from the techniques used to test manual controls.20 SAS 94 requires the auditor to use computer-assisted audit techniques (CAATs), such as auditing through the computer and general audit software, to test automated IT controls that are embedded in computer programs, when the IT environment is complex and the auditor determines that it is not practical or possible to reduce detection risk to an acceptable level by performing only substantive tests for one or more assertions.21 It can also be inferred from reading Sarbanes-Oxley, COBIT, SAS 94 and the PCAOB requirements that CAATs are required to effectively and efficiently test IT controls. In addition, the auditor should test data related to assertions to obtain evidence supporting the effective operation for IT controls related to the assertions. For simpler IT systems, CAATs may not be required.

To test sophisticated automated IT controls, the auditing-through-the-computer approach is preferred because it focuses on the processing steps and the edit routines and program checks incorporated into application programs. It assumes that if the application programs are soundly developed and incorporate adequate checks, then errors and irregularities are not likely to slip by undetected. As a result, the outputs can reasonably be accepted as reliable. This approach embraces a family of techniques, including test data, parallel simulation, integrated test facility and embedded audit module.22 However, when using CAATs, the auditor may be able to reduce the amount of testing of the automated controls due to the consistency by which computers process transactions. That is, embedded controls should consistently account for errors they were designed to detect, unless the control routine in the program is modified, overridden or turned off. As stated in SAS 94:

Once the auditor determines that an automated control is functioning as intended, the auditor should consider performing tests to determine that the control continues to function effectively. Such tests might include determining that changes to the program are not made without being subject to the appropriate program change control, that the authorized version of the program is used for processing transactions, and that other relevant general controls are effective.23

Another approach that indirectly tests controls, known as auditing around the computer, focuses on inputs and outputs; it ignores automated controls. This is a nonprocessing-of-data approach because the auditor does not prepare simulated transactions or use actual client files to process with application programs. Although the auditing-around-the-computer approach has several shortcomings, SAS 94 does not eliminate the use of this approach in noncomplex IT environments that process transactions in a periodic mode, such as payroll, billing and other routine applications, and where source documents are widely employed and leave a visible audit trail.

After testing the controls, the final level of control risk should be assessed. In certain circumstances, if control weaknesses are significant, the auditor may take into account the concept of offsetting controls. These offsetting controls are called compensating controls. A control weakness in one area may be offset by a control in another area. Compensating controls reduce risk exposure; what were originally considered control weaknesses are no longer a problem.24 These compensating controls should be tested and evaluated.

The final level of control risk is set after all testing has been completed and the test results have been evaluated. For clients that must comply with Sarbanes-Oxley section 404, the auditor must identify significant deficiencies and material weaknesses in internal controls that could result in misstated financial statements. The auditor and management should develop action plans to address the control deficiencies and weaknesses. However, the auditor is required to document any significant deficiencies or weaknesses noted from the testing of controls in his/her assessment of internal controls over financial reporting.

Summary and Conclusions

Under new regulations, such as Sarbanes-Oxley and PCAOB Standard No. 2, auditors are facing increasing responsibilities for assessing the internal control structures of their clients. Many of these clients rely heavily on IT systems to generate reliable financial reporting information. Therefore, evaluating IT controls is critical to assessing the ICS. Auditors are finding it necessary to revise the audit procedures used to assess and evaluate their clients' internal control structures.

IT, which is becoming ever more complex and sophisticated, is revolutionizing businesses. A large percentage of firms, large and small, rely on IT to initiate, record and process journal entries; enter transaction totals in the general ledger; and record recurring and nonrecurring combinations. Audit techniques must take into account the impact of this reliance on a financial statement audit. An auditor must fully understand the five components of the ICS to correctly evaluate the ICS and to set inherent, control and detection risks. This evaluation proceeds through three logical audit phases: initial audit planning, preliminary assessment of the ICS and testing of controls.

Prior to SAS 94, the auditing standards in force provided no guidelines to auditors about the impact of complex IT environments on the three audit phases required to evaluate the ICS. During an audit, auditors typically bypassed the testing of automated controls, gathering sufficient evidence about financial statement assertions by performing only substantive tests of account balances and classes of transactions. Audit planning, assessment and testing of a firm's internal controls for complex automated systems has been substantially modified by SAS 94. In such environments, bypassing testing of controls is no longer a viable option. It may be impossible, according to SAS 94, to restrict detection risk to an acceptable level by performing only substantive tests. Thus, in sophisticated IT systems, regardless of firm size, the auditor may reduce the assessed level of control risk by performing tests of controls, which provide evidence about the effectiveness of the design and operation of controls. CAATs, such as auditing through the computer, which embrace a family of approaches, including test data, parallel simulation, integrated test facility and embedded audit module, may be utilized to test controls.


1 American Institute of Certified Public Accountants, Statement on Auditing Standards (SAS) 94, The Effect of Information Technology on the Auditor's Consideration of Internal Control in a Financial Statement Audit, May 2001 (Amends SAS 55, Consideration of Internal Control in a Financial Statement Audit, April 1988)

2 Control risk is defined as the risk that material misstatements in management's assertions, leading to significant errors in the financial statements, will fail to be prevented or detected by the ICS.

3 Public Company Accounting Oversight Board, Standard No. 2, An Audit of Internal Control Over Financial Reporting Performed in Conjunction with an Audit of Financial Statements, Washington, DC, USA, 9 March 2004

4 The steps are not necessarily conducted using a “cookbook approach”; rather, their sequence is highly judgmental.

5 IT Governance Institute, IT Control Objectives for Sarbanes-Oxley: The Importance of IT in the Design, Implementation, and Sustainability of Internal Control Over Disclosure and Financial Reporting, USA, 2004, p. 37,

6 Most of the COBIT framework can be freely downloaded from the IT Governance institute web site at

7 Op. cit., ITGI, p. 36-37

8 Ibid, p. 37

9 Ibid, p. 24

10 Op. cit., SAS 94, paragraph 14

11 Inherent risk is the risk that internal or external environmental factors will lead to a material error or errors in a financial statement account balance or class of transactions, before assessing or evaluating the internal control structure.

12 Op. cit., SAS 94, paragraph 43

13 For an in-depth discussion of the subject of risk assessment, see Michael J. Cerullo and Virginia Cerullo, “Threat Assessment and Security Measures Justification for Advanced IT Networks,” Information Systems Control Journal, vol. 1, 2005. Also, Sarbanes-Oxley requires organizations to assess the overall IT financial reporting controls readiness. This readiness aids in determining if all departments involved in processing financial transactions are integrated with the Sarbanes-Oxley section 404 implementation plan.

14 This figure is explained further in the controls activities section.

15 Op. cit., ITGI, p. 60

16 Op. cit., ITGI, p. 79

17 Op. cit., SAS 94, paragraph 65

18 Ibid, paragraph 66

19 Op. cit., ITGI, p. 60

20 Ibid, p. 79

21 Op. cit., SAS 94, paragraph 3

22 Cerullo, M. Virginia; Michael J. Cerullo; “Impact of SAS No. 94 on Computer Audit Techniques,” Information Systems Control Journal, vol. 1, 2003, p. 53

23 Op. cit., SAS 94, paragraph 78

24 With respect to compensating controls, such controls can reduce the risk exposure in smaller companies. For example in smaller companies, owner-manager supervision can offset shortcomings in segregation of duties. In addition, users' review of the output can detect errors undiscovered by weak microcomputer application controls. A reliance on some compensating controls requires that these controls be tested and evaluated. The outcome of the evaluation would determine the amount of substantive audit techniques required to complete the audit.

M. Virginia Cerullo, Ph.D., CPA, CIA, CFE
is a professor of accounting at Southwest Missouri State University, Springfield, Missouri, USA. She specializes in internal auditing and is the coordinator of the Institute of Internal Auditors' Endorsed Internal Audit Program at SMSU. She received her doctorate from Louisiana State University and has published numerous articles in professional and academic journals.

Michael J. Cerullo, Ph.D., CPA, CITP, CFE
is a professor of accounting at Southwest Missouri State University, Springfield, Missouri, USA. He specializes in accounting information systems, information systems auditing and fraud examination. He has published approximately 150 articles in professional and academic journals. He received his doctorate from Louisiana State University.

Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by ISACA®, Inc.. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the Information Systems Control 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. Information Systems Control Journal does not attest to the originality of authors' content.

© Copyright 2005 by ISACA® Inc., formerly the EDP Auditors Association. All rights res erved. ISCATM Information Systems Control AssociationTM

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, Mass. 01970, to photocopy articles owned by ISACA® Inc., 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.