Acceptance testing regime: what the decision maker looks at
An acceptance testing regime sets out how a delivered system is checked against agreed criteria before a customer signs it off and payment obligations complete. The person reviewing the result usually checks three things: the test protocol, the list of open defects sorted by severity, and whether the agreed criteria were met in substance, not just attempted on paper.
What the regime covers
A regime of this kind applies whatever the delivered system does. It covers the test plan, the environment the tests run in, the criteria for passing each scenario, and the classes of defect that block sign-off versus the classes that do not.
The underlying technology can raise its own separate question that sits next to acceptance testing rather than inside it. Where the delivered system also carries tokenised rights or a crypto-asset claim, the test needs to confirm the same representation the token is meant to carry: Crypto services — when a token claims to carry. That is a separate check, run alongside the functional test, not a substitute for it.
What changes once testing starts
Once the test window opens, several deadlines start running at once. The window itself closes on a fixed date. Silence during that window is treated differently across contracts, and this is where most disputes actually start.
Many regimes treat an unanswered test window as deemed acceptance once the deadline passes without a written rejection. That single default rule decides when the warranty period begins and when the final payment falls due. A party that lets the window close without a written response usually loses the argument that testing never finished.
| Stage | What happens | Who typically signs off |
|---|---|---|
| Test readiness | Environment and test data confirmed, criteria fixed in writing | Project lead on both sides |
| Execution | Test cases run against agreed scenarios, defects logged with a reference number | Test lead, technical reviewer |
| Defect triage | Defects classed by severity, fixes scheduled or formally waived | Steering committee or the named decision maker |
| Sign-off | Acceptance certificate issued, or a written rejection sent within the window | Contract-designated decision maker |
What to do before testing opens
- Fix the acceptance criteria in writing before delivery starts — the customer's project lead confirms them in the test plan, not after the fact.
- Set severity classes for defects, typically critical, major and minor, so a single small fault cannot block sign-off — both sides agree the classes in advance.
- Schedule a fixed test window with a stated response deadline — the supplier proposes dates, the customer confirms them in writing.
- Log every defect with a reference number, date and severity on the day it is found — the tester who finds it records it, not a manager later.
- Escalate silence in writing to the named decision maker as soon as a deadline passes — the project manager sends the escalation, not the tester.
- Keep the signed acceptance certificate, or the written rejection, on file — whoever issues the document also stores the copy that proves the date.
Who decides and how long it takes
The contract usually names the decision maker directly: a steering committee, a named individual, or a specific role such as the customer's project sponsor. Where the contract is silent on this point, the practical answer is whoever signed the original order or statement of work, escalating to their line manager if they do not respond.
The stated test window is the main driver of timing. A short window of a few working days moves fast and rewards a supplier who tests thoroughly before submission. A longer window, common on larger systems, shifts risk toward the customer, because a slow internal review can eat most of the time without anyone noticing until the deadline is close.
Two or three situations that change the answer
If the fixed test window closes and the customer has not responded, most regimes treat that silence as acceptance by default. The supplier should send a written notice as the window closes, stating that silence will be treated as sign-off, and keep proof that the notice was sent.
If defects are found but all of them are classed as minor, the regime typically allows conditional acceptance: the system is accepted, and the minor defects move to a punch list with its own fix deadline rather than blocking payment.
If the parties disagree on how severe a defect is, the decision moves to whichever forum the contract names for that kind of dispute. Until that forum rules, neither side should treat the disputed item as settled in its own favour.
What this page does not cover
This page does not calculate damages for a late or failed acceptance, and it does not name a court or arbitral forum for a dispute — those points sit in the contract itself, not in a general procedure. It also does not cover data-breach notification that might occur during testing; that runs on its own separate clock and follows its own separate process.
Sources and limit
This page draws on procedural practice observed across technology delivery contracts. It does not cite a single statute, because an acceptance testing regime is set by the contract itself, not by one overriding law.
Where the underlying dispute turns on a counterparty's standing rather than on the test protocol, the relevant registry limit is described separately: Counterparty in Estonia and its limits explained.
Where the dispute turns on whether a document was actually delivered at all, the same registry logic applies to that record: Document in Poland and the evidence.
For how source tiers and delivery routes are classified across the registry as a whole, see Sources by tier and delivery route overview and its.
Checked: 4 June 2025.
Related reading
Change control procedure: what the decision maker looks at covers what happens once the delivered system needs to change after acceptance has already been signed off.
Frequently asked questions
How long does an acceptance testing regime usually take?
The stated test window controls this, and windows commonly run from a few working days to several weeks depending on system size. The real driver is how fast the customer's internal review moves, not the technical testing itself.
Which documents do you need before testing can start?
A written test plan with fixed acceptance criteria, a defined severity scale for defects, and a stated response deadline. Without these three, there is nothing objective for either side to point to once a dispute starts.
What happens if the other side does not respond within the window?
Most regimes default to deemed acceptance once the deadline passes without a written rejection. The safer course is to send a written notice as the deadline approaches, stating explicitly what silence will be treated as.
If your test window is closing and the other side has gone quiet, get the escalation letter right before the deadline passes, not after.