Factory Acceptance Test

A Factory Acceptance Test (FAT) is a formal, witnessed verification conducted at the supplier’s premises to demonstrate that equipment, automation, and associated software meet defined requirements prior to shipment. FAT typically proves functionality against the User Requirements Specification (URS) and Design Qualification (DQ), exercising safety interlocks, control logic (ISA‑88 phases/equipment modules), alarms, I/O mapping, recipes, reports, audit trails, and external interfaces (e.g., MES/LIMS/ERP per ISA‑95). EU GMP Annex 15 recognizes FAT as a means to reduce on-site work when rigorously planned and documented; however, FAT does not replace Site Acceptance Testing (SAT) or Installation/Operational Qualification (IQ/OQ).

In regulated industries, FAT materials become GxP evidence subject to data integrity expectations (21 CFR Part 11, EU GMP Annex 11 for computerized systems) and to good documentation practices. Under GAMP 5, supplier testing can be leveraged when supplier capability is assessed, scope is risk-based (ICH Q9), and traceability is maintained from URS to executed tests and deviations. The aim is to ship only when the system demonstrates fitness-for-intended-use and residual risks are explicitly documented for closure at SAT/IQ/OQ.

FAT occurs after design freeze/DQ and prior to shipment, bridging engineering and site qualification. It validates core functions in a controlled vendor environment, using calibrated instruments and emulation where field conditions are not fully available. Its outputs—executed protocols, defect logs, as-built configurations, calibration certificates—feed commissioning/SAT and reduce duplicate testing if equivalence is justified. FAT planning must anticipate site constraints so that test coverage dovetails with what will be reverified locally (utilities, environmental, recipes, site-specific interfaces).

Effective FAT begins with a risk-based plan (ICH Q9) that prioritizes testing of functions critical to patient safety, product quality, and data integrity. The FAT protocol should state scope, out-of-scope items (e.g., site utilities), roles and responsibilities (supplier, owner, QA), acceptance criteria, data capture methods, and deviation handling. It must include a requirements-to-test traceability matrix that references the latest, approved URS and DQ. Test data collection should specify instruments (with calibration status), software versions/builds, and test fixtures/emulators to be used.

• Traceability: Unique IDs map URS requirements to test steps and results.
• Configuration control: Frozen bill of materials, firmware/software baselines, parameter sets.
• Test independence: Witnessing by the owner’s QA/validation; separation of preparatory dry-runs from formal execution.
• Data integrity: Metadata, time-stamps, user attributions, and secure storage of raw records (Part 11/Annex 11).
• Deviations: Predefined grading, impact assessment, and closure paths (at FAT vs deferred to SAT/IQ/OQ).
• Change control: Handling of any design change discovered/implemented during FAT.

Acceptance criteria must be objective and quantitative where feasible: setpoint tracking within tolerance, alarm annunciation times, interlock response times, recipe phase transitions, and report content/audit-trail completeness. Criteria for simulated signals must define acceptable fidelity (e.g., I/O emulation latency, scaling) so that reuse arguments at OQ remain defensible.

When the system under FAT includes computerized components (PLC/DCS/SCADA, batch engine, HMI, historian, MES edge adapters), the test evidence becomes subject to electronic records controls. Under 21 CFR Part 11 and Annex 11, ensure that audit trails are enabled for GxP-relevant actions, that user roles and access controls are configured, and that electronic signatures applied to executed FAT tests are attributable, unique, and linked to content. GAMP 5 (2nd ed.) recommends leveraging supplier testing based on software classification and supplier assessment; for configurable platforms, FAT should focus on configuration verification, security hardening, exception paths, and reporting.

• Security model: Role-based access, password policies, lockout, and session management verified at FAT baseline.
• Audit trail: Create/modify/delete events for recipes, parameters, and setpoints; time-synchronization validation.
• Electronic signatures: If applied during FAT, ensure controlled accounts, meaning of signature steps, and signature manifestation.
• Data export/reporting: Verify completeness, accuracy, and contextual metadata for batch/lot reports.
• Backup/restore: Demonstrate recoverability of configurations and records to a known good state.

FAT for automated equipment should exercise ISA‑88 equipment modules, control modules, and phases using representative recipes and site-intended operating ranges. Interlocks and permissives are challenged, abnormal conditions are simulated, and alarm priorities, suppression rules, and shelving behaviors are verified (alignment with alarm philosophy). Where MES Level 3 interfaces are in scope (ISA‑95), FAT verifies handshake logic (start/stop/hold/abort), material lot/consumption messaging, equipment states, parameter download/upload, and electronic signatures at the handoff boundary. Message schemas (e.g., B2MML or vendor API) and error handling are tested against requirements.

