Demoted By SOX!

Yes, SOX is truly fantastic. Our auditors have decided that I have too much access and too much understanding of our information systems. Accordingly, I have been asked to lock myself out of all production systems. Yet, since I handle all enterprise application upgrades, I get to perform all upgrades / testing / troubleshooting in a development environment, only to create an upgrade document for my management staff so they can perform all production upgrades.

Won't tier 3 support be fun when I'm locked out of our production systems! Anyway...enough griping.

I am hoping the list may have a suggestion on how to do this with JDE. Luckily, ESU installations are cake. However, I have been asked to make it so I can load ESU's into planner, intall into DV7333 and PY7333 pathcodes, BUT be unable to load the ESU into PD7333.

Anyone have any ideas? Would I have to use table level security?

I have considered trying to negotiate with the auditors and changing the scenerio for JDE. Maybe we should require that a manager load the ESU into the planner pathcode and then I will merge it into the other pathcodes. This would accomplish what the auditors want - a guarantee that nothing was installed that management doesn't know about.

My problem with the above scenerio is that by locking down the deployment server so tightly that I can't execute any *.exe files (ESU's come as self extracting *.EXE's) on the deployment server, I won't be able to properly run OneWorld on the deployment server for the planner and deployment pathcodes.

How are others out there dealing with this?????

Thanks in advance.

Rather than being "Demoted by SOX", why don't you get "Promoted by SOX"... Work it out so that you get the appropriate management title that enables you to do your job appropriately...

Just a thought...

"Demoted by Sox"

I thought you were talking about the Yankees....

It's a tough situation - especially for smaller companies that don't have the luxury of a large ERP staff.

The key is to have a high-level person review what the ERP administrator is doing.

You do have to negotiate with your auditor. Perhaps your ERP Administrator could have a separate login to be used when a high-level of permissions is required to perform a task. This login would have logging enabled, to a network folder where NTFS auditing is enabled.

This log file is then periodically reviewed by an IT manager.

I have not thought this all the way through yet, but again - the key is to have some type of activity review and to take steps to assure that the Super User cannot cover their tracks.

Ryan,

Our entire company is undergoing through this exercise. We have come up with alternate process to tackle this situation. While SOX clearly states that it does not have problem with development/support personnel accessing production, it strongly is against "unrestricted" production data/code/job access to dev and support people.

The way we have approached this control is by coming up with a new process. We have made a list of critical applications (read as ALL!), and created functional userid's to access them. The password for these functional userid's reside with the 24X7 SSC (like a tier 1 helpdesk - highest level). Whenever i would need access to an application like JDEdwards, they would reset the password for it, and provide me access for 4 hours. If I need an extension, I simply call and get an extension, else after 4 hours, access is withdrawn. The managed helpdesk has a list of pre-approved personnel who can request access to assigned applications.

Believe me this does feel like a choker, but its much better than not being able to get on to production. And, this is SOX Compliant!

Hope you can talk your management in following so.

Thanks
Yogi