Part 13

The protocol converts the qualification strategy into executable evidence:

Requirement → Risk → Test Objective → Test Method → Acceptance Criteria → Execution → Raw Data → Deviation → Result → Review → Approval

The central principle is:

Qualification should demonstrate compliance with predefined requirements—not create requirements after seeing the results.

13.1 What Is a Qualification Protocol?

A qualification protocol is a controlled document defining in advance:

• what will be tested;
• why it will be tested;
• how testing will be performed;
• prerequisites for testing;
• who will execute/review the testing;
• what data must be recorded;
• what evidence must be retained;
• what acceptance criteria apply;
• how deviations and changes will be handled;
• how the final result will be assessed.

Protocols may be developed for:

• DQ;
• FAT;
• SAT;
• commissioning activities where appropriate;
• IQ;
• OQ;
• PQ;
• requalification;
• specific challenge studies.

The exact format and approval workflow depend on the company’s Pharmaceutical Quality System (PQS).

13.2 Why Is a Protocol Required?

The qualification protocol provides prospective control of verification.

Without a predefined protocol, testing can become:

Test → Observe Result → Decide What Was Expected → Declare Pass

A controlled approach is:

Define Requirement → Define Test → Define Acceptance Criteria → Approve → Execute → Record Actual Result → Compare → Conclude

This protects the scientific credibility and integrity of qualification.

13.3 GMP Purpose

The qualification protocol helps establish documented evidence that a facility, utility, equipment, or system is fit for its intended GMP use.

Your source establishes the broader evidence chain as:

Intended Use → Requirements → Risks → Design → Critical Aspects → Verification/Testing → Deviations → Traceability → Qualified State → Lifecycle Control.

The protocol principally governs the verification/testing portion of that chain.

13.4 Protocol vs Report

These should not be confused.

In simple terms:

Protocol = Plan

Executed Protocol = Evidence

Report = Assessment and Conclusion

13.5 Core Protocol Structure

Your source specifies that every qualification protocol should address the following 23 elements:

The remainder of Part 13 develops each requirement.

13.6 Document Title

The title should clearly identify:

• qualification stage;
• equipment/system;
• relevant location or project where needed.

Example

Operational Qualification Protocol for Tablet Compression Machine

or:

Installation and Operational Qualification Protocol for Tablet Compression Machine — EQP-TCM-001

Avoid ambiguous titles such as:

“Machine Qualification”

when multiple machines or qualification stages exist.

13.7 Document Number

Every controlled protocol should have a unique document identifier according to the company’s documentation system.

Example:

OQ/OSD/TCM/026

The identifier helps support:

• document control;
• retrieval;
• traceability;
• revision history;
• deviation linkage;
• change control;
• archival.

13.8 Revision Number

The protocol should identify its controlled revision.

Example:

Revision: 00

If the protocol changes before or during execution, the applicable document-control/change mechanism should preserve what version was approved and executed.

Do not silently replace an executed protocol with a revised version.

13.9 Revision History

A useful controlled-document table is:

Revision practices are company-specific and should follow the applicable PQS.

13.10 Equipment/System Identification

The protocol should uniquely identify the item being qualified.

Depending on the system, include:

• equipment name;
• equipment ID/tag;
• manufacturer;
• model;
• serial number;
• location;
• system name;
• subsystem;
• project number.

Example

This prevents qualification evidence from becoming ambiguous.

13.11 Purpose

The purpose states why the protocol is being executed.

Example — IQ

To provide documented verification that the tablet compression machine and its identified components are installed in accordance with approved design, manufacturer documentation and applicable approved requirements.

Example — OQ

To provide documented verification that the installed tablet compression machine operates according to approved functional requirements throughout the defined operating ranges.

Example — PQ

To provide documented evidence that the qualified equipment performs effectively and reproducibly under defined conditions representative of its intended use.

Purpose should be specific to the qualification stage.

13.12 Scope

The scope defines the boundaries of qualification.

It should identify:

Included

• equipment;
• subsystems;
• components;
• software;
• interfaces;
• utilities;
• qualification activities.

Excluded

Where relevant:

• upstream systems;
• downstream systems;
• separate utility qualification;
• process validation;
• cleaning validation;
• external computerized systems.

13.13 Why Scope Is Important

Poor scope definition creates:

• duplicated testing;
• missing testing;
• interface gaps;
• unclear ownership;
• qualification gaps.

For integrated equipment:

