Part 7

The FAT should fit the overall evidence chain established in the handbook:

Intended Use → URS → Risk Assessment → Design/DQ → FAT → SAT → IQ → OQ → PQ → Traceability → Qualified State

7.1 What Is a Factory Acceptance Test?

A Factory Acceptance Test (FAT) is a planned and documented series of inspections, reviews, and functional tests performed on equipment or a system, normally at the supplier’s facility, before shipment to the pharmaceutical manufacturing site.

Its fundamental question is:

Has the supplier manufactured, assembled, configured, and programmed the system sufficiently in accordance with the approved requirements and design to justify acceptance for shipment?

FAT may cover:

• mechanical construction;
• electrical systems;
• instrumentation;
• PLC;
• HMI;
• SCADA where applicable;
• operating sequences;
• alarms;
• interlocks;
• recipes;
• safety functions;
• computerized functions;
• documentation.

7.2 Purpose of FAT

The primary purposes are to:

1. verify equipment against approved specifications;
2. identify design/manufacturing deficiencies before shipment;
3. challenge important functions while vendor expertise is readily available;
4. confirm critical URS/design requirements;
5. verify software/configuration maturity;
6. identify outstanding punch-list items;
7. obtain objective evidence supporting subsequent qualification;
8. reduce installation/startup problems;
9. establish readiness for shipment.

FAT is particularly valuable because correcting a problem at the manufacturer’s factory is often easier than correcting it after installation.

7.3 FAT Is Not Automatically Qualification

An important distinction is:

Successful FAT does not automatically mean the equipment is qualified for GMP use.

FAT occurs before:

• final site installation;
• permanent utility connection;
• final site configuration;
• site environmental conditions;
• site interfaces;
• IQ/OQ/PQ completion.

Therefore, FAT is an important pre-delivery verification activity that may support qualification when appropriately planned and controlled.

7.4 FAT Position in the Lifecycle

Approved URS
     ↓
Risk Assessment
     ↓
Design Specification
     ↓
Design Qualification
     ↓
Fabrication / Programming
     ↓
Internal Vendor Testing
     ↓
┌──────────────────────┐
│         FAT          │
└──────────────────────┘
     ↓
Punch-List Closure
     ↓
Release for Shipment
     ↓
Transportation
     ↓
Installation
     ↓
SAT / Commissioning
     ↓
IQ
     ↓
OQ
     ↓
PQ

7.5 FAT Strategy

The FAT strategy should be established before execution.

It should define:

• FAT scope;
• applicable systems/subsystems;
• critical functions;
• tests to be witnessed;
• documentation requirements;
• responsibilities;
• acceptance criteria;
• deviation management;
• punch-list categories;
• retesting requirements;
• shipment-release criteria;
• tests intended for later qualification leverage.

7.6 Risk-Based FAT

FAT should be risk based.

The question should not be:

“What tests does the vendor normally perform?”

Instead:

“Which functions are sufficiently important that failure should be identified before shipment?”

The FAT scope should consider:

URS + DQ + Risk Assessment + Critical Aspects + Vendor Design

7.7 FAT Test Criticality

A useful approach is:

This prevents FAT from becoming a generic equipment demonstration.

7.8 FAT Prerequisites

Before FAT begins, confirm as applicable:

• □ URS approved
• □ DQ completed or sufficiently mature
• □ Risk assessment available
• □ Critical aspects identified
• □ FAT protocol approved
• □ Relevant drawings available
• □ Functional specifications available
• □ Software/configuration sufficiently mature
• □ Equipment assembled
• □ Vendor internal testing completed
• □ Required test instruments available
• □ Test instruments have appropriate calibration status
• □ Required utilities available
• □ Open design issues reviewed
• □ FAT team identified

7.9 FAT Protocol

A FAT should normally be executed against a predefined protocol or test plan appropriate to the system and project controls.

A recommended structure is:

1. Document Control

• FAT title
• document number
• revision
• project number
• equipment/system ID

2. Approval

• prepared by
• reviewed by
• approved by

3. Objective

Define what the FAT intends to establish.

4. Scope

Identify:

• equipment;
• subsystems;
• software;
• interfaces;
• exclusions.

5. References

Examples:

• URS;
• DQ;
• risk assessment;
• functional specification;
• design specification;
• drawings;
• P&IDs;
• electrical diagrams.

