Software Master Validation Plan All You Need to Know!

The validation plan is a strategic document that should state what is to be done, the scope of the approach, the schedule of validation activities and tasks to be performed.

The plan should also state who is responsible for performing every validation activity. Once reviewed the validation plan should then be signed off by the associated project team members.

The Validation Project Plan (VPP)

Validation plans are documents that express the philosophy of the company and how they intend to establish a working model for the project at hand. Validation plans state who is responsible for performing development and validation activities, who identifies which systems need to be validated and who identifies the nature and extent of the inspection and testing expecting for each system and who outlines the framework to be followed to accomplish the validation.

In general the project validation plan describes the organization, activities, and tasks involved in the development of a computerized system including:

  • Organizational structure of the computerized project
  • The departments or individuals responsible
  • Resource availability
  • Risk management
  • Time restrictions
  • The SLC and methodology that needs to be followed
  • Deliverable items
  • Overall acceptance criteria
  • Development schedule and timeline
  • System release sign-off process
  • Sample formats for key documentation

Verification of Documents

During the execution of a project, verification will check the reliability of the work as established by the project plan so that when the due dates for completion or handover arrive a high degree of certainty exists that the system is fully validated.

When multiple departments are involved in a project, the system owner will take responsibility for the validation documentation. Other department will provide documentation and personnel to support the development, validation and maintenance effort.

Predicated Regulations

Validation plans are not required by any of the predicated regulations but are considered a key project management practice. Validation plans are an essential documents for the overall management of projects, and are crucial for the success of the project.


Typically, managers their peers, end-users, and those responsible for delivering the system, approve validation plans. Quality assurance may also sign the document. The validation project plan and the requirements specification deliverable, together define the technical and regulatory requirements applicable for a project.

When to Start the MVP

Project validation plans should typically start during the early stages of the project, its usually the first document that will get attention. Initial project concepts and planning estimates should be elements in the creation of a project validation plan.

The initial project verification activities will assess the project teams capability to produce a validated system and provide input for defining the level of testing effort expected. Project verification will identify any critical deviations to the expected project timing and quality levels, as well as other issues affecting the timely approval of the validation report.

Approved Version

An approved version of the validation plan should be available when a computer technology supplier or contract developer is being selected, and should be updated whenever project events or verification results require a change.

Documents that support the update of the validation plans are:

  • System requirements
  • Criticality and complexity analysis
  • Project verification results
  • Other system descriptions

Validation Plan Format

The format of a validation project plan is flexible and may incorporate Gnatt charts. The contents of the validation plan may include, but are not limited to the following list:

Document Control Section

  • System/Installation name
  • Author(s)
  • Creation, save and print date
  • Version number
  • Document identification
  • Reviewer and review date
  • External document references
  • Table of contents
  • Intended audience
  • Scope
  • Objective
  • System description
  • Validation acceptance criteria
  • Verification activities and deliverables

Qualification Activities and Deliverables

  • Qualification planning
  • Project verification
  • Installation qualification
  • Operational qualification
  • Performance qualification
  • Process validation (if applicable)

Roles and Responsibilities

  • Application owner
  • Project management
  • QA
  • Validation team
  • Computer technology supplier or contract developer

Project Schedule

  • Project activities
  • Project documentation and delivery

Plans and Protocols, How Many?

When developing the validation plan, a decision has to be made about the manner in which the documents will be organized.

Small System

For small systems, it is possible to integrate the validation plan and all protocols into one document, and have one report to summarize all results.

Large System

For large system with many components, a validation project plan can be created that divides the validation effort into smaller, more manageable units with separate plans.

Multiple versions of the plan and protocols could be needed, with intern or partial reports.
The review and approval of the plan by QA is optional, but will provide an endorsement that the plan conforms to the current written procedures on computer systems validation, and that the document incorporates applicable regulatory requirments.

Validation Schedule

Validation plans and associated schedules are live documents that should be reviewed periodically. It’s a good idea to designate the system owner to ensure that the plan is always current.

As part of the conceptualization period, senior managers are presented with , and estimate the total effort to be expended (including maintenance for the project). Maintenance of existing software can account for over 70% of all effort expended by a software organization and this cost will be passed on to the customer.

As part of the schedule, it should be considered that the majority of the development of computer systems fails due to poor gathering of requirements. An investment up front can yield notable savings later.
The following list is a good example of items that need to be tracked as part of the project schedule.

  • Project kick off
  • Validation plan preparation, review and approval
  • Training of the validation team
  • Applicable SLC periods and events
  • Quality checkpoints for review
  • Project documentation due dates
  • Supplier or contractor developer audits
  • Development and approval of procedural controls
  • Specific plans and protocols for IQ/OQ/PQ
  • Development of traceability analysis and verify the traceability of design and testing elements against user requirements
  • Monitor the execution of specific protocols
  • Assemble, review and approve the results
  • Assemble, review and approve the final


  • Dr. Narayan G K A S S

    This is a new interactive format that is very ueser friendly.

  • suresh Garg

    Please send format

  • Duchnicz

    please, send me an example on electronic VMP. Do you have any other softwares for other validation documents ?

  • Navdeep Singh

    this is really an elaborated and useful information

  • Mohan Dass

    give me an example of a good validation report

  • Ranjit Barshikar

    This is excellent. It will help to all concerned in a big way if implemented.

  • mattossa

    An article of high value; thanks for your contribution.

  • Gilbert249

    Kindly share the format with me. Thanks a lot!!

  • Mohamed Orouk

    please, send me an example on electronic VMP. Do you have any other softwares for other validation documents ?

  • Please send me the copy of VMP. It will be very helpful. Thanks.

