Legacy\old Finanacial Apps 2164

  • What if a company were to uses a financial application that no longer is no longer supported by the programmers(co.).
    They have backups and can restore the application on a new server as well as restore the data but isn’t that a risk in itself?

  • this is an inherent risk with acquired application. Lack of vendor support is considered as one of the biggest scalability issue.
    the option that we have is to change the application as suggested by the vendor.

  • Hi - NC shares some good insight and below are some additional considerations:
    Some factors for Risk Assessment

    1. Does customer company have the source code? or rights to it from the vendor (esp. if not supported)? If not, are there risks associated with changing the technical foundations (e.g., new hardware, new operating systems, etc.) For example, if the application was only certified for Windows NT 4.0, companies could not easily move that particular application to Windows 2003 (or the new 2008) server environment.
    2. Is there a newer version of the software product that can be migrated to from the legacy system? If there is a bridge from old to new systems, it doesn’t have to be crossed immediately to satisfy SOX. It would represent a future solution for this risk (as one must weigh conversion and product costs – still there’s a cost for obsolence as well)
    3. Is the legacy system static? Most table or parameter driven applications can keep up with some change. However, is it keeping up with business needs, regulatory changes, etc. effectively?
    4. Are there any major outstanding issues with the accuaracy and reliability of the outputs (that are currently uncorrected)?
      Every company has both old and new applications. There’s nothing wrong with a legacy system as long as it’s accurate, reliable, and can be maintained – so it meets business/statutory needs. The inability to support a critical financial application should be seen as a business and even SOX based risk by management (who are ultimately responsible for SOX compliancy)

  • I would add one additional thing to the comments listed.
    Usually the security tables are included in the backups. If you ever restore from those tapes or media then you may be placed in a condition where user access is inconsistent with what is currently authorized OR you may be in a condition where the most powerful users as identified on the backup tape are no longer with the company.
    You should be aware of the security files / modules that exist within the application and the repercussions of restoring from old files. If this is an important application, then the best time to identify the effects of the action would probably be during something like a disaster recovery / business continuity test where the conditions could be controlled and there is no impact on current operations.

Log in to reply