6. Responsibilities

Define supplier/user/QA/engineering/validation responsibilities.

7. Equipment Description

8. FAT Prerequisites

9. Test Instruments

10. Mechanical Tests

11. Electrical Tests

12. Instrumentation Tests

13. Automation Tests

14. Alarm/Interlock Tests

15. Sequence Tests

16. Recipe Tests

17. Data-Integrity Tests where applicable

18. Documentation Review

19. Deviations

20. Punch List

21. Retesting

22. FAT Summary

23. Shipment Recommendation

24. Approval

7.10 FAT Responsibilities

A typical responsibility model is:

Actual responsibilities depend on the company’s Pharmaceutical Quality System.

7.11 Mechanical Checks

Mechanical FAT checks may include:

• overall construction;
• dimensions;
• equipment orientation;
• major components;
• guards;
• doors;
• access panels;
• product-contact components;
• seals/gaskets;
• piping;
• valves;
• motors;
• gearboxes;
• lubrication arrangements;
• equipment movement;
• product flow path;
• cleaning accessibility.

7.12 Equipment Identification

Verify:

• manufacturer;
• equipment type;
• model;
• serial number where assigned;
• major assemblies;
• equipment tag/reference.

Example:

7.13 Dimensional Verification

Critical dimensions may be verified where relevant.

Examples:

• overall footprint;
• height;
• product inlet;
• discharge elevation;
• maintenance clearance;
• utility connection points;
• interface dimensions.

This is especially important where the machine interfaces with:

• deduster;
• metal detector;
• isolator;
• containment system;
• upstream/downstream equipment.

7.14 Product-Contact Components

FAT may verify that identified product-contact components correspond to the approved design.

Examples for a tablet compression machine:

• hopper;
• feeder;
• product-contact covers;
• dies;
• punches where supplied;
• discharge chute;
• reject chute.

Documentation should be reviewed against approved specifications.

7.15 Materials of Construction

Material evidence may include:

• material certificates;
• supplier declarations;
• component lists;
• drawings;
• identification records.

FAT can confirm documentation availability and physical/component consistency.

Where installed material verification is required later, IQ may leverage suitable FAT evidence subject to the approved strategy.

7.16 Surface Finish

Where surface finish is a specified requirement, FAT may review:

• supplier certificates;
• manufacturing records;
• visual condition;
• specified finish documentation.

The method should reflect the approved requirement.

7.17 Cleaning and Accessibility

The FAT team should consider whether the equipment can actually be cleaned as intended.

Verify:

• access;
• dismantling;
• removal of product-contact parts;
• cleaning access;
• reassembly;
• product-retention points;
• drainability where applicable.

A machine may technically meet mechanical specifications yet still have poor GMP operability.

7.18 Electrical Checks

Electrical FAT checks may include:

• control-panel construction;
• component identification;
• wiring;
• cable identification;
• terminal identification;
• electrical drawings;
• power ratings;
• earthing;
• protection devices;
• motors;
• drives;
• emergency circuits.

7.19 Electrical Drawing Verification

Confirm drawings correspond to the equipment configuration.

Typical documents include:

• single-line diagram;
• wiring diagrams;
• control-panel layout;
• terminal diagrams;
• motor lists;
• cable schedules where applicable.

Any changes discovered during FAT should ultimately be incorporated into controlled updated drawings.

7.20 Motor Verification

For relevant motors verify:

• identification;
• rating;
• direction of rotation where appropriate;
• drive control;
• overload protection;
• operating status.

For a compression machine this may include:

• main motor;
• feeder motor;
• lubrication motor/pump;
• auxiliary drives.

7.21 Instrument Checks

Instrumentation FAT may verify:

• instrument tag;
• manufacturer;
• model;
• range;
• accuracy specification;
• installation;
• signal;
• calibration status;
• PLC/HMI indication.

A typical table:

7.22 Calibration Evidence

If measurements generated during FAT are used as objective test evidence, the suitability and calibration status of the relevant test instruments should be established.

Review as applicable:

• instrument ID;
• calibration certificate;
• calibration date;
• due date;
• traceability;
• measurement range.

A sticker alone should not automatically be treated as complete evidence of measurement suitability.

7.23 Loop and Signal Checks

Where appropriate, FAT can verify:

Field Device

↓

