How a Pharma FAT Differs From a Standard FAT
In most industries, a Factory Acceptance Test is a functional demonstration — you show the client that the system does what the spec said. If everything works, the client signs the delivery note and the system ships.
In pharma, a FAT is a formal quality event under GAMP 5. It generates controlled documentation that becomes part of the validated system's permanent quality record. The QA witness attending your FAT is not there to be impressed by the engineering. They are there to verify that:
- A formally approved FAT protocol exists before testing begins
- Every test is executed exactly as written — no improvisation, no skipping steps
- Every result is recorded contemporaneously in the protocol — not reconstructed afterwards
- Any deviation from expected results is formally raised and addressed
- The software version being tested is the version that will be delivered and installed
The protocol must be approved before FAT begins — and the protocol references your approved URS and FDS, so those must exist first. You cannot run informal testing, then write up the protocol to match. This catches engineers who are used to testing as they go and documenting afterwards. In pharma, the document comes first.
The FAT Protocol — What It Must Contain
The FAT protocol is a controlled document — it has a document number, version history, and requires formal approval signatures before it can be executed. A complete pharma FAT protocol contains:
- Purpose and scope — what the FAT covers and what it does not
- References — links to URS, FDS, HDS, and the software version being tested
- Roles and responsibilities — who runs each test, who witnesses, who has QA sign-off authority
- Test environment description — hardware configuration, software versions, test instruments
- Prerequisites — items that must be in place before FAT can begin (calibration certs, force table clear, approved drawings)
- Test cases — structured test cases covering all functional requirements
- Deviation procedure — how deviations are raised, assessed, and resolved
- Force audit section — mandatory verification that all PLC forces are cleared before sign-off
- Acceptance criteria — the conditions under which the FAT can be declared passed
- Sign-off page — signatures from supplier lead tester and client QA witness
The Force Audit — What It Is and Why It's Non-Negotiable
In any PLC commissioning environment, engineers use PLC forces — overriding input and output values in the force table to simulate field conditions during testing. This is normal practice. The problem arises when forces are left active on a system that is then shipped to site and installed in a GMP environment.
The force audit is a mandatory pre-release check that every entry in the PLC force table is empty before the FAT can be signed off. In TIA Portal, this means opening the Force Table and confirming zero active forces. In Studio 5000, confirming all I/O forces are removed. The QA witness initials every item in the force audit section of the protocol.
A system that ships with active forces is a serious GMP incident. The force audit is the gate that prevents it.
Handling Deviations During FAT
When a test case produces a result that doesn't match the expected outcome, it's a deviation. In pharma, the response is not to quietly fix it and re-run the test. The correct process is:
- Record the actual result in the protocol exactly as observed
- Mark the test case as FAIL
- Raise a formal deviation entry in the Master Deviation Ledger (MDL) and flag it in the traceability matrix
- Assess the impact — is this a critical finding, a major finding, or an observation?
- Implement a corrective action — software fix, hardware change, or procedure update
- Re-test the affected test case and record the new result
- Close the deviation in the MDL with reference to the re-test
Deviations at FAT are not failures — they are the system working as designed. A FAT with zero deviations is actually suspicious to an experienced QA reviewer. It suggests the test cases weren't challenging enough, or that results were massaged. Finding and closing deviations professionally is a sign of a mature validation process.
How to Prepare — The Week Before FAT
Most FAT failures happen not because the system doesn't work, but because the documentation isn't ready. The week before FAT, run through this checklist:
- FAT protocol reviewed, approved, and printed — with signature pages ready
- Software version locked — no changes after the version recorded in the protocol
- PLC force table cleared and verified
- All test instruments calibrated with valid certificates on site
- Signal generators, multimeters, and loop calibrators inventoried and tested
- MDL printed and ready — blank entries for any deviations that arise
- Client QA witness briefed on the protocol structure and their sign-off obligations
- Spare copies of all approved drawings referenced in the protocol
The FAT protocol template includes the full structure above — including the force audit section, attendee sign-in log, software version record, and deviation summary table. Every test case follows the same structured format your QA witness expects.