The Minimum IT Controls to Assess in a Financial Audit (Part II)

Transcription

1 The Minimum IT Controls to Assess in a Financial Audit (Part II) Tommie W. Singleton, Ph.D., CISA, CITP, CMA, CPA, is an associate professor of information systems (IS) at the University of Alabama at Birmingham (USA), a Marshall IS Scholar and a director of the Forensic Accounting Program. Prior to obtaining his doctorate in accountancy from the University of Mississippi (USA) in 1995, Singleton was president of a small, valueadded dealer of accounting IS using microcomputers. Singleton is also a scholarin-residence for IT audit and forensic accounting at Carr Riggs Ingram, a large regional public accounting firm in the southeastern US. In 1999, the Alabama Society of CPAs awarded Singleton the Innovative User of Technology Award. Singleton is the ISACA academic advocate at the University of Alabama at Birmingham. His articles on fraud, IT/IS, IT auditing and IT governance have appeared in numerous publications, including the ISACA Journal. In the last issue, volume 1, 2010, a model was presented to guide IT auditors in properly scoping the IT in a financial audit. That model measures the IT sophistication of an auditee. That measure (low, medium, high were used in the model in volume 1) basically determines the scope of the IT to be examined in the further audit procedures, and whether a subject matter expert (SME), such as a Certified Information Systems Auditor TM (CISA ), will be needed on the financial audit team. This second part focuses on certain IT areas, IT general controls (ITGC), that are generally considered fundamental in examining internal controls in the IT space of the auditee. There are five areas of ITGC identified as the essential areas of the IT space that would be examined, even if briefly, by the auditor as areas of IT that potentially introduce risk to the financial statements, the risk of material misstatement (RMM). While the applicability of any area or all five is certainly dependent on each auditee and its control environment, as a group they do represent the most basic and common areas of IT and controls that are examined in financial audits. Also, technical literature, such as Statement on Auditing Standards (SAS) No (the riskbased standards), has created the need for financial audits to specifically consider these areas. It is true that many financial audits will necessarily need to assess other aspects of IT. But, the purpose herein is to address those areas of IT that are likely to be assessed in almost all financial audits. The Minimum Five Areas Of It Controls To Assess The suggested minimum IT controls would be some of those included in ITGC. Almost all technical literature makes some reference to these controls, whether it is from ISACA, the American Institute of Certified Public Accountants (AICPA) or the Public Company Accounting and Oversight Board (PCAOB). The areas are IT entity-level controls, change management, information security, backup and recovery, and third-party IT providers. IT Entity-level Controls IT entity-level controls are related to the entity s environment, and thus are related to SAS No. 109, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement. These controls are those employed by management over the IT function as a whole, or in general. As a group, they provide an umbrella of controls over the acquisition, implementation and management of the IT (systems and technologies) used in the entity. Thus, they have an impact on all financial audits because all financial reporting lies under this umbrella. For example, IT governance would be a part of the IT entity-level controls. Regardless of size or IT sophistication, the entity should have some relatively formal set of controls to provide governance over the IT. At the low end of that spectrum, an owner-manager should have some reasonable control over the governance of IT. That function could be served by using industry guidance (recommendations, reviews on software, etc.) or a consultant to help guide those processes. Obviously in this case, the owner-manager will have a level of interaction and communication associated with good IT governance because of the size of the entity. But, it is also possible that the entity-level controls have no potential impact on RMM for the entity at the lower end of IT sophistication. At the other end of the IT sophistication spectrum, a much more robust set of controls would need to be in place, including some observable governance activities going up and down the organizational structure, system development life cycle (SDLC) best practices for IT software projects, and sound best practices in project management. Other controls in this area include IT policies and procedures, IT management, planning, 1 ISACA JOURNAL VOLUME 2, 2010

