Fundamental Segregation of Duties 320
This is a great conversation, I hope it continues.
What I am looking for are compensating controls when the segregation of duties has been violated. On occasion, we have a need to have the developer also install the code into production. Obviously this creates an issue, and I need a compensating control to mitigate the impact of this activity. No, I can’t prevent it…Already tried that avenue and failed.
Does anyone know of sufficient compensating controls to smooth this over with the auditors? I realize this will be a finding, I’m trying to make it so it doesn’t become a material weakness.
MrsM last edited by
We had a similar situation - small team on a system that is to be replaced soon so - due to size of team - need developers to be able to install. Our compensating control is as follows: detective control which captures when changes have been installed in the live system.
In our case, the system sends an e-mail notification when changes are promoted to live (although a secure report tracking changes should also be fine). This notification is reviewed by an independent person (i.e. IT person without access to promote changes on this system). They confirm the changes are valid and sign-off.
I’m actually already monitoring the system for changes such as these, and that’s how I’m able to identify that the developer is the same person that is installing the code.
My concern is that just identifying it is not an adequate control. What if the developer added some rouge code that noone else knows about. Since they developed it and deployed it, there is no control. How to mitigate that so it’s not a material weakness?
MrsM last edited by
On occasion, we have a need to have the developer also install the code into production.
What change sign-off documentation do you require your developers to complete as standard?
If you use a standard doc that already has two signatures (peer review is fine), then an independent review of your detective report to confirm all changes agree to signed change docs is sufficient to control the risk around unauthorised changes. This assumes the control cannot be circumvented (i.e. all changes show on your report),
As standard, we have an SDLC process that requires the developer to get the required approvals and QA testing before being installed into production. Those are not typically an issue for me, the issue arises when we have a small ‘emergency’ install that needs to be done right away. We have a policy/process for emergencies that requires the installer to send a change notification that the install was done. I have an independent group that monitors the production system for any changes, and matches the changes with the change notices.
My issue is that for ‘emergencies’ there is no approval or peer review. It’s coded, installed and an after the fact notification - that’s it. I wouldn’t have an issue if someone else besides the developer installed. With this current ‘process’ I have no separation of coder/installer.
KnightX last edited by
It sounds like your detect controls are pretty good, the only additional thing I could see doing to midigate the risk is to do a post implementation review of the code and test it in the test environment to ensure that the coder did not make any intentional or unintentional mistakes that could affect the financial statements. That should cover your bases from a financial risk anyway.
What kind of emergancy coding would not allow a coder to even email or call someone to notify them of something being moved into production?
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?
kymike last edited by
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.
mouse last edited by
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
mouse last edited by
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.
emobley last edited by
Some compensating controls to consider when encountering SOD issues:
- 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.
- 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.
NC last edited by
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
lolo56390 last edited by
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?
SimpleSamples last edited by
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.
harrywaldron last edited by
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.