The Problem With Multiple Independent FAT Protocols
When a project involves multiple suppliers, the natural tendency is for each supplier to produce their own FAT protocol, run their own FAT at their own facility, and hand over their own FAT report. On the surface this looks organised — each supplier is responsible for their scope. In practice it creates a structural gap in the GMP evidence package.
The IQ that follows the FAT is executed against the integrated system — the PLC communicating with the SCADA, the SCADA writing to the historian, the historian feeding the reports. If the FAT evidence is fragmented across three supplier reports, none of which tested the integrated interfaces, the IQ team arrives on site to qualify an integrated system that has never been formally tested as a system. Every interface issue discovered during IQ is a deviation that traces back to an integration gap the fragmented FAT structure allowed to exist.
The most common source of multi-supplier FAT deviations is not individual system failures — it is interface failures. The PLC passes its own FAT. The SCADA passes its own FAT. When you connect them, the OPC communication drops under load, the alarm handshaking doesn't work as designed, and the historian tags have different engineering units to what the PLC is outputting. None of these failures are visible in a fragmented FAT structure. They all appear as deviations at IQ — on site, under QA witness, at full project day-rate cost.
Three Models for Multi-Supplier FAT Structure
There are three practical models for structuring FAT evidence on a multi-supplier project, each suited to different project configurations and risk profiles.
Model 1 — Integrated FAT at a Single Location
All suppliers bring their components to a single location, integrate the system, and execute one protocol under one set of QA witnesses. This produces the cleanest GMP evidence — one FAT report covering the complete integrated system — and is the approach the Validation Plan typically assumes when it says "FAT at supplier facility."
The challenge is logistics. All suppliers must be ready simultaneously. If the SCADA supplier is two weeks behind the panel builder, the integrated FAT slips two weeks. For projects where the control panel, SCADA application, and server hardware all come from the same SI, this model is straightforward. When they come from different companies with different project schedules, coordination risk is high.
Model 2 — Component FATs Followed by Integration FAT
Each supplier runs a component-level FAT covering their own scope. The lead SI then runs a separate integration FAT — typically at the lead SI's facility or the SCADA supplier's facility — that tests the interfaces between components with all parties present. The integration FAT protocol explicitly references the component FAT reports as prerequisites, confirms their outcomes, and then tests the integrated behaviours that were not testable in isolation.
This is the most practical model for most multi-supplier pharma projects and is the recommended approach when components come from different locations. The key governance requirement is that the relationship between the component FAT protocols and the integration FAT protocol is explicit — each document references the others, and the overall FAT scope coverage across all documents is traceable to the URS and FDS requirements.
Model 3 — Separate Independent FATs
Each supplier runs and approves their own FAT independently, with no integration testing phase. This model is acceptable only when the interfaces between supplier scopes are genuinely trivial — for example, where the only interface is a hardwired discrete signal that will be verified during the SAT loop check. For systems with OPC-DA/UA communication, historian integration, SCADA-to-PLC data exchange, or any software-to-software interface, this model defers all integration risk to site — where it becomes deviation risk.
Who Owns the Integration FAT
On a multi-supplier project, someone must be accountable for the integration FAT — the document, the execution, and the report. This accountability should be defined in the Validation Plan and RACI matrix before the project starts, not decided informally when integration FAT week arrives.
The natural owner is the lead SI — the supplier responsible for the primary control system that all other components integrate into. If the PLC and SCADA come from the same SI, that SI owns the integration FAT. If they come from different suppliers, the client's Validation Lead typically needs to designate an integration lead, because neither supplier will naturally take ownership of testing the other's interface behaviour.
The integration FAT owner is responsible for: writing the integration FAT protocol and obtaining QA approval; coordinating all supplier participation; maintaining the single deviation log for integration-phase deviations; and producing the integration FAT report. Sub-supplier component FAT reports are referenced as supporting evidence, not absorbed into the integration FAT report.
Each FAT produces its own deviation log. A deviation found during the integration FAT that is caused by a fault in a sub-supplier's component is still logged in the integration FAT deviation log — because it was discovered during the integration FAT. The root cause investigation may conclude it originated in the sub-supplier's scope, but the deviation record lives in the document where the failure was observed. Do not transfer deviations between protocol deviation logs retroactively — it creates a document integrity issue.
Scoping Each Supplier's FAT Protocol
Under Model 2, each supplier's component FAT protocol must have an explicit scope boundary that makes clear what it covers and — equally important — what it explicitly excludes. The exclusions are the interface points that will be tested in the integration FAT.
A typical scope boundary for a PLC/panel FAT in a multi-supplier project includes: all PLC application logic, all I/O signal simulation with forced inputs and signal generators, power failure and recovery, safety interlock sequences, and alarm generation at the PLC level. It explicitly excludes: OPC communication to SCADA (interface), historian tag writing (interface), and SCADA alarm display and acknowledgement (SCADA scope).
The SCADA FAT covers: all HMI screens and navigation, user management and access control, alarm display and acknowledgement at the SCADA layer, trend historisation with locally injected test data, and report generation. It explicitly excludes: live OPC data from PLC (not available at SCADA-only FAT), end-to-end loop signal accuracy (requires PLC connection).
The integration FAT then covers everything that requires both systems active: OPC tag connectivity verification, end-to-end signal flow from simulated field through PLC through SCADA to historian, alarm origination in PLC and display in SCADA, write-back commands from SCADA to PLC, and power failure scenarios with both systems present.
Managing the Shared Deviation Log During Multi-Supplier FAT
The Master Deviation Ledger is a project-level document. During a multi-supplier FAT, deviations from all FAT events — component and integration — are logged in the project MDL. The MDL reference numbers are sequential across all events. This is important because the phase gate condition for proceeding from FAT to IQ requires zero open Category A deviations across all FAT activities — not just the integration FAT.
Practically, one person should own the MDL during FAT weeks — typically the Validation Lead or the integration FAT lead. Sub-supplier engineers should not have direct edit access to the master MDL; they raise deviations verbally or in writing to the MDL owner who records them formally. This preserves the integrity of the deviation record and prevents duplicate entries, numbering gaps, or deviations that were verbally agreed as closed but never formally recorded.
Software Version Control Across Suppliers
One of the most important FAT phase gate conditions is that the software version tested at FAT is the version that will be delivered to site. On a single-supplier project this is straightforward. On a multi-supplier project, there are multiple software version baselines to manage — PLC application version, SCADA application version, historian configuration version, server OS baseline, and potentially a mechanical control system version from the OEM skid supplier.
Each FAT protocol should document and hash the software version it tested. The integration FAT should document all component versions present during integration testing and verify that these match the versions documented in the respective component FAT reports. Any version increment between component FAT and integration FAT — even a minor patch — requires a change note explaining what changed and why re-testing is or is not required for the changed components.
The integration FAT sign-off page should include version confirmation fields for every software component in scope. This creates a single record of the integrated software baseline that was witnessed at FAT and will be shipped to site. The SAT and IQ then verify that this exact baseline arrived and was installed.
The FAT template (FAT-SYS-001) includes a software version and hash documentation section, a force table clearance record, and a structured deviation log — designed for a single-supplier FAT but easily extended for multi-supplier use by adding supplier scope columns to the scope table and adding version confirmation rows for each supplier's software baseline. The deviation management structure in the MDL (MDLSYS001) handles deviations from any project phase in a single sequential register. The framework gives you the document architecture; the multi-supplier coordination structure described in this article is what you add on top for complex project configurations.