Separate ownership from day-to-day access
Decide who holds each hosting, domain, DNS and third-party account, who pays its bills and who controls recovery. Those roles may belong to different people. The maintainer who uploads a release should not become the only person able to recover the client project.
List the account identifier, business owner, recovery-contact owner and authorized administrators. Record where recovery material is held without putting the material itself in this sheet. Confirm that business continuity does not depend on a departing contractor's personal email or device.
Complete a responsibility matrix together
The example below is a proposal to discuss, not a statement of PrivateHostLab's contractual duties. The client owns business decisions, the agency takes the technical work it accepts, and the provider's duties come from the actual service agreement. Replace roles with named people or a documented provider contact.
For every row, add an approval boundary and the agreed contact method. A replacement must accept the role and have the necessary access. A blank replacement or an unknown provider escalation route is an open action, not assumed coverage.
Scroll horizontally for all table columns.
| Responsibility | Proposed primary | Replacement to name | Escalate when |
|---|---|---|---|
| Hosting budget and renewal | Client budget owner | Client-authorized deputy | A payment decision or renewal is unassigned |
| Domain and DNS control | Client owner; agency changes only by agreement | Authorized domain operator | Access fails or records route users incorrectly |
| OS and application maintenance | Agency maintainer under the agreed scope | Qualified agency replacement | An update fails or an unsupported component needs a decision |
| Backup and recovery checks | Named agency or client data operator | Trained recovery operator | A copy is missing or a restore check fails |
| Infrastructure issues | Provider within its verified service boundary | Route stated in the actual agreement | Evidence points outside application control |
| Client incident updates | Agreed project contact | Client-approved replacement | A critical workflow is interrupted or the next update is due |
Give operators the access their task needs
Use individual identities where the relevant system supports them. Keep publishing, deployment, billing and account recovery permissions distinct where practical. OWASP recommends granting the minimum privileges needed and reviewing permissions for accumulated access. Translate that principle into a named task and review date for each project account. OWASP Authorization Cheat Sheet.
Agree who can add or remove SSH keys and who verifies the result. Before changing SSH configuration, preserve a known working session and a confirmed recovery route; validate the configuration before applying it, then prove a new authorized connection before closing the old session. Ubuntu explicitly advises checking configuration before restarting OpenSSH to avoid losing access. Ubuntu OpenSSH server documentation.
The handover document should contain key fingerprints or access-record references, never private keys, passwords or wallet recovery phrases.
Define escalation by business impact
Separate a routine content request, a planned maintenance change and an incident affecting a critical client workflow. Write the coverage hours, time zone, first contact, replacement and next communication checkpoint. Do not turn a convenient messaging channel into an implied response-time guarantee.
Alerts should lead to an action someone can take. Google's monitoring guidance distinguishes visible symptoms from possible causes and asks whether a page is urgent and actionable. For this project, “enquiries cannot be submitted” is a clearer incident description than “the server looks unusual.” Google SRE monitoring guidance.
A useful escalation note records the affected workflow, first observed time, last known success, recent change and actions already taken. Remove personal data and secrets from supporting logs.
Assign the recovery decision as well as the backup task
Agree which point in time the data must be recovered to and how long recovery can take before the business is materially affected. These are different planning questions reflected by NIST's recovery point and recovery time objectives.
Name the person who maintains copies, the person who tests them and the approver for a production restore. Rehearse on a separate destination. Record the restored data point, functional checks, elapsed time and gaps; a successful rehearsal is evidence for that exercise, not a guarantee about every future incident.
Hand over a usable project record
Imagine a client changing its day-to-day maintainer after a campaign. The outgoing agency supplies the current release, dependency inventory, deployment steps, database and upload recovery procedure, scheduler details, DNS map and third-party account register. The client confirms which accounts and ongoing work move to the replacement.
The receiving operator should perform a controlled exercise with the documents: locate the approved release, restore sample data in isolation, find the next scheduled job and identify the renewal owner. Record what could not be completed and resolve it before relying on that operator for an incident.
- Confirm the replacement's authorized access before removing the departing person's access.
- Rotate credentials that were shared, or revoke individual identities when that is the appropriate control.
- Remove obsolete keys, deployment tokens and access grants across the project inventory.
- Confirm the disposition of remaining copies and open work under the agreed handover terms.
Accept the sheet, then maintain it
Mark each handover check accepted, blocked or requiring follow-up, with the reviewer and evidence location. An unresolved recovery contact should stay visible rather than disappearing into a general “handover complete” message.
Review the sheet whenever the client, agency, provider scope or application changes. Link it to the approved hosting budget and migration record. This worksheet prepares an operating agreement; it does not replace the actual seller terms or create provider support commitments. Compare it with the published service scope and resolve missing details explicitly.
Sources & review
Technical references were checked on September 12, 2026. Examples are planning exercises; referenced software documentation does not establish PrivateHostLab service capabilities.