Agree on the handover window and owners
Confirm who is authorised to approve transfers and revoke access. Name the client account owner, outgoing contractor, replacement operator and person who can help if access breaks. Agree a cutoff, permitted changes during the overlap and the evidence required before completion.
Have a current project inventory, the agreed scope of work and access to the client's secure credential system. Establish how account recovery works before removing the outgoing operator. If the handover follows suspected compromise, the incident response owner should determine containment timing; the normal overlap sequence may be inappropriate.
Inventory ownership separately from login access
List each service's account owner, current operators, automation identities, recovery owner and required transfer action. An administrator login does not settle who controls billing or recovery. Record credential references or public key fingerprints only; never put passwords, tokens, private keys or recovery codes into this register.
Scroll horizontally for all table columns.
| Project asset | Ownership question | Completion evidence |
|---|---|---|
| Domain and DNS | Who controls the registrar, renewal and recovery contact? | Owner confirms access and current records. |
| Hosting and server | Who controls the account, console and privileged users? | Replacement independently verifies necessary access. |
| Repository and deployment | Who owns the repository, automation and deploy credentials? | Approved release deployed to an isolated target. |
| Application and integrations | Who administers the CMS, mail, APIs and scheduled jobs? | Role and integration checks recorded. |
| Backups and recovery | Who controls backup storage and any required decryption material? | Replacement completes an isolated recovery exercise. |
Transfer ownership and operational knowledge
Use the service's supported transfer or invitation mechanism, then have the receiving owner verify control from their own account. Avoid adopting the contractor's personal identity as a shared login. Reissue project credentials through the approved secure system where a personal account previously supplied them.
For GitHub repositories, a transfer retains associated secrets, deploy keys and webhooks, and existing collaborators can remain. Review these explicitly after the transfer. The transfer receipt establishes a change of ownership, not completion of access removal.
Provide the release reference, runtime versions, configuration locations, scheduled jobs, external dependencies, backup scope and recovery procedure. Add known failures and the next maintenance task. Explain where credentials are retrieved securely without copying their values into documentation.
Let the replacement perform the work
Ask the replacement to follow the written procedure without borrowing the contractor's session. They should obtain the approved source, deploy to an isolated test target, locate useful logs and demonstrate the permitted application administration task. Record every missing step, then update the instructions and repeat the affected check.
Have them restore an agreed backup to a separate test destination with outbound integrations disabled or redirected. Check representative records, uploads and application behaviour. Record the backup identifier, target, elapsed time and unresolved gaps. Do not overwrite production to demonstrate recovery, and do not interpret a successful backup job as a completed restore test.
Remove departing access across every route
After replacement access and recovery are verified, remove the contractor from relevant teams, repositories, hosting accounts and application roles. Review active sessions and revoke project tokens, integrations and credentials they could retain. Where a credential is shared, issue its replacement, update dependent services and test them before retiring the old value. Repeat the replacement's task after revocation to catch hidden dependence on an old credential.
GitHub deploy keys remain active when their creator is removed from a repository. Inspect them separately, including write permissions and the machine using each key. For authorised OAuth apps, the account owner should review the app list and revoke obsolete authorisations using GitHub's controls.
For SSH access, identify the actual public-key authorisation configuration. OpenSSH documents that AuthorizedKeysFile selects the files used for public-key authentication; do not assume every server uses one default file. Keep a verified recovery path and test the replacement's fresh connection and required privileges before closing the maintenance session.
Example: the repository moved, but deployment did not
In this fictional scenario, Cedar Workshop changes its website contractor. The repository reaches the client's organisation, but the deployment job still uses a credential owned by the departing contractor. The replacement can edit code yet cannot publish the approved build. The handover remains incomplete.
The owner arranges a project-controlled deployment credential with the permissions needed for that job. The replacement verifies deployment and recovery on the test target. The team then retires the old credential, reviews remaining deploy keys and reruns the permitted checks. The closure record links to these results without containing credential values.
Close with evidence and scheduled ownership
Record the owner who accepted the handover, each revoked access reference, completion time, replacement test results and outstanding exceptions. Confirm who will act on the next scheduled job failure, domain renewal and maintenance task. Agree how temporary test data and contractor-held project copies are handled under the existing agreement.
Access removal cannot prove that historical copies were never retained. A recovery exercise proves the tested scenario, not every failure mode. Keep those boundaries visible and carry unresolved work into the operating responsibility record with a named owner and due date.
Sources & review
Technical references were checked on September 12, 2026. Examples are planning exercises; referenced software documentation does not establish PrivateHostLab service capabilities.