Segregation of Duties 2277



  • Hi,
    I am glad to have found this forum. The information available here is very useful in my area of work.
    I have a situation for an in-scope application in my company. Basically, I am from the IT department and we are trying to remediate the segregation of duties problem that we discovered.
    There exist a separate smaller IT team under the finance department in charge of a financial application. The IT team’s responsibility is solely systems support/development of the application. There is segregation of duties within the small team in that only one of the personnel is responsible for move-to-production of application code. The remaining 3 personnels play developer roles. Finance users in that department would request for a change, obtain approval from their direct finance manager, send the request to the IT systems support team within Finance. The IT manager will then review and approve the request, pass it to the developers for implementation.
    Both the business user community (i.e. change requestors) and the IT team belong to the same financial organization structure. Would that be acceptable under SOX? Please advise.



  • I am assuming testing and UATs from the Business would have taken place before the changes are deployed into Prod, so as long as the developers are not the ones deploying the changes in Prod, it should be fine.
    Also, the person who is responsible for pushing the changes to Prod - as long as he/she is not a developer, it should be fine.



  • Hi and welcome to the forums 🙂
    I agree with SG’s recommendations and would add the apsect of having an electronic audit trail of the process as well within the change control system (e.g., email is fine, as long as each TEST-to-PROD promotion is documented and retained historically). This way changes could be researched as well.
    SOX 404 doesn’t have absolutes and is somewhat flexible for adaptation to one’s particular computing environment. However, SOX 404 puts the responsibility on management to ensure automated financial systems are controlled properly.
    External auditors often use COBIT checklists to help certify IT financial controls for the company. If you register as noted in this thread, you can receive a free copy:
    http://www.sarbanes-oxley-forum.com/modules.php?name=Forums-and-file=viewtopic-and-t=1920
    You might also check with both internal or external audit for any areas of improvement. Certainly, one should not set up a bureaucracy or hinder productivity in the current process, unless there is significant material risk. Still, there might be ideas for better ensuring SOD, autonomy levels, and other classical audit controls that might strengthen the current process.



  • Thanks for the input. Wouldn’t this be considered a risk since the data owner and the business owner is under that same organization structure, Finance. And the finance VP would be the same person approving any change request as well as system accesses.



  • :idea: Hi - If everyone was willing, I actually like the idea of integrating the special financial IT support within the MAIN IT department itself. That helps better achieve standards, SOD, etc., if everyone is willing to do this.
    Sometimes separate IT team members may felt left out of the IT mainstream – or on the opposite side, they may feel more special and privileged, if they’ve gotten better treatment through the years. This type of change may be hard to make and the system owners can still keep them as full dedicated staff.
    If this type of change is too difficult to achieve, than strive for the best levels of controls and ‘after-the-fact’ monitoring reviews as possible.



  • Thanks, I was intending to propose that to the management. But first I would need to justify that with supporting evidence of the risks in not segregating the duties. In writing the report to management, I will have to justify that IT within a finance department presents a risk. And if they have individuals in charged of a specific duty (e.g DBA duties for employee 1, Developer duties for employee 2, 3, 4), it would be even harder to justify. Can I comment that there is no segregation of duties since the DBA, security admin, developer roles are all within a single group controlled by finance? Would this present a risk even though they have a segregation of duties within?



  • Thanks for the input. Wouldn’t this be considered a risk since the data owner and the business owner is under that same organization structure, Finance. And the finance VP would be the same person approving any change request as well as system accesses.
    Data owners and Business owners are usually the same person and generally under the same organization within the company. There is no issues in finance VP approving system access and approving change request (other criteria’s of change management as pointed out by SG taken care of in the request) as someone from management is providing oversight and taking bottom line for the risk. IT department is not the data owner.
    With that I see no issues here if:

    1. IT team is separate team and has no overlap with business activities. That means business users are not maintaining systems part time.
    2. As SG pointed person migrating change to production is not a developer.
      Calvin


  • Thanks for the reply.
    Previously, I mean to say Technology (IT) owner and Data/Business owner. Can the finance VP be the owner for both IT and Data owner?
    I guess I will put up the structure for a clearer picture.
    Basically, a Sr manager finance/controller has eleven Assoc Accountants/Accountants/Sr accountants and one Manager Finance systems support. All accountants or other financial department staff are the business users for this application. Hence, there may be a time whereby the both initiating and approving authority are under the same sr manager finance/controller.
    The Manager Finance Systems support is the IT team in finance. Under him, he has 4 system analysts. Each systems analysts assumes role of developer when required. Each analyst is responsible for changes/development of a single processing module (e.g. AR, AP, AM, GL). One analyst is assigned to be a DBA, he is responsible for promoting changes to production.
    On the other hand, a single person responsible for a combination of the role of a system administrator and computer support / operator would that present a potential control weakness?



  • In addition, the Finance systems support manager is the security admin who is in-charge of add/modify/delete user in application/DB. He is the one performing the independent code review and approval as well. I presume that will be an issue too, is this correct?



  • Can the finance VP be the owner for both IT and Data owner?
    Hi - It’s definitely better to have IT centralized and separate from the finance area. However, SOX itself won’t necessary mandate this. In fact, SOX 404 is supposed to work for de-centralized IT environments as well. I don’t see a problem with the finance VP having IT resources reporting to them, as long as underlying control approaches are in place to prevent folks from unchallenged fraud or accidents .
    There are a few weaknesses in the approach as shared. Still, I’m not certain if these points alone are materially weak enough to justify the move on their own merits. Even though there are just a few individuals supporting the IT fincancial systems environment, there are some checks and balances (e.g., with the DBA and Security Admin).
    The change management and production release controls process are probably the focal points for justifying moving these folks to a centralized IT environment, (rather than organizational reporting structures). For example, developers should not be releasing their own work without approval and a change control system is also needed. If the process is reasonably controlled from both a SOX and general IT audit perspective, I could see Finance keeping their small IT staff intact.
    Finally, the Finance area most likely desires it’s own dedicated staff, rather than competing with others for resources. There’s even an advantage to this, as they can keep the data and applications more confidential among fewer participants (e.g., I’ve seen this approach used at other companies, particularly for highly sensitive apps like Payroll or HR).



  • Totally agree with what Harry said.



  • It makes more sense to me right now. Thanks for the reply.
    One more question on the segregation of duties:
    Finance system support manager being the review and approving authority in areas of development and change management, also holds the role of a security administrator (super user access) in approving (together with approvals from user management) and implementing user access in application/database. That would be an issue I presume?



  • Ideally
    a person who administers privileges( or has access to do that) cannot carry approve privileges, as any misdeed done by the reviewer, as an administrator, would get overlooked.
    There is an SOD issue.



  • Hi - As the Finance system support manager (SSM) has multiple roles, I agree that SOD could be better done in this situation. Still, a company only has finite HR resources and in a small department, you sometimes have to do the best you can. I could actually see the current process working okay and not being a major material risk, as long as the SSM is not doing development work also.
    Where I see more of a SOX related issue, might be where the SSM can also write or change code in addition to their security/approver role. In other words, they could take programming changes or production transactions from ‘coast to coast’ in their regular job roles without checks-and-balances. You definitely don’t someone to be ‘chief, cook, and bottlewasher’ (e.g., developer, approver, and security admin – all in the same normal job role).
    As NP share, the ADMIN access can allow almost anything to take place. Even there hopefully there’s logging, documentation standards, etc., imposed if someone deviates from their normal job roles.


Log in to reply