Domain, hosting, SSL and access: what your company must control

The domain that was registered in the nephew's name

It's more common than it seems: years ago an employee, a family member or the previous agency registered the domain with their personal email. It works fine until renewal, a provider change or access recovery is needed, and then the company discovers it doesn't control something it believed was its own.

Four assets, four questions

Domain

ICANN publishes the rights and responsibilities of those who register a domain, including the importance of keeping contact data accurate. Its public lookup tool allows viewing basic registration data, although many personal details are hidden for privacy. Ideally the registrant should be the company and the contact email should be a corporate address not tied to an individual. ICANN also describes reminder policies before expiration: make sure you receive them.

Certificates

Certificates that enable “https” have an expiration date. Let's Encrypt, for example, issues short-lived certificates intended to renew automatically. If your site depends on automatic renewal, someone must verify that it actually works.

Accesses

• Each person with their own user account; no shared accounts.
• At least two company administrators on critical services.
• Two-step verification where available.
• Remove accesses when someone leaves the company or a provider changes.
• Store passwords in a password manager, never in spreadsheets or the inventory file.

The inventory

The inventory records what exists, who is the owner, who is responsible and when things expire. It does not store passwords: use a password manager for that. Review it quarterly and whenever a provider or a key employee changes.

Procedure

1. List domains, hosting accounts, certificates and systems with administrative access.
2. For each item, verify the registrant, provider and expiration date.
3. Identify an internal owner.
4. Correct registrant names and personal emails.
5. Enable two-step verification and review users.
6. Store the inventory without passwords.
7. Schedule reminders before each expiration.

Applied example

Limits

This guide does not replace reviewing your contracts with providers or legal advice about ownership. Transfer procedures depend on each registrar.

How to use the downloadable inventory

1. One row per asset.
2. Verify registrant and expiration at the provider.
3. Note where the credential is stored, never the credential itself.
4. Review it every quarter.

Control criteria

Complete concise example

Concise example. A fictional logistics company wants to change web providers. When starting the inventory it discovers the domain is registered to the previous agency, hosting is paid with a former employee's personal card and the certificate is renewed by a plugin that nobody checks.

First it uses ICANN Lookup to check the domain's public data and asks the agency for the transfer code and change of registrant. Then it opens a hosting account in the company's name, with two administrators and two-step verification, and migrates the site with technical support. Finally it configures expiration alerts to a shared corporate email.

The inventory ends up with one row per asset, its registrant, its expiration and where each credential is stored, without writing any password in the file. Invented example.

Questions to ask your current provider

• In whose name is the domain registered?
• Who pays for hosting and with which account?
• How is the certificate renewed and who receives the notice?
• What accesses do you have and which do we have?
• How would the handover work if we change provider?

How to know if it worked

• All assets are in the company's name.
• There are two administrators on each critical service.
• Expirations have reminders.

Plan for the first four weeks

1. Week 1: complete the inventory.
2. Week 2: verify registrants with each provider.
3. Week 3: correct registrants and accesses.
4. Week 4: enable two-step verification and reminders.

Diagnosis before starting

• Use ICANN Lookup to check your domain's public data.
• Check who pays for hosting.
• List the administrators of each service.

A second contrasting example

Concise example. A fictional company has everything registered in its name, but the sole administrator goes on vacation the day the domain expires and the payment card has expired. They add a second administrator and enable automatic renewal with a valid payment method. Unlike the first example, the risk was dependence rather than ownership. Invented example.

What to do when something fails

• If the domain expires, contact the registrar immediately: there is usually a recovery period.
• If you lose an access, use the provider's official recovery process.
• If a former provider withholds access, request it in writing.

How to measure it with your own data

• Each quarter review the registrant and expiration of every domain at the registrar.
• Count services with a single administrator.
• Verify how many users have two-step verification enabled.
• Note whether expiration alerts arrived on time.

If after two quarterly reviews there are no assets registered to third parties, all critical services have two administrators and alerts arrive at the corporate email, control is with your company. Any row that remains pending in two consecutive reviews requires an action with a date and an owner.

Common mistakes

• Domain registered to a person.
• Personal or defunct contact email.
• Only one person with access.
• Passwords recorded in the inventory.
• Relying on automatic renewal without verification.

Checklist

• Registrations in the company's name.
• Corporate contact emails.
• Two administrators on critical services.
• Two-step verification.
• Expiration reminders.