A UAT sign-off is a short record where the person responsible for a project confirms testing is finished and states whether the product can go live. Copy the template below, fill in the brackets and get one named approver to complete it.

The form works best as the last step of a planned round. If you do not have one yet, start with the UAT test plan template.

UAT sign-off template

UAT SIGN-OFF FORMProject name: [Project name]Release or version: [Release number]UAT environment: [URL]UAT dates: [Start date] to [End date]Test plan reference: [Document name and version]TEST SUMMARYScenarios planned: [Number]Scenarios run: [Number]Scenarios passed: [Number]Scenarios failed: [Number]Scenarios not run: [Number and reason]ISSUE SUMMARYCritical: [Number] raised, [Number] fixed and retested, [Number] openHigh: [Number] raised, [Number] fixed and retested, [Number] openMedium: [Number] raised, [Number] fixed and retested, [Number] openLow: [Number] raised, [Number] fixed and retested, [Number] openDECISION (tick one)[ ] ACCEPTED. The product meets the agreed criteria and can go live.[ ] ACCEPTED WITH CONDITIONS. The product can go live once the conditions below are met.[ ] NOT ACCEPTED. The product cannot go live. Reasons are below.CONDITIONS AND OUTSTANDING ISSUES (repeat for each issue)Reference: [Issue ID]Description: [One line]Severity: [Critical / High / Medium / Low]Owner: [Name]Due date: [Date]Must be fixed before go-live: [Yes / No]REASONS FOR NOT ACCEPTING (if applicable)[Reasons]WHAT THIS SIGN-OFF COVERSThis form confirms acceptance of the scope in the test plan above.It does not remove any warranty or support commitment in the projectcontract. Requests made after this date are handled as change requests.SIGNATURESApprover name and title: [Name, job title]Signature:Date:Delivery lead name and title: [Name, job title]Signature:Date:

Paste it into Word or Google Docs and save it as a PDF once it is complete, so the agreed version cannot change.

A filled-in example

This example is invented. It is a fictional dental practice launching an online booking site, accepted on condition that one issue is fixed before launch.

UAT SIGN-OFF FORMProject name: Harbour Street Dental, online bookingRelease or version: Release 1.4UAT environment: https://uat.harbourstreet.exampleUAT dates: 11 January 2027 to 15 January 2027Test plan reference: HS-UAT-PLAN v1.1TEST SUMMARYScenarios planned: 18Scenarios run: 18Scenarios passed: 16Scenarios failed: 2Scenarios not run: 0ISSUE SUMMARYCritical: 1 raised, 1 fixed and retested, 0 openHigh: 2 raised, 2 fixed and retested, 0 openMedium: 5 raised, 3 fixed and retested, 2 openLow: 4 raised, 2 fixed and retested, 2 openDECISION[x] ACCEPTED WITH CONDITIONSCONDITIONS AND OUTSTANDING ISSUESReference: HS-31Description: Reminder text shows the old practice phone numberSeverity: MediumOwner: Dev teamDue date: 19 January 2027Must be fixed before go-live: YesReference: HS-34Description: Cannot add a second appointment from the confirmation pageSeverity: MediumOwner: Dev teamDue date: 5 February 2027Must be fixed before go-live: NoReference: HS-36Description: Logo slightly blurred on some tabletsSeverity: LowOwner: Dev teamDue date: 5 February 2027Must be fixed before go-live: NoReference: HS-37Description: Spelling error on the cancellation policy pageSeverity: LowOwner: Practice managerDue date: 20 January 2027Must be fixed before go-live: NoSIGNATURESApprover name and title: Dr Alina Nowak, Practice PrincipalSignature: A. NowakDate: 18 January 2027Delivery lead name and title: Sam Okoro, Project ManagerSignature: S. OkoroDate: 18 January 2027

The three possible decisions

Decision	Use it when	What happens next
Accepted	Exit criteria are met and nothing needs to change before launch	Book the go-live
Accepted with conditions	Core journeys work and the remaining issues have a clear owner and date	Fix pre-launch conditions, confirm them, then go live
Not accepted	A core journey fails, or the product does not match what was agreed	Fix, retest the affected scenarios and bring the form back

Save countless hours on your projects

Raise tasks in under 3 seconds using our revolutionary widget

When conditional sign-off makes sense

Conditional sign-off means "yes, as long as these specific things happen". It keeps a launch moving when the product is fit for use but a small number of items are still open.

Use it when:

