It is possible to have a working website and still be unsure who can renew the domain, change the hosting or recover an account. The problem often stays invisible until somebody leaves, a payment card expires or a new supplier needs access.
You do not need to administer every service yourself. You do need a usable record of the accounts, who controls them and how the business can regain access. This checklist focuses on proving that access works. For rights to code, design and licensed assets, use our separate website ownership and contract questions.
Start with an account register
Create a short register in a business-controlled location. For each service, record the provider, account address, purpose, business contact, administrator, billing owner and renewal date. Link to the relevant entry in your password manager rather than putting passwords in the register.
A practical inventory should cover these separate parts:
- Domain registration: where the web address is registered and renewed.
- DNS: where the records connecting that address to website and email services are managed.
- Hosting and deployment: where the site runs and how an authorised change reaches it.
- Editing and source files: the CMS, code repository or agreed export, as applicable.
- Connected services: forms, analytics, Search Console and any integrations or paid licences.
These may be supplied by different organisations. A single invoice does not establish that there is one account or one recovery process.
Verify the domain and DNS arrangements
Ask the provider to confirm the registered holder’s details and the business’s authority to manage the domain. Check that renewal notices reach a monitored address, the billing method is current and somebody knows the renewal date. Automatic renewal is useful only while its account and payment details remain usable.
Confirm who can sign in to the registrar and who can change DNS. Those controls may sit in different places. Record the process for obtaining authorised access if a supplier manages either account on your behalf.
Check that the recovery arrangements remain usable if the website or business email becomes unavailable. Agree an appropriate recovery route with your IT contact. Avoid making one departing employee’s personal account the only way back in.
A website move can affect email if DNS records are changed incorrectly. Have whoever manages email identify the records that must be retained. Proving access is an inspection task; you do not need to change live records to demonstrate it.
Check what your hosting access actually permits
Being able to edit a page does not necessarily mean you can manage hosting, renew a subscription or retrieve a backup. Ask which role your account has and what it allows. Where a provider manages a shared hosting account, document the agreed export, transfer and support route instead of expecting access to other customers’ sites.
For a custom-coded website, confirm where the agreed source files are held, who can access them and where build and deployment instructions are recorded. For a CMS, confirm the appropriate administrative access and how content and uploaded files can be recovered.
Ask what a recoverable copy includes and who can restore it. A ZIP file is only useful if its contents and restoration process are understood. The maintenance guide explains how backups and recovery fit into ongoing responsibilities.
Use individual access and reliable recovery
Where the service supports it, use named accounts with appropriate permissions and multifactor authentication. Give contributors the access their work requires, while keeping authorised administrative access available to the business. Do not circulate a shared master password in a project email.
Store credentials and recovery codes in the business’s approved secure system, with access limited to the people who need them. Have an authorised deputy and document how access is reviewed when staff or suppliers change. Recovery should not depend entirely on one person’s phone.
The NCSC's guidance on securing important business accounts explains sign-in protection and removing access that is no longer needed.
For example, a wholesaler’s office manager may handle renewals while an IT partner manages DNS and hosting. Both should know which actions belong to them, and the director should know the recovery route if either contact is unavailable.
Test the handover together
Arrange a short session in which your authorised contact signs in using their own account. Check the website or property name, role and recovery settings. Open the agreed source location or editing area, and confirm where support requests and renewal notices go.
Record each result as verified, awaiting access or managed by the named provider. Give unresolved items an owner and a completion date. An invitation email alone does not prove that the right person can reach the right account.
Review access before removing an outgoing supplier, so necessary integrations and administrative routes remain available. The post-launch handover guide helps connect these checks to the wider support arrangements.
If you are planning a website rebuild, bring the account register to the initial discussion. It will make the technical handover much easier to plan, even if a few rows still say “to be confirmed”.