Restricting access to production 505

  • I am trying to satisfy the following control:

    ‘The duration of time for opening the production environment to perform direct changes is monitored and restricted. Exceptions are documented and approved by management’
    The main problem is that there are two applications with one developer/support analyst for each. We can put some controls in place for programme changes. We had having problems with proving that there are controls over direct data changes (these are old legacy systems shere some problems can only be fixed by direct changes to data).
    Would a control based round helpdesk tickets and approvals suffice?
    Any views welcome

  • Sounds like you already have the control, but you need to demonstrate the evidence.

  • Thanks but I am concerned that the controls are not tight enough as we cannot detect unauthorised changes. Perhaps we are trying too hard to make things watertight am have to get management to accept some level of risks.

  • you are correct in that this control is weak.
    as a temporary solution, perhaps you can consider something like:

    1. when ‘data diddling’ in production is your only option,
      • require a helpdesk ticket to be opened
      • require the programmer/analyst to be assigned to the ticket to perform analysis on what should be changed
      • capture evidence of the problem, this can be a file comparison or screen print or something that can be attached to the help desk ticket
      • backup the production file before making changes (this gives you a point to restore to just in case it gets screwed up)
      • review the proposed data changes with an IT and/or user manager (show them the problem and screen prints) and get their approval
      • make the change to production data and caputre/keep an audit trail
      • you can even compare the production file (after the change) to the backup taken previously to prove that only xx records were changed
      • document all of this in the help desk ticket
        longer term it would be helpful to look at implementing a solution to what is causing the data issues

  • i think everything that ugogirl mentioned gets you on the right path to providing your SOX auditors reasonable assurance over the significant application.
    Good overall entity level IT controls along with adequate financial controls in place to assess the outputs of the application are helpful as well. Example being, if the application has some weaknesses in the general IT areas (like program change), we need to evaluate reliance being placed on the application. If we depend on reports generated from that application, are the reviewers of the report performing reasonability tests/comparisons/reconcililations on a consistent basis?
    What might help logging is issuing firecall IDs to those people who must access production for certain purposes, but should be otherwise kept out.

  • It is not right to say that you have a legacy system and that forces you to directly change the file/data. There are ways to change the data without directly changing the file. Think about it…
    ugogirl - excellent post.

  • The steps mentioned by ugogirl is a age old solution but nicely captured. hard to belive that the we have to reinvent the wheel for the current generation of techies

Log in to reply