No critical or high-severity issues are open
Every condition can be checked by someone, so there is no doubt when it is done
The client understands what the remaining issues mean for real users
There is a real reason to launch now, such as a campaign date

Avoid it when a core journey is broken, or when the list is so long that "conditional" really means "not ready". A condition should never be used to hide a blocker.

How to write a condition

Weak condition	Better condition
Fix the booking issues	HS-31: reminder text shows the correct phone number. Owner: dev team. Retested by the practice manager by 19 January.
Sort the content before launch	HS-37: spelling corrected on the cancellation policy page by the practice manager by 20 January.
Check mobile	HS-36: logo sharp at tablet widths. Fix due 5 February, after launch.

Each one needs an owner, a date and a test. Say what happens if a date is missed. For a pre-launch condition, the usual answer is that the go-live moves. For a post-launch condition, it goes to the support queue with the agreed priority.

Once a pre-launch condition is complete, record it. A one-line email from the approver ("HS-31 retested and confirmed, please go ahead") closes the loop and stays with the signed form.

Handling outstanding issues

Not everything has to be fixed before launch. Sort every open item into one of four groups:

Group	What it means	Example
Fix before go-live	Would harm users or the business if it shipped	Wrong phone number on an appointment reminder
Fix after go-live	A real issue, safe to live with for a short time	Second appointment cannot be added from the confirmation page
Backlog	Minor and not time-critical	Logo slightly soft on one tablet size
Not a defect	A new request or a misunderstanding	"Can we add online payments?" moves to change control

Keep this list as an issue log attached to the form, with the reference, severity, decision, owner, due date and the person who will retest. If you already track issues in a tool, export the list so nothing depends on memory. In QualityHive, which is our product, the Excel export is on the Mega plan and above.

Agree the severity rules with the client before testing. If you are starting from scratch, our piece on bug severity vs priority gives you plain definitions to reuse.

Who should sign

Sign-off belongs with one person who has the authority to accept the work. On most website projects:

Project	Approver	Also signs
Small business website	Owner or managing director	Agency project manager
Corporate marketing site	Marketing lead or director	Agency account or project lead
Online shop	Commercial or e-commerce lead	Agency project manager
Regulated sector	Business owner, with compliance review recorded	Delivery lead

Testers should not be the approver. They tell you what happened in testing. The approver decides what the business will accept.

Signing off by email

A signed PDF is the cleanest record. An email is often fine as long as it names the project and the decision. Send the summary and attach the issue log, then ask the approver to reply with one of the three decisions. Our UAT email templates include a sign-off request you can adapt.

Whichever format you use, check the contract. Some agency contracts have a deemed acceptance clause, which treats the work as accepted if the client does not respond within a set number of days. This article is general guidance rather than legal advice, so ask a solicitor if a contract dispute is likely.

When the client will not sign

Find out what is actually stopping them. It is usually one of three things:

A specific issue. Add it to the log with an owner and a date, then ask again.
Nervousness about the launch. Offer a short call to walk through the website handover and the plan for the first week.
The decision-maker has changed. Get the new person up to speed and confirm in writing that they hold the approval.

Avoid going live without a written decision. If the client insists on launching, ask for a one-line email confirming that, so the record is clear.

Bugs found after sign-off

Sign-off records the state of the product on that date. A defect found afterwards is usually handled under whatever warranty or support terms the contract sets out. New requests go through change control. Keep the form and the issue log together, because both will be needed if anyone disagrees later about what was accepted. Running the round through website UAT software means that history is already in one place, and our guide to user acceptance testing explains the steps that lead up to this point.

Revolutionise your QA processes

Frequently asked questions

Who signs off UAT?

One named approver from the business, usually the project sponsor or product owner, with authority to accept the work. The delivery lead normally countersigns to record that the summary is accurate.

Can you go live with open UAT issues?

Yes, if none of them are critical or high severity and each has an owner and a date. Record them on the form as outstanding issues or conditions.

Is an email enough for UAT sign-off?

Often yes, if it names the project and the decision and is sent by the person with authority. Attach the issue log and keep the email with the project records. Check your contract for specific requirements.

What is conditional sign-off?

It is acceptance that depends on specific, checkable actions being completed by agreed dates. The product is fit for use, and the listed items are the only ones still open.

What is the difference between UAT sign-off and project sign-off?

UAT sign-off accepts the results of testing. Project sign-off closes the whole engagement, often including training, handover and final payment. They can happen on the same day, but they cover different things.