Similar articles:

The Difference Between Qualification and Validation [Video]

There is a general saying within the life sciences:

“We qualify a system and/or equipment and validate a process”

A system and/or equipment must be qualified to operate in a validated process.

For example:

“You qualify an autoclave, whereas you validate a sterilization process”

Manufacturers should identify what validation and qualification work is done. All systems, equipment, processes, procedures should be reviewed and the manufacturer should decide what qualification and validation work needs to be performed.

Direct, Indirect or No Impact

All facility areas, utilities and process equipment must be assessed and classified as direct impact, indirect impact or no impact following an analysis of their impact on the identity, strength, quality, purity or safety of products manufactured at the facility and also the safety of the operators & environment.

Impact on Quality

Each system or item of equipment having direct or indirect impact on the product quality must be validated. The extent of validation or qualification should be determined by performing the risk assessment of that particular system or equipment.

Join the Discussion

Use our community to find our more about validation and qualification.


Similar articles:

The Difference Between Prospective, Concurrent and Retrospective Validation

Unless you’re starting a new company you will need to plan on a variety of approaches.

Prospective validation occurs before the system is used in production, concurrent validation occurs simultaneously with production, and retrospective validation occurs after production use has occurred.

In this article we will discuss all three and also discuss the role the master validation plan (MVP) performs for each one.

1. Prospective Validation

Prospective validation is establishing documented evidence, prior to process implementation, that a system performs as is intended, based on pre-planned protocols.

This is the preferred approach.

Production is not started until all validation activities are completed.

The MVP need not go into much detail about this approach since it’s the standard method, however, prospective validation follows a step wise process illustrated here.

The process commences with the development of a Validation Plan and then passes through the DQ, RA, IQ, OQ and PQ phases after which process, computer, analytical and cleaning validations are performed which are followed by a final report.

After which the instrument or equipment will be subject to preventative maintenance and requalification on a routine basis.

Periodic Basis

On a periodic basis all instrumentation and equipment should be reviewed. This review is intended to identify any gaps which may have developed between the time it was last qualified and current requirements.

If any gaps are identified a remediation plan will be developed and the process will start again.


The MVP may need to describe what is done with product produced during prospective validation. Typically, it is either scrapped or marked not for use or sale.

The product may be suitable for additional engineering testing or demonstrations, but appropriate efforts need to be made to ensure this product does not enter the supply chain.

Ideally, all validation is done prospectively; i.e., the system is validated before use. However, there are cases and conditions which may prevent this.

2. Concurrent Validation

Concurrent validation is used to establish documented evidence that a facility and process will perform as they are intended, based on information generated during actual use of the process.

In exceptional circumstances (for example, in a case of immediate and urgent public health need) validation may need to be conducted in parallel with routine production. The MVP needs to define how product is managed throughout the process.

Typically, the product batches are quarantined until they can be demonstrated (QC analysis) to meet specifications.

The Right Decision?

The decision to perform concurrent validation should not be made in a vacuum. All stakeholders including management, Quality Assurance and the government regulatory agencies should all agree that concurrent validation is an acceptable approach for the system under consideration.

As always the principal requirement is patient safety is not compromised. The rationale to conduct concurrent validation should be documented along with the agreement to do so by all the stakeholders. This can be part of the Validation Plan or documented as a deviation.

The Process

The concurrent validation process is identical to that of prospective validation. The process starts with the development of a Validation Plan, followed by the DQ, RA, IQ, OQ and PQ phases after which process, computer, analytical and cleaning validations are performed, ending with a final report.

Again, routine preventative maintenance, requalification and periodic review are performed.

3. Retrospective Validation

Retrospective validation is validating a system that has been operating for some time. There are various schools of thought on how to approach retrospective validation. Some may feel that a full-blown validation is required to assure the system is functioning properly.

Others may feel that since the system has been in use, presumably without issues, validation is not necessary and a memo to file justifying why validation is not necessary may be issued.

Doing a full validation may not be required, since you already have proof that the system functions as required – at least in the situations in which production was conducted. Doing nothing, though, is a risk.

It’s likely that the controls haven’t been challenged so there may be some hidden flaws that haven’t been identified that could lead to non-conforming product, hazardous operating conditions, extended delays, etc.

Historical Data

Historical data can certainly be used to support validation. For example, if there is detailed and statistically-significant evidence that production runs are well controlled you could rationalize and justify not doing full validation.

During retrospective validation, it’s advisable that existing product be quarantined, and production put on hold until validation is complete.

As an exception, producing product as part of the validation exercise would follow concurrent validation. This may not be practical since product may have already been distributed, but caution is advised for the reasons outlined.

General Process

The general process for retrospective validation follows the same process as for prospective and concurrent validation except DQ is seldom performed, as the system has already been in use for some time.

Instead a survey and review of available information is performed. This normally occurs before the validation plan is created.

The MVP should also provide guidance on managing inventory during retrospective validation.

One Major Issue

One potential major problem that can occur with retrospective validation the determination of what action should be taken if an issue is found with the system during retrospective validation?

As with everything else, a risk-based decision is warranted. This could be anything from product recall, to customer notifications, to just documenting the justification of the decision why nothing was done.

Again, the MVP should provide guidance on dealing with situations concerning out of specification conditions revealed during retrospective validation, which should also definitely include involving regulatory support.



Similar articles: