Financial Software Updates from Vendor 2313



  • We are using third-party financial software for our public telco company.
    Our vendor pushes out regular changes and updates to its financial software customers, after performing its own change management procedures.
    Our IT function migrates the changes into production, but does not do any extensive testing since it was done by the vendor. Our SOX auditor is taking the position that extensive testing must be done in-house, even though we don’t touch the actual code.
    This level of testing would be extremely burdensome and costly for a small company.
    Any thoughts?



  • Hi Rob and welcome to the forums 🙂
    As an IT professional, I firmly believe in testing all changes - under the premise of ‘once bitten, twice shy’ 😉
    I agree with the auditor that even these vendor system changes, should be tested. However, since you don’t have ownership of the change process, the testing doesn’t have to be major in scope . In examining SOX and COBIT 4 controls, testing any releases to financial software (whether in-house or from a vendor supplied package) should be performed.
    I would suggest meeting with the auditor and hopefully compromising in setting up a standard test plan for the process. For example, it might include:

    • Testing security controls , and autonomy levels for the system (ensuring all financial control processes will work with the new software release is the most important
    • Entering and reviewing a few transactions in UAT or QA environment
    • Loading the production data base in test and ensuring that it will work with the new software (e.g., inquiry and data entry)
    • Running a few standard reports or extracts of the full system and comparing to production
      Hopefully, some quick dedicated pilot testing can be accomplished in just a few days and with minimal resources. The code base doesn’t need to be shaken down like an in-house system. However, vendors do make mistakes and thus if you can ensure all is well the user areas would benefit from a transitional perspective, from a brief but focused test of the new system.


  • Hi Harry,
    Your response is helpful, but pragmatic. If we keep using our current financial software we will have to incorporate some of those recommendations into our IT environment.
    Thanks again for your valuable input.



  • Harry, as usual, has provided excellent inputs.
    Testing of vendor provided changes becomes significant from the viewpoint of dependencies and variation in the environment.
    We are never certain abt the IT infrastructure being used by the vendor in which it carries out the testing for updates, It may be really strong or very weak.
    Its better to test the updates in the environment in which we operate and we control



  • How much access can I give the vendor(3rd party) to the test environment?
    Can I grant remote access to the test box?
    What other steps that i should follow?



  • Hi - Yes, SOX 404 doesn’t specifically restrict it. Certainly, you’d want this well controlled. I’d recommend some of the following, if you do decide to grant permissions to the vendor:
    – formal NDA signed by executives of both firms
    – Documentation and standards on what can and cannot be done by the 3rd party
    – Good VPN security controls (e.g., two-factor like SecureID) to better ensure no one else from the outside can ‘hack in’
    – Having previously performed Network Pentetration testing in the past, even TEST boxes should be made as secure as possible. Security is only as strong as your weakest link and even test boxes should be hard and crunchy on the outside, so that bad guys don’t get any footholds into your trusted network.


Log in to reply