Upstream System
      ↓
Compression Machine
      ↓
Deduster
      ↓
Metal Detector
      ↓
Downstream System

The protocol should establish which elements and interfaces fall within its boundary.

13.14 References

The protocol should reference applicable controlled documents.

Examples include:

• URS;
• risk assessment;
• design specifications;
• DQ;
• FAT;
• SAT;
• previous qualification;
• equipment manuals;
• drawings;
• P&IDs;
• instrument lists;
• alarm lists;
• interlock matrices;
• SOPs;
• change controls.

Only relevant references should be included.

13.15 Reference Document Table

Revision identification is valuable where the protocol depends on a specific approved baseline.

13.16 Definitions and Abbreviations

Define terminology that could otherwise be misunderstood.

Example:

Avoid filling the protocol with unnecessary generic definitions.

13.17 Responsibilities

The protocol should define who is responsible for activities such as:

• preparation;
• technical review;
• QA review;
• approval;
• execution;
• witnessing;
• deviation handling;
• raw-data review;
• final assessment.

Actual responsibilities depend on the company’s PQS.

13.18 Example Responsibility Matrix

The vendor should not independently define site GMP acceptance where that responsibility belongs to the pharmaceutical manufacturer.

13.19 System Description

The protocol should contain sufficient information to understand:

• what the system does;
• its intended use;
• major components;
• operating principle;
• critical functions;
• automation architecture where relevant;
• major interfaces;
• applicable utilities.

It should not necessarily reproduce the entire equipment manual.

13.20 Example System Description

For a tablet compression machine:

Material Feed
     ↓
Feeder System
     ↓
Die Filling
     ↓
Pre-Compression
     ↓
Main Compression
     ↓
Tablet Ejection
     ↓
Dedusting
     ↓
Metal Detection / Collection

The system description provides context for the qualification tests.

13.21 Prerequisites

Prerequisites are conditions that should be satisfied before relevant qualification testing begins.

Examples:

• approved protocol;
• equipment installation completed;
• required utilities available;
• calibration current;
• preceding qualification stage completed;
• software version established;
• drawings available;
• test equipment calibrated;
• safety checks completed;
• personnel trained;
• applicable deviations assessed.

13.22 Prerequisite Checklist

The protocol should define how unresolved prerequisites are handled.

13.23 Critical vs Noncritical Prerequisites

Not every open prerequisite necessarily has the same impact.

For example:

Critical

• missing calibration of a reference instrument;
• unsafe installation;
• uncontrolled software version.

Potentially noncritical

• an unrelated cosmetic punch-list item.

Open prerequisites should be assessed rather than automatically ignored or automatically stopping all work.

13.24 Test Instruments

Qualification often uses independent measuring devices.

Examples:

• calibrated tachometer;
• temperature data logger;
• pressure gauge;
• multimeter;
• particle counter;
• anemometer;
• timer;
• weighing balance.

The protocol should identify test instruments relevant to the qualification.

13.25 Test Instrument Register

Record only fields relevant to the intended measurement and site procedure.

13.26 Calibration Requirements

Your source separately emphasizes the relationship:

Calibration → Instrument suitability → Qualification → Process control.

Qualification protocols should establish that relevant measuring instruments are suitable for the intended test.

Consider:

• calibration status;
• range;
• accuracy;
• tolerance;
• traceability;
• calibration due date.

13.27 Calibration Sticker Alone Is Not Enough

A test instrument may be “calibrated” but unsuitable for a specific qualification measurement.

Example:

Acceptance criterion:

10.00 ± 0.05 units

Reference instrument capability:

±0.5 units

The instrument may have a valid calibration certificate yet lack adequate measurement capability for the intended verification.

Therefore:

Calibration status and measurement suitability are related but not identical concepts.

13.28 Calibration Status During Execution

Before using a test instrument, verify:

• correct instrument identity;
• calibration validity;
• applicable range;
• appropriate condition.

If an instrument is later found out of tolerance, assess impact on qualification data generated using that instrument.

13.29 Test Methodology

The protocol should describe how qualification tests will be executed.

The methodology should be:

• understandable;
• executable;
• repeatable;
• sufficiently detailed;
• scientifically appropriate.

A second competent person should be able to understand what is required without relying on undocumented verbal instructions.

13.30 Poor Test Method

Weak:

“Check speed.”

This leaves unanswered:

• what speed?
• how?
• with what instrument?
• where measured?
• how long?
• how many readings?
• what tolerance?

