Applying IT controls

By Chris Anderson
Illustration: Baiba Black

When it comes to IT general controls as a prerequisite to reliance on application controls, there’s a difference of opinion

Financial and information technology managements are faced with competing, complex and confusing standards and guidance on how to evaluate the design and operating effectiveness of IT application controls. An application control — a user’s transaction processing limit, for example — must function within a secure, trustworthy computing environment (i.e., the surrounding network, server hardware and operating systems) for it to work. This is what placed in operation means, and it is required before an IT application control can be considered to be designed effectively.

There are conflicting opinions and guidance regarding whether effectively designed and operating information technology general controls (ITGC) are a prerequisite to reliance on application controls that provide key internal controls over financial reporting.

Corporate management, CAs, audit committee members and IT security and control professionals need to debate the minimum ITGC requirements to support a conclusion that an IT application control is designed effectively and has been placed in operation.

The conceptual and practical problems lie in the situation where apparently strong application controls operate in a weakly controlled computer environment —for example where accounting system packages are in-stalled on a computer server within a local area network (LAN) where the LAN and server operating system and database management system password rules are weak, little or no logging and review of possible unauthorized activity takes place and too many people have LAN and server administration privileges. This happens in small and medium organizations, and in a few large ones from time to time.

The importance of ITGC
On one side there is the point of view of the Financial Executives International Internal Control Evaluation Framework, published in December 2004 and incorporated into the Public Company Accounting Oversight Board’s Staff Questions and Answers, Auditing Internal Control over Financial Reporting, issued November 22, 2004. Question 35 of this document makes the following claim: “IT general controls, by their nature, do not affect the company’s financial statements directly.”
On the other side is the following:

CICA Handbook Sec. 5141.054: “Obtaining an understanding of internal control involves evaluating the design of a control and determining whether it has been implemented. Evaluating the design of a control involves considering whether the control, individually or in combination with other controls, is capable of effectively preventing, or detecting and correcting, material misstatement.”

CICA Handbook Sec. 5141.060 notes that IT poses specific risks to an entity’s internal control, including (among others) reliance on systems or programs that are inaccurately processing data or processing inaccurate data; un-authorized access to data that may result in improper changes to data, including the recording of unauthorized or nonexistent transactions; and most importantly, unauthorized changes to systems or programs, or failure to make the necessary correct changes to systems or programs.

AU Sec. 319, Consideration of Internal Control in a Financial Statement Audit, also stresses that ITGC risks need to be considered when evaluating the design effectiveness of application controls, and concludes that the nature and characteristics of an entity’s use of IT in its information system affect the entity’s internal control.

The CICA IT Control Guidelines (3rd Edition) also disagree with the approach suggested by the working group in the evaluation framework: “For reliance by management or auditors to be placed on fully automated control procedures or computer-assisted control procedures, general computer controls must be implemented and operating consistently and reliably. If they are not, there can be no assurance that fully automated and computer-assisted controls continue to operate as designed. Fully automated and computer-assisted controls do not compensate for weak general computer controls. If the condition of general computer controls is less than satisfactory, greater assurance must be sought from manual control procedures that do not in turn require assurance from general computer controls.”

In July 2004, the CICA Information Technology Advisory Committee issued a white paper, “IT Control Assessments in the context of CEO/CFO Certification.” It states, “IT controls are fundamental to the reliability and integrity of the information processed by the automated systems on which most organizations are dependent for their business and financial transaction processing — and overlooking or minimizing their importance creates a significant risk. The effectiveness of other controls, particularly manual controls, is also more often than not dependent on the effectiveness of IT controls.”

The key point here is that it must not be assumed that an IT application control has any inherent correctness or integrity within it (given the past 50-year history of application bugs and human errors in coding resulting in the best practice of, at the minimum, three errors in every 1,000 lines of code). Further, inherent consistency of IT processing over time must not be assumed because this requires the IT application control to be located in a well-managed and nonhostile processing environment. These assumptions are dangerous to make when trying to obtain a high level of assurance about the financial statement integrity of an IT application control. The position that IT (application) controls are inherently more consistent than human behaviour is not necessarily true. The inherent risk of human error still exists, not in day-to-day manual transaction processing, but in the human errors contained within the code that automatically processes the transactions and possibly in the operation of the computing system. There is merely a shift of the inconsistency of human behaviour involved in the transaction processing from one point (i.e. manual transaction processing)to the design, coding and operation that automate the work steps and integrate that application code with enough other technology to give it life.