PLC Input

↓

PLC Logic

↓

HMI Display

↓

Alarm/Control Output

For example:

Change simulated pressure input.

↓

PLC receives correct value.

↓

HMI displays corresponding value.

↓

Alarm activates at defined condition.

This can provide strong integrated functional evidence.

7.24 Automation FAT

Automated pharmaceutical equipment may require significant FAT effort.

Areas can include:

• PLC;
• HMI;
• SCADA;
• I/O;
• sequences;
• alarms;
• interlocks;
• recipes;
• access controls;
• electronic records;
• audit trails;
• reports;
• backup/configuration management.

The extent depends on intended use and risk. The master prompt also calls for additional lifecycle documentation for PLC/HMI/SCADA/DCS/MES-controlled systems rather than assuming identical testing for every computerized feature.

7.25 PLC Verification

FAT may verify:

• PLC manufacturer/model;
• hardware configuration;
• I/O modules;
• communication modules;
• program version;
• control logic;
• configured parameters;
• backup availability.

Critical PLC logic should be functionally challenged rather than only visually reviewed.

7.26 HMI Verification

Test applicable functions such as:

• login;
• navigation;
• start/stop;
• parameter display;
• parameter entry;
• equipment status;
• alarms;
• recipe selection;
• trends;
• reports;
• user roles.

The test should focus on intended use and risk.

7.27 SCADA Verification

Where SCADA is included, FAT may verify:

• communication;
• graphics;
• process values;
• alarms;
• trends;
• historian;
• user access;
• reports;
• electronic records;
• audit trail;
• data storage.

Site-specific infrastructure may require further SAT/OQ verification.

7.28 I/O Testing

An I/O test can verify:

Input Device → PLC → HMI

and

HMI/PLC → Output Device

Examples:

Digital Input

Guard switch opened.

Expected:

PLC receives guard-open signal.

Digital Output

PLC activates reject solenoid.

Expected:

Physical reject device actuates.

Analog Input

Simulate defined sensor signal.

Expected:

Correct engineering value displayed.

7.29 Alarm Testing

Critical alarms identified through risk assessment should be challenged.

A suitable alarm test should verify:

1. alarm trigger condition;
2. correct alarm message;
3. visual/audible indication where designed;
4. equipment response;
5. acknowledgement;
6. reset behavior;
7. alarm record/history where applicable.

7.30 Example Alarm Test

Test

Low lubrication pressure.

Method

Simulate or create the defined low-pressure condition using an approved method.

Expected Result

• correct alarm appears;
• equipment responds according to approved design;
• alarm is recorded where applicable;
• reset is possible only after required conditions are restored.

Evidence

• protocol observation;
• alarm printout/screenshot where appropriate;
• system record.

7.31 Interlock Testing

Interlocks should be challenged, not merely confirmed from drawings.

Example:

Guard Interlock

1. Operate machine under defined safe test condition.
2. Activate/open the designated guard.
3. Observe machine response.
4. Attempt restart where applicable.
5. Restore guard.
6. Verify reset/restart logic.

Acceptance criteria should derive from the approved specification.

7.32 Emergency Stop

Verify applicable emergency-stop devices.

Typical checks:

• identification;
• accessibility;
• actuation;
• machine response;
• reset;
• restart behavior.

Emergency-stop tests should be performed safely under defined conditions.

7.33 Sequence Testing

Sequence testing verifies that the equipment performs operations in the intended order.

For example:

Power ON
   ↓
System Initialization
   ↓
Safety Checks
   ↓
Utility Permissives
   ↓
Machine Ready
   ↓
Start Command
   ↓
Auxiliary Systems
   ↓
Main Operation
   ↓
Process Control
   ↓
Normal Stop

Failure conditions should also be evaluated where risk significant.

7.34 Permissive Testing

A permissive is a condition that must be satisfied before an operation can proceed.

Example:

Machine start may require:

• guards closed;
• emergency stop reset;
• lubrication available;
• required utility available;
• no critical fault active.

FAT should challenge important permissives.

7.35 Recipe Testing

For recipe-controlled equipment, FAT may verify:

• recipe creation;
• recipe naming;
• recipe selection;
• parameter configuration;
• parameter ranges;
• modification;
• saving;
• loading;
• deletion restrictions;
• access restrictions;
• version/change traceability where applicable.