13.31 Improved Test Method

Example:

1. Confirm machine is in the defined test condition.
2. Set turret speed to the approved lower test point.
3. Allow operation to stabilize.
4. Measure actual speed using the identified calibrated reference instrument.
5. Record HMI indication.
6. Record reference-instrument reading.
7. Compare against approved acceptance criteria.
8. Repeat for nominal and upper test conditions.

This is executable and reproducible.

13.32 Acceptance Criteria

Acceptance criteria are among the most critical parts of a protocol.

They should be:

• predefined;
• objective;
• measurable where applicable;
• scientifically justified;
• linked to approved requirements/specifications;
• suitable for determining pass/fail.

13.33 Sources of Acceptance Criteria

Depending on the test, criteria may derive from:

• URS;
• design specification;
• approved process requirement;
• engineering specification;
• manufacturer specification where appropriately accepted;
• regulatory/GMP requirement where applicable;
• risk assessment;
• approved site standard.

Do not invent limits merely to complete a protocol.

13.34 Weak Acceptance Criteria

Examples:

“Machine should work properly.”

“Result should be satisfactory.”

“Alarm should be okay.”

“System should perform normally.”

These are subjective.

13.35 Better Acceptance Criteria

Examples:

Upon activation of the identified emergency stop, the equipment shall respond according to the approved safety/functional specification and shall not restart until the required reset/restart sequence is completed.

Or:

The configured user role shall permit and restrict functions according to the approved user-role matrix.

The acceptance criterion should match the requirement being verified.

13.36 Acceptance Criteria Must Exist Before Execution

The fundamental sequence should be:

Requirement
     ↓
Risk / Criticality
     ↓
Test Design
     ↓
Acceptance Criteria
     ↓
Protocol Approval
     ↓
Execution
     ↓
Actual Result
     ↓
Comparison

Not:

Execution
   ↓
Result
   ↓
Create Convenient Limit
   ↓
Pass

13.37 Test Scripts

Each qualification test should be uniquely identified.

Example:

• IQ-001 — Equipment Identification
• IQ-002 — Component Verification
• OQ-001 — Start/Stop Verification
• OQ-002 — Turret Speed Challenge
• OQ-003 — Guard Interlock
• OQ-004 — Alarm Verification

Unique test IDs support traceability.

13.38 Standard Test Script Structure

The source explicitly requires the detailed IQ test format:

Objective → Prerequisite → Test method → Expected result → Actual result → Acceptance criteria → Evidence → Pass/Fail → Executed by → Reviewed by.

This is also a useful general structure for executable qualification tests.

Test ID

Unique test reference.

Test Title

Specific function being tested.

Objective

Why is the test performed?

Prerequisite

What must exist before execution?

Test Method

Exactly what should be done?

Expected Result

What behavior/result is expected?

Actual Result

What actually happened?

Acceptance Criteria

What defines acceptable performance?

Evidence

What objective records support the result?

Status

PASS / FAIL / N/A as controlled.

Executed By

Name/signature/date.

Reviewed By

Name/signature/date.

13.39 Example OQ Test Script

Test ID: OQ-INT-003

Title

Guard Interlock Verification

Objective

Verify the designated machine guard interlock operates according to the approved functional requirement.

Prerequisites

• Equipment available for safe testing.
• Required OQ prerequisites complete.
• Relevant guard identified.

Method

1. Confirm the designated guard is closed.
2. Establish the approved test operating condition.
3. Open the designated guard using the approved safe method.
4. Observe machine response.
5. Attempt restart with the guard open.
6. Close the guard.
7. Perform the defined reset.
8. Verify restart behavior.

Expected Result

System shall respond according to the approved interlock design.

Actual Result

Acceptance Criteria

Observed interlock, restart-inhibition and reset behavior shall comply with the approved functional/interlock specification.

Evidence

Status

□ PASS
□ FAIL

Executed By

________________ / Date: ______

Reviewed By

________________ / Date: ______

13.40 Data-Recording Requirements

The protocol should define how actual data are recorded.

Depending on the test:

• actual numerical values;
• observations;
• timestamps;
• test conditions;
• equipment state;
• operator/user;
• alarm text;
• electronic record ID;
• raw-data reference;
• attachment number.

Do not rely only on check marks where actual measurements or observations are necessary.

13.41 Expected vs Actual Results

A well-designed protocol distinguishes between:

