Who should own your domain, hosting, and business email?

Your company name may be on the website while a former employee, freelancer, or agency controls the accounts behind it. You may discover the gap when a renewal fails, email stops, the supplier relationship ends, or an urgent change needs a login nobody can find.

The business can keep control of those accounts while specialists handle the technical work. Make sure the organisation can see the billing, recover access, and decide who administers each service. Give suppliers the permissions they need through that account structure.

Keep the domain under organizational control

The domain is the address on which the website and often the email system depend. Register it in an account controlled by the organization, using a role-based business address rather than one employee's personal inbox.

Record the registrar, account owner, renewal date, payment method, and recovery process. Enable multi-factor authentication and keep recovery codes in an approved secure location. Turn on automatic renewal, but do not treat it as the only control; expired cards and missed messages still happen.

A supplier can manage DNS and renewals through delegated access. They do not need to become the legal registrant or sole account holder. Check that registration contact details are accurate and that any privacy service does not prevent the business from proving control.

Understand where DNS is managed

DNS connects the domain to the website, email, verification records, and other services. It may be managed at the registrar, hosting provider, a security platform, or another DNS service.

Document the authoritative provider and nameservers. Keep a current export or record of important entries. A careless nameserver change can disable both the website and business email even if neither service itself has failed.

Limit editing access, use named accounts, and review changes. Before a migration, lower relevant record lifetimes only when needed, copy all existing records, and plan rollback. Do not delete unfamiliar email or verification entries merely because they are unrelated to the website.

Put hosting in the right account

Hosting runs the website or application. For a business-critical system, the organization should normally be the account owner or have a clearly documented contractual right to the deployed application, data, configuration, and transfer.

The supplier may manage deployments and technical settings. Use team roles instead of sharing one password. Ensure billing notices and service incidents reach more than one responsible person.

Find out what you could take with you if you moved suppliers. A static site, custom application, managed builder, and proprietary agency platform differ in how easily they can be transferred. Ask where the source code lives, whether the database can be exported, which services are required, and what handover would involve.

Treat business email as a separate critical service

Email may use the domain but is not the same as website hosting. Moving the website should not require moving mail, and changing DNS without copying mail records can interrupt delivery.

The organisation should control the main email account, administrator roles, billing, account creation and closure, security policies, and recovery. Use at least two carefully protected administrators where the provider allows it. Personal addresses should not be the only recovery route.

Document mail exchange, sender-policy, signing, and reporting records. These controls help legitimate messages arrive and make domain impersonation more difficult. Configuration should be based on the actual sending services rather than copied blindly from a template.

Own analytics and business listings

Analytics, search tools, maps, advertising accounts, tag managers, business profiles, consent platforms, and social properties often outlive a website build. Create them under the organization and invite partners with the minimum role required.

Do not let a supplier place multiple clients inside an account that cannot be separated later. Confirm which historical data remains available after access changes and whether the organization can add or remove users independently.

For Google Business Profile and similar listings, keep primary ownership with the organization. Agencies and staff can be managers. Review old access when roles change.

Define ownership of code, design, and content

A contract should explain the rights to custom source code, design files, written content, photography, licensed assets, fonts, and third-party components. A promise that “you own the website” leaves those rights unclear unless the agreement spells them out.

Open-source dependencies remain under their licenses. Stock assets and fonts may have usage restrictions. A supplier's reusable tools may remain theirs while the client receives a license to use the delivered system. Custom project work may transfer after final payment, depending on the agreement.

Store source code in a repository with organizational access when appropriate. Keep installation, environment, deployment, and backup documentation proportional to the system's complexity. Never place passwords or secret keys in the repository.

Use delegated access instead of shared passwords

Most modern services support members, roles, or collaborators. Give each person a named account and only the permissions needed. This creates accountability and allows access to be removed without changing credentials for everyone.

Use a business password manager for services that cannot delegate. Protect administrator accounts with phishing-resistant multi-factor authentication where possible. Do not send passwords, recovery codes, or secret keys through ordinary email or chat.

Review access at project completion and periodically afterward. Remove former staff and suppliers, rotate shared secrets, and confirm that active owners can still recover the accounts.

Build a simple digital asset register

The register can be a protected table containing the service, purpose, web address, business owner, technical manager, billing owner, renewal date, recovery method, data classification, and handover notes. It should point to the password manager, not contain passwords.

Include the domain, DNS, hosting, repository, email, form delivery, database, storage, analytics, search tools, maps, advertising, consent, newsletter, booking, payment, and licensed media. Record key dependencies: the contact form may rely on an email provider, for example.

Review the register before renewals, staff departures, supplier changes, and major launches. Name the person responsible for each item so that “IT” and “the agency” are not each expecting the other to remember.

Plan handover before it is needed

A clean handover includes an account inventory, role changes, code and data export where applicable, deployment instructions, outstanding renewals, known issues, backup status, and a short period for questions. Verify access by signing in through the organization's own account.

Do not wait for a disputed relationship or outage. Include handover expectations in the original proposal and contract. Agree which assistance is included and which migration work is separately estimated.

Use the asset register to check that your business can recover the important accounts and that specialists have the access needed to manage them. Agree responsibilities while the working relationship is good. A supplier change or staff departure is much easier when account access and handover have already been planned.