7.36 Example Recipe Test

Requirement

Only authorized users may modify approved recipe parameters.

Test

Step 1: Login as Operator.

Step 2: Attempt recipe modification.

Expected:

Modification prevented.

Step 3: Login as authorized role.

Step 4: Modify permitted parameter.

Expected:

Modification permitted according to role.

Step 5: Review applicable audit/event record.

Expected:

Relevant change information is recorded as specified.

This links:

URS → Risk → Design → FAT Evidence

7.37 User Access Testing

Where role-based access is GMP relevant, FAT may challenge a user-role matrix.

Example:

The actual matrix must follow approved requirements.

7.38 Data-Integrity Checks

Where the system creates or manages GMP-relevant electronic data, FAT may include appropriate data-integrity checks.

Potential areas include:

• unique users;
• access levels;
• audit trails;
• timestamps;
• record generation;
• record retention;
• data modification;
• reports;
• configuration control;
• backup.

The FAT scope should reflect the system’s intended use rather than treating every electronic feature as equally critical.

7.39 Audit-Trail Testing

Where applicable, test whether defined GMP-relevant actions generate the required audit information.

Potential checks include:

• user identity;
• date/time;
• action/event;
• changed value where applicable;
• old/new value where supported/required;
• reason for change where configured;
• audit-trail availability;
• protection from ordinary-user modification.

7.40 Electronic Records

Where electronic records are part of intended use, FAT may verify:

• record generation;
• completeness;
• readability;
• retrieval;
• protection;
• storage behavior.

Site-dependent retention and infrastructure arrangements may need additional verification after installation.

7.41 Backup Testing at FAT

Where applicable, the supplier may demonstrate:

• PLC program backup;
• HMI configuration backup;
• SCADA configuration backup;
• recipe backup;
• database backup.

However, site backup architecture may differ.

Therefore, successful vendor backup testing does not automatically replace site backup/restore verification.

7.42 Power Failure/Recovery Testing

Where risk significant, FAT may simulate loss of power.

Verify:

• equipment enters appropriate state;
• data are handled as designed;
• parameters are retained as specified;
• recipes are retained;
• system restarts appropriately;
• unsafe automatic restart does not occur where prohibited by design;
• alarms/events are generated as applicable.

7.43 Communication Failure Testing

For integrated equipment, FAT may simulate communication loss between:

• PLC and HMI;
• machine and SCADA;
• machine and peripheral equipment;
• machine and metal detector;
• machine and checkweigher;
• upstream/downstream systems.

Verify defined failure response.

7.44 Interface Testing

Consider a compression line:

Compression Machine
       ↓
    Deduster
       ↓
 Metal Detector
       ↓
   Checkweigher
       ↓
 Collection System

The FAT should assess critical interface signals where the equipment can be assembled/integrated at the supplier.

Examples:

• start permissive;
• stop signal;
• reject signal;
• downstream fault;
• upstream/downstream interlock.

7.45 Safety Testing

Applicable safety functions may include:

• emergency stop;
• guard switches;
• door interlocks;
• overload protection;
• safety relay;
• pressure protection;
• motor protection.

Safety testing should follow appropriate engineering/EHS requirements in addition to any GMP relevance.

7.46 Documentation Review During FAT

FAT should not focus only on machine operation.

Review applicable turnover documents such as:

• GA drawings;
• P&IDs;
• electrical drawings;
• pneumatic diagrams;
• instrument list;
• component list;
• material certificates;
• calibration certificates;
• manuals;
• software versions;
• alarm list;
• I/O list;
• spare-parts list.

7.47 Document Status

Documents may be classified:

• Approved
• Reviewed
• As-built pending
• Draft
• Open
• Not available
• Not applicable

Outstanding documentation should enter the FAT punch list where necessary.

7.48 FAT Test Script Format

A strong FAT test sheet can use:

7.49 Example FAT Script — Guard Interlock

FAT Test ID

FAT-SAF-007

Requirement

URS-SAF-015

Objective

Verify the designated guard interlock operates according to the approved functional specification.

Prerequisites

• equipment powered;
• safety system operational;
• approved safe test condition established.

Method

1. Confirm guard is closed.
2. Start equipment.
3. Open designated guard according to test procedure.
4. Observe equipment response.
5. Attempt restart with guard open where safe/appropriate.
6. Close guard.
7. perform required reset.
8. verify permitted restart.

