Baselining of Legacy Systems 393



  • Has anybody out there collected any expierence with baselining of legacy systems? In theory I know what to do… at least what i should do. Every time i ask our ext. auditor what they expect me to do or what they could rely on I won’t get a usefull consistant answer. It seems to me that the big four are not sure about that topic. I would welcome any suggestions or even better some samples. Every material provided would be handeled strictly confidential.



  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • By baselining do you mean establishing a point where we can say that automated controls are effective and have been tested so that we can rely on general controls going forward?
    I have some expertise in this area but I’m not precisely sure what you mean.



  • We own a couple of systems which are somewhat of age (10 years or older). Actually we don’t have any information about these systems. Like eg functional specifications, change history. These systems are running ever since.
    Our approach would be like get the y2k or Euro Conversion tests to show that the systems are bascially doing what they are expected to do. Have the business functions selecting some typically cases, define the expectations about the outcome and have them running through the system. Document those tests and present it to the ext. auditors.
    The point is, that our ext. auditors don’t know or say what they would expect.
    I am acutally interessted what did you expierence out there. And what would even be better; if you could provide a sample.



  • We has something like this in my previous project - a UK Plc with PwC as auditors.
    The problem we had was primarily with Program change,or more specifically with the implementation many years before for which no documentationremained. Basically we agreed a point at which General Controls could be considered effective going forward - which involved some remediation first. After this point we could rely on Program Change as effective provided that the controls were tested and found to be effective.
    In order to determine the effectiveness of our IT controls we basically had to carry out a one-off exercise very much like User Acceptance Testing which then determined our baseline. In doing this we had to ensure that this UAT covered all of the automated controls and systems generated reports that we were identifying within our process documentation.
    Documentation of the UAT was not significantly different to what you would normally expect for this type of work.
    One unexpected advantage in this process was that we identified a number of automated controls that were not being picked up in our process documents that made our life easier when it came to tesing key controls.



  • Thanks Denis, that’s even simpler than what I thought of. How did you convince PWC to follow that approach?



  • The key to external auditor buy-in is to present things in language they understand. By showing that the general controls over the relevant applications were in place at a certain point in time there was no question that there was an issue from that point onwards.
    From there you only need to establish your basis for managements assertion up to that point - this is achieved through the pseudo-UAT I described. In addition to that we also did a certain amount of transactional testing (30 transactions I think) to prove that thre had been no issue thorughout the year.
    In a normal systems inplementation you demonstrate your basis for initial reliance by doing UAT at the point you implement the system - if you didn’t do that there would be a General Controls issue. Effectively we applied the same logic to demonstrate that it was reasonable for management to conclude that the sytem worked throughout the year.



  • I think that should do it. Thanks for the hint.


Log in to reply