2 strategy, human resources, and IT risk management. The prime question becomes what kind of impact the entity-level controls have on RMM. For the low level of IT sophistication, the risk is likely to be so low as to become irrelevant. Change Management This term has become a popular one and this area of control has grown in significance over the last decade or so. However, it has best practices that have been developed over decades under other names, such as SDLC. Basically, change management controls are the controls management has in place to ensure that all changes in the IT portfolio are authorized properly and implemented securely. In the case of the latter, the controls would ensure that the systems or technologies were acquired with some forethought as to their reliability and applicability to the entity, and were tested offline diligently before becoming operational. Change management applies to software (applications) and hardware (infrastructure, including operating systems and networks). Change management is probably more often relevant to financial reports when it relates to application software used in financial reporting either in the processing of financial data or in the automated functions of the financial reporting process. Again, a proper scoping of this issue is important. For example, at the low end of the IT sophistication spectrum, the entity is probably using commercial off-the-shelf (COTS) applications and standard (i.e., COTS) hardware and operating systems for its infrastructure. Furthermore, if the owner-manager authorizes those purchases, change management probably has a low level of significance or risk (RMM) to the audit maybe so low as to become irrelevant to RMM. Thus, the minimum IT audit procedures might be limited or none, e.g., ensuring recent versions of the COTS products are being employed. The IT auditor cannot know, without some examination, that activities in the risk assessment phase of the financial audit are designed to determine the level of RMM related to change management, at least for the first year s audit of a client, or periodically thereafter. If the entity s IT staff codes applicable programs (i.e., those that affect financial reporting data or processes), or modifies applicable commercial software, the opposite is true. There would be a need in this case to have a robust audit procedure to gain assurance over authorization of software and infrastructure changes. Obviously, in this case, there would be a great deal more changes, made a lot more frequently. This scenario tends to be present when the level of IT sophistication falls on the upper half of the spectrum. Information Security Information security relates to the financial audit because of the inherent risk that an unauthorized party could gain access to financial reporting applications or data and intentionally or unintentionally create misstatements in the data. For instance, an employee may accidently be given access to an application he/she should not be using, and that person may decide for various reasons to make entries into a relevant application. Without proper training or controls, that person could key in transactions, incorrectly creating misstatements. Likewise, a rogue employee or outside cracker may gain access to the system with the intention of creating fictitious or even fraudulent transactions that potentially could be material. For the purposes of this discussion, security will be related primarily to two types of access: Physical access and environment controls over the computer center and key technologies Logical access to applications and data granted by access controls Physical controls include locked doors, cameras and other means to limit physical access to servers and other critical infrastructure. It even includes some aspects of construction, e.g., a single-story building set apart from others, with underground utilities, is generally seen as a best practice for the computer center. If the computer center is in a multistory building, consideration should be given to placing it on the top floor to limit physical access. Again, this aspect of information security and the risk it presents to the financials may or may not be relevant, and may or may not have the potential to lead to RMM. Logical access includes access to applications and data through technologies not requiring a person to be physically present. For instance, logins to networks are a logical access control. In addition to simply requiring an ID and password, the logins usually are subject to some type of access control matrix or system that limits what the authorized party can access. For example, Microsoft Active Directory can ISACA JOURNAL VOLUME 2,

3 grant limited access to systems and data for each person or suitable group of persons. Access control could also include application login controls separate from or in addition to the network controls. Logical access is generally considered to be even more important (i.e., higher risk) when remote access is possible, in which case it is generally considered best to add another layer of controls, such as biometrics, swipe cards, security questions, temporary personal identification numbers (PINs), etc., to increase control over authentication of users (i.e., ensuring they are who they say they are). At the lower end of IT sophistication, it is likely that neither of these types of security access is a severe enough risk to present an RMM. For instance, there are likely to be compensating controls, such as management review, over errors or fraud entered into the financial system via information security control weaknesses. In addition, logical access that is closer to the data is generally considered more effective (provides more assurance) than those further away. Thus, application access controls that are effective can possibly negate the risks associated with information security at the perimeter. While no conscientious manager would consider a logical access risk at the perimeter to be unimportant, it could be irrelevant to RMM in the financial reports because of compensating controls or more effective controls closer to the data and processes. That is, while an intruder could gain unauthorized access to the entity s network due to a perimeter weakness, if application access controls are strong, that person could not gain access to the application. The only question becomes whether that person could circumvent the application and gain unauthorized access to the database/data. But even then, if an intruder were able to access the data and do something nefarious that created a misstatement, and if that misstatement were material, would the entity be able to detect it or prevent it (compensating control)? If so, RMM is relatively low even though the information security risk might be high at the perimeter. Information security is one of those areas that inherently will have problems in all entities. It is not possible to have a perfect information security environment. Therefore, there will always be issues of concern in a review of an entity s information security, but IT auditors need to be careful to segregate information security problems and risks from RMM in a financial audit. It is likely in the lower end of the IT sophistication spectrum, as defined above, that information security will have a negligible effect on RMM (e.g., no remote access, no online transactions or only a few secured ones, combined with a reasonable level of logical access control or compensating control). Backup and Recovery Backup and recovery relate to the entity s ability to recover from a critical event that causes the loss of data and/or systems. It could be as simple as restoring a backup of data, necessary because the network hard drive crashed and is no longer accessible, thus requiring the entity to reconstruct its accounting records, including those since the backup was last made. It could be a larger scope if the computer center burns or is destroyed by a tornado, hurricane/typhoon or other storm. In that case, the entity has to restore systems and technologies (e.g., hardware) as well as data. This issue is commonly referred to as business continuity planning (BCP) or disaster recovery planning (DRP). From a management perspective, this issue is normally considered one of critical importance. From the perspective of an IT audit, the same is probably true. But from the perspective of a financial audit, there are a limited number of scenarios on the lower half of the IT sophistication spectrum where that would lead to an RMM. So some caution should be exercised in seeing this issue as a problem or as important rather than whether it is really an RMM that is not compensated by some other control. Generally speaking, for the low end of the sophistication spectrum, the IT auditor probably wants to know that there is a backup of data that is stored safely offsite and that management has restored it successfully in a test of the restore process at some point in the fiscal year under audit. At the upper end of the sophistication spectrum, the entity may well be subject to an RMM if the system crashes, e.g., entities that process online transactions 24/7 in very large volumes, creating the potential of a material misstatement due to a significant loss of transactions/data. In such a case, the IT auditor may want to personally test recovery of the data backups and perform some audit procedures to gain assurance that the entity s BCP is effective. 3 ISACA JOURNAL VOLUME 2, 2010

