How IICL Contracts, in Plain Language.
A short explanation of the agreements behind an IICL engagement — what each document covers, who signs it, and where scope changes are handled.
One master agreement, one scope document
Every engagement uses a master services agreement covering the commercial and legal framework, plus a separate scope document per piece of work. The framework rarely changes; the scope document is where the specifics live.
Scope is written, not implied
The scope document states the requirement, the deliverables, the delivery gates, the named owners on both sides and the acceptance criteria. If something is not written there, it is not in scope.
Changes are priced before they are built
Requirements move. A change request records what changed, the impact on timeline and cost, and who approved it — agreed before any work begins on the change.
Intellectual property is unambiguous
Work produced for a client under a scope document belongs to the client on payment. IICL retains its pre-existing tools, frameworks and product platforms, which are licensed rather than transferred.
Data handling is a schedule, not a footnote
Where an engagement touches personal or regulated data, a data processing schedule sets out purpose, categories, retention, sub-processors and security controls.
Exit is planned at the start
Every agreement includes notice terms, handover obligations and what happens to documentation, credentials and access when an engagement ends.