SOX Roll-forward Testing - Automated Control - Low Risk 2585
toosunneo last edited by
I am working in the Internal Audit group with Big 4 consultants. From looking at their testing workpapers, it appears that they are performing testing of automated controls (such as access is restricted by system) for roll-forward or year-end update testing for low risk controls. If it is a manual control, low risk, then we only perform inquiry for roll-forward.
I would appreciate if anyone could share their thoughts on why we need to perform testing for automated control for roll-forward, even though this is low risk control.
milan last edited by
You are correct to be concerned about unnecessary controls testing of automated controls (example: access controls) that are categorized as low risk controls.
As a suggestion, it might be helpful to ask the engagement manager how they view (from a risk perspective) the automated controls and potential impact on financial reporting. If they cannot establish a clear linkage between the automated control(s) or do NOT concur that the risk is low, they are not obligated to test the automated controls.
The IIA, wwwdottheiia.org notes the following regarding testing of automated controls:
Where there are good change management controls within ITGC over an application, management may decide to test only a sample of automated controls each year.
The principle, called benchmarking, is described in the PCAOB document issued on May 16, 2005. The principle needs to be applied to each automated control in turn, examining whether: (a) the software has been changed since the last time it was tested, (b) whether there are sound change management processes and controls relative to the software, and whether the control is of such significance that risk demands it be tested every year.
If effective and consistent change management controls are in place, the application and systems that contain the automated controls should be reliable.
However, they also caution to test a sample even if there were no changes. In my opinion, this seems to reflect the conservative nature of the external auditor and to apply auditor judgment when determining the extent of reliance he or she places on the system controls.
Based on the above, the auditors might be correct in testing a sample, but you might be successful to ensure a minimal sample size and efficient testing approach.
Denis last edited by
For an automated control the approach I would expect to see is:
- testing of General Computer Control around the application; and, if effective
- test of one on automated controls
If GCC are effective I would not expect to see a roll forward test on an automated control tested at an interim date.
Where GCC are not effective you would need to conduct a full (or even extended) sample on the control.
Alternatively, you might still take a full sample approach on automated controls if doing so was less work than assessing the GCC.
gmerkl last edited by
Does your system produce any compiled (i.e. in machine language) or pre-compiled code and is it possible to look up the date when the last compilation (i.e. the last change) was made? If yes, this may be a shortcut to prove that nothing has changed (so no testing needed). If you are using an ERP system and if the ERP system consists of several modules or components that can be compiled independently, you will not have had changes in most parts of the system unless you did an upgrade or applied some sort of patch from the vendor. The only typical changes are in-house developed reports.
It’s completely inefficient to test automated vendor programmed controls (i.e. those the three way match for vendor invoices work, does it bill all shipments that have not been billed yet, etc.) in an ERP system since this means testing almost the entire functionality of the ERP system because everything flows into accounting from purchasing, production, sales and payroll.
If you only mean access controls with automated controls, then they are not really automated. The only automated part would be that the vendor code automatically compares a user’s access rights with the access rights necessary for this particular transaction. Assigning certain access rights to a certain user is actually a manual control (because a natural person needs to decide which access rights to assign and to type in the transaction). There should be controls around assigning access rights and creating new user accounts. I would say those controls are rather low risk. If they really want to test some changes to user access rights, they should do a smart risk based selection and only select changes to access objects with a close link to financial reporting and changes that assign create or change rights to the object. Personally I think user access rights are extremely low risk.