Expected Result

Predefined before execution.

Actual Result

Recorded during execution.

Example:

Writing:

Actual Result: “As expected”

may be inadequate when the test should record objective data.

13.42 Actual Numerical Data

Where a numerical measurement is performed, record the actual result.

Weak:

Speed: ✓ Pass

Better:

The raw measurement is part of the evidence.

13.43 Raw Data Requirements

The protocol should define what constitutes raw/supporting data.

Examples:

• instrument readings;
• printouts;
• electronic records;
• trend data;
• chromatograms where relevant;
• audit trails;
• screenshots;
• reports;
• laboratory results;
• calibration records;
• photographs where appropriate.

Raw evidence should be attributable and linked to the applicable test.

13.44 Attachments

Qualification protocols often generate attachments.

Examples:

• printouts;
• screenshots;
• drawings;
• certificates;
• data sheets;
• alarm reports;
• audit-trail reports;
• trend reports;
• calculations;
• vendor evidence.

Attachments should remain controlled and traceable to the protocol/test.

13.45 Attachment Identification

A practical approach:

Attachment OQ-005-A01

or:

Protocol Attachment 07 — Alarm History

The protocol should make it possible to determine:

• which test generated the attachment;
• what the attachment represents;
• whether all expected pages are present.

13.46 Screenshots

For computerized-system testing, screenshots may provide useful evidence.

However, screenshots should not replace meaningful testing.

Where appropriate, identify:

• system;
• screen/function;
• test ID;
• date/time;
• relevant user;
• applicable result.

Part 14 of your source specifically requires screenshots and electronic records to be addressed under Good Documentation Practices during execution.

13.47 Deviations and Discrepancies

The protocol should define how unexpected events are handled.

Examples:

• acceptance criterion not met;
• test cannot be executed as written;
• unexpected equipment behavior;
• incorrect protocol instruction;
• missing prerequisite;
• instrument problem;
• software defect;
• design deficiency.

Do not simply overwrite or ignore the problem.

13.48 Deviation Lifecycle

Your source defines the qualification-deviation lifecycle as:

Observation → Documentation → Initial Assessment → Impact Assessment → Investigation → Root Cause where required → CAPA/Correction → Re-test → QA Assessment → Closure.

The protocol should reference the applicable deviation/discrepancy procedure.

13.49 Deviation Log

A protocol may include:

This facilitates final reconciliation.

13.50 Change Control

The protocol should explain how changes discovered or required during qualification will be managed.

Examples:

• component replacement;
• instrument replacement;
• PLC modification;
• HMI modification;
• software upgrade;
• utility change;
• design change;
• operating-range change.

The source’s later change-control model is:

Change → GMP Impact → Risk Assessment → Qualification Impact → Required Testing → Documentation Update → Approval → Implementation → Verification → Closure.

13.51 Do Not Make Uncontrolled Changes During Qualification

Example:

OQ discovers incorrect PLC alarm logic.

Unacceptable:

Vendor changes PLC → Test repeated → Pass.

Better lifecycle:

Failure → Documentation → Impact Assessment → Controlled Change → Software/Configuration Identification → Regression Scope → Retest → Final Baseline

The qualification package should preserve what changed and why.

13.52 Re-testing

The protocol should define the principles governing retesting.

Retesting should normally be:

• documented;
• justified;
• linked to the original failure/discrepancy;
• appropriately authorized;
• scientifically scoped;
• fully traceable.

13.53 Retesting Is Not “Repeat Until Pass”

Your source explicitly identifies the following as an unacceptable practice:

Repeating tests until they pass without investigation.

Correct sequence:

Test Failure
     ↓
Document
     ↓
Assess
     ↓
Investigate
     ↓
Correct
     ↓
Determine Retest Scope
     ↓
Authorize
     ↓
Retest
     ↓
Evaluate

13.54 Original Failed Results Must Remain

If:

OQ-007 → FAIL

followed by:

OQ-007-R1 → PASS

the qualification record should preserve both.

The final conclusion should show the complete history rather than replacing the failed result with the successful retest.

13.55 Regression Testing

For computerized or automated systems, a correction may affect functions beyond the original failed test.

Example:

PLC logic for reject control is modified.

Potentially affected:

• reject command;
• reject confirmation;
• reject count;
• alarm;
• interface;
• audit trail;
• recipe logic.

Therefore, retest scope should follow impact assessment rather than automatically repeating only the original test.

