I have a fully validated configurable COTS software system, but I’m struggling with how to organize the change control documents so that all of the employees of our numerous facilities can find things easier.
When the vendor releases a major upgrade (version 5.x to version 6.x for example), we perform a risk assessment, regression testing, IQ, etc. before using it in the Production environment. Should this paperwork be kept with the other less significant change control documents (configuration changes requested by the system owner, bug fixes, etc.)?
Currently, I keep the two types of documents (upgrades vs changes) in separate binders but that makes it tough to get a good chronological picture of all the changes made to the system. In other words, should major vendor upgrades be considered just another change to the system and lumped (in chronological order) with the other changes?
The downside to lumping them together is that auditors want to see when certain versions were installed. (That’s when they think the system should be “re-validated” - a term I don’t use). This makes it harder to find the upgrade documents.