How can we control I.T. access to all transactions? 2054



  • My question relates to a comment that our consultant made recently regarding I.T.'s role in SOX. He mentioned that I.T. should ideally not have access to or the ability to make business transactions in the company. I think we can all agree that proper S.O.D. is essential, but how can this be achieved?
    Although our I.T. staff never do make transactions, their position as overseers of our ERP system put them in a situation where they can literally do (trasact) anything at any time they would like - accidentally or not. Of course, we would like to have an effective PREVENTATIVE control to mitigate this risk, but I do not know how we can control something over which I.T. has ultimate supervision. As far as I can tell, the best that we can do is to put in place a robust DETECTIVE control… which does not seem sufficient to me in terms of SOX compliance.
    Can anyone help?[/b]



  • Is it possible for your IT department to have read only access as opposed to transact for modules but still provide access as administrator?



  • That’s the problem. Since I.T. is the department that determines who has read-only access versus full-access, they could conceivably change their access privileges without anyone else knowing.
    Again, this could certainly be caught with a detective control, but it would be after-the-fact. We were hoping to figure out whether there are any conventions that we had not considered. We are hoping to implement a preventative control here, but it appears as though it might be impossible unless we grant administrative duties to other departments. However, naturally no other departments have the expertise to take this on.



  • He mentioned that I.T. should ideally not have access to or the ability to make business transactions in the company
    Hi Albie - I agree with the consultants concerns regarding IT’s ability to potentially craft fraudulent transactions based on ADMIN authority. Having worked in IT security for almost a decade and with a current interest, below are some thoughts:

    1. You definitely don’t want to grant ADMIN authority to any user area to oversee IT’s security actions. This increases risks and exposures far more so, than your current exposure for accidents to happen. There should be as few people as possible with domain admin authority.
    2. I would rate this concern as a low probability, (as most likely your IT security admins are loyal, trustworthy, etc.). Still, lightening can strike anywhere and we’ve all read about the ‘inside threat’ for employees to be tempted by the ‘dark side of the force’. Thus it’s important to mitigate the risks. Some ideas are as follows, that may or may not work specifically:
      – Capture key events related to the financial application in security logs where possible and practical (e.g., when read only access is changed)
      – Implement checks and balances within IT, where ADMINS take time out and review logs and question changes
      – Internal Audit should regularly examine controls on sensitive systems and the IT Auditors should review log history. An IT auditor working in that area would be better equipped than users to perform these types of checks
      – If you can add special application security controls to the OS security that helps (e.g., where you need special passwords or must use of security tokens). While the ADMIN can still do anything, it’s more difficult to manipulate the application directly to cut a check, etc.
      – Make sure you have strong security policies that discuss the consequences of fraud, so that it’s in everyone’s best interest.
    3. As everyone should ‘work for the same company’, designing IT control systems should be done without creating distrust and adversial situations (e.g., IT v. user areas). Still, there is a need to ‘trust but verify’ all highly privileged access rights and designing controls might be best done where one admin provides ‘checks and balances’ for another (or IT auditors can check things also).


  • Thanks for the comments, Harry.
    I fully agree with you on the need to avoid creating an adversarial relationship with our I.T. dept. Distrust is not a consideration here at our company (all I.T. employees here are loyal and trustworthy); I was just under the impression that strong controls would be required since ADMIN authority poses such a high risk throughout the various departments.
    We are a non-accelerated filer, so we have not yet had to pass a SOX audit, and we’re still trying to figure out what will pass muster and what will not. From what you’ve suggested, it appears as though strong detective controls should be sufficient.
    Many thanks for your help.



  • One of the strongest controls that you could have would be an activity log that cannot be edited (read only). This log should be reviewed by someone independent of the system administrator.%0AFrom a risk perspective, you cannot cover all risks with 100% certainty. At the end of the day, IT changes to production databases are probably pretty low risk as changes could create out of balance conditions or reports that do not make sense. These would be caught during account reconciliations, data foll-forwards by Finance, etc. You will, in effect, have controls that, when looked at together, will triangulate into solid assurance that everything is OK.



  • One of the strongest controls that you could have would be an activity log that cannot be edited (read only). This log should be reviewed by someone independent of the system administrator.
    I agree … At our company the members of the IT security team reviewed this. A good practice was to weekly rotate among individuals reviewing this. This way security admins got cross-trained, and a fresh set of eyes saw this each week (as it might become ignored or merely glanced over by a single individual doing this over a long period of time).
    Secondly, always make sure logs get reviewed as the IT security team is often very busy and after-the-fact reviews seem like processes that can be postponed in light of the priority requests in front of the team members.
    Finally, investing in some good reporting tools can also help. For highly sensitive areas it’s good to consolidate and filter on logs, so you can quickly find the ‘needle in the haystack’.



  • I’m not an expert when it comes to SOX from an IT perspective, but what we do here, is any time access requests are issued to certain modules that impact financial reporting, the IS department issue a risk acceptance form which has to be approved by me, the Group SOX Manager, before the chages can be implemented.
    This works here because I get to review the access and consider any SOD risk prior to approval, and as I am an accountant as opposed to an IS specialist, all access is appropriately monitored.
    The best approach to test that the control was operated effectively would be to review the changes made via an enquiry report and select sample incidents to ensure that appropriate approvals were obtained…



  • One of the strongest controls that you could have would be an activity log that cannot be edited (read only). This log should be reviewed by someone independent of the system administrator.

    Agree with this. Also agree with the approach Harry has suggested about setting up the filters to help in review. The logs can be copied real time to another log server where they can be reviewed on periodic basis. Most of the systems provide this functionality.


Log in to reply