Custom Database 2061



  • I have some question on SOX Testing. We have a custom Access database that we use for Project Management and Bulk inventory. It has been determined that it falls under the SOX application scope because it generates numbers that go into the ERP system.
    The Database has an MS Access front-end and a SQL back-end. The database is constantly being updated and changed to accommodate new company needs.
    Since this is a custom database and we only have one Access developer that has access to both testing and production. Is this going to be a SOX Nightmare ?What requirements is needed for custom Software to be SOX Compliant? Do we need a full process flow and documentation of the database? What type of questions will an Auditor ask?
    Thanks



  • Hi EMan - The SOX issues related in using Microsoft Access is similar to those for key Excel spreadsheets (i.e., you may want to search our forums on the keyword Excel).
    While the developer is most likely very trustworthy and issues haven’t surfaced, I can see the need for better SOD, Audit, and Change Control approaches. Accidents can always occur, and better checks-and-balances can help prevent these types of issues. Hopefully there’s a way of also achieving it, without adding too much overhead:

    1. Below is a general search that may offer a few ideas:
      General Search - paste to browser and add www
      google.com/search?hl=en-and-q=Microsoft Access SOX controls
    2. Establish TEST / PROD environments for the data base that is being used by MS Access … I couldn’t tell from the post if the back-end data base is SQL-Server (if so, this might help, as it offers a little better security and if not you may want to consider porting the data there)
    3. Establish Change Control System for the MS Access code used to query, view, or enter results (e.g., the code and forms piece). Maybe when changes are released, the official version of the code could be copied from TEST to PROD with the developer’s superviser or another ADMIN allowed to move the code across.
    4. The SOX documentation should be completed, since you have determined this to be a relevant application. However, I’d wait until after streamlining and better controls are formulated.
    5. I’d also recommend looking at the application with the developer assisting, so that you optimize the solution (e.g., don’t make the developer’s life too difficult, yet achieve the needed controls). In other words, gradually make the changes (and you may have to give the developer TEST/PROD access for a little while as you transition to a better solution).
      I don’t see this as a SOX nightmare and most likely some auditors could even miss this, if it’s not a substantial application. Still, it’s better to be proactive and ‘do it right’. Good luck 🙂

Log in to reply