There are strong arguments supporting the position that application code needs something else to breathe life into it. By itself, application code is mere lines of characters on a page (source code) or a string of zeros and ones (executable code).

Design and implementation
Unless the application function that provides the internal control (an exception report, for example) is properly implemented, we cannot say it is designed effectively. Where do you implement code? For typical computer systems — comprising an operating system, a database management system and some sort of network connection — don’t assume inherent consistency of IT processing over time unless the IT application control is located in a well-managed and nonhostile processing environment.

The assumption that IT application processing is properly implemented and inherently consistent is valid only if: ITGCs are in place to ensure that application code logic has appropriate integrity through proper design, coding and testing; and the application code is kept safe through operationally effective controls over changes to the code and access to the data the code manipulates to produce expected results.

Safe environment
You need to trust the application systems and to do that, you need to trust the IT infrastructure to keep the data and programs safe from unauthorized and untested changes. Automated controls need a safe house within which to operate. If proper evaluation of internal control design effectiveness requires that the identified control is not only correctly designed on paper but placed in operation, then where else is an application control placed if not into what is commonly called a computer environment? Application controls do not operate in a vacuum. An operating system has to translate the application instructions into machine instructions, perform arithmetic and logic tasks, and provide the result back to the application. The application code does not operate in isolation. The safe house is needed for the application system to do its work and satisfy the user’s needs, and a control architecture brings it all together.

How to break the problem down
The diagram on page 43 was developed by the IT Governance Institute (www.ITGI.org) in its research document “IT Control Objectives for Sarbanes-Oxley” to provide guidance on how to plan and scope the evaluation of IT general controls within a financial reporting context.

The diagram uses a layered view of the financial reporting process to guide management and auditors in decomposition of the information processing components that result in financial reports. The layered view breaks down the technology and process components so they can be readily understood and evaluated.

The key point of this diagram is to show the different layers needed to interact to produce financial reports that have integrity. Management and external auditors can document and evaluate each layer in the diagram and bring these results together in what might be called a horizontal approach. Or, they may consider the information system to be a vertical slice of each of these layers. In this case, the data is entered into an identified system that includes the application and its underlying database management and operating systems, and relevant parts of the network are evaluated as a whole to determine whether or not that system performs its functions correctly and the relevant application controls are designed effectively. This is the vertical approach to analyzing the information system and associated internal control.

Whether you take a vertical or horizontal approach, eventually all the applications that are significant for financial reporting or any other business purpose, and the underlying infrastructure, have to be evaluated in order to understand the control risks that may exist.

All applications need trustworthy IT infrastructure (operating systems, database management systems, networks) to manifest their destiny and to breathe life into their lines of code. The applications need the overall infrastructure (the horizontal point of view) or the IT infrastructure specific to the application (the vertical point of view) to function in a secure and trustworthy manner. Primarily this means authentication of users, access control or privilege management, and control over changes to systems.

Organizations that continue to develop, acquire and implement new application systems to meet the changing business user needs require a mature set of IT infrastructure processes and technologies — one that provides a secure processing environment for all applications and gives the chief information officer and the organization an efficient and effective way to rise to the challenge of establishing trustworthy application systems processing to meet management and regulatory needs.

From an audit standpoint, it’s not sensible to evaluate IT application controls as designed effectively without first figuring out if important ITGC, such as how changes are made and what access the users and IT personnel have, are free of material weaknesses and are operating effectively.

Chris Anderson CA (NZ), CISA, CMC, CISSP, is a partner with Grant Thornton Consulting in Toronto

Technical editor: Yves Godbout, CA•IT, CISA, director of IT services, Office of the Auditor General of Canada