Download or print article

We are coming into the fall season when IT auditors schedule their annual IT walkthrough and assessment. Many IT Directors and Chief Accounting Officers responsible for the results of their company’s Sarbanes-Oxley (SOX) internal control assessment dread this timeframe because they often still have the same philosophical and practical disagreements each year over IT general controls (ITGC).  These include: what areas should be in scope for assessment, how much should be tested, what is considered adequate controls for an objective, or even the basic premise of why it’s relevant to SOX and the evaluation of internal controls over financial reporting (ICFR).  What are the common areas of disagreement between IT auditors and management when it comes to IT general controls? And, what is really important? 

To tackle the question of what’s important, we must first have a common understanding of 1) what is an IT General Control (ITGC) and how does it fit into an overall control framework, 2) the authoritative guidance, 3) the control frameworks that provide guidance on ITGC, and last, but not least, reflect on the importance to the specific organization or 4) the company’s facts and circumstances.  We can then apply this framework to some commonly disputed items.

1. DEFINING IT GENERAL CONTROLS

IT general controls can best be defined by contrast to IT application controls.  Application controls are those that are implemented within a software application and directly affect or control the processing of a transaction or event, often referred to as transaction processing controls.  IT general controls, in contrast, do not directly relate to processing transactions but support the IT environment. Some IT general controls have a more direct connection to the process controls, and others are more indirect.  To this extent, ITGC are very similar in nature to entity-level controls.

ITGC controls are focused on four areas:
• Computer Operations
• Program Changes
• Information Security or access to programs and data
• Systems Development and Implementation

These four areas are outlined in the COSO Internal Control: Integrated Framework as well as the Control Objectives for Information and related Technology (COBIT) framework.

2. AUTHORITATIVE GUIDANCE FOR PUBLIC ISSUERS

SEC Release 33-8810

The SEC guidance on management’s internal control assessment provides the best basis for establishing that IT general controls must be considered in a SOX assessment.

It states “Controls that management identifies as addressing financial reporting risks may be automated, dependent upon IT functionality, or a combination of both manual and automated procedures.  In these situations, management’s evaluation process generally considers the design and operation of the automated or IT dependent application controls and the relevant IT general controls over the applications providing the IT functionality.  While IT general controls alone ordinarily do not adequately address financial reporting risks, the proper and consistent operation of automated controls or IT functionality often depends upon effective IT general controls.”

Important in this narrative is the reference to automated controls or those dependent upon IT functionality.  A company may not have identified any key automated controls to the financial reporting process and therefore, believe that IT general controls are not relevant to the SOX process.  However, when referring to controls dependent upon IT functionality, the SEC specifically gives examples such as balanced postings.  This would suggest, as seems reasonable, that a company is dependent upon IT functionality where it is using a general ledger application or any other financially-relevant information system that compiles, balances, or reports financial information for the interim or annual financial statements.  Therefore the IT general controls that support the operation and management of changes in these environments are relevant to the evaluation of ICFR.

The SEC further explains that the identification of risks and controls within IT should be an integral part of management’s top-down, risk-based approach.  They go on to explain that “aspects of IT general controls that may be relevant to the evaluation of ICFR will vary depending upon a company’s facts and circumstances”, an area we will address as item number four below.

PCAOB Audit Standard No. 5

The Public Company Accounting Oversight Board’s Audit Standard No. 5 (“The Standard”) which replaced Audit Standard No. 2 to focus more on a risk-based approach does not directly give guidance on how much IT general controls should be considered.  It states that an important factor in considering the risk of a control is the extent to which it relies upon “the effectiveness of other controls (e.g., the control environment or information technology general controls)”.  The Standard also discusses the need to test ITGC controls when application controls are relied upon to ensure the effective operation of the application controls.

