Development access to operations 2209

  • Does SOX mandate any limitation on development resources having access to the operating environment. Specifically, how long (hours, days, weeks…)can a software developer have access to the operating environment when trouble shooting an issue? What are the SOX requirements in this area?

  • Hi Jeffrey and welcome to the forums 🙂
    SOX 404 itself is written a high generic level and doesn’t provide rigid or precise guidelines. The focus in the SOX documents is that management has placed appropriate security and other controls on finanical IT systems for risks that are determined to be ‘material weaknesses’
    Still, the lack of guidelines and standards between these two areas can pose some risks (even materially) to financial systems. Also, the SOX auditor is certainly going to strutinize this sensitive area. The close relationships between these two areas needs to be properly controlled. Below are some ideas:

    1. You may want to look at the COBIT 4.0 standards as they are often used by external SOX auditors as a checklist to evaluate SOX 404 compliancy.
      Free COBIT 4.0 guidelines after registration
    2. SOD (Separation of Duties) are always important controls for SOX, SAS 70, and other key standards. There should be a clear deliniation of roles and responsiblities.
    3. Published standards on how these two areas should work together in a controlled manner are always beneficial to define and helpful during an audit.
    4. Electronic card access and/or Sign-in logs should be established and enforced as warranted. Developers sometimes need to visit operational personal or even interact with servers to load data or software. Auditors often want to review electronic logs or guestbooks to ensure this is kept to a minimum and respresents appropriate developer physical access to the area.
    5. Good physical access controls are also beneficial.

  • Yes, from Segregation of Duty point of view, developer having access to production environment is considered to be one of key SOX control. The only way to prevent this is do not allow developer have access to production environment.
    However it may happen some time that due to small team size/ due to nature of operations like in your case for supporting/troubleshooting developer is having access to production, then one should have developer access to production justification document sign off by business and also one should implement detective control to review the activity log of developers on periodic basis to ensure that whatever activity done by developer were authorized to do.

  • Has anyone found any creative compensating controls that would mitigate this risk other than complete monitoring of the IDs?

  • The classic soluation is to have separate development, quality assurance and production systems with transports of changes from one system to the other. At least transports of changes from the QA system to the production system should be reviewed and electronically approved by a second person.
    The advantage of the solution is that you only need to review a few transports and can avoid unauthorized changes. The main advantage and the main control objective is that changes are first tested in the quality assurance system, which is populated with data that is comparable to the production system (i.e. the real world). Sometimes the QA system is populated with data that is periodically copied from the production system. Ideally an end user is doing a test in the QA system in order to determine whether the change fulfills the user requirements and is working as intended, he then communicates his OK to an IT manager who electronically approves the transport to the production system or initiates the transport (if the developer cannot initiate transports himself).
    If you still have emergency user-ID with development and customizing access to the procution system, there should be a clear policy when they can be used and the hopefully rare activity of those emergency user-IDs needs to be monitored by a second person.

Log in to reply