Practical planning guide

Website Ownership and Access Handover Checklist

Know which accounts the business can administer and what must be verified before a previous provider’s access is retired.

By Stefan Nadwodny

Account control is not the same as legal ownership

Use this checklist when accepting website delivery or changing maintenance providers. It is an operational planning aid, not legal advice, a domain-transfer procedure or a guarantee of recovery.

ICANN describes the domain registrant as the individual or entity that registers a domain and enters a contract with a registrar. Registrants manage domain settings through that registrar. [25]

Keep three questions separate: who is the domain registrant, which provider account role grants administrative access, and what legal rights the contract grants over code, design and other assets. Do not treat an account role as proof of legal rights. For disputed or unclear rights, pause the relevant change and seek professional advice.

Inventory the services without collecting secrets

Recommended scope: record the registrar, DNS, hosting, source and backup locations, email delivery provider, Analytics, Search Console and third-party integrations. Record absent services as “not used” only after the business owner confirms that status; do not assume all eight exist on every site.

Use business-controlled role names and safe evidence references. Never put passwords, recovery codes, API keys, authorization tokens or private credentials in this register, a shared screenshot or a contact form. A dashboard screenshot alone should not be accepted as evidence of working recovery or exclusive control.

Copy the blank access and renewal register

Copy the tab-separated block into a private working spreadsheet; split on tabs if needed. Use one row per actual account, adding rows where a category has several providers. The role and owner fields refer to people’s responsibilities, not stored credentials.

Service/category	Business account owner	Provider role	Recovery owner	Renewal owner	Renewal date	Dependency	Evidence reference	Replacement access verified	Removal approval	Status
Domain registrar	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]
DNS	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]
Hosting	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]
Source and backups	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]
Email delivery provider	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]
Analytics	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]
Search Console	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]
Third-party integrations	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]	[Complete]

Hypothetical completed row

Fictional planning example only: this is an imagined hosting handover, not an account on this website. Evidence labels refer to a fictional private checklist and contain no credentials.

Service/category	Business account owner	Provider role	Recovery owner	Renewal owner	Renewal date	Dependency	Evidence reference	Replacement access verified	Removal approval	Status
Hosting	Business operations owner	Outgoing maintainer: administrator	Business operations owner	Finance owner	2027-01-31 (fictional)	DNS and backup restore plan	Private checklist H-01 (fictional)	Yes in illustration: separate sign-in and recovery route checked	Pending: dependency review not approved	Hold old access; unresolved dependency review

In this illustration, replacement sign-in is not enough to approve retirement: dependency review remains a blocker. The renewal date is fictional, not a published service commitment.

Search Console: distinguish roles and surviving tokens

Google distinguishes a verified owner, who uses a verification token, from a delegated owner, who is granted ownership status without using a token. These describe Search Console access mechanisms; do not use them as a legal title record. [24]

Removing an owner from a Search Console property does not delete or revoke that owner’s verification tokens. A remaining token can let a deleted owner re-verify ownership. [24]

Google also cautions that the same token can be reused by services such as Search Console, Merchant Center and Google Workspace. Removing it could negatively affect other services that rely on it. [24]

Recommended boundary: record the verification method and dependency owner, not token values. Ask the authorized administrator to produce a service-specific access-retirement plan after confirming replacement access and dependencies. Do not delete DNS records, transfer a registrar account or remove verification tokens as a generic checklist step.

Use a staged acceptance checklist

Recommended order: complete each stage and document blockers before approving the next. Stop the relevant change when access or rights remain unclear.

Inventory and agree scope. Assign an accountable business owner for every account and identify missing access, renewal responsibilities and contractual questions.
Verify replacement access first. Have the authorized business representative use their own access to confirm the necessary administrative role and approved recovery route. Keep secrets in the provider’s secure flow, not this worksheet.
Review continuity and dependencies. Confirm who maintains DNS, email, backups, billing and shared verification methods. Record evidence and unresolved blockers; a screenshot is not the entire acceptance test.
Request scoped retirement approval. Only after replacement access is verified and dependency blockers are resolved should the business owner approve a provider-specific plan for retiring old access. Record exactly what is approved and who will implement it.
Accept and follow up. After separately authorized implementation, ask the administrator to recheck business access and dependent services, record actual results and keep unresolved items open. Do not mark the handover complete merely because a provider sent a list of accounts.

Stage	Assigned owner	Evidence reference	Unresolved blockers	Decision/status
[Stage]	[Role]	[Non-secret reference]	[Issue or none verified]	[Hold / approved with scope / verified]

What to do when the register is incomplete

Agree the missing item, accountable owner and next check with the current provider. Keep an affected renewal, access-removal or transfer decision on hold until its prerequisite is verified. Escalate unclear contractual rights to an appropriate professional rather than assuming administrative access settles the dispute.

This guide does not offer legal transfer services, guaranteed recovery or a standard handover package. Use it to define the work you need before agreeing scope.

Related guidance and scoped help

Use a separate SEO checklist when the site is also being redesigned.

Explore website services or browse all resources.

Share goals and access gaps only. Never send passwords, recovery codes, authorization tokens or private credentials through the contact form.

Discuss your website handover scope

Sources

Numbered citations support the attributed statements. Worksheets, naming rules and acceptance steps are editorial recommendations; examples are hypothetical.