Last updated: 23 July 2026. View change log.

This Annex forms part of the Web Development Master Services Agreement and describes the scope, responsibilities and limitations that apply to the Change Control Process.

1. What counts as a change?

  1. A “Change” is anything that alters:
    • the agreed scope, features or requirements;
    • designs that have already been signed off;
    • assumptions or constraints identified during discovery; or
    • delivery timescales or dependencies in a material way.
  2. Examples include:
    • adding new features or user journeys that were not in the original scope;
    • significant redesigns or rebranding mid-project;
    • changes to core integrations or platforms; and
    • new regulatory or compliance requirements introduced after work has started.

2. Requesting a Change

  1. Either you or we may raise a potential Change.
  2. We will normally:
    • capture the request in writing; and
    • ask clarifying questions where needed.

3. Impact assessment

  1. For each proposed Change, we may assess:
    • the impact on scope and complexity;
    • the impact on timelines and milestones;
    • the impact on cost; and
    • the technical or risk implications.
  2. We will share a summary of this assessment with you before we proceed.

4. Approval

  1. If you want to go ahead with the Change, we will:
    • agree any adjustments to price and timescales; and
    • record the Change in an updated Order, Statement of Work or change log.
  2. We are not obliged to implement a Change until it has been agreed in this way.

5. Emergency or minor changes

  1. Very small changes or urgent fixes may sometimes be handled informally (for example under a retainer) where the impact is clearly low and both of us agree.
  2. Where an emergency change is needed to address a serious production issue, we may make it promptly and document the change afterwards.