What is UAT sign-off?
UAT sign-off is the written acceptance of a release by the people it is built for, such as the product owner and business stakeholders, after they have tested it against the agreed acceptance criteria. ISTQB defines user acceptance testing as "a type of acceptance testing performed to determine if intended users accept the system" (ISTQB Glossary), and the sign-off is where that decision is recorded.
A good user acceptance testing sign-off records four things: what was tested, on which build, what is still open, and who accepted it on what terms. It does not mean the release has no bugs, and it should never pretend to. It means both sides agree the release meets the criteria they set, with known issues listed rather than hidden.
UAT is not the same as QA. The delivery team checks that the build works as specified before anyone else sees the release; UAT is the product owner and business users checking that it meets their needs. If they are the first to find broken links or a failing form, QA was skipped. Our website QA checklist covers that step.
The UAT sign-off template
Copy the tables below into a document or spreadsheet and replace everything in square brackets. Keep one UAT sign-off document per release, not per project, so each approval points at a specific build.
For smaller releases, the same UAT sign-off template works as a short release sign-off form or a website sign-off template: keep sections 1, 4, 5 and 8, and drop the rest.
| Field | Details |
|---|---|
| Product owner | [Name, and the team or business unit that owns the product] |
| Project | [Project name] |
| Release | [Release name or version, for example Phase 1 launch or v1.4.0] |
| Delivery team and lead | [Team name, lead's name] |
| Ticket or contract reference | [Epic, ticket or change request number, or the contract reference where one applies] |
| UAT window | [Start date] to [end date] |
| Field | Details |
|---|---|
| Journeys and features | [For example: book a consultation, checkout, account area] |
| Pages or templates | [For example: home, service, product, basket, contact] |
| Requirements covered | [Links to requirements, specifications or tickets] |
| Changes since last sign-off | [List, or first release] |
| Field | Details |
|---|---|
| Environment and URL | [Staging or UAT URL] |
| Build tested | [Build number, commit or deployment ID] |
| Browsers and devices | [As agreed, for example current Chrome, Safari, Firefox and Edge; Safari on iPhone; Chrome on Android] |
| Test data and accounts | [Test accounts used; confirm no real customer data] |
| Integrations in test mode | [For example payments in sandbox, CRM test pipeline] |
| QA evidence | [Link to the QA or evidence report for this build] |
| ID | Acceptance criterion | Result | Evidence | Tested by, date |
|---|---|---|---|---|
| AC1 | [Example: a visitor can book a consultation for any open slot and receives a confirmation email within five minutes] | [Pass / Fail / Needs input / Not tested] | [Link or screenshot] | [Name, date] |
| AC2 | [Example: product prices include VAT and match the approved price list] | [Result] | [Link] | [Name, date] |
| AC3 | [Example: checkout can be completed with a keyboard alone] | [Result] | [Link] | [Name, date] |
| AC4 | [Criterion] | [Result] | [Link] | [Name, date] |
| Issue | Summary | Severity | Status | Agreed action and date |
|---|---|---|---|---|
| [ID] | [Short description, with a link to the ticket] | [Critical / Major / Minor / Cosmetic] | [Open / Fixed, awaiting retest] | [Fix before launch / Fix by date after launch / Accepted as is] |
| [ID] | [Summary] | [Severity] | [Status] | [Action, date] |
| Severity | Meaning | Suggested rule for sign-off |
|---|---|---|
| Critical | A key journey is blocked, data is lost or wrong, or there is a security or legal risk | Fix and retest before launch |
| Major | A feature fails or misbehaves, and the workaround is painful | Fix before launch unless the approver accepts it in writing |
| Minor | Works, with a small problem and an easy workaround | Launch with a dated fix plan |
| Cosmetic | A visual or copy detail that does not affect use | Batch into a later release |
| Item | Reason | Risk and follow-up |
|---|---|---|
| [Example: load testing] | [Out of scope for this release] | [Plan before the spring campaign] |
| [Example: live payments] | [Test mode only during UAT] | [Smoke test on production after launch] |
| [Item] | [Reason] | [Follow-up] |
| Condition | Owner | Due |
|---|---|---|
| [Example: issues 3 and 7 fixed and retested before go-live] | [Delivery team] | [Date] |
| [Example: final privacy notice text supplied] | [Product owner] | [Date] |
| [Condition] | [Owner] | [Date] |
| Item | Details |
|---|---|
| Decision | ☐ Accepted ☐ Accepted with the conditions in section 7 ☐ Not accepted (reasons attached) |
| Statement | By signing, the approver confirms that the release and build described above have been tested against the criteria in section 4, and accepts it on the terms in sections 5 to 7. |
| Role | Name | Organisation | Signature | Date |
|---|---|---|---|---|
| Approver: product owner (authorised to accept) | [Name] | [Team or business unit] | [Signature] | [Date] |
| Stakeholder (optional) | [Name] | [Team or business unit] | [Signature] | [Date] |
| Delivery lead | [Name] | [Delivery team] | [Signature] | [Date] |
Prefer a file? Download the UAT sign-off template for Excel or Google Sheets (.csv), the Markdown version (.md), or get the whole release readiness kit (.zip) with a release readiness report and checklists. Free under CC BY 4.0. Scoring a release first? Try the release readiness scorecard.
Want evidence for UAT and client sign-off attached to every result, not just a filled-in template? Start with a free 45-day trial, no card.
Work email only. We keep your email, team size, plan choice and the page you joined from, only to contact you about the ShipperAG pilot. No spam.
How the UAT sign-off process works
Sign-off goes smoothly when it is planned at the start of the project, not improvised at the end. These are the steps for a typical release.
- Agree acceptance criteria early. Write testable criteria into the tickets or specification before the build starts.
- Agree the UAT plan. Who tests, the UAT window, the environment, the severity scale, where issues are logged and who signs.
- Finish your own QA first. Hand over a build that has passed internal QA, with the evidence attached, so UAT is about fit rather than basic bugs.
- Freeze the build. Everyone tests one identified build. Changes made during UAT go into a new build and a new round.
- Log issues in one place. One tracker or shared sheet, not a mix of email, chat and calls.
- Triage together. Sort each item into defect, change request or question, and agree its severity against the scale.
- Fix and retest. Record which build each fix was retested on.
- Complete and sign. Fill in the UAT sign-off template with results, open issues, conditions and what was not tested, then collect signatures from the named approver.
- Launch and close the conditions. Track each condition to its due date and record when it is met.
How to write acceptance criteria an approver can sign
Good acceptance criteria are specific, testable and agreed before the build. If two people could disagree about whether a criterion passed, rewrite it.
| Vague | Testable |
|---|---|
| The site should be fast | Home, category and product templates have a Largest Contentful Paint of 2.5 seconds or less in the agreed test set-up |
| Forms work | A valid contact form submission reaches the sales inbox within five minutes and creates a CRM lead with every field filled |
| It works on mobile | Every journey in section 2 can be completed in Safari on iPhone and Chrome on Android without sideways scrolling |
| The site is accessible | Key journeys pass the WCAG 2.2 AA checks listed in the test plan, with any exceptions named |
A simple pattern helps: given a starting situation, when the user does something, then an observable result follows. For accessibility criteria, agree which checks are automated and which need a person; our guide to AI accessibility testing explains the split.
Common UAT sign-off pitfalls
These are the mistakes that turn sign-off into a dispute, and each one is cheap to prevent.
- Vague acceptance criteria. "Works well on mobile" cannot pass or fail. Every criterion needs an observable result.
- Scope creep dressed as bugs. New requests arrive as "issues" during UAT. A defect is a failure against the agreed criteria; anything else is a change request with its own estimate.
- Sign-off by email thread. "Looks good, go ahead" in a long thread rarely names the build, the scope or the open issues, and it is hard to find later. Record the decision in a dated document.
- The wrong signatory. A junior stakeholder approves, then their manager disagrees. Name the approver with authority in the UAT plan.
- Testing the wrong build. Testers work on staging while fixes are still landing. Freeze and identify the build.
- No end date. UAT drifts for weeks while the launch date slips. Agree the window and what happens if feedback is late.
- Hidden gaps. Nothing is listed as not tested, so the approver assumes everything was. Say plainly what was out of scope.
How an evidence report makes sign-off faster
Approvers sign faster when they can see the evidence behind each result instead of being asked to trust a summary. An evidence report that sorts every result into four states maps straight onto the UAT sign-off template above.
- Verified
Checked and reproduced by an independent run. Goes into section 4 as a pass, with the evidence linked.
- Issue found
A real, reproduced failure with screenshots and steps. Goes into section 5 with a severity.
- Needs input
The requirements were unclear or contradictory. Becomes a question for the product owner, then a condition or a change request.
- Not covered
Outside what was checked, shown plainly. Goes into section 6.
The same structure makes sign-off defensible. If a problem appears months after launch, you can show what was checked, on which build, and who accepted which open items.
This is the report ShipperAG is built to produce. It checks each release against your requirements, design system and business rules, and re-runs every finding in a fresh session before reporting it. The report is a single HTML file that your team can approve, or share with stakeholders to review and sign. See a sample report from a real run, or read how it works.
UAT sign-off and contracts
Settle what sign-off means before UAT starts: in your release process and, where a contract applies, in the contract too. Make sure the sign-off document says the same thing. Points worth settling in writing:
- How acceptance works: the criteria, the UAT window, and how the approver accepts or rejects a release.
- What happens if the approver does not respond by the end of the window. Some contracts include deemed acceptance; agree it explicitly rather than assume it.
- How defects found after sign-off are handled, for example during a warranty or support period.
- Who can accept the release, and in what form: a signed document, an e-signature or a named approval in your project tool.
- How change requests raised during UAT are estimated, priced and scheduled.
This section is general information, not legal advice. Ask a qualified adviser to review your contract terms.
Sources: ISTQB Glossary, user acceptance testing (checked 19 September 2026).