Change control procedure: what the decision maker looks at
A change control procedure decides whether a proposed change to a technology contract is accepted, rejected or sent back for rework. The decision maker checks scope impact, cost impact, timeline impact and whether the change touches a term the other side has already relied on. Every step from request to sign-off is logged, because that log becomes the record if the change is disputed later.
What changes once a request is raised
Before a request is submitted, the contract sits still. Once it is submitted, three clocks start at the same time: the clock for the impact assessment, the clock for the decision, and — often overlooked — the clock for whatever happens if nobody answers. A request that sits unassessed for weeks does not freeze the underlying obligations; the original contract keeps running until a signed change order replaces part of it.
The practical risk is not the change itself. It is the gap between "we agreed in principle" and "we signed the change order." Work started in that gap is work started without authorisation, whatever was said in the meeting.
What to do
The stages below are the mechanics common to most change control clauses. Names of documents may differ; the sequence rarely does.
| Stage | Who acts | Typical duration | What is produced |
|---|---|---|---|
| Request submitted | Requesting party | Same day | Written change request, referencing the affected clause or deliverable |
| Impact assessment | Receiving party's technical and commercial leads | 3–10 business days | Impact assessment note |
| Decision | Named decision maker per the contract's escalation tier | 2–5 business days after assessment | Approval, rejection, or return for rework |
| Sign-off | Authorised signatories of both parties | 1–3 business days | Signed change order or addendum |
| Implementation start | Delivery team | Per date agreed in the change order | Updated scope baseline |
To move through these stages without creating a dispute later:
- Requesting party: submit the request in writing, naming the clause or deliverable it affects.
- Receiving party: assign a named owner to the impact assessment within the window the contract sets, or a reasonable window if none is set.
- Both sides: compare the assessment against the original scope and raise any discrepancy before the decision meeting, not after.
- Decision maker: record the decision in writing, with a date, even where the decision is a rejection.
- Signatories: sign the change order before implementation begins — a verbal go-ahead does not authorise work.
- Delivery team: update the scope baseline only after signature, never after a verbal agreement.
Who decides
The decision maker is whoever the contract's escalation matrix names for that tier of change — a named individual, a role, or a joint committee. It is rarely "the client" as a whole. Low-impact changes usually sit with a project or delivery manager. Changes touching price, timeline beyond an agreed threshold, or liability usually sit with a governance board or a named senior contact from each side.
Where the contract sets a decision window and that window passes without a decision, the contract's own silence clause governs what happens next. Where the contract is silent on silence, the safer reading is that no response is not consent, and the matter is reviewed case by case rather than assumed either way.
If your situation differs
If the change affects a deliverable involving tokenised assets, the question of who owns the asset runs separately from the change control decision itself — see Crypto services — when the buyer of a token for how that separation is drawn.
If the party proposing the change is a subcontractor rather than the direct counterparty, the escalation matrix usually still runs through the prime contract, not through the subcontract terms.
If the contract has no escalation matrix at all, the decision defaults to whoever signed the original agreement, and the timeline becomes whatever a court or arbitrator later calls reasonable — a weaker position for both sides than a clause would give.
Sources and limit
This page sets out a procedure, not an entitlement. It does not price a specific change, does not decide whether a given change breaches the contract, and does not replace the escalation matrix your own agreement already contains. Treat it as a checklist for the mechanics, not a substitute for the clause.
Before raising or resisting a change, it often helps to know who actually stands behind the other side to the contract. Counterparty in Estonia and its limits explained sets out what a counterparty report there can and cannot confirm.
The same caution applies to the paperwork itself. Document in Czechia and the evidence explains what a document report there establishes, and where it stops.
How the case data behind these reports is compiled and kept current is described separately: Delivery statistics, published automatically overview explained.
Verified: current as of the review date shown at publication. No article, regulation or statute numbers are cited on this page; the escalation mechanism described here depends on the contract's own drafting, not on a specific statutory provision.
Related reading
The same decision-maker logic applies one stage earlier in the contract lifecycle. Audit rights procedure: what the decision maker looks at covers what happens before any change is even proposed.
FAQ
How long does change control procedure take in practice?
For a small change — a scope clarification, a minor timeline shift — request to sign-off typically runs one to two weeks. For a change that requires governance-board sign-off, including a full impact assessment and calendar coordination, three to six weeks is closer to typical. No fixed statutory period applies; the contract's own deadlines govern, and where the contract is silent, "reasonable" is the working standard.
Which documents are needed to start?
A written change request naming the affected clause or deliverable; the original contract, including any prior change orders that altered it; and, once underway, the impact assessment. If a similar change was approved before, keeping that precedent on hand speeds the current decision.
What happens if the other side does not respond?
Check the contract first for a deemed-acceptance or deemed-rejection clause — many change control provisions include one. If none exists, non-response is not consent and does not authorise implementation. Escalate through the notice mechanism the contract specifies, and keep a record of each attempt and its date; that record matters if the delay itself becomes a dispute.