Expected Result

System behavior shall comply with the approved safety/interlock design.

Actual Result

Evidence

Status

PASS / FAIL

7.50 Example FAT Script — Critical Alarm

FAT Test ID

FAT-ALM-012

Objective

Verify the defined critical alarm is activated at the specified condition and produces the designed system response.

Method

1. Establish normal operating condition.
2. Simulate the defined abnormal condition.
3. Observe alarm activation.
4. Record alarm message.
5. Verify associated machine response.
6. Acknowledge alarm.
7. Restore normal condition.
8. Verify reset.
9. Review alarm history where applicable.

Acceptance Criteria

The correct alarm and system response shall occur in accordance with the approved functional specification.

7.51 Example FAT Script — User Access

Test ID

FAT-CSV-021

Objective

Verify unauthorized users cannot perform restricted recipe modifications.

Method

1. Login using Operator account.
2. Navigate to recipe configuration.
3. Attempt restricted modification.
4. Record response.
5. Login using authorized account.
6. Perform permitted action.
7. Review applicable audit record.

Acceptance

Access rights shall correspond to the approved user-role matrix.

7.52 FAT Data Recording

Execution records should be contemporaneous and attributable.

Record:

• actual observations;
• measured values;
• equipment configuration;
• software version;
• instrument IDs;
• date/time;
• tester;
• witness where applicable;
• attachments;
• deviations.

Do not simply write “OK” where actual measured results are needed.

7.53 Screenshots

Screenshots may provide useful evidence for computerized functions.

They should be:

• relevant;
• identifiable;
• attributable to the test where possible;
• legible;
• linked to the protocol step;
• retained in a controlled manner.

A screenshot should supplement, not replace, a properly executed test.

7.54 Raw Data

Potential FAT raw data include:

• measurements;
• system printouts;
• alarm records;
• audit-trail records;
• trend outputs;
• test-instrument readings;
• photographs where justified;
• screenshots;
• vendor test records.

Evidence intended for qualification leverage should be retained appropriately.

7.55 FAT Deviations

A FAT deviation/discrepancy occurs when:

• expected result is not achieved;
• acceptance criterion fails;
• protocol cannot be followed;
• unexpected equipment behavior occurs;
• design deficiency is discovered;
• test configuration differs materially.

A suitable lifecycle is:

Observation

↓

Document

↓

Assess Impact

↓

Investigate

↓

Correct

↓

Approve Retest

↓

Retest

↓

Disposition

↓

Closure

7.56 Do Not Test Until Pass

An unacceptable practice is:

Fail → adjust machine → repeat test → record only passing result.

The failed result is part of the evidence.

Instead:

Fail → document discrepancy → assess/investigate → correct → authorize retest → retain original and retest evidence.

This principle becomes even more important when FAT evidence will later be relied upon during qualification.

7.57 FAT Punch List

Not every FAT observation necessarily prevents shipment.

A punch list provides controlled management of outstanding items.

Example categories:

Category A — Shipment Blocking

Examples:

• critical GMP function fails;
• major safety issue;
• critical software incomplete;
• significant design noncompliance.

Category B — Must Close Before SAT/IQ/OQ

Examples:

• noncritical document updates;
• agreed configuration correction;
• minor software change requiring verification.

Category C — Minor

Examples:

• cosmetic correction;
• labeling;
• minor documentation formatting.

Categories and disposition rules should be predefined by the project/PQS.

7.58 FAT Punch-List Template

7.59 Software Changes During FAT

Software changes during FAT require careful control.

Example:

Alarm fails.

↓

Vendor modifies PLC logic.

↓

Test passes.

This is not sufficient by itself.

Ask:

• What was changed?
• What version changed?
• What other functions could be affected?
• Is regression testing required?
• Is the final software backed up?
• Is documentation updated?
• Which tests must be repeated?

7.60 Regression Testing

When software changes, regression testing should assess potentially affected functions.

Example:

Change to reject logic may affect:

• reject activation;
• reject confirmation;
• alarms;
• batch counts;
• event records.

Therefore, testing only the changed screen may be inadequate.

7.61 Configuration Baseline at FAT

At successful FAT completion, establish a configuration baseline where relevant.

Potential records include:

