Change control procedure: stages and deadlines
A change control procedure in a technology contract moves through five fixed stages: request, impact assessment, costing, approval, and implementation. A straightforward request usually clears all five stages within two to four weeks, provided both sides answer on time. The common cause of delay is not the substance of the change. It is silence past the agreed response window.
What actually changes once a request is filed
Filing a change request freezes the original delivery plan for the specific item under review. Delivery dates elsewhere in the contract do not move automatically. Only the change itself, and anything that directly depends on it, is put on hold until the parties sign off or reject the request in writing.
This matters for risk allocation. A party that keeps building a dependent module without waiting for sign-off usually cannot later claim that the pending change caused the delay. The freeze clock runs from the date the request was formally logged under the contract's change control clause, not from the date either side first raised the idea informally, in a call or in an email thread.
It also matters for cost. Most contracts treat work carried out before approval as unbilled unless the change order says otherwise. A supplier that starts implementation before sign-off is usually taking that cost on its own account, whatever the informal understanding between project teams may have been.
The five stages of the procedure
The table below sets out a typical sequence. Exact wording differs between contracts, but the order of actors rarely does.
| Stage | Typical duration | Who acts |
|---|---|---|
| Request submitted | Same day | Requesting party |
| Impact assessment | 5–10 business days | Receiving party |
| Costing and revised timeline | 3–5 business days | Receiving party |
| Approval or rejection | 5 business days | Both parties, joint sign-off |
| Implementation | Set in the approved change order | Party assigned in the sign-off |
Each stage normally produces its own document: the request form, the assessment memo, the costed proposal, the signed change order, and a completion record. Skipping the paperwork at any single stage is the most common reason a later dispute cannot be resolved from the file alone.
The point of no return sits at approval. Once both sides sign the change order, withdrawing it without additional cost usually requires a second, separate change request rather than a simple cancellation notice.
Steps to open a change request
- Draft the request in writing, describing the change and the reason for it. The requesting party's project lead prepares this.
- Attach a reference to the original scope, specification, or statement of work that the change modifies. The requesting party's project lead does this.
- Log the request under the contract's change control clause, with a date and time stamp. The contract owner on the requesting side handles logging.
- Send the request to the counterparty's named change control contact, not to a general project inbox. The requesting party sends it.
- Track the response deadline against the window stated in the contract. The requesting party's project lead tracks this against a fixed calendar.
- Escalate to the decision-maker named in the contract if the deadline passes without a substantive response. Either party may trigger escalation.
Who decides, and by when
Approval sits with whoever is named as the change control authority in the contract. This is usually a named individual on each side, or a joint change control committee, not a court and not a regulator. Where the contract names a committee, a deadlock is typically resolved by escalation to a senior sponsor on each side, within a fixed number of business days set out in the clause itself.
If the contract is silent on who decides, the practical default is the signatories to the original agreement, acting jointly. Nothing in the standard procedure shifts that decision to a third party unless the contract itself creates one, for example through an independent expert clause.
Deadlines in the table above are typical, not universal. Some contracts compress the whole sequence into ten business days for low-value changes and reserve the longer window only for changes above a stated threshold of cost or scope.
Common forks
- If the change affects a component licensed under separate terms, for example a module carrying usage-based fees, the fee mechanism needs its own review before sign-off. See Royalty tokenised rights explained and the deadline for how that review typically runs.
- If the counterparty does not respond within the stated window, send a written reminder citing the deadline, then escalate under the contract's own escalation clause. Silence should not be treated as either approval or rejection.
- If the change is urgent and touches safety or security, many contracts allow an expedited track with a shortened assessment period. Written sign-off is still required before implementation starts, even on the expedited track.
Where this page stops, and what to check next
This page describes a standard procedural sequence. It does not tell you what a specific contract's change control clause actually says, and it does not resolve a dispute over whether a change was validly requested in the first place. Wording varies enough between contracts that the clause itself has to be read before any deadline in the table above is relied on for a live decision.
Two adjacent situations come up often enough in change control disputes to flag here. One is a counterparty that changes its registered name mid-procedure, which raises a separate question about who remains entitled to receive and approve requests: Counterparty report when the counterparty changes name what it covers that question in more detail.
The other is a change order that ends up unsigned by one side, which raises the separate question of who decides whether it took effect at all: Document report when an assignment is unsigned explained sets that out.
For a related procedure inside the same contract family, covering how inspection rights are exercised rather than how scope is changed, see Audit rights procedure technology contract.
Verified
Reviewed 2025. This page describes a standard procedural sequence drawn from recurring clause structures in technology contracts, rather than a single named regulation, since no statutory deadline governs change control as such. For how material across this site is collected, cross-checked, and dated, see Methodology: collection, cross-checking and dating and its limits.
Frequently asked questions
How long does change control procedure take in practice?
A straightforward request typically clears all five stages within two to four weeks. Requests touching third-party licensed components, or crossing more than one team internally, usually take longer, mainly because the impact assessment stage extends.
Which documents are needed to start?
A written change request, a clear reference to the original scope or specification it modifies, and a record of who submitted it and on what date. Many contracts also require a preliminary cost estimate before the request is formally logged as open.
What happens if the other side does not respond?
Silence past the stated deadline does not count as approval or rejection under most standard clauses. The correct step is a written reminder citing the exact deadline, followed by escalation under the contract's own escalation clause if there is still no substantive answer.