Validation Protocol Execution Tips – Top 10

So you’ve finally reached the stage where you are now free to execute your validation protocol after months of development, review and approval. It would be a real shame at this stage if the execution went horribly wrong and the protocol was strewn with errors and deviations….after all this hard work this is what you will be judged on so it’s critical that you take the execution aspect very seriously.

Below are my top 10 tips to help you achieve execution success!

Tip 1: Develop the Protocol from Approved Design Specifications

Ensure that the protocol has been written from an approved design document. There’s no point in developing tests from an unapproved FS (Functional Specification) or DS (Design Specification) if the design is going to change. Your protocol needs to reflect what is in your approved design document.

This is especially significant when developing software validation test scripts, for equipment qualification the tests may come from approved OQ and PQ protocols that are not linked to requirements….the we’ve always done it this way approach!

Tip 2: Test Objectives Clearly Defined

The tests should be written in a manner where the objectives are clearly defined and each test is unambiguous. Having well defined requirements will assist with this but if you don’t you should make every effort possible to craft each test step in a manner that is easy to understand.

Remember if may not always be you who are executing the script you developed so keep that in mind throughout the development process.

Tip 3: Sufficient Space in the Protocol

If you are not executing your protocol electronically then you are using the traditional paper approach of handwriting on the paper print-out. If this is the case make sure that you leave sufficient space in the expected result columns to add sufficient test results.

There is nothing more frustrating for the reviews to have to use a magnifying glass to see what you have written.

Tip 4: Tester needs to have Testing Knowledge

Has the person who is developing the test script prior experience with this type of work? Testing is a skill and is one that is often overlooked. Great testers don’t just test the obvious functions they think outside the box and ensure other angles aside from the intended use are covered.

Tip 5: Time to Dry Run

It may not always to be possible to dry run your test script before the official execution but good project managers will factor in dry run executions as part of the project timelines. It’s amazing what you will find wrong with your script if you take the time to dry run it before official execution.

This may seem like extra work at the time but it will save you a huge amount of work overall. Treat the dry run as a real run, document all of your test results like you would the real run (You’ll be surprised what you find!)

Tip 6: Make Sure the QA Review is not just a Formatting Review

Does the QA person pre-approving your protocol really understand what they are reviewing? I have seen it time and time again where the QA review turns into a formatting review where you get the document back with only formatting changes. If that is the case either your protocol is perfect (which is never the case) or the QA person is not technical enough to really understand what is been tested.

For example if you are testing for Part 11 compliance does the QA person know what that means?

Tip 7: Execute in the Morning

This may seem like an obvious tip but try and schedule your execution times in the morning when you are fresh and not rushing to get home. Give yourself sufficient time to execute, this isn’t a speed test you need to take a quality driven approach to your executions.

Tip 8: Remember to Read the Pre-Requisite Section Carefully

Ensure that all of the pre-requisites have been performed before execution. Many protocols have a pre-requisite section where set-up data needs to be configured before the actual testing can commence.

There is little point in rushing through the protocol only to find out mid-way through the test that you forget to input the set-up data that allows you to execute the test.

Tip 9: Easily Accessible Deviations Forms

Deviations are part and parcel of any validation execution, its human nature to make mistakes and making mistakes with validation protocols is no different. Whether they come from the actual or expected results or from not executing a test correctly it is good practice to have a bundle of deviation forms at hand to populate at the time the deviation occurred.

This will ensure that you remember exactly what the issues were instead of trying to recall later.

Tip 10: Attach Test Evidence Correctly

Usually test evidence needs to be generated to support validation executions, from print-outs of equipment pressure and temperatures to screen-shots of software applications. Ensure that each additional print-out or attachment is numbered correctly and also references the protocol number.