• PLC software version;
• HMI version;
• SCADA version;
• firmware versions;
• recipe configuration;
• parameter list;
• user-role configuration;
• alarm configuration;
• I/O list.

This baseline helps demonstrate whether the site-installed system is the same configuration that was tested.

7.62 FAT Report

A FAT report should summarize the execution and disposition.

Recommended sections:

1. Objective
2. Scope
3. Equipment/system identification
4. FAT dates/location
5. Participants
6. Protocol executed
7. Test summary
8. Deviations
9. Retests
10. Punch-list items
11. Software/configuration status
12. Documentation status
13. Outstanding actions
14. Overall conclusion
15. Shipment recommendation
16. Approval

7.63 FAT Test Summary

Example:

The summary should not hide original failures.

7.64 Release for Shipment

FAT completion does not necessarily mean automatic shipment.

A formal decision should assess:

• critical tests completed;
• critical deviations resolved;
• shipment-blocking punch items closed;
• software baseline established;
• equipment safe for shipment;
• documentation adequate;
• remaining items assigned;
• site impact understood.

7.65 Shipment Decision

A practical decision tree:

FAT Completed
     ↓
Any Critical Failure?
 ┌───┴───┐
Yes      No
 │        ↓
Hold   Open Items?
Shipment  │
 │      ┌─┴─┐
Correct Yes  No
 │       │    │
Retest   ↓    ↓
 │    Assess  Release
 └────→ Impact for Shipment
          ↓
 Can safely close at site?
      ┌───┴───┐
     No      Yes
      │        │
    Hold    Conditional
 Shipment    Release

7.66 FAT Does Not Replace SAT

Transportation and installation introduce new variables.

SAT may therefore verify:

• shipment damage;
• equipment identity;
• reassembly;
• utility connections;
• site configuration;
• site interfaces;
• communication;
• FAT punch-list closure.

Thus:

FAT proves factory-state performance; SAT confirms the relevant site-installed state.

7.67 FAT Does Not Automatically Replace IQ

Some FAT evidence may support IQ.

Examples might include:

• material certificates;
• component identification;
• factory instrument records;
• software baseline;
• vendor drawings.

But IQ still needs to establish that the installed equipment is appropriate and corresponds to the approved configuration.

7.68 FAT Does Not Automatically Replace OQ

FAT may contain extensive functional testing, but OQ addresses operation of the installed/configured system within its qualification strategy.

Some FAT tests may potentially be leveraged rather than mechanically repeated.

The decision should be documented and risk based.

7.69 What FAT Evidence Can Potentially Be Leveraged?

Potential examples include:

• material verification;
• component verification;
• instrument information;
• I/O testing;
• PLC logic testing;
• HMI testing;
• alarm tests;
• interlock tests;
• sequence tests;
• recipe tests;
• user-role tests;
• audit-trail tests;
• software-function tests.

Whether they can actually be leveraged depends on evidence quality and whether the tested state remains representative.

7.70 Conditions for Leveraging FAT Evidence

Before relying on FAT evidence, assess:

1. Approved/Controlled Test

Was testing conducted against an appropriately controlled protocol/test specification?

2. Traceability

Can the test be linked to:

• URS;
• risk;
• design requirement?

3. Acceptance Criteria

Were acceptance criteria predefined?

4. Actual Results

Were actual observations recorded?

5. Raw Data

Is supporting evidence retained?

6. Test Instruments

Were relevant instruments suitable and appropriately calibrated?

7. Personnel

Are executors/witnesses identifiable?

8. Deviations

Were failures transparently documented and resolved?

9. Configuration

Is the FAT configuration equivalent to the delivered configuration?

10. Change Control

Were changes after FAT identified and assessed?

11. Transport/Installation Impact

Could shipment or installation invalidate the test?

12. Site Dependency

Does the function depend on site utilities, networks, environment or interfaces?

Only after considering these factors should FAT evidence be relied upon for later qualification.

7.71 Example — Suitable FAT Leverage

Function

PLC calculation logic.

FAT

Comprehensively challenged under an approved test protocol.

After FAT

• software frozen;
• checksum/version controlled;
• no relevant software changes;
• site installation does not alter calculation logic.

Qualification Strategy

Site verifies:

• correct software version;
• correct configuration;
• applicable inputs/interfaces.

The documented FAT evidence may then support the qualification package according to the approved strategy.

