This site uses cookies to provide you with a more responsive and personalised service. By using this site you agree to our use of cookies. Please read our cookie notice for more information on the cookies we use and how to delete or block them.

Bookmark Email Print this page

Certifying automated information technology controls

Common challenges and suggested solutions

Author: By Baskaran Rajamani

Information technology (IT) has transformed the way in which business is conducted. Due to extensive automation of business processes and data processing, IT has become pervasive across all functional areas of the business. It is critical in accounting and financial reporting processes, where internal controls over financial reporting are frequently embedded within software applications. Consequently, to comply with Canadian Securities Administrators certification requirements and/or the U.S. Sarbanes-Oxley Act, organizations must identify, document and test their numerous embedded IT controls.

Embedded application/automated controls offer several advantages over manual controls: Firstly, they tend to be more effective controls since they are usually preventive controls. Secondly, automated controls generally require only one sample to be tested (as opposed to say 25 samples per year for routine manual controls operating many times per day) with a consequent reduction in test efforts. Thirdly, based on recent guidance from the Public Company Accounting Oversight Board (PCAOB), under certain monitored conditions, embedded controls once tested (i.e. benchmarked or baselined) could be subject to a rotation plan and tested once in only three years instead of every year.

On some levels, it has been relatively straightforward for the IT department to identify and test IT general controls — including the internal controls organizations implement over IT management processes such as computer operations, change management and problem management. Yet, the proper identification, documentation and testing of internal controls embedded within the various software applications has proven more complex than anticipated. That is why it’s important to understand the challenges and potential solutions to testing embedded application controls.

Four primary challenges
Although the issues faced by individual organizations vary depending on an organization’s size, the extent of automation and industry, companies tend to face four categories of challenges with regard to automated controls:

  1. Identification and documentation. Although there are some exceptions, automated controls are usually hidden in a system’s (or application’s) logic. As a result, these controls are not always obvious to end-users, making it difficult for business users to identify them. In multi-divisional organizations with a shared and/or outsourced application environment, the identification of automated controls can be even more challenging. As a result, business users tend to identify and test system controls that are obvious to them, ones to which they can relate. For instance, take the example of a mortgage application in a financial institution. The business may document and test controls around the verification of reports from the system and the manual reconciliation performed. While these may be valid manual controls, they tend to be “detective” in nature (i.e. errors are identified after they have occurred). This also means the financial institution may fail to properly document and test automated preventive controls (such as control features within the software related to complex calculations) that tend to be more effective because they are performed by the system and don’t deteriorate over time (assuming system changes are managed). Further, manual detective controls may be far removed from the key automated preventive controls, making them undetectable by downstream controls.
  2. Testing. For key automated controls that have been identified and documented, their design and operating effectiveness must be tested in year one (and in subsequent years as required by the rotation plan). Testing raises challenges of its own. First, the testing of automated controls demands skills that are not usually within business management’s skill set. As such, IT and business management must collaborate and define the scope of a reasonable test of controls. Second, it can also be challenging to test certain types of complex automated controls in a production/live environment.
  3. IT-dependent manual controls. A third challenge that arises when dealing with application controls is the issue of how to treat IT-dependent manual controls. IT-dependent manual controls are activities performed by an individual using, for instance, a system-generated report, e.g. resolution of exceptions by an individual based on a system-generated exception report related to a reconciliation. In this example, there are two controls that mitigate the risk that transaction data lacks integrity (and consequently do not reconcile): First, the automated control that the application is capable of identifying accurately breaks (i.e. mismatches) in the reconciliation. Second, the manual control that deals with and resolves system-identified exceptions. The challenge arises when organizations begin to consider whether they must document and test the automated control as well as the manual control, or whether they can simply confine their reviews to the manual controls.
  4. Signing off. A final issue that arises around automated controls concerns whether it is the responsibility of business managers or IT managers to sign off on documentation and testing. Business managers often feel they are not properly qualified to sign off on the effectiveness of automated controls. On the other hand, the IT function often sees itself as a service provider that delivers on business unit requirements and expects the business units to determine if the technology operates as desired. As such, IT managers often feel they are not in a position to take accountability for automated controls that they developed in response to business requirements.

Exploring some solutions
While there are no hard and fast rules for dealing with the challenges related to automated IT controls, experience suggests some best practices:

  • Organizations that have successfully identified key automated controls have taken a collaborative approach with relevant business, IT and compliance representatives coming together to walk through the business process and identify key automated controls.
  • Where organizations have a shared application environment, it makes sense to develop a list of key automated controls for each application that can be commonly documented and tested once, then leveraged by the user community to avoid duplication. This is ideally done with a cross-functional team that includes both compliance and technology specialists. Once a list of common automated controls is compiled, business managers can identify the automated controls that should be documented and tested.
  • In their efforts to devise and resource a sustainable testing model, many organizations have chosen to acquire the relevant IT testing skills either by recruiting new resources or training existing resources drawn from a combination of IT and business representatives. Either way, a collaborative approach between business and IT for testing automated controls, combined with some training, yields the best results. Concepts such as “continuous control monitoring” are emerging to automate the testing of application controls.
  • In situations where automated controls cannot be tested in the live production environment during the normal course of business, a recent copy of the relevant portions of the production environment may be used.
  • For IT-dependent manual controls, consider documenting and testing both the automated and manual controls where the inherent risk is high, particularly if the automated control was not explicitly included during user acceptance testing when the application went live, or subsequently. On the other hand, if business users can easily identify automated control malfunction, or if the automated control’s incidence of errors is very low, organizations may conclude that the documentation and testing of the manual control alone would be sufficient.
  • Consider explicitly identifying and testing controls as part of ongoing user acceptance testing process, and leveraging those tests for compliance.
  • In determining who should sign off and take accountability for automated controls, organizations have a few options. The IT department can sub-certify for automated controls, enabling the business managers to sign off on the end-to-end process and key controls over financial reporting within the process. Alternatively, IT and business can jointly sign off on automated controls.

Regardless of how your organization chooses to resolve these issues, it is critical that you consider IT challenges as part of your certification process and proactively develop a well-supported strategy to identify and resolve automated IT control deficiencies.

 

Understanding IT controls
One of the key ingredients of CEO/CFO certification is identification, documentation and testing of internal control over financial reporting. Given the pervasiveness of IT, IT controls form an important component of certain internal controls over financial reporting.

In discussing IT controls, it helps to understand the two main types:

  • IT general controls mitigate risks within IT management processes that usually fall under the purview of the IT department. They include processes such as managing IT operations, managing changes to the IT infrastructure or applications, managing information security and managing system-related problems.
  • Automated controls are embedded within an organization’s application systems. These controls work by virtue of the programming logic or custom configuration that applications rely on to process transactions or make complex calculations. As an example, consider a financial institution’s mortgage application that relies on a variety of complex factors to approve a mortgage application. All these calculations take place in the “background” without any manual intervention and are considered automated controls.

While general controls tend to be well understood by most organizations, automated controls pose unique challenges.

For more information about certifying IT controls:

Deloitte Image 

close