Supplier Audits standard software providers

Supplier audits must establish whether such contiguration management requirements are implemented by the supplier organization. Experience shows that rarely are all controls applied. However, there is an increasing use of standard contiguration management products that provide access control and modification of software, contiguration, and documentation tiles. 

Server Application Application software products such as the MRP II software product. GAMP level 4 software requiring a supplier audit, validation of the configuration, and confirming the operability of the standard element of the software (e.g., SAP R/3). There may also be some standard software such as GAMP level 3 requiring the version to be recorded and operability confirmed (e.g., third-party utilities provided with the server application). 

Client Applications A client may be used for more than one application (e.g., MRP II, LIMS, and EMS). Each application will have an associated file set providing what is often referred to as its Graphical User Interface (GUI). File sets are usually built into standard client set-ups. Individual files may include some element of configuration. GAMP level 3 (e.g., Windows NT) and GAMP level 4 software require the version to be recorded, operability confirmed, and any configuration validated. Supplier Audit requirements are usually satisfied as part of the server application validation. 

Howard Garston-Smith, formerly of Pfizer, has published a book on software quality assurance. It provides a postal audit checklist reproduced in Appendix 7C. If the supplier has already prepared an internal ISO 9000 mapping or an internal audit report on how it aligns to industry standards such as the GAMP Guide, this can be offered as an alternative to the auditor s postal checklist. A reduced postal checklist may be agreed upon, at the very least. Wherever possible, photocopies of actual example documents and test records should be inspected for documentary evidence of validation. Remember that the pharmaceutical and healthcare companies are themselves being inspected for documentary evidence of validation. 

The key to the process is to understand the system that is being proposed. It is good practice for the auditor to spend time reviewing the User Requirement Specification and the system descriptions and understanding of what software categories exist for the proposed system. This should be followed up, with the postal audit checklist. This will also provide valuable information to enable the auditor to plan the audit. Available information should be used to customize the audit checklist to address the specific issues that are relevant to both the supplier and proposed project. Consider, for example, a system that includes hardware and software, where some of the software is custom, other parts are configurable and yet others are part of a standard package. The auditor will need to establish how each part of the system will be developed, and how the build phase will be controlled. There may even be more than one supplier. The auditor would need to split up the main elements and examine how each part of the system will be built. 

---