Site Acceptance Test is a formal test of equipment, software or a system after it has been installed at the customer’s site. It confirms that the delivered solution works in the real operating environment, including integration, configuration and operational checks against acceptance criteria.
What the test is used for
A Site Acceptance Test is the final on-site validation step before handover. It confirms that the installed equipment, software or system behaves as expected in the customer’s environment, where real wiring, integrations, local settings and operating conditions can expose issues that lab testing did not.
Because it happens after deployment, SAT is less about proving the design in theory and more about proving the delivered configuration in context. That makes it a practical checkpoint for installation quality, interface correctness, operational readiness and acceptance against the agreed criteria.
What a Site Acceptance Test covers
The scope is usually tied to the contract, project plan or acceptance specification. Typical checks include start-up behaviour, control logic, alarms, communications, interlocks, configuration consistency and any functions that depend on the customer site rather than a test bench.
A strong SAT also verifies that the delivered solution still works when connected to surrounding systems, shared services and site-specific constraints. This is why SAT often uncovers mismatches between vendor assumptions and the reality of the live environment, especially when an installation depends on multiple teams or third-party components.
When the subject is industrial or operational technology procurement, the OT Product Procurement Guide is relevant because it treats FAT and SAT checks as part of secure-by-demand buying and acceptance requirements.
Why Site Acceptance Test matters to security and resilience
SAT is important because some failures only appear once a system is installed in its real trust boundary. Configuration drift, unexpected network exposure, weak integration assumptions and misaligned operating procedures can create availability problems or weaken control assurance even when the delivered product passed earlier testing.
It also matters because acceptance is the last easy point to catch deployment defects before the system becomes business-critical. If a fault is missed here, the organisation may inherit hidden operational fragility, later rework, or a control gap that is harder and more expensive to correct after go-live.
For connected environments, the final on-site review should also confirm that authentication, access paths and external dependencies are behaving as intended. Authoritative control baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 help frame that kind of validation as part of broader control assurance and operational governance.
How Site Acceptance Test fits into delivery and handover
In practice, SAT sits between installation and formal acceptance. It is the point where the supplier, integrator and customer confirm that the delivered system is complete enough to be handed over, supported and operated under real conditions.
That means SAT is as much a governance event as a technical one. It establishes whether the delivered scope matches what was purchased, whether exceptions are documented, and whether any residual issues are accepted, deferred or treated as blockers to go-live.
Where the test confirms that the live environment contains identity-bearing controls, service connections or privileged functions, the organisation should also validate the surrounding access model using references such as NIST Cybersecurity Framework 2.0 and, for connected service environments, the SPIFFE workload identity specification as a conceptual guide to trust and workload verification.
Site Acceptance Test and post-handover confidence
A completed SAT does not prove the system will never fail, but it does give the customer evidence that installation, configuration and site-specific behaviour have been checked against acceptance criteria. That evidence becomes especially valuable when the system is safety-critical, production-critical or difficult to restart.
It is also the point at which unresolved issues should be recorded cleanly, because vague handover language often becomes a future support dispute. A disciplined SAT outcome should leave no ambiguity about what was tested, what passed, what was waived and what still requires remediation after handover.
For teams that want a broader testing lens, the OWASP Web Security Testing Guide is useful when the delivered solution includes web-facing components that need structured validation before acceptance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CA-2 — Control Assessments | SAT is a site-level control assessment of installed systems and configurations. |
| Recommendation — Document and execute site acceptance checks that verify installed controls against acceptance criteria. | ||
| NIST CSF 2.0 | PR.IR-01 — Networks and environments are configured to support system resilience objectives | SAT validates the real operating environment and installed configuration before handover. |
| PR.DS-01 — Data-at-rest is protected | SAT often confirms that deployed storage and configuration protect data in the live site context. | |
| Recommendation — Validate the installed environment against resilience and operating assumptions before go-live. Verify that deployed storage, configuration and handling meet protection expectations on site. | ||
| OWASP ASVS | V13 — Configuration | SAT checks that the delivered system is configured correctly in its real deployment setting. |
| Recommendation — Test the live configuration and deployment settings against the accepted baseline. | ||
Related resources from NHI Mgmt Group
- Who is accountable when wallet acceptance fails a fraud or identity test?
- What breaks when a browser automation helper decrypts credentials from every saved site instead of the single site under test?
- How should security teams test XML-based web applications for cross-site scripting risks?
- What is the difference between a portable on-site NAAT test and a traditional laboratory PCR workflow?