SOX considerations in designing new system 1659



  • Hi
    I’m in the process of building and designing a financial application that will be under scope of SOX. I’m trying to figure out ways to integrate SOX within the actual application in order to cut corners. By cut corners I mean to make the internal control process easier, auditing, segregration of duties, any way in which we can automate/simplify something SOX related as opposed to have a human do it.
    What kind of things can I apply to the application? I guess user activity reports is one thing, but user access will already be controlled on the application level.
    Another thing is to log everything. IE: Log changes to maintenance tables, log user login creation etc. This doesn’t strike me as mind blowing stuff, just more or less keeping track of everything.
    Thanks for any advice.



  • Hi and welcome 🙂 COBIT 4.0 is the most widely accepted IT auditing standard for SOX compliant applications and this would be beneficial to review for ideas.
    Please add ‘www’ to link and paste into your browser
    isaca.org/Template.cfm?Section=COBIT6-and-Template=/TaggedPage/TaggedPageDisplay.cfm-and-TPLID=55-and-ContentID=7981
    isaca.org/Content/NavigationMenu/Members-and-Leaders/COBIT6/Obtain_COBIT/COBIT40-Brochure.pdf



  • Hi,
    Another idea to determine the controls to integrate into the financial application is to obtain example risk and control matrices for financial applications and related application controls.
    If you review the application controls identified in the control matrices, this should give you a starting point to identify the relevant key controls to embed during the design and development of the financial application.
    Good luck,
    Milan



  • I would reiterate Milan’s comments.
    I have been involved in a couple of projects within my Company looking at the SOX impact of new systems. Generally our approach has been:

    1. Determine which financial processes will be impacted by the new system.
    2. More specifically determine which control risks/objectives are impacted - or what new risks arise - as a result of the new system and the business process that will go with it. Bear in mind that this may be an iterative process.
    3. Determine what controls are available or configurable (or even better required) within the system to meet the risks from stage 2 above.
    4. Ensure that these controls are tested and found to be effectively designed as part of the UAT process
    5. Provide a SOX ‘sign-off’ that 1-4 have happened and the results are acceptable as part of the go-live decision
    6. Update process documentation as part of the implementation
    7. Test operating effectiveness after go-live

Log in to reply