One of the most impactful pieces of information in the Standard regarding the importance of IT general controls does not actually even mention the specific term “IT general controls”.  It is the guidance on the evaluation of deficiencies. The Standard states that the severity of a deficiency is dependent upon two things: “1) Whether there is a reasonable possibility that the company's controls will fail to prevent or detect a misstatement of an account balance or disclosure; and 2) The magnitude of the potential misstatement resulting from the deficiency or deficiencies.”  In applying this standard, many IT auditors conclude that one ITGC deficiency by itself generally would not warrant an evaluation as a significant deficiency or material weakness since ITGC controls do not directly relate to the achievement of a financial statement assertion. However, if an ITGC issue contributes to the deficiency of a key application control, (for example, ineffective testing of program changes to an application resulting in inaccurate system calculations of an account balance), then the ITGC deficiency is generally considered to be as severe as the application deficiency. The aggregation of multiple ITGC deficiencies however, can trigger an auditor to conclude that they are important enough to call to the attention of those responsible for oversight of financial reporting, i.e. the Chief Financial Officer and Audit Committee, and therefore a significant deficiency. The step from significant deficiency to material weakness is largely judgmental.

3. THE CONTROL FRAMEWORKS

COSO

The Committee of Sponsoring Organizations of the Treadway Commission’s Integrated Framework for Internal Control (COSO) is the most commonly used control framework when evaluating the Sarbanes-Oxley Section 404 assessment of ICFR.  COSO defines internal control and five components of internal control: control environment, risk assessment, control activities, information and communication, and monitoring.  IT general controls may be contained in any of these five components.  COSO provides a definition of IT general controls and the key areas considered in ITGC but does not give detail guidance on designing or implementing IT controls.

COBIT

The Control Objectives for Information and related Technology (COBIT) published by the IT Governance Institute (ITGI) is widely used by IT auditors and management to supplement the COSO framework since it goes beyond defining the key areas of ITGC by outlining specific guidance on the application of a control framework for designing and implementing IT controls. It defines commonly accepted control objectives for technology and gives examples of controls to meet the control objectives.  The IT Control Objectives for Sarbanes-Oxley, 2nd Edition (“SOX COBIT”) published by the ITGI applies the COBIT framework to Sarbanes-Oxley and provides additional IT guidance on areas of greater importance to internal control over financial reporting.  This includes an approach to risk assessment for the information technology environment and guidance on the priority of controls. It is interesting to note that this publication places a greater priority on risk assessment and the risk-based approach than the first edition, although it was published prior to the PCAOB’s Audit Standard No. 5 which emphasized risk-based approach. The references to PCAOB in SOX COBIT refer to Audit Standard No. 2, which is now superceded.  The SOX COBIT document provides good guidance on points to consider, example controls and tests for controls.  The use of this document however, sometimes gets warped when the points to consider for entity-level IT controls and example activity-level controls get used as a “checklist” rather than as guidance, and little thought is given to understanding the company’s circumstances and the overall achievement of control objectives.

4. THE COMPANY’S FACTS AND CIRCUMSTANCES

In applying the above guidance and frameworks, it is important to also take the company’s specific circumstances into consideration.  Avoiding a “checklist” audit is as simple as two considerations:

1. Achievement of relevant control objectives
   In most cases, a variety of different controls can be utilized to achieve the same control objective. Sometimes it is desirable to utilize multiple controls to achieve a control objective to achieve greater assurance. However, utilizing all the possible controls or all of the illustrative controls listed in the SOX COBIT is not necessary to provide reasonable assurance of control over financial reporting.
2. Risk (or applicability) to the company
   An auditor who is not following a top-down risk-based approach to the assessment of company controls may request information on controls or control objectives that are not even relevant to the company, such as controls around a System Development Lifecycle methodology, when the company has no software development activities and utilizes only “off-the-shelf” applications. The controls relevant to assess for SOX not only need to be applicable, but the level of control and the nature and extent of testing should be consistent with the system’s or area’s risk and the specific control risk.  The use of a good risk assessment for IT will right-size the number of controls identified as key to SOX and the nature and extent of testing to what is reasonable and appropriate to the company. A good IT risk assessment is not independent of the overall SOX risk assessment, but follows it from the identification of existing risk to financial statement accounts to relevant process to the IT applications and systems that support those processes.

