Excerpt from Technical Guide: Computer Validation Master Planning

2. Developing the Computer Validation Master Plan

   The master plan should be developed early in the life cycle, with input from the targeted user community, the quality unit (regulatory/compliance), and the information technology group responsible for the system (development and support personnel). If the personnel that will maintain the system in production are different than the personnel responsible for implementing it, the former should also be represented. Although not always closely involved in plan development, it is critical that the system owner or sponsor (management of the business area the system will support) understand what is documented in the plan and be an approval authority.

2.1 Timing
   Anyone familiar with a basic Software Development Life Cycle (SDLC) knows that the first phase is planning. Why is it, then, that so often the technical project planning is performed at this stage, but validation planning doesn't get addressed until after the software is developed or acquired? Validation master planning should begin at the concept and planning phase of the system life cycle. In fact, if the validation process is adequately interwoven with the system life cycle, as in the quality systems approach, there needn't be two separate plans. This timing approach also enables the master plan to address early activities, such as vendor evaluation and selection, which can be such critical components of the overall computer validation approach.

2.2 Templates
It is beneficial to invest the time to develop a computer validation master plan template. In fact, it is well worth the initial time investment to develop templates for all of the required validation deliverables. Not only does it promote completeness and consistency across systems, the templates can be developed so that when they are used properly, compliance with the company's internal validation SOPs is practically guaranteed.
    Controls around the use of deliverable templates must be clearly defined, and training on their use must be provided. It is also important to note that the use of deliverable templates does not mean that every computer validation will be conducted in the same way. There still must be a thorough review of the deliverables by the cross-functional validation team members to ensure that the deliverable content is appropriate for the specific system being validated.    Once a template is available, a good rule of thumb is to allow deliverable authors to add content to the standard template content in their own documents. But for deletions of standard template content, it is a good idea to require the deliverable author state "N/A" in the given section and provide a rationale. The reason for this is because if the section is merely deleted, it could raise questions in a reviewer's mind as to whether the topic was just forgotten or ignored.
    A suggested computer validation master plan template is provided with this Technical Guide starting on page 36 and is also provided on disk. Since many companies develop their own systems internally, the template is written to accommodate this approach, but it can be easily modified for use with a purchased system. For those who prefer the IQ, OQ, PQ validation approach, this template can provide a baseline from which to create an internal template more suitable for that approach.
    Finally, there is no need to internally re-document information that the vendor can supply. If the system will be wholly or partially vendor-supplied, leverage any vendor-supplied documentation by referencing it (by title, version, and date) in the relevant deliverable and section and providing the required context for the reference. More information on the assessment of vendor work and the use of vendor documentation is provided in the section of this Technical Guide entitled Vendor Selection and Management.

2.3 Some Helpful Logistics
   Depending on how comfortable the involved personnel are with working electronically, providing input and review to the draft validation master plan can be done in a very time-economic way. Assuming a cross-functional validation team exists, someone on that team should create the first draft of the computer validation master plan, using a template if one is available. The draft can then be distributed electronically to all relevant parties for review and input. Once the author has received input and incorporated the comments that need no further discussion, actual meeting time can be limited to resolution of controversial topics and/or clarification of issues. If available, a laptop computer can be brought to the meetings so changes can be made on-line as they are agreed to. The revised draft can be sent out for review and input as many times as it takes to reach the final version. Since impact on peoples' schedules can become an issue when developing a document of this depth and breadth, this small effort at minimizing that impact can help a great deal.

2.4 Approvals
   Document approvals are, of course, company-specific. However, if the cross-functional validation team approach is used, it is suggested that the approvals minimally include the validation team members and the system owner.

2.5 Document History
   It is critical to maintain a revision history of the master plan. This is especially important after the document has been approved with signatures and dates. But even prior to this point, it is helpful to version the drafts of the document during the review process. Simply placing a static date in the footer of the document and changing it at each new draft can accomplish this. After signed approval of the master plan, however, it is considered to be a controlled document, and a formal revision history must be maintained.
   Master plans are typically updated during a system requalification activity, when the initial validation activities are repeated due to a major change to the system. In the interim period, however, an amendment may be required to address changes to the initial strategy. An example of something that would prompt an amendment to the master plan may be a change in vendor status that changes the vendor management strategy originally documented in the plan.

The following sections provide the suggested content for the master plan.

3. Components of the System Validation Master Plan (SVMP)

    The components of the SVMP work together to provide the total picture of the system's nature and scope, how it will be validated, and how its validated state will be maintained. One of the most critical goals of the system validation master plan is to convey the scope of the system being validated - what it includes and what it does not include. Today's information systems commonly comprise many components and often interface with other systems. It is very important to draw the boundary around what the system is and what is being validated under the plan being written. If this scope is not clearly conveyed and a logical rationale provided, reviewers or auditors may formulate their own idea of what should be in the scope. This can cause an unwanted and unnecessary dilemma in an audit situation.
    The great thing about a well-written master plan is that, together with the validation final report, it often provides enough information about the system and its validation that the other documentation may not require review in an audit situation. (Of course, it is still wise to prepare and execute these lower-level deliverables with diligent attention to regulatory requirements, as well.) The suggested main topics or sections in the SVMP are reflected in Figure 1. The remaining sections of this Technical Guide will explain each topic or section in detail...