Audit Serve, Inc.

 

Technical Articles
Conferences
Audit Programs
Audit Serve Seminars
Consulting Services
Audit Vision Email Newsletter Free!
What's New
Contact Us

 

The Worldwide Connection for Audit, Security, Control and SOX Professionals

Assessing the Adequacy of IT General 
Controls SOX Testing 
(Part 2 of 2)
By: Mitchell H. Levine, CISA
Audit Serve, Inc.


         


HP NonStop Server Security and Encryption Solutions
www.xypro.com


   The objective of the SOX test is to prove that the control activities included in the Risk and Control Matrices are functioning as stated.  The first part of the article focused on SOX testing approaches used, test data to be used and sampling approaches.   

   The most critical component of the SOX test is to define the conditions in which a test would pass or fail.  In some cases, there are multiple pass/fail conditions per test sample.  For example, there are two pass/fail conditions for the test objective to ensure that properly authorized requests exist.  The test data required to perform this would be a system generated list of security changes made. The first test condition would be to determine whether a security request exits for the security change.  The second test condition would be a validation against the authorized approver list to ensure that the security change was approved by the appropriate person.  If there was not a formal request then the second test condition to validate the approver cannot be performed.  Regardless, both test conditions would need to pass for the test sample to be categorized as a test that passed.  A case could also be made to separate the two test conditions into separate tests which would increase the total number of tests performed.

 
   Controls are defined as control objectives which are transposed into control activities.  Each control objective could have multiple control activities. The frequency of the control activity which determines the sample size could be different for each control activity which is associated with a particular control objective.   For certain control activities, the frequency is intermittent.  For example, the control activity to ensure that security patches are applies to the production database servers for a SQL Server environment is intermittent.  There has not been a security patch for SQL server since 2004 therefore there would be no tests which could be performed for this control activity.  Another example of an intermittent control frequency would be to ensure that security requests are formally approved.  In a small environment there may only be a few security changes per year in which case the entire population would be included in the annual sample selection.  Controls with intermittent frequencies should be re-evaluated on an annual basis.

   Each control activity would have their own test.  In some cases there may be multiple tests per control activity with each test having different test frequencies and sample sizes.  When a control is an automated control, the test frequency consists of one annual test.  For instance, an email notification which is sent for each backup failure which supports the control to ensure that failed backups are identified and acted upon would only require an annual validation to prove that the email notification process is functioning.  However, the second test consists of ensuring that proper follow-up occurred for failed backups identified.  The determination of whether this is a daily control can be debated (i.e., the frequency of the backup as compared to an intermittent control which is based on the frequency of the failure). 

   Another example of multiple tests for a control activity relates to the detective review processes that are in place.  For instance, a control activity which is comprised of identifying and notifying the owners of IDs when there are more than four successive invalid logon attempts to their ID within a single day involves two tests.  This control requires an area responsible for performing this review and documenting the review that occurred and notifying the owners of the Ids to determine whether they were the cause of the invalid logon attempts.  The first test is a reperformance test to ensure that review process is being performed correctly.   The reperformance test consists of reperforming the system operation function to gather the data which is analyzed based on pre-defined rules.   The compilation of the incidents derived from the reperformance review is then compared to the summary reports used to support the weekly review process to ensure the review process also identified these incidents.    The second test consists of ensuring that the review is actually occurring and the associated emails notification to the owners of the Ids is being sent out.  The second test’s sample size is based on the frequency of the review process.  The reperformance test is typically an annual review.


   SOX testing require the tester to provide a rational for the type of test performed and the sample selection.  The one lesson which everyone has learned with SOX is that every SOX tester may have a different view on how the test should be performed.


For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.

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.

 

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.