13.56 Summary Section

The executed protocol should contain or support a summary of execution.

The summary may include:

• total tests;
• tests passed;
• tests failed;
• tests not applicable;
• deviations;
• retests;
• open items;
• change controls;
• overall protocol status.

13.57 Example Protocol Summary

This example demonstrates why a final “35/35 Pass” statement alone may hide important execution history.

13.58 Protocol Conclusion

The conclusion should answer whether the protocol objectives were achieved.

Example:

Based on execution of the approved protocol, review of recorded results, supporting evidence, deviations and approved retesting, the protocol objectives have been satisfactorily demonstrated, subject to the final qualification lifecycle assessment.

Do not automatically state:

“Equipment is released for GMP production.”

unless the protocol itself is the authorized final release mechanism under the site’s PQS.

Your source separately requires a Qualification Summary Report and GMP release process.

13.59 Approval

The protocol should have defined approvals according to the company’s PQS.

Potential approvers/reviewers may include:

• Validation/CQV;
• Engineering;
• Production;
• QA;
• Automation/IT;
• QC;
• EHS where applicable.

Not every protocol requires every function’s signature.

Approval responsibilities should be risk- and system-appropriate.

13.60 Pre-Approval vs Post-Execution Approval

Two different controls are involved.

Pre-execution approval

Confirms that:

• scope is acceptable;
• methodology is appropriate;
• acceptance criteria are predefined;
• responsibilities are clear;
• testing is authorized.

Post-execution review/approval

Confirms that:

• execution is complete;
• actual results are recorded;
• deviations are assessed;
• evidence is adequate;
• conclusions are supported.

These should not be confused.

13.61 Why Protocols Should Normally Be Approved Before Execution

This is the central requirement specifically requested in Part 13.

Pre-approval establishes that the organization has agreed before testing on:

What will be tested

How it will be tested

What evidence will be collected

What constitutes acceptance

Without this control, qualification risks becoming retrospective.

13.62 Problem With Retrospective Approval

Consider:

Equipment Tested
       ↓
Results Obtained
       ↓
Protocol Written
       ↓
Acceptance Criteria Selected
       ↓
Protocol Approved
       ↓
All Results Pass

This creates an obvious question:

Were the acceptance criteria chosen because they represented approved requirements, or because the results were already known?

Pre-execution approval protects against this ambiguity.

13.63 Correct Prospective Sequence

URS / Requirements
        ↓
Risk Assessment
        ↓
Qualification Strategy
        ↓
Draft Protocol
        ↓
Technical Review
        ↓
QA / Required Approval
        ↓
CONTROLLED APPROVED PROTOCOL
        ↓
Execution
        ↓
Raw Data
        ↓
Deviations / Changes
        ↓
Review
        ↓
Final Protocol Disposition

13.64 Protocol Approval Gate

A practical approval gate is:

Before Execution

□ Protocol identified

□ Correct revision

□ Scope defined

□ References current

□ Risk assessment considered

□ Prerequisites defined

□ Test instruments defined

□ Test methodology approved

□ Acceptance criteria approved

□ Data-recording requirements defined

□ Deviation process defined

□ Retest process defined

□ Required signatures complete

Only then should controlled execution normally begin.

13.65 Controlled Protocol Copy

Where paper protocols are used, execution should occur on an appropriately controlled copy according to the site’s document-control system.

This helps prevent:

• duplicate execution;
• uncontrolled photocopies;
• missing pages;
• substitution of pages;
• execution against obsolete revisions.

Detailed execution GDP is covered in Part 14 of your source.

13.66 Protocol Page Control

A controlled paper protocol may identify:

Page X of Y

along with:

• document number;
• revision;
• protocol title or abbreviated identifier.

The exact format is company-specific.

The objective is document integrity and traceability.

13.67 Protocol Amendments

Sometimes an approved protocol requires modification before execution is complete.

Potential reasons:

• incorrect instruction;
• changed design;
• additional test required;
• acceptance criterion requires justified revision;
• system configuration changes.

The modification should follow the site’s approved document/change mechanism.

13.68 Never Silently Edit an Approved Executed Protocol

If a test method is incorrect:

Do not:

erase original instruction → replace it → continue as though it was always written that way.

Instead:

Document issue → Assess impact → Follow approved amendment/deviation/change process → Obtain required authorization → Continue appropriately

The historical record should remain understandable.

13.69 Test Script Design Principles

A strong test script should be:

