GAMP Good Practice Guide: The Validation of Legacy Systems

1 Legacy SystemsNOVEMBER/DECEMBER 2003 PHARMACEUTICAL ENGINEERING1 Copyright ISPE 2003 GAMP good Practice Guide: The Validation of Legacy SystemsThis Guidediscusses theconsiderationswhich shouldexplain thisactivity andsuggests aprocess to befollowed inorder to assessand view of the rapid evolution of both newtechnologies and regulatory expectations overrecent years, it is crucial that pharmaceuticalorganizations take positive action to maintaintheir existing cGxP-related Systems in a vali-dated state. This guide discusses the consider-ations which should explain this activity andsuggests a process to be followed in order toassess and validate Legacy is a Legacy System?There is no formally accepted definition of Legacy System, but for the purposes of thisGAMP good Practice guide (GPG), a LegacySystem should be considered to be any GxPrelevant system that is in place and in use, andwhich is deemed not to satisfy current regula-tory is not acceptable under any circumstanceto implement a new system that has not beenvalidated.

2 Legacy System Validation is notequivalent to prospective Validation and is notan option for new Systems . (Ref: PIC/S PI-011-1.)3 Typical Issues Encounteredwith Legacy SystemsThere is a risk that a Legacy System, which hasnot been the subject of a recent validationprogram, will fail to comply with current regu-latory expectations, , 21 CFR Part 11. There-fore, there is a need to review existing systemsfor compliance. Typically, the issues are asso-ciated with: ownership of the system Validation package security system functionality data integrity archiving of of the SystemThe owner of a Legacy System has the respon-sibility to ensure that: the system continues to be relevant to the(GxP) process being supported the operating procedures are up-to-date user training is sufficient to maintain thecompetence of the users a formal change control procedure is in placeand is followed any necessary maintenance agreements,( , Service Level Agreements,) are in placeand validEssentially, the owner of a Legacy Systemshould ensure that an appropriate validationpackage this age of mergers, acquisitions, divest-ments, outsourcing, and reengineering of orga-nizations, operational responsibilities are fre-quently reorganized.

3 As a result, the ownershipof existing Systems may become poorly definedor unknown. Without a formal and controlledhand-over process, it is unlikely that the knowl-edge associated with a particular system willbe passed to the new owner, or even that theby the ISPE GAMP ForumReprinted fromThe Official Journal of ISPEPHARMACEUTICAL ENGINEERING November/December 2003, Vol. 23 No. 6 GAMP good Practice Guide2 PHARMACEUTICAL ENGINEERING NOVEMBER/DECEMBER 2003 Copyright ISPE 2003 Figure 1. Legacy Systems Validation SystemsNOVEMBER/DECEMBER 2003 PHARMACEUTICAL ENGINEERING3 Copyright ISPE 2003location of critical system documenta-tion will be made known to the incoming owner must take appro-priate steps to identify those systemsunder his ownership.

4 When a systemhas no owner, it will fall into an uncon-trolled is, therefore, critical that the sys-tem owner be clearly identified,whether an individual or a representa-tive team accountable for widespreador enterprise PackageIt is usually the case that documenta-tion associated with Legacy Systems isno longer up-to-date or complete. TheLegacy System may have been vali-dated to an earlier regulatory expecta-tion that is no longer adequate. Withchanges in the use of a Legacy System,parts of the system documentation mayno longer reflect accurately what thesystem does, how it does it, or how itshould be used. All such issues need tobe remedied in a Legacy System vali-dation program, which should producea Validation package for the required Validation packageconsists of the system documentation,together with the qualification docu-mentation, fronted by a Validation Planand concluded by a Validation Sum-mary DocumentationIn the context of this GPG, systemdocumentation should be regarded asthe live documents, such as specifica-tions ( , URS, FS, design/configura-tion specifications, source code), Re-quirements Traceability Matrix, Stan-dard Operating Procedures (SOPs)

5 ,user reference manuals, and Help the application of a formalchange control procedure, the live documents will fail to represent thesystem provides the documen-tary evidence that the system doeswhat it is supposed to do, accuratelyand consistently. For Legacy Systems ,the qualification documentation maynot be available or may not be ad-equate in terms of current regulatoryexpectations. Existing documentationalso may have failed to incorporate thequalification of any changes that havebeen made to the system since it wasfirst is frequently an issue withLegacy Systems ; particularly with theadvent of ISO17799, there is an in-creasing focus on the physical and logi-cal security of the system and its Systems which contain electronicrecords and are subject to Validation ,must be able to demonstrate that ac-cess to the system is properly also is a requirement that, whereappropriate, there are multiple levelsof security, , users may have differ-ent access rights from supervisors, whoshould have different access rights fromthe system administrator.

