Automated Control Testing Frequency 1781



  • Now this is where you have really confused me. If you had baselined the system with a sample of say 3 per each parameter (required by my auditor) coupled with proper change management processes then there would be no risk of any systematic error and a sample of 1 would suffice.
    If there is still a genuine possibility of a systematic error then surely a sample of 3 would only suffice if there are no more than 3 parameters involved eg there should be a minimum of 1 sample for each scenario. Infact if that were the case would it not make sense to either re-baseline the system so that you know there is no systematic error or, if the baselining cannoy guarantee there is no risk of a material error, intoduce an overarching control that provided the necessary assurance?



  • With a test of 1 it is important to ensure that the test covers all relevant scenarios - this may require more than one transaction. With some automated controls it may not require any transaction i.e. you may be testing that the system does not allow you to enter transactions outside a range which you may test by attempting to enter a wrong transaction.



  • You baseline the system during the first year. Subsequent years you benchmark transactions once in a year provided material change management have not occurred multiple times during the year and the ITGC over ICFR applications are deemed effective.
    Instead of searching for an all inclusive sample, we are better off with another one or two sample to incorporate all parameters.
    I hope that this helps.



  • I follow what you are saying, it is a difference in terminology from my perspective. The nature of our systems dictate that each sample covers one parameter. Therefore when I refer to one sample it is one per parameter and no more but we will sample the system more than 3 times because we have more than three parameters.
    All that being said, with over 30 systems each with between 20 and 50 parameters, we have chosen in a number of cases to go with overarching reasonableness controls rather than system testing to satisfy ourselves that our figures are materially correct.



  • On a slightly different topic - with the benchmark / baselining. When you make an acquistiton and migrate the new subsidary onto your systems should you rebenchmark (as we were requested) for say system access rights or just benchmark the new users.
    In practice is just more of the same data but was wondering if there is an approved route to doing this? (nb the new users had ‘prior’ approval from the board into our system)



  • I understand your dilemma.
    You can endeavor to identify a particular sample that would meet all parameters breaking them into 3 samples. It is your call how to tackle the situation. You can work with the control owner to derive an efficient sampling strategy to get to the bottomline of application control assurance.
    Otherwise, I would recommend that you go in for one dummy transaction incorporating all parameters if the system can permit can permit backout of this dummy transaction.
    All the best.



  • Abu,
    I would recommend rebenchmark as this tantamounts to an in scope change management.



  • Hi Chavva
    thanks for the quick reply. - at least my time wasn’t wasted 🙂



  • My experience within Internal Audit and my time at PwC is as follows:
    sample size of 1. But, you must cover all of the possible parameters.
    I.e. Test to ensure that the system calculates the payroll correctly:
    Sample 1: enter valid numbers
    sample 2: Enter negative numbers
    sample 3: enter numbers way out of range. (like tax amount higher than salary)
    sample 4: etc



  • Sample sizes guidelines from IIA and external Audit have been:
    Nature of Control Frequency of Occurrence Min # of Items to Test
    Manual Many times per day (> 5,000 transactions/mo)
    60
    Manual Many times per day 40
    Manual Daily (365 per year) 20
    Manual Weekly (52 per year) 10
    Manual Monthly (12 per year) 3
    Manual Quarterly (4 per year) 2
    Manual Annually (Once per year) 1
    Programmed
    Test one application of each programmed control activity if supported by effective IT general controls Otherwise test similarly to a manual control (e.g., 60)
    IT General Controls
    Follow the guidance above for manual and programmed aspects of IT general controls


Log in to reply