Specific

Clearly identify the function.

Executable

Personnel can perform it.

Reproducible

Another competent person could repeat it.

Risk based

Testing depth reflects criticality.

Traceable

Linked to requirements/risks.

Objective

Pass/fail is not based on opinion.

Evidence driven

Actual data demonstrate the conclusion.

13.70 Avoid Over-Scripting

Protocols should be detailed enough for controlled execution without becoming unnecessarily cumbersome.

Overly scripted protocols can create:

• administrative burden;
• excessive transcription;
• meaningless checkboxes;
• execution errors.

The objective is not maximum paperwork.

It is:

Sufficient objective evidence to demonstrate the qualification requirement.

13.71 Avoid Under-Scripting

The opposite is equally problematic.

Example:

“Check all alarms.”

This does not identify:

• which alarms;
• trigger conditions;
• expected responses;
• reset behavior;
• evidence;
• acceptance criteria.

A risk-based balance is required.

13.72 Challenge Testing

For OQ in particular, protocols should distinguish normal operation from challenge testing.

Normal operation asks:

Does the function work under expected conditions?

Challenge testing asks:

Does the system respond correctly when limits, alarms, interlocks, failure modes or abnormal conditions are challenged?

Your source explicitly requires OQ to cover challenge testing, upper/lower operating limits and scientifically justified worst-case testing.

13.73 Example — Alarm Test Script Design

A robust alarm test may include:

13.74 Example — Range Test Script

The selected points should be justified by requirements and risk rather than automatically using three points for every parameter.

13.75 Computerized-System Protocol Requirements

Where equipment includes:

PLC / HMI / SCADA / DCS / MES / computerized controls

additional protocol considerations may include:

• software/configuration identification;
• user roles;
• access control;
• audit trails;
• electronic records;
• interfaces;
• backup/restore;
• time synchronization;
• security;
• reports;
• recipe management.

Your source explicitly requires these areas to be integrated where applicable rather than assuming every computerized feature requires identical testing.

13.76 Software Baseline

A computerized qualification protocol should identify or reference the applicable qualified configuration.

Examples:

• PLC program version;
• HMI version;
• SCADA version;
• firmware;
• configuration version;
• recipe version where applicable.

Without configuration control, qualification may not establish exactly what was tested.

13.77 Protocol and Traceability Matrix

Every significant test should be traceable to the requirement/risk it verifies.

Example:

The source’s Part 12 model requires traceability through:

URS → Risk Assessment → Design → FAT/SAT → IQ → OQ → PQ → SOP/Control → Final Qualification Status.

13.78 Protocol and Risk Assessment

Testing should not be copied mechanically from previous equipment.

Risk assessment should help determine:

What needs testing → Why → How extensively → At which lifecycle stage

For example:

High-risk reject function

Detailed challenge testing.

Low-risk cosmetic screen formatting

Minimal verification or justified exclusion.

This aligns with the source’s risk-based qualification approach.

13.79 Vendor Protocols

Vendor protocols can be valuable.

But the pharmaceutical manufacturer should assess whether the vendor protocol:

• addresses approved URS;
• addresses GMP risks;
• contains adequate acceptance criteria;
• provides appropriate evidence;
• uses suitable instruments;
• handles deviations appropriately;
• supports traceability.

Do not approve a vendor protocol merely because:

“This is the vendor’s standard qualification package.”

13.80 Leveraging Supplier Evidence

Supplier/FAT/commissioning evidence may potentially be leveraged when:

• testing is relevant;
• evidence quality is adequate;
• requirement is covered;
• configuration is controlled;
• test remains valid after shipment/installation;
• risk assessment supports reliance;
• site qualification strategy allows it.

The source specifically requires the qualification program to determine where documented supplier/commissioning evidence may be leveraged.

13.81 Example Protocol Cover Page

OPERATIONAL QUALIFICATION PROTOCOL

Equipment: Tablet Compression Machine
Equipment ID: __________
Manufacturer: __________
Model: __________
Serial Number: __________
Location: __________
Protocol No.: __________
Revision: __________

Approval

Actual signatories should follow the company’s PQS.

13.82 Recommended Protocol Table of Contents

