FAT vs SAT Acceptance Criteria: Evidence and Punch-List Control
Factory Acceptance Testing (FAT) proves the build at the supplier; Site Acceptance Testing (SAT) proves the installed system meets the same intent in your real environment. When acceptance criteria and evidence expectations are vague, SAT turns into re-testing instead of confirming installation and integration.
A clean split between FAT and SAT keeps acceptance objective, keeps the punch list under control, and lets QA close the evidence package without delays.
TL;DR
- Derive acceptance criteria from URS and risk controls (ISO 14971) and split them into FAT vs SAT early.
- Define measurable limits, boundary conditions, and data capture requirements for every critical test.
- Run a single punch list with severity, owner, closure evidence, and approved carry-over rules.
- Package FAT evidence (protocols, raw data, configs, calibration) so SAT does not repeat FAT.
Why this matters
Regulatory drivers are clear: EU MDR and FDA 21 CFR 820 expect equipment qualification and documented acceptance evidence for production and quality-critical systems. ISO 13485 document control expectations also apply — uncontrolled vendor documents or missing revisions can invalidate the record.
Business drivers are just as real: unclear criteria lead to repeat testing, delayed site readiness, and supplier disputes about what was actually delivered.
What “good” looks like
Good FAT/SAT execution looks boring in the best way: traceable requirements, predictable evidence, and no surprises on site.
- Critical URS requirements mapped to FAT or SAT with a risk rationale (ISO 14971).
- Acceptance criteria include limits, tolerances, and failure mode challenges, not just nominal runs.
- FAT fixes design/build issues; SAT confirms installation, utilities, and interface integration.
- Punch-list items are classified as pre-ship vs SAT close-out with clear closure evidence.
- Software/firmware versions are frozen or controlled with defined retest triggers.
A practical way to keep this tight is a single acceptance criteria table with the test location (FAT or SAT), method, limits, data capture expectations, and approval owner. That table becomes the master reference for both protocols and prevents late scope drift.
Evidence / Artifacts checklist
Keep evidence lean but explicit so QA can trace every claim to an artifact.
- Approved FAT protocol and SAT protocol with acceptance criteria and roles.
- Signed acceptance criteria table with FAT/SAT split and test identifiers.
- Requirements traceability matrix linking URS → risks → tests → results.
- FAT test report with raw data, deviations, and objective pass/fail statements.
- Configuration and version records (PLC/HMI/firmware) plus parameter snapshots.
- Calibration certificates for measurement tools used during FAT/SAT.
- Punch list with owner, severity, closure evidence, and approved carry-overs.
- As-built drawings, wiring/pneumatic schematics, and utility verification results.
- Training or readiness sign-off for operators and maintenance (if required for SAT).
Common audit / QA questions
- Which requirements are proven at FAT vs SAT, and why?
- Where is objective evidence for limits, alarms, and failure modes?
- How are open punch-list items controlled and approved for SAT?
- Which configurations were tested, and are they locked for SAT?
- Are all measurements traceable to calibration records?
Typical failure modes
- Acceptance criteria use subjective language or omit measurable limits.
- FAT evidence is summarized without raw data or traceability to URS.
- Punch-list carry-overs have no risk assessment or close-out plan.
- Configuration changes after FAT invalidate SAT without retest triggers.
- Supplier and QA disagree on what constitutes closure evidence.
When to call for help
If FAT results are ambiguous, the punch list keeps growing, or SAT scope is drifting into re-testing, a short evidence and criteria review can unblock the project. For a focused FAT/SAT evidence check, contact me.