How to Ensure You Control Your Web Application's Domain and Hosting

A business can pay for a web application and still depend on a supplier for the domain, DNS, cloud account or billing access that keeps it online. Proper control means the organisation can renew, recover, delegate and transfer critical services without relying on one external individual.

List the critical control points

Use organisation-controlled accounts where practical

Critical services should normally be held in an account controlled by the business or in a clearly governed arrangement that protects the business's recovery rights. The supplier can receive named delegated access appropriate to its role.

Avoid:

• registration under a developer's personal email address;
• shared administrator passwords;
• billing linked only to a supplier employee;
• recovery codes kept in one person's inbox;
• multiple customers hosted in an inseparable account without a transfer plan.

Verify the domain position

Check the registrar account, registrant information, renewal date, payment method and recovery contacts. Confirm that the business can authenticate and transfer the domain if required.

Record all domains used by the system, including API, administration, email and redirect domains. An overlooked secondary domain can interrupt integrations or user access.

Document DNS safely

Export or record current DNS entries and identify why they exist. Protect the account with named administration and multifactor authentication. Define who may approve changes and how urgent recovery works.

Do not copy sensitive credentials into the DNS inventory. The record should describe service ownership and purpose.

Understand the hosting ownership model

There are three common arrangements:

• Business-owned tenant: the organisation contracts with the provider and delegates supplier access.
• Dedicated supplier-managed tenant: the supplier operates a separate account or subscription for the customer with defined transfer rights.
• Shared supplier environment: several customers use a common account or platform, making direct transfer more difficult.

No model is automatically wrong, but the risks, billing and exit route should be explicit.

Establish administrative resilience

Use at least two appropriately authorised administrators and maintain controlled recovery information. Apply least privilege to daily supplier access. Review:

• owner and administrator roles;
• multifactor authentication;
• emergency access;
• activity logs;
• service identities and API keys;
• leavers and supplier access removal.

Control billing and renewals

Record the legal customer, billing owner, payment method, commitments and renewal dates. Set alerts for domain, certificate, hosting and critical service expiry. Avoid a position where the service stops because an invoice went to a former supplier contact.

Test recovery rather than relying on screenshots

The business should periodically prove that an authorised person can:

• sign in through the normal and recovery routes;
• view and update billing contacts;
• make a controlled DNS change;
• access current backups;
• identify the production environment;
• contact provider support;
• remove or change supplier access.

Plan the supplier exit

Before the relationship ends, confirm:

• which resources transfer and which require migration;
• who will operate the service after handover;
• how deployment identities and secrets are replaced;
• how shared supplier resources are separated;
• when outgoing access is removed;
• how continuity is monitored during the change.

Control checklist

Prove control independently

Ask someone who is not the day-to-day developer to prove control of the registrar, DNS, cloud account and current backup. Any step that requires the supplier's personal login or undocumented knowledge should become a priority handover action.