A website handover checklist for lasting ownership

Treat handover as an operational test

A site is not handed over merely because it is public. The business needs enough control to renew the domain, operate hosting, edit approved content, receive inquiries, inspect measurement, update dependencies and recover from failure. Some services can remain managed by a supplier, but the arrangement, access limits, exit process and responsible person should be explicit.

Schedule handover before launch pressure peaks. Name one business owner and one technical contact, then list every external account and asset. Avoid sharing a single password among several people. Create named accounts where the service supports them, grant only the access each person needs, enable suitable multi-factor authentication and test account recovery without publishing or emailing secrets.

Build an ownership register

Use one row for each domain, DNS provider, hosting service, content system, source repository, deployment service, form mailbox, email sender, analytics property, tag manager, search account, file store and licensed asset. “The agency has it” is not an owner. Record the legal or business account holder, named administrators and the person responsible for day-to-day operation.

For each row, capture the login route, recovery method, renewal date and payer, access-review date, export process, dependency, maintenance owner and exit action. Store the register in a controlled business location, separate from the credentials themselves. ICANN’s registration overview explains that registrants work through registrars and have responsibilities for accurate registration information; confirm the business can identify and reach its registrar account.

• Asset or service, purpose and production address or account identifier.
• Business owner, current administrators and least access each role requires.
• Recovery contact, multi-factor method and last successful recovery check.
• Renewal date, billing owner, cancellation effect and expected expiry warning path.
• Export or transfer method, format, supplier dependency and contract location.
• Backup coverage, retention, restore evidence and last tested recovery date.
• Maintenance task, frequency, responsible person and escalation contact.

Transfer access without exposing secrets

Do not place production passwords, private keys or API tokens in a handover document, source repository or ordinary email thread. Use the organization’s approved password or secrets-management system and rotate credentials that were temporarily shared during delivery. OWASP’s secrets guidance covers centralization, access control, rotation and auditing. The practical goal is to know which system holds each secret, who may retrieve it and how access is removed.

Transfer source files and usage rights as well as exported images. The handover pack should identify the production source repository, release instructions, editable brand artwork, font and image licences, copy source, privacy and legal text owners, and any third-party component terms. Note which assets were created for the project and which are licensed rather than owned outright. Keep personal inquiry data out of design archives and sample databases.

Ask for restore evidence, not a backup promise

Record what is backed up: application files, configuration, uploaded media, content and stored inquiries may live in different systems. State the schedule, retention, encryption, location, access and deletion process. A provider snapshot can be useful, but it may share the same account and failure boundary as production. Decide what outage or loss the recovery plan is intended to handle.

Run a controlled restore test or review recent, reproducible evidence from one. Confirm how long recovery took, what point in time was restored and which manual steps remained. NIST’s contingency-planning guide describes backup and recovery as part of broader plans that should be developed, tested and maintained. Give the business a concise recovery runbook with decision owners and supplier contacts.

Hypothetical example: finding an ownership gap

Consider a hypothetical consultancy receiving a redesigned site. Its ownership register shows that the domain is in the founder’s business account, hosting has two named administrators and content exports are documented. Analytics, however, sits inside a contractor’s personal account with no business administrator. The team marks measurement as not handed over even though reports are visible.

Before completion, the business creates or confirms its own analytics organization, receives the correct administrative role and verifies that site data still arrives under the intended consent settings. The contractor’s access is reduced to the agreed support role. The team records the property identifier, access-review date and removal process in the register. This is a hypothetical control example, not a Kinetivy client result.

Complete and verify the handover pack

Use the register during a live handover session. Ask the business owner to sign in through the normal route, locate billing and recovery settings, edit a safe test item, view an inquiry record, inspect analytics access and find the deployment and rollback instructions. Remove test data afterward. Record gaps with an owner and due date instead of treating a spoken explanation as completion.

• Confirm domain registrant details, registrar access, DNS control, renewal and recovery.
• Verify named access to hosting, content, source, deployment, forms, email, analytics and search tools.
• Receive current documentation, editable assets, licence notes, data exports and supplier agreements.
• Rotate transferred secrets and record where access is managed, reviewed and revoked.
• Review backup scope and perform or inspect a successful restore with a documented runbook.
• Assign security updates, content reviews, inquiry checks, billing, incident response and access reviews.
• Record the support and exit process, including how data and accounts can move to another provider.