6 The way inwhich access rights are granted alsomay need to be relating to security are ad-dressed in the good Practice and Com-pliance for Electronic Records and Sig-natures, Part 2: Complying with 21 CFR Part 11: Electronic Records andElectronic Signatures and in GAMP 4,Appendix FunctionalityChanges to regulations or their inter-pretation may have caused the capa-bilities of the Legacy System to beregarded as inappropriate or inad-equate. For example, the Legacy Sys-tem might not have the capability torecord audit trails that are now re-quired for compliance with 21 CFRPart increasing concern about thecontrol of electronic records and signa-tures, the availability of audit trailshas become a prominent issue.

7 Theaudit trail needs to record who didwhat, when they did so, and retain theoriginal value for any altered data;again, this is addressed in the GoodPractice and Compliance for ElectronicRecords and Signatures, Part 2: Com-plying with 21 CFR Part 11: ElectronicRecords and Electronic Legacy Systems do not have anaudit trail facility although some willprovide a transaction history for a lim-ited number of batches and then over-write that are issues to be addressedwhen reviewing the status of LegacySystems and deciding appropriate ac-tions to remedy those issues in order tobring the Legacy Systems into compli-ance with current regulatory IntegrityWhere a Legacy System failed to dem-onstrate the accurate and consistentcapture, change, and retention of dataduring a prior Validation effort, and forsystems which have never been vali-dated.

8 It may not be possible to showthe integrity of the data now residingwithin the Legacy of DataData archived from the Legacy Systemis often overlooked, but must be re-tained in a secure and accessible man-ner. Further guidance is provided inGAMP 4, Appendix O6: Guideline forRecord Retention, Archiving, and of LegacySystemValidationThe objectives of validating a LegacySystem are fundamentally the same asfor prospective Validation except that,being accomplished after the system is in place and in use, some elements ofthe Validation process have objectives of Legacy Systemvalidation include: to ensure that the Legacy Systemproperly supports the process to ensure that the Legacy Systemhas been properly installed, is oper-ated correctly, and that proceduresand practices are in place to allow itto be maintained in a state of con-trol throughout its useful life to establish a complete set of systemdocumentation providing a precisedefinition of the operating environ-ment, functionality, hardware andGAMP good Practice Guide4 PHARMACEUTICAL ENGINEERING NOVEMBER/DECEMBER 2003 Copyright ISPE 2003software, procedures, and referencemanuals associated with the LegacySystem to provide indexes to the documen-tation set ( , by the use of trace-ability matrices for documents anduser requirements)

9 To provide a framework to demon-strate regulatory compliance5 Benefits of LegacySystem ValidationUndertaking Legacy System valida-tion has valuable benefits and shouldnot be perceived as having regulatorycompliance as its only objective. Thesebenefits include: assurance that the system is fit forpurpose and relevant to the processthat it supports, from both a busi-ness perspective and a GxP perspec-tive understanding of the actions re-quired to achieve compliance withevolving regulations, , 21 CFRPart 11 enhanced confidence in the engi-neering of the Legacy System demonstration that users are com-petent to operate the Legacy Sys-tem to an appropriate level and areprovided with approved procedures provision of a baseline from whichto manage change control potential to reduce system mainte-nance costs6 Typical Process forLegacy is assumed that a Validation MasterPlan (VMP) (see GAMP 4, AppendixM1)

10 , or equivalent document, alreadyexists and formally identifies theLegacy Systems under review. As aninitial step, this document should bereviewed and updated to ensure that itincludes all Legacy Systems and refer-ences all Legacy System 1 shows a typical process forLegacy System Validation . This pro-cess is detailed in Sections - Analysis and RiskAssessmentOnce the inventory of a Legacy Systemis in place, a Gap Analysis can be un-dertaken, which should be conductedagainst the V-model, shown in Figure2 and include a review of the ChangeControl history for this system (seeGAMP 4, Figure : Basic Frameworkfor Specification and Qualification, andGAMP 4, Appendix M4: Categories ofSoftware and Hardware).