4 Third-party IT Providers Another area of ITGC is the use of third-party providers who provide some service to the user entity that is relevant to the financial reporting transactions or processes. In addition, a user entity might outsource functions of its IT (e.g., desk help, network support). For those third-party providers whose impact is significant to the financial reports, the user auditor may choose to rely on a SAS 70 audit (Type II) by the service auditor. Thus, the IT auditor may be asked to review the SAS 70 for effectiveness of IT controls over the service. A second aspect of using third parties is vendor management. The IT auditor should gain assurance that when a third-party provider is relevant to RMM, the vendor selection process leads to effective vendors and services and an appropriate mitigation of any risks that the applicable IT service presents to the financial reports. However, at the low end of the IT sophistication, it is likely that neither of these issues can be assessed as a significant part of RMM. For example, if the entity outsources support of its server and networks, there is clearly some risk associated with the vendor having access to the financial applications and data. If the vendor is a reliable one, then the risk would probably be low. If not, the IT auditor would need to think through the process of what would happen if the rogue vendor were to do something unauthorized in the financial transactions. Does some compensating control exist to detect or prevent any misstatements, including fraud, created by a rogue vendor? A Mapping Model For Practical Use As mentioned previously, these controls are a part of the technical literature from various professional organizations, even the PCAOB. To simplify the application of these concepts, a mapping was made between these five areas and two respected ITGC models: CobiT and the IT Assurance Framework TM (ITAF TM ) (see figure 1). By reviewing the referenced items of CobiT or ITAF, the IT auditor has access to additional information to assist in performing due diligence. Figure 1 Mapping Minimum IT Procedures With ITAF and CobiT Minimum IT Procedure Description ITAF CobiT IT entity-level controls Equates to SAS No. 109 IT governance IT operations management Change management Information security Backup and recovery Third-party IT providers Changes to software/programs Changes to infrastructure Physical and environmental controls Logical access controls (applications and data) Backup of data Business continuity planning (BCP) Disaster recovery planning (DRP) Outsourced IT Vendor management SAS 70 audits (change aspect of , 11, 12, 13, 14) PO1-10 DS1, 3, 6-13 ME1-4 AI1-7 DS DS DS2 ISACA JOURNAL VOLUME 2,

5 Conclusion Five areas of ITGC were identified as the minimum areas to evaluate on every financial audit. That is, each of these areas has the potential to be an area in which RMM does exist. Yet, it is vitally important that in the context of a financial audit, the IT auditor should make sure that there is a direct and significant relationship between ITGC and RMM, i.e., the financial data and/or financial reporting processes. An effective thought process is dependent on the IT auditor s ability to evaluate each of these on a case-by-case basis; therefore, IT auditors must be careful in using canned audit procedures or checklists or even last year s audit plan. The only constant in the IT space is that it changes constantly. While some of these areas will end up irrelevant to RMM, especially at the lower end of the IT sophistication spectrum, that does not mean they are totally ignored. It could be that the audit team or audit manager would choose to convey to management these problems, risks or weaknesses either formally or informally (e.g., to provide good client service). The formal approach would become part of the management comment letter from the auditor and/or the SAS No. 115 report. Caution should be taken in assessing control risk at the max and then relying on computer printouts, such as subsidiary balances lists, to perform audit procedures, because the auditor is relying on IT controls although the auditor has said that he/she would not rely on controls. Therefore, it is likely that most audits will need to rely on some controls and, therefore, almost all audits should include some tests of control in these areas. The bottom line is that IT auditors are trained and educated to recognize IT weaknesses and risks. In the financial audit, IT auditors need to resist the temptation to include all major IT problem areas in the audit plan. The audit plan should include gaining assurance over controls in the IT space that can be identified as having the potential to lead to an RMM, after considering compensating controls; that will be used to reduce or replace substantive procedures; and that will be relied upon as controls over computerized output that are necessary for further audit procedures in the audit plan. 5 ISACA JOURNAL VOLUME 2, 2010