Acceptance testing regime: stages and deadlines
An acceptance testing regime is the sequence of steps a delivered system goes through before the customer signs it off as accepted. It runs from delivery notice through test execution, defect classification and remediation, ending in sign-off or in deemed acceptance once a deadline lapses. Miss a step in that sequence, and silence usually resolves the question for you, rather than leaving it open for a later dispute.
How the regime typically unfolds
Most technology contracts treat acceptance testing as a fixed sequence rather than a single event on a single day. The vendor delivers a version or a module, the customer runs the test scripts agreed in advance, and any issues found are logged and classified by severity before the contract decides what happens once the window closes. The stages below appear, in this order, in the great majority of technology delivery contracts, though the length of each stage is a matter for negotiation rather than a fixed rule.
| Stage | What happens | Who normally acts |
|---|---|---|
| Delivery notice | Vendor confirms the system or module is ready for testing against agreed criteria | Vendor |
| Test window opens | Customer runs the agreed scripts and records the outcome against each criterion | Customer |
| Defect log | Issues found during testing are recorded and classified by severity | Both sides, jointly |
| Remediation | Vendor fixes defects that sit above the agreed severity threshold | Vendor |
| Re-test | Customer confirms that the fix resolves the logged defect | Customer |
| Sign-off or deemed acceptance | Customer signs the acceptance certificate, or the deadline lapses and acceptance is deemed | Customer, or the clock itself |
The last row is where most disputes begin. A contract that ties acceptance to silence, rather than to a signature, shifts risk onto whichever side is slower to act once the deadline starts running. A contract that requires an active certificate, by contrast, puts the burden on the customer to say no in writing, which tends to produce fewer surprises later.
What changes once testing starts
Before the test window opens, delay usually costs the vendor time and, in some structures, money. Once the window opens, the clock generally runs against the customer instead, because inaction from that point tends to favour whoever drafted the deadline. This is not unique to software delivery. A comparable structure governs when the fixed period in Delisting tokenised rights explained and the deadline converts inaction into a final outcome for a tokenised asset, without anyone signing off on the result.
Once the clock starts against the customer, three practical things change. The burden of showing that a defect exists shifts to whoever raises it, rather than sitting with the vendor by default. The severity classification agreed earlier becomes decisive, because a defect rated as minor rarely stops the clock on its own. And any silence that runs past the deadline is read as acceptance, not as an unresolved question that can be picked up later.
Steps to run before you sign
Preparation happens before the test window opens, not during it. Waiting until testing has started to agree what "acceptance" means tends to produce disputes about wording rather than about the system itself. The following sequence keeps the deadline working for both sides rather than against one of them.
- Confirm the acceptance criteria in writing before delivery, so the test scripts measure exactly what was promised, not a looser version of it.
- Assign a single decision-maker on the customer side who has the authority to sign the acceptance certificate, so sign-off does not stall while someone senior is found.
- Check whether personal data will flow through the system during testing; if it will, review the underlying Data processing agreement overview and its limits before the window opens, not after testing has begun.
- Set the severity thresholds for defects in advance, in writing, rather than negotiating them once a specific defect has already appeared.
- Calendar the deemed-acceptance date the moment the test window opens, not the day before it lapses, so nobody discovers the deadline has already passed.
- Keep a written log of every defect raised, including minor ones, in case the severity classification is challenged later.
Who decides, and by when
Acceptance is a contractual decision, not a judicial one. The forum is whatever body the contract names for the purpose: a joint steering committee, a named technical lead, or the customer's project sponsor. The deadline is whatever the contract sets for the test window and for the remediation period that follows a defect; neither extends automatically once it has started running, whatever the reason for the delay.
If the contract is silent on who signs, acceptance defaults to whoever holds the authority to bind the customer as a matter of contract law generally, which is rarely the project manager who actually ran the tests. That gap is worth closing before delivery, not after a dispute has already started.
Common variations
If your contract sets a fixed test window with no automatic extension, treat every delay caused by the vendor as a reason to pause the clock in writing. Do not assume the clock pauses itself simply because the delay was not your fault.
If the contract allows partial acceptance module by module, run each module's test window and defect log separately, so a delay on one module does not block sign-off on a module that has already passed.
If no acceptance certificate exists and the system has already been in live use for several weeks, deemed acceptance has probably already occurred, whatever the calendar written into the contract technically says.
If the vendor disputes a defect's severity rating rather than fixing it, treat that dispute as a separate step with its own deadline, rather than letting it silently extend the remediation period.
What this page does not resolve
This page sets out the sequence and the deadlines that usually apply across technology delivery contracts. It does not calculate what a missed deadline costs under your specific contract, and it does not decide whether a particular defect crosses the severity threshold you agreed. Both questions depend on the wording actually used in your contract, not on a general regime that applies uniformly across every agreement.
Sources and their limits
The stages set out above reflect how acceptance testing is typically structured in technology delivery contracts as a matter of drafting practice, not a single statutory procedure that applies regardless of contract wording. No fixed rule sets the length of a test window; that is a matter for negotiation between the parties. Reviewed 2025.
Where a subprocessor is added mid-project, the risk profile behind the acceptance regime changes, because the system being tested is no longer the one originally scoped; the Counterparty report when a subprocessor is added what it sets out what that change costs to get wrong.
Where the test scripts or the acceptance criteria exist only in translation, a dispute over wording quickly becomes a dispute over which language version actually governs; the Document report when a translation is disputed explained covers that situation in more detail than this page can.
Related reading
Acceptance is frequently followed by change requests once the system is live and in use. The Change control procedure technology contract sets out the stages and deadlines that typically follow sign-off.
Frequently asked questions
How long does acceptance testing regime take in practice?
Length depends entirely on what the contract sets for the test window and the remediation period; there is no standard duration across contracts generally. What matters more than the number of days agreed is whether the clock has a written pause mechanism for delay caused by the vendor itself.
Which documents are needed to start?
At minimum, the file needs the acceptance criteria, the agreed test scripts, and a defect severity scale that both sides have signed. If personal data will be processed during testing, the data processing agreement should already be in place before the window opens, not arranged once testing is under way.
What happens if the other side does not respond?
Silence during an acceptance window is rarely a neutral outcome. Most acceptance clauses convert an unanswered test window into deemed acceptance once the deadline passes, so non-response tends to favour whichever side drafted the deadline in the first place.
Next step
If a transfer mechanism used by the same vendor is being questioned separately, review When a transfer mechanism is questioned in detail before the acceptance deadline in this contract closes.