7.72 Example — FAT Evidence Should Be Reverified

Test

Emergency-stop function.

FAT Result

Pass.

After FAT

Machine is:

• dismantled;
• transported;
• rewired;
• reassembled.

Because installation may affect safety wiring and physical function:

Site verification remains appropriate.

7.73 Example — Site-Dependent Function

FAT

SCADA interface tested using vendor simulation.

Site

Actual interface connects to the site’s network/database.

The FAT proves vendor-side functionality.

It does not fully demonstrate the actual site interface.

SAT/OQ should verify the site configuration.

7.74 Supplier Testing vs User-Witnessed FAT

Suppliers may perform extensive internal testing before formal FAT.

Supplier internal testing can be valuable, but formal reliance depends on:

• documentation quality;
• supplier capability;
• approved specifications;
• traceability;
• risk.

High-risk functions may warrant direct user/SME witnessing according to the project strategy.

7.75 Supplier Assessment and FAT Leverage

Confidence in supplier evidence is stronger when the organization understands supplier capability.

Factors include:

• quality system;
• engineering controls;
• software-development controls;
• test practices;
• documentation;
• change management;
• deviation handling;
• personnel competence.

Greater reliance on supplier testing generally requires greater confidence that supplier evidence is trustworthy and applicable.

7.76 FAT and Traceability

A strong FAT should integrate with the requirement traceability matrix.

Example:

This supports the broader traceability model requested in your source: URS → Risk Assessment → Design → FAT/SAT → IQ → OQ → PQ → SOP/Control → Final Qualification Status.

7.77 Worked Example — Tablet Compression Machine FAT

The master prompt specifically identifies the tablet compression machine as the complete worked qualification example and calls for critical testing of compression force, pre-compression force, turret speed, fill depth, tablet-weight control, feeder operation, motors, lubrication, guards, interlocks, emergency stop, reject mechanisms, interfaces, alarms, recipes, user access, audit trails, electronic records, power recovery and backup where applicable.

A practical FAT could include:

Mechanical

• hopper;
• feeder;
• turret;
• punches/dies interface;
• compression rollers;
• discharge;
• reject chute;
• guards.

Process Controls

• turret speed;
• feeder speed;
• fill-depth adjustment;
• pre-compression;
• main compression.

Safety

• guards;
• emergency stop;
• interlocks.

Automation

• PLC;
• HMI;
• alarms;
• permissives;
• sequence;
• recipes.

Data Integrity

Where applicable:

• users;
• access levels;
• audit trails;
• records;
• reports;
• backup.

7.78 Example Compression-Machine FAT Matrix

7.79 Worked Risk-to-FAT Example

URS-CM-025

The machine shall provide automatic rejection for defined reject conditions.

↓

Risk Assessment

Failure could allow identified nonconforming tablets to remain in the accepted stream.

↓

Design

PLC-controlled reject system with physical reject mechanism and defined monitoring.

↓

FAT

1. Establish machine operation.
2. Generate defined reject condition.
3. Verify reject command.
4. Verify physical rejection.
5. Verify applicable indication/alarm.
6. Verify rejected/accepted counts where designed.
7. Repeat appropriate challenges.

↓

Result

Pass / Fail

↓

Evidence

Test record + relevant electronic/physical evidence.

↓

Site Strategy

Reverify critical installed functionality during OQ as justified.

7.80 FAT RACI Example

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

Actual roles depend on the company’s PQS and contractual arrangements.

7.81 Common FAT Deficiencies

7.82 Inspector Perspective

An inspector may ask:

Why did you rely on this FAT test instead of repeating the test during OQ?

A strong answer demonstrates:

• risk assessment;
• approved leverage strategy;
• adequate FAT protocol;
• predefined acceptance criteria;
• raw evidence;
• controlled configuration;
• absence/assessment of post-FAT changes;
• site verification where necessary.

Another likely question:

Was the software changed after FAT?

The organization should be able to provide:

FAT Version → Change History → Delivered Version → Installed Version → Qualification Version

7.83 Inspector Question — FAT Failure

An inspector may ask:

Show me what happened when this test initially failed.

Strong evidence should contain:

Original Failure

↓

Deviation/Discrepancy

↓

Investigation

↓

Correction

↓

Impact Assessment

↓

Approved Retest

