Segregation Duties:Who can implement a change to Production? 189



  • Or 'Which came first? The chicken or the egg?
    A SOx issue from our external audit identified that our Operations Team ‘Implementors’ have access to the production system.
    Our developers do not have access to production. Our Operations Team Implementors (2 system administrators) load changes to production on a scheduled implementation date set by our Change Control Board.
    If your company is SOx compliant, who and how do you ‘push the button’ to implement a change to your production system?
    If no one has access to production how do we implement changes?
    Thanks,
    j2



  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • First of all,
    I would challenge the auditor on that issue. The risk at play here is whether or not a change can go into production go un noticed. It sounds like you do have procedures for going live on certain dates.
    You can mitigate the risks of the implementors by ensuring that good audit logging occur and is reviewed by your security group on all admin account activities. (ie. keeping the admins honest).
    However, from what you wrote, it sounds like the implementing operator is the idea way to have your changes moving into production.
    hope it helps.
    tristanatbui.com



  • Yoda404,
    Thanks. We have reviewed and decided we can involve another set of eyes (Change Control Manager) to verify (mitigate risk) and sign off of the implementation. A daily system generated report of changes to production program files is distributed to key IT Managers to alert of ‘unauthorized’ change implementation. (Compensating Control)
    One of the key problems is the language used (BBX) is interpretative and does not use compiled code. So, the operator is uploading code that can be altered after development and before implementation without notice.
    I hope this will help others with similar issues.
    j2



  • Along the same lines, we’re having issues with the lack of inherent controls around PeopleSoft object changes. Has anyone come up with a monitoring activity that can facilitate independent review of object changes?
    Our external auditor has not been able to give us any actionable activities to improve our position, and we’re left to try and develop a monitoring control on our own. Note that we’ve looked at Qwest’s STAT tool, but it’s too expensive (USD165k), and we don’t have enough time before 12/31 to implement a bolt-on tool.
    Any ideas?
    :x



  • Hi,
    SOX is about implementing controls, what you are suggesting is an automated controls which tends to be more expensive and alot more hassles. Definitely something to implement in the long term, however in the short term, there is nothing wrong with ensuring a manual control be in place to address the risk.
    Is it possible to make every change of peoplesoft objects printed out and signed off? how often does it occur? can some one do a reconcilation between the log files in people soft and your change register to detect any unauthorised changes? if so why not do that…just remember that SOX is all about looking for detective and and preventive controls.
    Cheers
    tristanatbui.com



  • If I could add to yoda’s comments:
    SOx does not mandate how any particular process (financial or IT) should be controlled, what it says is that a company must have a control frameowrk that results in its financial statements being controlled.
    In practical terms this means that we need to look at how well controlled are key business systems. For this the benchmark control framework is CobIT. Generally we refer to this as General Computer Controls.
    An important part of General Computer Controls is how program change (or application development) is controlled. Best practice is that there should be separate environments for (at a minimum) development and production, with preferably one for test as well. Developers should not have the ability to make changes in test or production. Code movements between environments should be appropriately authorised.
    Hope this helps.


Log in to reply