1. Document Control
2. Approval
3. Revision History
4. Purpose
5. Scope
6. References
7. Definitions/Abbreviations
8. Responsibilities
9. Equipment/System Identification
10. System Description
11. Qualification Strategy
12. Prerequisites
13. Test Instruments
14. Calibration Requirements
15. General Execution Instructions
16. Test Scripts
17. Acceptance Criteria
18. Raw-Data Requirements
19. Attachments
20. Deviations/Discrepancies
21. Change Control
22. Retesting
23. Traceability
24. Execution Summary
25. Conclusion
26. Post-Execution Approval

This expands the source’s required elements into a practical protocol layout.

13.83 Example General Execution Instructions

A protocol may instruct executors to:

1. Verify correct controlled protocol revision.
2. Confirm prerequisites before relevant testing.
3. Record actual observations contemporaneously.
4. Record numerical values rather than only check marks where measurements are required.
5. Identify supporting evidence.
6. Document unexpected results.
7. Follow the applicable deviation procedure.
8. Do not alter acceptance criteria during execution without appropriate control.
9. Identify test instruments used.
10. Sign/date completed test sections.

Detailed GDP requirements belong to Part 14.

13.84 Protocol Execution Flow

Approved Protocol
       ↓
Verify Prerequisites
       ↓
Verify Test Instruments
       ↓
Execute Test
       ↓
Record Actual Result
       ↓
Acceptance Criteria Met?
    ┌──────┴──────┐
   YES            NO
    │              │
Record Pass     Document Failure
    │              ↓
    │          Deviation
    │              ↓
    │         Investigation
    │              ↓
    │       Correction/CAPA
    │              ↓
    │      Authorized Retest
    │              ↓
    └──────────────┤
                   ↓
             Review Evidence
                   ↓
             Protocol Summary
                   ↓
                Approval

13.85 Protocol RACI

R = Responsible, A = Accountable, C = Consulted, I = Informed.

Actual responsibilities depend on the company’s PQS.

13.86 Common Protocol Deficiencies

13.87 Inspector Perspective — “Show Me the Approved Protocol”

Inspector Intent

Determine whether qualification was prospectively planned and controlled.

Expected Evidence

• approved protocol;
• revision;
• approval date;
• execution dates;
• controlled copy/electronic workflow.

Strong Response

The organization can demonstrate that the applicable protocol was approved before execution and identify any controlled amendments/deviations.

Potential Red Flag

Execution records predate protocol approval without an appropriate documented rationale/process.

13.88 Inspector Perspective — “How Were Acceptance Criteria Established?”

Inspector Intent

Determine whether criteria are scientifically and technically justified.

Expected Evidence

• URS;
• specification;
• risk assessment;
• process requirements;
• design requirements;
• approved protocol.

Strong Response

Requirement → Scientific/Technical Basis → Acceptance Criterion → Test Result

Potential Red Flag

“The vendor suggested the limit after the test.”

13.89 Inspector Perspective — “What Raw Data Supports This Pass?”

Inspector Intent

Determine whether the conclusion is supported by objective evidence.

Expected Evidence

• actual readings;
• printouts;
• electronic records;
• screenshots where relevant;
• instrument identification;
• calculations;
• test signatures.

Potential Red Flag

Only:

PASS ✓

with no underlying evidence.

13.90 Inspector Perspective — “Why Was the Test Repeated?”

Inspector Intent

Determine whether the organization investigated failures or merely tested until a passing result was obtained.

Expected Evidence

Original Failure → Deviation → Investigation → Corrective Action → Retest Authorization → Retest Result

The source explicitly identifies repeating tests until they pass without investigation as unacceptable.

13.91 Inspector Perspective — “Which Software Version Did You Test?”

Inspector Intent

Determine whether computerized qualification was executed against a known controlled baseline.

Expected Evidence

• software version;
• PLC/HMI/SCADA identification;
• configuration record;
• change history;
• qualification evidence.

Potential Red Flag

The team cannot establish which version was actually tested.

13.92 Best-Practice Protocol Principles

A strong qualification protocol should be:

Prospective — normally approved before execution.

Requirement based — linked to intended use and URS.

Risk based — testing effort reflects criticality.

Specific — test objective is clear.

Executable — instructions can actually be followed.

Objective — pass/fail is not subjective.

Measurable — actual values are captured where relevant.

Traceable — requirements connect to evidence.

Controlled — revision, changes and copies are managed.

Transparent — failures and deviations remain visible.

Evidence driven — conclusions are supported by raw data.

13.93 Master Protocol Checklist

Document Control

• □ Correct title
• □ Unique document number
• □ Revision identified
• □ Equipment/system uniquely identified
• □ Revision history where applicable

