JOnline: The Information Systems Auditor Unmasked 

 
Download Article

Chances are good that most IT professionals have encountered an information systems (IS) auditor over the course of their careers. Whether these auditors are internal or external to an organization, IS auditors perform specific procedures to determine assurance with respect to an organization’s controls over its information systems. These procedures ultimately serve to benefit the organization, but those benefits may not readily translate to the IT professionals during the course of the audit engagement. In many cases, IT professionals may ask themselves or the auditors questions concerning the purpose of the audit or why the auditors take certain approaches when assessing controls.

This article guides the IT professional through the mind and methodology of the IS auditor with a specific focus on procedures performed by external auditors, particularly external auditors associated with financial statement reporting, while stressing the importance of the audit process itself.1 In doing so, some of the more common questions IT professionals may have are addressed and suggestions are provided to alleviate the time commitment required for such audits.

Audit Origins

“Who are you and why are you here?”

External IS auditors provide a service to their clients based on the clients’ needs. But from where exactly are these needs stemming? Be they privately held or publicly held (e.g., organizations that sell bonds to the public or sell stock on a regulated exchange), many organizations must provide financial statements to various interested parties. A privately held organization may execute loan agreements with lending institutions that in turn may require audited financial statements to ensure the financial viability of the company (and, thus, of the loans provided). Publicly held organizations are subject to regulatory requirements by such organizations as, in the US, the Securities and Exchange Commission (SEC), whereby those organizations must file audited financial statements for public inspection. This information, in turn, provides comfort to current shareholders, analysts, prospective investors and other interested parties with respect to the organization’s profitability and ability to generate revenue.

An organization’s audited financial statements effectively provide assurance to concerned third parties with respect to the reasonableness of the financial information reported, but what does this have to do with that same organization’s IT environment? Auditors are held to certain regulatory standards; in this respect, auditors of financial statements adhere to standards prescribed by such institutions as the American Institute of Certified Public Accountants (AICPA) or the Public Company Accounting Oversight Board (PCAOB). Those standards are codified and available as auditing guidance or generally accepted auditing standards.2

Under these generally accepted auditing standards, an auditor must obtain an understanding of an organization’s business, including its controls over internal financial reporting.3 Internal financial reporting, meanwhile, does not rely simply upon reconciliation and review processes performed by various individuals within a company; such reporting additionally stems from the applications that generate financial data and the systems that support those applications.

Internal Controls Over Financial Reporting and the IT Relationship

“Why are you testing this?”

Understanding controls over internal financial reporting requires that auditors obtain an understanding of systems and applications in place at an organization that ultimately impact its financial statements. Effectively, auditors must understand those systems and applications and their respective controls to determine where a risk may result; a risk is most relevant to the possibility that an organization’s financial statements may be materially misstated. An auditor must be able to present an opinion as to whether a reasonable investor or other interested party could place reliance upon an organization’s financial statements being absent of significant discrepancies. Without understanding the general IT controls pertinent to an organization, this opinion cannot be achieved, as a significant risk of material misstatement cannot be assessed without understanding the systems that process the financial data or support the processing of that data.4

Generally accepted auditing standards prescribe that a top-down approach to risk assessment be performed; that is, the most general controls pertinent to the financial statements’ preparation should be considered with respect to their risk and precision before more specific controls are considered (e.g., manual reconciliation processes).5 This, in turn, allows auditors to determine the controls that are key to the financial statement process, i.e., the controls the failure of which could effectively produce a material misstatement within the financials.

IT General Controls

“Why are you not testing that?”

Auditors thus start with an assessment of entity- or company-level controls, which include general IT controls.

What general IT controls are pertinent to a given company? The answer is actually dependent upon the organization itself. In obtaining an understanding of the organization’s business and its systems, the auditor determines the business process cycles most relevant to the processes impacting the financial statements. Those cycles may include, for example, processes concerning revenue generation, cash receipt, inventory procurement and payroll. From those cycles, the financial auditor determines which cycles are critical to the preparation of materially accurate financial statements and, in turn, the applications that assist in processing the transactions related to these cycles.

The nature of the IT risk assessment is not a haphazard process, but specifically focused, based on the understanding of the business and its processes related to the client. The assessment itself is developed based on standardized control objectives. Many IS auditors consider control objectives prescribed by organizations such as the Committee of Sponsored Organizations of the Treadway Commission (COSO).6 Those control objectives in turn encompass certain control groups including, but not limited to:

  • IT governance—Controls generally focus on how the IT objectives in place at an organization follow an organization’s strategic business objectives.
  • Program changes—Controls generally focus on authorization and testing of system implementations and program changes and segregation of duties among code development and migration.
  • Operations—Controls generally consider areas such as data backup, production processing, help-desk functions, and data center physical and environmental security.
  • Logical access—Controls generally consider authorization and authentication controls in various layers (e.g., application, database, operating system, overall network), including segregation of duties and access administration.

Naturally, the specific applications that play a role in the generation of the financial statements are considered. At this point, the IS auditor considers logical access controls, such as complexity of password parameters enforced, the reasonableness of access rights assigned within the applications, and how roles are segregated based upon job function. In this regard, the auditor may additionally consider how such roles are administered with respect to newly hired employees or how access is eliminated when users leave an organization.

Assessing Risk Beyond the Application

“Where else would you like to go?”

IT general controls do not end at the application itself. Databases or operating systems may support the relevant application and in turn present an additional layer of security requiring assessment of risk; the network itself may merit additional risk assessment, depending upon its level of sophistication and use.

Furthermore, applications themselves may be subject to modification—be they source code enhancements, configuration changes or customized reports. In this regard, the auditor examines evidence to ensure any program changes that impact financial data are authorized by appropriate business management, and are adequately tested to ensure that such program changes function as intended and that access to develop and promote them are restricted to separate individuals or job functions.

IS auditors effectively make judgments about the criticality of various IT general controls based on the understanding gained through assessing the various systems and processes. As a point of contention, an auditor may expect less risk at operating system and network layers, given their more indirect relationship to the prepared financial statements and the relatively immediate and apparent nature of certain security failures, as well as compensating controls at both the application layer and via business process controls (such as management reviews concerning errors or fraud).7, 8 In response to this, auditors may narrow their focus to specific applications and still complete a valid risk assessment.

Evidence Collection

“How would you like to see this?”

The methods by which IS auditors conduct their risk assessments may vary, but generally accepted auditing standards dictate that certain procedures must be performed to allow a reasonably independent auditor to reperform such risk assessment. In that regard, auditors may follow certain test procedures as prescribed by auditing standards. The procedures include the following:9

  • Corroborative inquiry—The separate inquiries of two or more individuals who have knowledge of a control to confirm the design or operation of the control. Auditors typically perform this procedure when physical evidence cannot otherwise be obtained, such as when auditors must determine who has knowledge of a system’s default or generic administrator account password. As auditing standards further mandate that auditors utilize a reasonable level of audit skepticism when performing their testing procedures, this additional level of inquiry ensures that the standards are appropriately met.10
  • Observation—Specific observation of system screens by auditors to confirm the design or operation of the control, such as a single sign-on process for an application. At this point, auditors may observe organization personnel accessing relevant systems to understand how access is gained and how roles are granted upon access.
  • Inspection—The retention and examination of physical media, such as screenshots (e.g., of password parameters, login screens) or reports (e.g., access rights listings, terminated user reports). The retention of physical documentation, especially documentation supporting controls that can be evidenced only at a given point in time (such as password parameters), guarantees that the audit evidence obtained allows for an independent party with reasonable audit experience to reperform the control test.

Tests of Controls—Auditing Beyond the Risk Assessment

“Why are you testing that many?”

In many instances, the IS auditor may perform more robust testing of IT general controls. When this occurs, the auditor has determined, based on the initial risk assessment (i.e., the sum of inquiries, observations and inspections of IT general controls performed), that the controls designed may be operating in such a manner that additional testing of such controls may serve to reduce subsequent testing of financial reports themselves. Testing controls cannot remove all testing of the pertinent financial reports, but it may reduce that testing to such a degree that the total audit time can be reduced without necessarily impacting the quality of the audit itself.11

When the decision to test the operating effectiveness of controls is reached, auditors must then ensure that the populations of the relevant controls subject to testing are complete. If a population representing the operation of a control is incomplete (such as a listing of terminated employees tested to ensure that access is removed from systems on a timely basis), auditors cannot conclude that the control has effectively operated to allow for a reduction in later financial testing (e.g., if a listing of terminated users cannot be generated, how can an auditor ensure that all terminated employees have a chance of being selected to test timeliness and completion of access provisioning?).

Having obtained the appropriate populations and verified their completeness, auditors then test a sample of items within that population to ensure that the control related to such population has consistently operated. The number of items selected depends not only on the size of the population (i.e., the larger the population, the greater the number of items that must be considered), but also on the level of risk that the lack of a related control would produce to the financial statements (sample sizes can be additionally impacted by the level of any testing performed by the company, as examination of the quantity, quality and results of such testing may permit auditors to reduce their own samples). As a point of reference, the lack of operation of application data backups may produce less risk to financial statements, as the live data are not necessarily impacted. Thus, a relatively smaller sample of backup logs may be inspected (if any at all). Correspondingly, user terminations may provide greater risk, as open accounts may promote a risk of unauthorized access to systems and data. Thus, an auditor may inspect greater samples of termination notifications and individual access listings to ensure the effective operation of such control.

Conclusion

Figure 1In performing independent IT systems risk assessments, IS auditors can provide a benefit to clients by documenting and discussing potential risk areas with respect to the control objectives deemed significant to the financial statements. To assist auditors in completing such risk assessments, company IT personnel should consider the following suggestions, which may expedite the risk assessment process and thus minimize the required interview and documentation assembly time required of an organization’s personnel:

  • When scheduling the risk assessment, request from the IS auditor a client request list that may allow an organization’s personnel to obtain screenshot evidence, reports, contracts and so forth in advance of the interview process. In cases where the IS auditor has a long-standing relationship with the organization, auditors can be asked to tailor the listing to specifically consider the applications and control objectives relevant to the organization.
  • Review the client request list in advance of the IT controls interviews, and distribute the listing to personnel directly responsible for the relevant controls, including parties outside of IT roles, such as payroll administrators and/or accountants.
  • While participating in the IT control interviews, ensure that the interviews are performed in the presence of a workstation or terminal to allow IS auditors to observe any systems controls and obtain screenshots to evidence such, where permissible by the organization.
  • Provide all screenshots and reports presented for observation at the end of the interview to reduce subsequent requests for clarification and supporting documentation.

Figure 1 provides a basic checklist that details the aforementioned points and may serve to reduce audit preparation time on the part of IT professionals.

Endnotes

1 This article is based in part on the experiences of the author.
2 It is important to point out that generally accepted auditing standards extend beyond the boundaries of the US. As an example, many countries adhere to International Standards on Auditing (ISA). Those standards prescribe guidance relevant to planning and executing an audit engagement, including obtaining an understanding of an organization’s operations and assessing risk of material misstatements. For the purposes of this article, however, the author has focused more specifically upon auditing standards generally accepted in the US.
3 As of the writing of this article, the current source of the auditing guidance discussed herein is the American Institute of Certified Public Accountants (AICPA) Statements on Auditing Standards (SAS) No. 109, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement. As SAS are currently undergoing a codification, which will allow for convergence with ISA, the related proposed applicable standard is AU-C: section 315, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement.
4 American Institute of Certified Public Accountants, SAS No. 109, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement, March 2006, para. 1, 21 and 57
5 Public Company Accounting Oversight Board, Auditing Standard No. 5, An Audit of Internal Control Over Financial Reporting That Is Integrated With an Audit of Financial Statements, June 2007, para. 21
6 Op cit, AICPA SAS No. 109, footnote 8
7 Singleton, Tommie; “The Minimum IT Controls to Assess in a Financial Audit, Part II,” ISACA Journal, USA, vol. 2, 2010, www.isaca.org/journal. Singleton notes that “logical access that is closer to the data is generally considered more effective (provides more assurance) than that further away.”
8 The Institute of Internal Auditors, GAIT Methodology: A Risk-Based Approach to Assessing the Scope of IT General Controls, August 2007, p. 21
9 Op cit, AICPA SAS No. 109, para. 6 and 55
10 Ibid., para. 19
11 American Institute of Certified Public Accountants, SAS No. 110, Performing Audit Procedures in Response to Assessed Risks and Evaluating the Audit Evidence Obtained, March 2006, para. 5

Brian Vazzana, CISA, CICA, CPA.CITP, is an information systems (IS) and assurance services senior manager with BDO USA LLP, an independent member firm of BDO International Ltd.—the fifth largest accounting services firm in the world. Vazzana manages BDO USA’s Chicago, Illinois, USA, Milwaukee and Madison, Wisconsin, USA, and Kalamazoo, Michigan, USA, IS assurance practices.


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.

© 2013 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.