You need to be able to pass the drop test!


  • davidj

    Good article, although I would say that you dont always have the luxury of starting the protocol when it is convenient for you. I have found that when performing OQ and PQ on plant, you will need trained operatives available (as you wont be allowed to work on the equipment unspervised) and you have to work around them and not the other way round! I have had to execute protocols at the end of the working day, and I know people who have had to work during the night, as it was the only time operators were available!

    Would also say that for point 5, you would have the protocol reviewed and approved anyway under GMP. You must NEVER use any unapproved qualification documents!

    A tip:
    When working on a GMP plant ensure that you have been sufficiently trained to be allowed on plant without supervision (ie gowning procedures) as that can be a real pain if operators are busy and cant spare the time to escort and supervise you. Are you fully trained in the company’s procedures for writing and executing protocols, and deviations? If not – forget doing any validation work!

  • Muzaffer

    It is a very nice article, as it reminds me actually the things we got during execution. We should do the dry run as real run and must be reviewed by any one else.

  • rama

    Very nice article . definately useful for the validation perfromers .

  • matt

    Very practical advise – especially tips 2,5,8 and 10.


  • john saenz

    One often forgetten point, but in my opinion important point is ORGANIZATION…that is create a binder or package to pre define what you are to collect in the field…i.e. cal certs, screen shots, software back ups, test results sections….often during execution, there is not enough time to ensure that the correct screen shots, or data sheets are collected or data sheets are are fully completed, or BI request / Lab request paperwork is not completed,
    Organize the binder…it will amke for a much easier report closure session
    john saenz

  • Koushik Rajaram

    It is a very nice article, informative and concise. Would you mind to publish/share information about how to prepare equipment qualification and process validation protocols and what are the guidelines which we need to refer to before preparing such a protocol and report.

  • shital y

    Pls review this site: and references listed below it may help.
    Moreover , koushik as you have not specified for what type process validation eg. dosage form its hard to guide you further.

Similar articles:

7 Top Tips for Validating Computer Systems in a Regulated Environment [Video]

The validation of any computer system in a regulated environment is always a tricky task with so many areas to cover. Not only do you have to ensure that the application adheres to 21 CFR Part 11 but it must also be validated to ensure that data integrity is not compromised throughout it’s life cycle.

To help you successfully validate a computer system remember the following:

1. Development Methodology

Select a development methodology that best suits the nature of the system – the risk analysis you do will help decide what level of validation is required.

For example, if you purchase the system from a third party vendor you may be able to leverage some of the testing they have already performed to streamline the effort.

2. Hardware

Select hardware based on capacity and functionality – vendors and IT personnel will guide this part of the process.

3. Opertional Limits

Identify operational limits to establish production procedures

4. Opertional Functions

Identify operational functions associated with the

  1. Users
  2. Processes
  3. Regulations
  4. Company standards
  5. safety requirements

5. Worst Case Scenrios

Identify and test worst-case production scenarios

6. Master Validation Plan

Clearly document the validation process and start by creating a master validation plan to define the effort involved

7. Written Procedures

Ensure the availability of written procedures to maintain the validated state of the computer system.

21 CFR Part 11 - Electronic Records

This video is taken from our online course on 21 CFR Part 11 – Electronic records. Click here to find out more about this course.


Similar articles:

The 9 Golden Rules – Ensuring Laboratory Data Integrity [Video]

The enduring assets of a laboratory’s work are the records that document those activities. When laboratory records are used to support a regulatory function, they are considered to be legal documents.

For records to be considered reliable and trustworthy they must comply with the following criteria:

1. Legible and Understandable

They must be able to be read and understood for the lifetime of the record, without having to refer to the originator for clarification. The information may be needed in five, ten or twenty years’ time, perhaps after the originator is no longer available.

2. Attributable

Who made the record or created the data and when?

3. Contemporaneous

The record must be made at the time the activity was performed

4. Original

The information must not be written on a post-it, piece of scrap paper, sleeve of a lab coat etc. and then transcribed.

5. Accurate

No errors or editing without documented amendments.

6. Complete

All the information and data associated with the analysis is included.

7. Consistent

All elements in the sequence of analysis must be date & time stamped and must be in the expected order.

8. Indelible

Records are made on to controlled documents, such as laboratory notebooks or controlled worksheets, or saved to electronic media.

9. Available

Over the entire lifetime of the record for review, audit and inspection.



Similar articles: