IT General Computer Controls 1510
itgcctester last edited by
During the first year of controls testing, our company had very detailed controls…even some procedures docuemented as controls. Obviously this made it very difficult to test.
For this years testing, we have reworded the controls at a high level…eg change mgmt is:
-requests are approved
-changes are tested before going to production
-production migrations are approved and verified
-access to production is appropriately restricted (no developers with more than read/execute)
-emergency changes are subject to change control procedures.
-access to code/code repository is restricted to appropriate personnel.
With those controls and desktop procedures. Would this be adequate? Or would we be missing something integral in the process? Any feedback would be great. Thanks.
harrywaldron last edited by
Hi and welcome to the forums
This looks like a good list for controls and it’s a good point to state these at both a high level (strategic controls) and a more granular level, (tactical operational controls)
Below are a few of my own ideas to add to the list that may or may not be applicable for your organization:
- Change Management Communications – In addition to technically based security controls, formal communications related to major changes should be made. Email group lists are ideal for this process. The notification process ensures nothing is sneaking into the financial systems unexpectedly.
- Software Versioning Controls – As software, Excel documents, etc are revised – they are subject to version controls, so that a reviewer or auditor can trace back the historical changes.
- Physical Security Controls – This might be important to document and test as well, to ensure only authorized folks can go into the Data Center, Server rooms, or other restricted areas which might house financial data.
- Financial System Controls – For each applicable system, describe the workflow, technical safeguards (e.g., security, versioning, etc), and human safeguards (e.g., separation of duties, autonomy levels, checks and balances, etc). The Financial Systems are the key focal point of applications which must be controlled using the SOX compliancy standards.
NC last edited by
welcome to this wonderful forum.
I would suggest you to have a look at the SOX cobit processes released by ISACA somewhere in 2004. As a guideline, it is quite comprehensive, and when read with the COBIT document itself, it helps big time w.r.t itgcc.
SOX control objectives link
Hope this helps
milan last edited by
In the SOX Business Process Documentation including documentation of control activities, it is generally considered acceptable and appropriate to address the 5 basic ‘Ws’ to assess if the documentation is adequate.
Who performs the control? (Who is the process owner?)
What is the control? (What is the Control Objective?)
Why is the control performed? (What is the risk mitigated?)
When is the control peformed? (Daily, Weekly, Quarterly, Annually, or per incident)
Where is the control performed? (What function area performs the control?)
If you can satisfy that these basic elements are addressed in the process documentation, you will likely be able to satisfy the requirements of the external auditor.
Hope this helps,