• I/O checkout with calibrated simulators; analog scaling and engineering units verified.
• Recipe execution across nominal and edge-case ranges; phase reentry and exception paths.
• Alarm generation, classification, shelving timeout, and audit-trail entries.
• Batch/report generation, including genealogy and parameter-as-executed.
• Interface negative testing: malformed payloads, loss of comms, retry/backoff logic.

Document the exact firmware, controller models, network topology (as tested), and emulator versions. This clarity supports equivalence arguments and highlights any deltas to be re-challenged at SAT/OQ if the site uses different controllers, drivers, or network security controls.

To credibly leverage FAT outcomes on-site, compile a controlled evidence package: executed protocols with objective results, raw data and logs, calibration certificates, software build-of-materials, configuration exports (recipes, parameters, security), traceability matrix, and a consolidated deviation/punch-list with impact and closure plans. Align test IDs and requirement IDs with the site’s qualification numbering so traceability extends seamlessly through SAT and IQ/OQ.

1. Classify FAT tests by intended reuse (credit to SAT vs OQ vs information-only).
2. Perform a gap assessment for site-specific variables (utilities, environment, network hardening, data flows).
3. Define equivalence criteria (hardware/firmware versions, emulator fidelity, calibration status) for reuse acceptance.
4. Record any residual risks and assign closure at SAT/OQ with clear acceptance criteria.

Define deviation grading in the FAT plan, with immediate impact assessment on product quality, patient safety, and data integrity. For major deviations, require root-cause analysis and corrective action at FAT or a risk-justified deferral plan to SAT/OQ. Any design or configuration changes during FAT must follow formal change control, with re-testing of affected functions and updated baselines. The release-for-shipment decision package should summarize coverage vs. URS/DQ, open items, residual risks, and commitments for closure.

• Deviations linked to requirements, tests, and corrected builds.
• Risk assessment per ICH Q9(R1) with documented acceptance rationale.
• Updated as-built documentation and configuration snapshots after fixes.
• Formal owner QA approval with e-signature (where applied) and archival of final evidence set.

Frequent FAT weaknesses include: over-reliance on screenshots, lack of raw data linkage; incomplete coverage of exception paths; emulator fidelity not demonstrated; unverified audit trails and security; and undocumented design changes. Avoid these by enforcing raw data retention, ensuring time synchronization is validated, demonstrating emulator performance constraints, and requiring supplier configuration management. For interfaces, practice failure injection and verify recoverability and reconciliation logic. For data integrity, verify that audit trails capture who/what/when/why and are reviewable.

• Do not accept pass/fail with no objective measurements or logs.
• Prohibit retrospective protocol edits—use controlled deviations and addenda.
• Require proof of calibration for all measurement instruments used at FAT.
• Lock down software versions; treat hot-fixes under change control with impact analysis and targeted re-tests.
• Clarify which tests will be repeated or sampled at SAT/OQ to confirm site equivalence.

Because FAT executes at the supplier, define where GxP records are originated and archived. If electronic test execution tools are used, ensure they meet 21 CFR Part 11/Annex 11 expectations: validated platforms, controlled user access, secure audit trails, and e-signatures with clear meaning (review, approve, witness). If paper is used, control templates, ink signatures, and error corrections per GDP. Maintain a master index of all FAT artifacts and ensure handover into the owner’s document control with preserved metadata.

• Executed protocols with traceability matrix and cross-references.
• Raw datasets (e.g., PLC/HMI logs, historian exports, message captures).
• Certificates (materials, calibrations), and as-built drawings/recipes.
• Configuration exports and security role matrices.
• QA approvals and release-for-shipment certificates.

Orchestrating end-to-end traceability is central to making FAT creditable. The platform should tie URS requirements to DQ, to FAT tests and results, and onward to SAT and IQ/OQ, with change control and e-signature governance. Interfaces should be emulated and captured with consistent identifiers so that site re-tests can anchor on the same requirement IDs. Integration with MES/QMS/eBMR/eDHR/LIMS ensures that once a system moves into production, the qualified configuration aligns with executed batches and maintenance states.

Use this concise checklist to align FAT with GMP and computerized system expectations, and to maximize reusable evidence while minimizing site disruption.

• URS/DQ locked; risk assessment (ICH Q9) identifies critical functions and data integrity risks.
• Supplier assessment per GAMP 5 completed; roles and witnessing plan agreed.
• FAT protocol approved with objective acceptance criteria and traceability matrix.
• Calibrated instruments listed; emulator/simulator specifications documented and verified.
• Security configuration (roles, passwords), audit trails, time-sync validated at FAT baseline.
• ISA‑88 functional coverage (phases, interlocks, alarms) and exception paths exercised.
• ISA‑95 interfaces tested, including negative tests and message capture logs.
• Deviations graded, investigated, and either closed or risk-justified for SAT/OQ.
• Evidence package assembled: raw data, logs, configs, reports, certificates, and approvals.
• Release-for-shipment summary signed by QA; open-item closure plan defined for site.