Purpose and Scope

• □ Purpose defined
• □ Scope defined
• □ Boundaries clear
• □ Exclusions identified where necessary

Technical Basis

• □ URS referenced
• □ Risk assessment referenced
• □ Design/specifications referenced
• □ Applicable FAT/SAT evidence referenced
• □ Relevant SOPs identified

Responsibilities

• □ Author identified
• □ Reviewers identified
• □ Approvers identified
• □ Executors/witnesses defined as applicable

Prerequisites

• □ Previous qualification stage status
• □ Installation status
• □ Utilities
• □ Calibration
• □ Test equipment
• □ Software/configuration
• □ Safety readiness
• □ Training

Testing

• □ Unique test IDs
• □ Objective
• □ Prerequisite
• □ Test method
• □ Expected result
• □ Actual result
• □ Acceptance criterion
• □ Evidence
• □ Pass/fail
• □ Executor
• □ Reviewer

Data

• □ Raw-data requirements defined
• □ Numerical data fields provided
• □ Attachments controlled
• □ Electronic evidence addressed
• □ Calculations controlled where applicable

Exception Management

• □ Deviation mechanism defined
• □ Discrepancy handling defined
• □ Change-control mechanism defined
• □ Retesting requirements defined
• □ Original failed results retained

Closure

• □ All tests reconciled
• □ Deviations reconciled
• □ Retests reconciled
• □ Open items identified
• □ Summary completed
• □ Conclusion supported
• □ Post-execution review/approval completed
• □ Traceability updated

13.94 Protocol Readiness Decision

Protocol Drafted
      ↓
Scope Clear?
 ┌────┴────┐
 No       Yes
 │         ↓
Revise   Requirements/Risks Addressed?
          ┌────┴────┐
         No        Yes
          │          ↓
       Revise    Test Methods Complete?
                    ┌────┴────┐
                   No        Yes
                    │          ↓
                 Revise   Acceptance Criteria
                           Predefined?
                           ┌────┴────┐
                          No        Yes
                           │          ↓
                        Revise   Prerequisites/
                                 Instruments Defined?
                                  ┌────┴────┐
                                 No        Yes
                                  │          ↓
                               Revise     Review
                                            ↓
                                        Approval
                                            ↓
                                         EXECUTE

13.95 Golden Rule of Qualification Protocols

Never design qualification testing around the result you already obtained. Define the requirement, test methodology, evidence requirements and acceptance criteria first; obtain the required approval; then execute and transparently document what actually happens.

13.96 Part 13 — Key Takeaway

A robust qualification protocol provides the controlled bridge between:

Requirements/Risks

and

Objective Qualification Evidence

The source specifically requires qualification protocols to address document identification, equipment/system identification, purpose, scope, references, definitions, responsibilities, system description, prerequisites, test instruments, calibration, methodology, acceptance criteria, test scripts, data recording, attachments, deviations, change control, retesting, summary and approval.

The practical protocol evidence chain should therefore be:

URS/Requirement → Risk → Test Objective → Approved Method → Predefined Acceptance Criterion → Controlled Execution → Actual Result → Raw Evidence → Deviation/Change if Applicable → Retest if Justified → Review → Final Status → Traceability

Most importantly:

Protocol approval before execution protects the prospective, objective and scientifically defensible nature of qualification.

Next: Part 14 — Good Documentation Practices During Execution

Part 14 in your source requires detailed coverage of:

ALCOA+ → contemporaneous documentation → permanent ink for paper records → date/time → signatures/initials → corrections → blank fields → N/A → raw data → attachments → printouts → electronic records → screenshots → page numbering → controlled copies → transcription → calculation verification → second-person verification → corrections to executed protocols

It also specifically requires discussion of unacceptable practices including backdating, pre-signing, unjustified data reconstruction, uncontrolled worksheets, unexplained overwriting, discarding failed results, repeating tests until they pass without investigation, and copying previous qualification results without execution.

About the Author

Ramesh Palav is a pharmaceutical professional with 20+ years of industry experience in manufacturing, GMP, quality systems, validation, compliance, and operational excellence. Through Pharma Manufacturing Hub, he shares practical insights on pharmaceutical careers, manufacturing, quality, validation, Pharma 4.0, AI, and professional development.

His goal is to help students, freshers, experienced professionals, and career-break professionals build the knowledge and skills needed to succeed in the pharmaceutical industry.