Fundamental Segregation of Duties 320



  • Denis i do agree with you. I have a query though:
    What about the case of acquired applications (off the shelf) where we dont have access to the code.
    In this case we still do a lot of changes in the applications or database changes. In this case would we still be bound by the segregation of duties in development and production?



  • I think that the simple answer is yes. There still chould be change controls in place to limit who can make configuration changes and those making the configuration changes generally should not be also doing processing in the production environment.



  • thank you



  • Hi kymike,
    but in my case the system administrator and some consultants responsible for development have access to the production environment. The users of the application do not have access to production.
    in this case how would i address the issue



  • Sorry the users of the application do not have access to development



  • I advise any emergency be highly visible and allow some bureacracy to slow the process a little to ensure only true emergencies are coming in and are under the microscope. Even if the developers come in screaming with blood seeping out their eyes. If they come in via stretcher take their pulse. Some people act better than they code. The process should be a little painful. Not unsurpassable but painful.
    On a completely different note I wasn’t talking about conflict with access into production. I was talking more along the lines of reporting structure. I don’t think anyone is asking that basic question. Who do you report to? And examining that relationship as to whether it makes sense or not. Are there square pegs in round holes?
    In todays global economy people need to open their eyes past financials. IT is not a garment factory.



  • All,
    Some compensating controls to consider when encountering SOD issues:
    IT related

    • Mentioned in several prior posts: Reconcile production code (libraries, executables, scripts, etc.) to approved released versions in the source code repository. This tells us that what’s in production went through the change management process with proper testing, approvals, etc. This test should be part of management’s SOX testing anyway (SOD issues aside) to validate completeness of the population within the source code repository.
    • If the population of the source code repository is validated as per the prior step (nobody circumvented the process) and released code has undergone appropriate testing and is approved, this would indicate that only authorized changes made it to production. In the case of emergency changes, proper approvals were obtained after the fact.
      Financial controls (partial list)
    • Look for and test financial reconciliations that would detect anomolies introduced by unauthorized changes to production.
    • A/R aging - if an unauthorized change exaggerates revenue customers will not pay their bills and/or complain.
    • Use of audit tools like ACL, Approva, etc. find out stuff like a vendor that has the same bank account number as an employee.
      HR controls
    • Check that all employees (or at the very least, people with sensitive IT access) undergo a background and reference check. Generally, you don’t hire people who have committed fraud in the past.
    • Consider a mandatory vacation policy as this complicates fraudulent activity.
      There are other controls that others could add to this list I’m sure.
      Ed


    hey all
    Y all this fuss and confusion, there are so many tools( biggies and nominal ones too) that take care of so many SOX related issues, mainly SOD. You have tools like Virsa, approva, Foxt, Securinfo etc to bend thier backs so that we buy those tools, implement them and be relaxed ( though few may prefer the manual processes over these tools, all said and done manual methods are flexible u see 😉 )
    Looks like our fello soxers have looooooooooooooootsa time to design their own control methodologies.
    Iam of the view that, these tools will help us big time when it comes to sustenance of our SOX compliance efforts.
    After all, SOX came up to ensure the survival of all these corporations rite 😛
    cheers all



  • Hello and thanks for the post: I have a situation where one person is the developer/administrator/manager of a in-house built financial system on a AS400 subject to SOX regulation. Since it is not possible to segregation the functions with additional staff, the only way to provide compensating controls is to implement what was suggested i.e. monitoring of the changes made, and unalterable audit trail.
    The problem is that the administrator has the ability to edit the audit trail files, delete them etc.
    Would there be anyone who knows how to protect the audit trail without changing the logic of the application?



  • The auditors are claiming that developers cannot have access to qa, uat or production. They are also demanding that there will be some kind of seperation of source control such that migrating source from dev to qa requires physicaly moving the source code somewhere. I guess their belief is if the source physically resides somewhere else than somehow that will make it safe. I don’t know how else it can be done. The goal is to ensure that the source code that corresponds to a production executable is known to be the actual code that the executable is compiled from, whithout (unauthorized) patching of the executable. The remaining request is to enforce that all developers when requesting source control send some kind of request to senior management. The manager will then have to perform some action to release the code in question to the developer. All of this, I am sure sounds wonderful on paper, and in a power point presentation, but in the tranches, this will create an incredible nightmare. Something that has probably been mentioned in this forum is the concept of change request forms or equivalents, but I don’t see much mention of them very explicitly. In my experiences, every modifiaction to the production environment has a change request, usually from the user. The change request gets approved (pre-approval) by designated authorities (usually) before a developer even sees it. Subsequent approvals might be neeeded, but the change request is used as the authority for virtually every affect it has on production.
    Using this methodolgy, the problem of ’ send some kind of request to senior management ’ and ’ release the code in question to the developer ’ is insignificant. There are software that can automate the process.



  • Good points SS 🙂 … The Change request system is indeed important in the SDLC process.
    Most companies have more pending requests than people to work on them. Senior management participation is needed to help prioritize the most critical business projects among competing requests. It’s beneficial to have an IT senior management steering group to help in this decision process.


Log in to reply