COMMON AREAS OF DISAGREEMENT

Network vulnerability

When assessing controls to ensure system security, many auditors following COBIT will insist that a network vulnerability assessment or attack and penetration test should occur every year. An auditor following the SOX COBIT model will point to an illustrative control that states: “Appropriate controls, including firewalls, intrusion detection and vulnerability assessments exist and are used to prevent unauthorized access via public networks.”
However, this control is only illustrative and by no means mandatory.  Furthermore, the SOX COBIT document identifies some controls as “most relevant” to SOX, however threat and vulnerability assessments are not among them.  Companies with an elevated threat level, such as Fortune 100 companies or companies that are well-known in the media, and could be considered a target from outside hackers may need to have continuous vulnerability monitoring with specialized network monitoring software (intrusion detection systems or intrusion prevention systems) as well as periodic attack and penetration studies, along with strict firewall rules and related configuration policies.  However, a middle-market company with little external threat based on name-recognition or confidentiality of information in its possession may have adequate security even if its network is secured only by good firewall rules and basic firewall monitoring.  The level of control should be commiserate with the company and the IT risk assessment.

Segregation of duties

A common assessment of segregation of duties by an IT auditor includes obtaining security data from the company’s ERP system, and then comparing it to best practice cases, outlining which duties should not be performed by any one single person. One such best practice, for example, mandates that “A person who creates accounts payable invoices in the system should not also be able to produce check runs to pay the invoices”.  While this addresses the valid concern that a person could create an invoice to their own benefit and then create a check to pay that invoice, there are a number of conceivable mitigating controls that may be in place to prevent such an occurrence.  A strict conflict match based on two activities considered to be inappropriately segregated according to best case scenarios, however, does not consider mitigating controls or the remaining risk level.  In the above example, an Accounts Payable clerk who can create both invoices and checks may be prevented from defrauding the company by not having the authorization to  create invoices for vendors that have not been approved by a another party, or sign any of the checks they have created themselves. Checks may be reconciled by another person. These would be considerations in the assessment of segregation of duties that may fully mitigate or reduce the conflict to a point where the risk of the scenario is very low.  A structured approach to documenting segregation of duties conflicts, related controls, and mitigating controls will reduce the amount of discussion with auditors and helps avoid the time-consuming assessment of segregation of duties.

Backup and recovery

From the beginning of SOX assessments, auditors have agreed that a full-scale disaster recovery plan was outside the scope of SOX.  Continued debate occurs, however, as to what relevance to internal control over financial reporting there is to taking data backups of systems. Also debated is whether testing the recovery of those backups is something that should occur periodically and to what extent.  The inclusion of controls over data backups is closely tied to our definition of ITGC and the authoritative guidance on what types of ITGC are considered relevant in an assessment of ICFR. ITGC support the IT environment and their inclusion is based on the extent to which process or application controls are dependent upon IT.  Data backups sustain the continuity of the IT environment which supports the financially-relevant applications. At a small company where most journal entries are made at month-end and a whole new set of financial statements could be re-created very quickly, data backups are not as significant.  And while backups are relevant to most companies, the absence of reliable backup procedures or controls may not pose a high risk and may not lead to a significant deficiency.  The necessity of testing the ability to recover data from backup is often debated.  The fact is that you can’t rely on a backup being usable unless you can prove it.  The level of backup control should be based on 1) ability to ensure that the right data is in fact there, and 2) data can be recovered.  Some auditors insist that a full recovery test be performed.  If one separates verification of data and ability to recover into two parts then you find that full recovery testing may not be necessary. The question of what proves it can be recovered will depend upon the software and data format.

CONCLUSION

ITGC is a necessary part of the IT controls supporting financially-relevant applications.  Auditors may go overboard on what controls are necessary, the level of significance of certain controls and on certain tests due to a checklist approach to auditing ITGC.   A structured IT risk assessment supported by documentation of the environment, including relationships to related process controls can reduce the amount of discussion and therefore time spent by auditors.

Download or print article