Audit Serve, Inc.

The Premier Audit, Security and Sarbanes-Oxley Consulting Company

Sarbanes-Oxley 404: Finalizing the IT General 
Controls Portion of the Review
 (Part 1 of 2)

By: Mitchell H. Levine, CISA
Audit Serve, Inc.

                                                             

Low Cost & Highly Skilled 
IT Audit and SOX Consulting Resources Available Immediately
Call Mitch Levine at (203) 972-3567 or 
email levinemh@auditserve.com for additional information

Most organizations are scrambling to complete their Sarbanes-Oxley implementation projects which consist of the remediation of the control gaps they identified, performing tests and identifying issues derived from the testing.   This article address four key areas which need to be completed to achieve Sarbanes-Oxley compliance.   The primary focus of this article is IT General controls but many of the points discussed can be applied to the application and financial areas of the Section 404 projects. 

Validating the Scope

Within the IT General Controls areas many organization used the IT Governance standard for defining the controls required.  The first version released in 2003 had 138 control objectives which were reduced to 78 control objectives in the second versions released April, 2004.  Additional areas were further removed from the scope of the Sarbanes-Oxley project by PCAOB such as disaster recovery.  Many of these 78 control objectives could be applied to operating system, database and application levels which further expanded the actual work being performed.  Many organizations have decided to not include all 78 IT Governance control objectives in the scope of their project. It is important for companies to explain the rational for the control areas they included in the scope of their Sarbanes-Oxley projects.  In addition, many organizations have centralized and distributed processing and therefore may have performed different levels of control validation.  For instance, the internal Sarbanes-Oxley compliance group may have performed complete independent testing of the controls of the centralized processing areas but relied on self assessments by the remote areas.

As part of validating the scope of the Sarbanes-Oxley project, companies were required to complete the exercise of identifying their in-scope applications, databases and servers/processors.  The selection of the applications was based on whether transaction and batch processing impacted revenue, asset valuation or expense reporting which ties to the balance sheet and income statement.  In most cases, companies defined the databases which were in-scope based on identifying which databases are used by the in-scope applications.  However, this method of identifying in-scope applications is not “cut and dry” since multiple applications impact a single database.  Therefore, if an out-of-scope application updates an in-scope database (i.e., because it is updated by an in-scope application) wouldn’t that make the out-of-scope application in-scope since it can update data used by the in-scope application?  The only defense to this approach is if there was security in place which prevents the out-of-scope application from impacting the data used by the in-scope application.  However, there are many fields used by both applications which are the reason why they are on the same database.   It is important to document the rational that was used for defining the in-scope applications, databases and servers which will be reviewed by the external auditors.

  
Validating Controls

The key starting point for Section 404 of the Sarbanes-Oxley Project was the identification of the Control Objectives for each of the control areas which were considered in-scope for the Sarbanes-Oxley project.  The control descriptions where were established for each control objective formulating the basis for establishing the test procedures.   Control descriptions should be derived from policies and is a component of the standard operating procedures.  Many controls have been written at a policy level which would translate into testing procedures.  

For instance, writing a control description which states that security administration and change control procedures are in place to prevent individuals from gaining direct access to alter data is quite different from a control description which states that individual user access to alter data is restricted from all users.  The first control description would translate into a test which checks a sample number of security access forms to ensure that no direct data level of access is being granted.  The second control description would require a test which checks the access entitlements to the data to ensure it is restricted from all users.  The first control description would be the testing of the preventive control which prevents future non-compliance.  The second control description would be the testing to identify all past non-compliance.  Both tests are critical, however the primary focus should the control that prevents future non-compliance.  In addition, the external auditors would not disclose the past non-compliance because they are not performing substantive testing as part of their review.

The final stages of the Sarbanes-Project should assess possible changes to the control description to align them with controls which prevents material risk.  However, if the external auditors have already reviewed the control objectives and descriptions used by your organization it would be too late to change them until after their year-end review since any significant change would invalidate the testing performed.

The remaining two areas of this article will be discussed in the next issue of Audit Vision which includes Remediation Project Prioritization and Completion dates and a discussion of the overall documentation requirements.

Copyright  2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

This article appeared in a past issue of the Audit Vision E-Mail Newsletter.