# Continuity clause checklist

Six groups of requirements to put in front of a supplier before signing, or to hold an existing contract against. Tick each line the draft already covers; the count and its reading update as you go. Each line is written so it can be pasted into a requirements list as it stands, and the unticked lines are the ones to send to legal.

## How to use it

- Tick a line only when the draft covers it in substance, not when it mentions the topic. Your legal team will have their own wording; what matters is that each requirement is present.
- Work through the six groups in order. The reading at the side tells you which unticked lines to raise first.
- If you are holding an existing contract against the list, tick what the signed text already gives you, not what the supplier has agreed to informally.

### 1. Repository and account ownership

- [ ] All source code and configuration for the platform is held in repositories owned by an organisation the client controls.
- [ ] All cloud, hosting, domain, DNS and third party service accounts the platform uses are registered to the client, with the client as billing party.
- [ ] The supplier works in these repositories and accounts under named user accounts, and the client can revoke that access without the supplier's cooperation.
- [ ] Where an account cannot be registered to the client, the contract lists it, states why, and sets a date by which it will be transferred.

### 2. Escrow position

- [ ] Where any component cannot be held in a client owned repository, the contract states whether it is held in escrow, with whom, and what triggers release, together with build instructions and dependency lists.
- [ ] The escrow deposit is refreshed at a defined interval and on each major release.

### 3. Handover obligation with a defined period

- [ ] On written request, the supplier hands over all code, credentials, configuration, documentation and project history within a defined number of working days.
- [ ] The handover obligation applies during the contract, not only at its end.
- [ ] Handover uses open, documented formats and includes a written description of the deployment process, including any manual steps.
- [ ] The supplier confirms in writing that no further credentials, accounts or repositories exist beyond those handed over.
- [ ] After notice by either party, the supplier continues to deliver and support for a defined transition period at the contracted rate.
- [ ] During the transition period, named personnel are available to a successor team for knowledge transfer, for a defined number of hours.
- [ ] The handover and transition obligations survive a change of control of the supplier.

### 4. Named key personnel

- [ ] The contract names the individuals who hold principal knowledge of the platform.
- [ ] The supplier notifies the client before any named person leaves the engagement, with a minimum notice period.
- [ ] Replacing a named person includes a documented handover inside the supplier's team, which the client may review.
- [ ] If the supplier ceases to deliver, the client may engage named personnel directly, and any non-solicitation clause is drafted to permit this.

### 5. Access inventory maintained as a deliverable

- [ ] The supplier maintains a current access inventory listing every account, service, repository and environment the platform depends on, with owner, billing party and administrative users for each.
- [ ] The inventory is delivered at an agreed interval and on request, and reviewed jointly at least once a year.
- [ ] Credentials are stored in a vault the client controls, and the supplier's staff reach them through it rather than holding their own copies.

### 6. History stored in a client controlled system

- [ ] Tickets, decision records and documentation are kept in a project tool instance owned and paid for by the client, with the supplier working in it as a guest.
- [ ] Where the supplier's own tooling is used for any of this, the contract requires a full export in a documented format at an agreed interval and on request.
- [ ] Architecture decisions are recorded in the repository alongside the code, so they travel with it.

### Your result

**Fewer than half the lines ticked.** The arrangement rests on the supplier's goodwill rather than on anything you control. Raise anything unticked in sections 1, 3 and 6 first: those three decide whether a supplier change is a week of administration or a year of reconstruction. Sections 2, 4 and 5 can be negotiated; what matters is that each is present in some form.

**Half or more of the lines ticked.** Anything unticked in sections 1, 3 and 6 is raised first: those three decide whether a supplier change is a week of administration or a year of reconstruction. Sections 2, 4 and 5 can be negotiated; what matters is that each is present in some form.

Paste the list into your requirements document as it stands, and send the unticked lines to legal, starting with anything open in sections 1, 3 and 6.