FAT/SAT Documentation: A Checklist That Survives an Audit
What actually needs to be in a Factory and Site Acceptance Test package, and the gaps that show up most often during regulatory review.
Factory Acceptance Testing and Site Acceptance Testing produce the paper trail that proves a control system does what it was designed to do, before and after it leaves the integrator's shop. In regulated industries, this isn't paperwork for its own sake — it's frequently the first thing an FDA, EPA, or internal QA auditor asks to see.
Why FAT/SAT documentation gets scrutinized
FAT proves the system works as specified before it ships and before installation costs are sunk. SAT proves it still works correctly once installed in its real environment, accounting for anything that changed between the shop and the site — different power quality, different network conditions, field wiring differences. Auditors care about both because a system that passed FAT but was never re-verified on site has an unverified gap exactly where real-world failures tend to happen.
FAT documentation checklist
- Approved functional design specification, version-matched to what's being tested
- I/O point-by-point verification log, with simulated signal source noted for each point
- Alarm testing log — every alarm triggered and acknowledged at least once, with response time noted
- Interlock and safety logic verification, including forced-fault testing where applicable
- HMI screen-by-screen walkthrough sign-off against the design spec
- Network communication verification between all panels/nodes in the test configuration
- Punch list of any deviations, each with a disposition (fixed before ship / accepted deviation / deferred to SAT)
- Sign-off from both integrator and client witness, dated
SAT documentation checklist
- Confirmation that all FAT punch list items were closed or formally re-dispositioned
- Field wiring verification against as-built drawings, not just the original design
- Power quality check at the installed location (voltage, grounding, noise)
- Full I/O re-verification with actual field devices, not simulated signals
- Network performance verification under actual site conditions
- Operator walkthrough and sign-off, confirming the system matches training material
- As-built documentation package finalized and version-locked
- Final sign-off from client operations and quality representatives
Gaps that show up most in audits
| Gap | Why it happens |
|---|---|
| Version mismatch between tested spec and final as-built | Design changes made during commissioning aren't fed back into the controlled document |
| Alarms tested at FAT but not re-verified at SAT | Assumption that simulated alarm logic and real field alarm logic are equivalent |
| Missing witness signatures on punch list closure | Verbal sign-off treated as sufficient under schedule pressure |
| No record of who performed each test | Single technician runs multiple roles without distinct sign-off |
None of this is complicated, but all of it is tedious under schedule pressure — which is exactly when it tends to get skipped. Building the documentation template before testing starts, with every required field already in place, removes the temptation to fill gaps in later from memory.