Change Management - Scope 1408



  • I apologize in advance if this is a repost.
    I’m trying to create a reliable, sensible definition for what application changes to financial applications or infrastructure changes need to be run through the change management approval and testing processes for SOX. This definition would be used by the organization’s various IT departments to distinguish between true, SOX impacting changes that require change mgmt oversight, and nominal changes (ie. changing the title of a report only) that may bypass the change management process rigor.
    I’m thinking that the definition need to tie back to the potential impact of financial data, but I’m having a tough time with verbage that provides real guidance to IT management having to make this distinction.
    Any help or guidance would be appreciated.



  • See Page #13 in the following document:
    http://www.iai.es/upload/doc/GTAG-2[1].pdf
    4.1 What Is the Scope of Change Management?
    This guide focuses on IT operational change management, beginning when upgrades or updates to IT assets (infrastructure, applications) are identified for movement to production (e.g., from either an application development or research and development (R-and-D) team) and ending when such assets are retired from the production environment.
    This includes application maintenance and emergency change controls. Specifically excluded are the changes that occur during software design and development. The term, change management, as used in the guide, excludes the process of configuration management. Configuration management is concerned with identifying, controlling, maintaining, and verifying the versions of all IT components (hardware, software, associated documentation) [ITIL 00]. However, the change management process must interact with the configuration management process (and companion controls) when changes are made to configurations.
    If someone has a better definition that is written in plain English, that would also be helpful.
    Regards,
    Milan



  • If someone has a better definition that is written in plain English, that would also be helpful.
    For Change Management only – a more simplified view is to make All changes to the production environment subject to change management procedures 😉 🙂
    It’s beneficial to design a standard approach, as long as it’s efficient – whether the application or area of change is directly or indirectly affected by SOX requirements. This way folks don’t have to think and perhaps miss or become lax in following guidelines.
    For example, I like the idea of tiered levels of change management procedures, if they aren’t already in place as follows:

    • Change Management Level one - Ordinary day-to-day production releases with appropriate separation-of-duty controls and communications to appropriate parites (e.g., standards for daily program releases to production, balancing controls for automated systems, routine workflows related to financial processing, etc).
    • Change Management Level two - Communications of major events via change management, (e.g., Major new systems being implemented, Major application releases, Special handling for Financial statement approvals, etc). This is usually to a higher level audience, who would benefit from knowing about major events rather than day-to-day normal changes.
      On the sampling/testing side, the wording is nebulus and subject to interpretation. Many financial systems and workflows associated directly with SOX compliancy can be identified, as they are obvious. However, there are also indirect system relationships where a front-end system may feed the accounting/financial system ultimately on the back-end.
      Some ideas might include:
    1. Performing an application system inventory (looking specifically for SOX compliancy needs and relationships)
    2. Work with internal or external auditors in determining whether sampling is required for the ‘gray’ areas. This is still a judgement call, but having some 2nd opinions on record would be helpful, in case a future SOX compliancy audit cited the failure to test.
    3. When in doubt and there appears to be a SOX relationship, you might add that to the testing list (as long as it’s not too costly or involved)

Log in to reply