↓

Retest Result

↓

Final Disposition

The original failure should remain visible in the lifecycle record.

7.84 FAT Best Practices

A mature FAT program should:

• start from approved requirements;
• use risk assessment;
• identify critical aspects;
• involve appropriate SMEs;
• use predefined acceptance criteria;
• challenge critical functions;
• retain raw evidence;
• document actual results;
• control software versions;
• document failures;
• control punch lists;
• establish shipment criteria;
• identify tests intended for later leverage;
• maintain traceability.

7.85 FAT Inspection-Readiness Checklist

Before FAT

• □ URS available
• □ Risk assessment available
• □ DQ status acceptable
• □ Critical aspects identified
• □ FAT protocol approved
• □ Acceptance criteria defined
• □ Drawings/specifications available
• □ Vendor internal testing completed
• □ Test instruments identified
• □ Calibration status acceptable
• □ Software version identified

Mechanical

• □ Equipment identification
• □ Major components
• □ Dimensions/interfaces
• □ Product-contact parts
• □ Materials
• □ Surface condition
• □ Guards
• □ Cleaning accessibility
• □ Product path

Electrical

• □ Control panel
• □ Wiring
• □ Component identification
• □ Motors
• □ Drives
• □ Protection
• □ Earthing
• □ Drawings

Instrumentation

• □ Instrument identification
• □ Range
• □ Calibration status
• □ Signals
• □ Display
• □ Critical loops

Automation

• □ PLC
• □ HMI
• □ SCADA where applicable
• □ I/O
• □ Operating sequences
• □ Permissives
• □ Alarms
• □ Interlocks
• □ Recipes
• □ User access
• □ Audit trails where applicable
• □ Reports/records where applicable
• □ Backup where applicable
• □ Failure/recovery tests

Documentation

• □ GA drawings
• □ P&IDs where applicable
• □ Electrical drawings
• □ Instrument list
• □ I/O list
• □ Alarm list
• □ Material certificates
• □ Calibration records
• □ Manuals
• □ Software/configuration records
• □ Spare-parts information

Closure

• □ All tests accounted for
• □ Failures documented
• □ Deviations assessed
• □ Retests authorized
• □ Raw evidence retained
• □ Punch list generated
• □ Critical items closed
• □ Software baseline recorded
• □ Outstanding actions assigned
• □ FAT report completed
• □ Shipment disposition approved

7.86 FAT Release Gate

A useful formal gate is:

Equipment shall not be released for shipment until FAT results, deviations, critical punch-list items, configuration status, and outstanding risks have been reviewed and dispositioned according to the approved project/quality procedures.

However, this should be treated according to the company’s approved PQS and contractual strategy rather than as a universal regulatory wording requirement.

7.87 Golden Rule of FAT

The objective of FAT is not to watch the supplier run the machine successfully for an hour.

The critical question is:

Has objective evidence demonstrated that the manufactured and configured system satisfies the important approved design and functional requirements, including credible failure/challenge conditions, sufficiently to justify shipment and support the subsequent qualification lifecycle?

Part 7 — Key Takeaway

A strong pharmaceutical FAT converts the approved design into physical and functional evidence before the equipment leaves the supplier.

The evidence chain should be:

URS → GMP Impact → Risk Assessment → DQ → Critical Aspects → FAT Test → Actual Result → Raw Evidence → Deviation/Punch-List Closure → Configuration Baseline → Shipment Decision

The greatest value of FAT comes from finding problems before they reach the pharmaceutical site, particularly problems involving:

mechanical design + product-contact construction + instrumentation + PLC/HMI/SCADA + alarms + interlocks + sequences + recipes + user access + applicable data-integrity controls.

FAT evidence may also be leveraged during subsequent qualification rather than automatically repeating identical tests, but only when the evidence is sufficiently controlled, traceable, reliable, relevant to the delivered configuration, supported by predefined acceptance criteria and raw data, and unaffected by subsequent modification, transportation, installation, site configuration, or other changes.

The next lifecycle stage is Part 8 — Site Acceptance Test (SAT), covers shipment damage, installation verification, utility connections, instruments, electrical and safety checks, PLC/HMI/SCADA and communications, alarms, basic functional testing, FAT punch-list closure, and site-specific differences after the equipment arrives at the pharmaceutical manufacturing facility.

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.