Igor Yussupov
UAT sign-off is the written statement from the business owner that the release does what the business needs and can go live. It should be given by one named person who owns the outcome, not by QA or the delivery team, and it should record what was tested, what is still open, who accepted it and when. A sign-off that says only "approved" cannot be checked later. Below is what to record, a template, and how to handle sign-off when defects are still open.
What sign-off is
Sign-off is the point where the people who asked for the system say it is acceptable. It marks the end of the UAT round and the decision to release. It is not a test result, and it is not a guarantee that the software has no defects. It is a decision, made with the evidence in front of the approver, and the record of that decision.
It sits at the end of the round described in the UAT guide, and it relies on the criteria you set in the plan. If you have not written those yet, start with the UAT test plan template.
Who should approve
The approver should be the person who is accountable for the business outcome the system supports. Usually that is a business owner, a head of department or a product owner on the business side. Three rules help:
- One name. A committee cannot sign. If several departments are affected, each can give a recommendation, but one person gives the final acceptance.
- Not the person who built it. QA and the delivery team report the evidence. They should not also be the ones accepting it.
- A named stand-in. If the approver is on leave in go-live week, someone with the same authority must be able to sign.
Other roles feed in. Testers say what they found. QA summarises the defects and their severity. The project manager tracks the schedule. Severity and priority are set before the approver sees the list, so the decision is about the business impact, not about what a bug should be called.
What to record
A good record lets someone who was not in the room understand the decision six months later. Include:
| Field | What goes in it |
|---|---|
| Release | Project, release name and the build or version tested. |
| Scope | What was covered and what was out of scope. |
| Testers and dates | Who took part and when the round ran. |
| Results | Scenarios planned, run, passed and failed. |
| Open defects | Each open defect with its severity and the decision: fix first, accept, or defer, with an owner and date. |
| Exit criteria | Whether each was met. If one was not, say so. |
| Decision | Accepted, accepted with conditions, or not accepted. |
| Approver and date | Name, role and date. A signature or a dated reply that is stored with the project. |
Copy-paste sign-off template
UAT SIGN-OFF: [Project] [Release / version]
Build tested: [version or build id]
Round dates: [start] to [end]
Testers: [names or roles]
SCOPE
Covered: [workflows / roles]
Not covered: [out of scope]
RESULTS
Scenarios planned: [n] Run: [n] Passed: [n] Failed: [n]
EXIT CRITERIA
[ ] [criterion 1] Met / Not met
[ ] [criterion 2] Met / Not met
OPEN DEFECTS
ID Summary Severity Decision (fix / accept / defer) Owner Date
[ID] [one line] [level] [decision] [name] [date]
DECISION
[ ] Accepted
[ ] Accepted with the conditions listed above
[ ] Not accepted. Reason: [reason]
Approver: [name, role]
Date: [date]
Stand-in (if applicable): [name]Keep the signed record where an auditor or a new project manager would look for it: with the project, not in a personal inbox. If your contract or company policy requires a particular form, use that form and treat the template as the checklist behind it.
Signing off with open defects
Almost every release ships with something open. The question is whether anyone decided that on purpose. Accepting with open defects is fine when:
- The defect is listed with its severity and a clear description.
- The approver has seen it and chosen to accept it, with a workaround where one exists.
- There is an owner and a date for the fix, or a stated reason it will not be fixed.
The deciding information is in the reports: what the tester did, what failed, and how often. That is why report quality matters at this stage. A one-line report forces the approver to guess, and they will either block the release out of caution or accept something they do not understand. UAT exit criteria covers how to set the thresholds for these decisions before the round starts.
When to refuse
Withholding sign-off is part of the approver's job. Refuse, or accept only on written conditions, when:
- A main scenario was not run, or failed, and has no agreed workaround.
- A defect affects money, personal data or legal obligations.
- The environment changed during the round, so the results do not describe the build going live.
- The testers who took part do not represent the people who will use the system.
After sign-off
A sign-off describes one build. If the build changes afterwards, even for a small fix, someone needs to decide whether the acceptance still holds. For a small, well-understood change, a short written confirmation from the approver may do; for anything touching the tested workflows, retest the affected scenarios. Write down which it was.
FAQ
Is UAT sign-off legally binding?
That depends on your contract and your jurisdiction. In many projects the contract refers to acceptance, and sign-off is the evidence of it, so treat the record seriously. This article is not legal advice; check with whoever owns the contract.
Who is responsible for UAT sign-off?
The business owner or product owner who is accountable for the outcome. QA and the project team supply the evidence and recommendations, but they should not be the ones accepting.
Can you sign off UAT with open defects?
Yes, if each open defect is listed with its severity, the approver has chosen to accept it, and there is an owner and a date for the fix. Unlisted, unexplained defects are the problem, not open ones.
Does SnagRelay handle sign-off?
No. SnagRelay collects the defects testers find, with the element, console errors, failing requests and steps, and sends them to your tracker or its inbox. The plan, the scenarios and the approval stay in the tools you use for them. The defect list it produces is what the approver reviews. See UAT testing with SnagRelay.