Your website is up, your email arrives, nothing is broken. Now name the company your domain is registered with, without looking. Then name the account your analytics property was created under. Most business owners can answer one of those two questions, and it is rarely the second one.
We collect this access data at the start of every project, and honestly, it was always a bit painful. Domain, DNS and the rest have no clear structure, the way a password manager gives one to passwords. That is the whole problem in a sentence. A password manager imposed a shape: one entry per service, with a username, a password, a URL. You can see at a glance when one is missing. Website access never got a shape like that. Nobody can tell you what a complete set even looks like, so a gap goes unnoticed until the day it matters.
This piece supplies the missing shape. The register below applies to any provider and any technology, including the provider you are perfectly happy with right now.
Why this is nobody’s fault
A website gets assembled over several years from ten separate services, by several people, each of whom did the sensible thing at the time. The domain came first. The hosting arrived with the relaunch. Someone in marketing set up analytics one afternoon. There is no single moment at which anyone was supposed to write all of it down, so nobody did.
That is the ordinary case. Your provider is not holding anything back. The information simply never got gathered in one place, because no such place existed.
Which accounts does a website actually consist of?
A website consists of ten things you can own and lose separately: the domain at the registrar, the transfer code, the renewal payment, the DNS zone, the hosting, the source code, the CMS account, the mailbox host, analytics, and the destination of your enquiry forms. The table below is the register, ready to check off.
| Account | What it actually is | Who should hold it | What to ask for and write down |
|---|---|---|---|
| Domain at the registrar | The lease on the name. In Austria, a .at domain belongs to whoever is recorded at nic.at as the Domaininhaber, the registered holder | The business, as registered holder. Always | The registrar’s name, the login, confirmation that the business is the registered holder, and the renewal date |
| Transfer code (AuthInfo) | The confirmation code that moves the domain to a different registrar | The business, on request | Confirmation that you can request it at any time. You do not need it today, you need to know you can get it |
| Renewal payment | The card the domain renewal is charged to every year | The business | Which payment method is on file, and whether auto-renew is switched on |
| Nameservers and DNS zone | The address book that decides where the domain points, for the website and for the mail | The business owns the DNS account, the provider gets a role inside it | Which company runs the DNS, the login, and an export of the current records |
| Web hosting | Where the site actually runs | The business owns the account | The provider, the login, and where the site gets deployed from |
| Source code and repository | The website itself, as code | The business owns the repository, or the organisation it sits in | Where the code lives, who has admin, and whether the business owns the account or is a guest in the provider’s organisation |
| CMS account | Where the content is edited | The business is the account owner, the provider works inside it as admin or editor | Whose name the account is in, and who holds the owner role |
| Mailbox host | Separate from the web host, and usually forgotten until the MX records move | The business | Who runs the mailboxes and where the admin login sits. This is generally not the same company as the web host |
| Analytics | The property collecting your visitor data | The business owns the property, the provider is granted access | Which tool, whose account the property was created under, and whether the data leaves with you |
| Form destination | Where the enquiries actually land: an inbox, a CRM, a webhook | The business | Where enquiries arrive today and who receives them. This breaks silently and often goes unnoticed for weeks |
Two of those rows carry a trap you only see once you have lived through it. The first is the renewal payment. A domain gets charged once a year, and if the card on file belonged to a team member who has since left, the charge quietly fails at some point. The second is analytics. The domain and the code are things you hold outright. With an analytics property, everything hangs on the login it was created under. In practice it belongs to whoever created it, and if that was somebody’s private account, the entire history walks out with them.
What the register deliberately does not do is explain DNS again. If you want to know what a nameserver or an A record actually does, that is covered in DNS, domains and email: the guide for non-tech owners. This piece is only about which of these things exist in your business and who holds them.
Who actually owns your .at domain?
Your .at domain belongs to the person or company recorded at nic.at as the Domaininhaber, the registered holder. nic.at puts it plainly: the holder has the sole right of use and can dispose of the domain freely, and without the holder’s consent the domain’s data cannot be changed and the domain cannot be deleted (nic.at). That register entry is what decides it. The rights to the domain hang on it, regardless of who pays the annual invoice.
The second half of the answer is the transfer code. nic.at describes the AuthInfo as a one-off combination assigned to a specific domain that acts as the confirmation code when the domain moves to another registrar. You get it from your current registrar. For .com and the other generic endings there is a binding rule behind it: ICANN’s Transfer Policy requires the registrar to give the registered holder the AuthInfo code within five calendar days of the request, unless it provides a way for you to generate the code yourself (ICANN Transfer Policy, 5.2).
Do not request the code as a precaution and file it away, though. A transfer code is a key, and keys do not belong in a drawer for a year. All you need is the knowledge that you can get one when you need it.
Does your provider need your password?
No. Every service in the table above can invite a person by email and give them a role: admin, editor, collaborator. The business stays the owner of the account and the provider works inside it with their own login. Shared logins exist because they are quicker on day one, and they are the single most common cause of the mess this piece is about.
The reason for that is structural. A role can be granted and revoked without anyone having to change a password and circulate the new one around the business. It also makes the guest list visible: in a properly set up account, the members page tells you exactly who has access, any time you care to look.
In practice this comes down to three habits:
- Accounts get created on a company address, not on a private
firstname.lastname@gmail.comand not on the agency’s address either. - The business holds the owner role everywhere, and the provider gets admin or less.
- If a service cannot invite people by role at all, that tells you something about the service, and it belongs on the replacement list for your next change.
There is a legal edge to this too. For the data your website processes, you are the controller under GDPR. A provider that builds and hosts on your instructions is a processor and needs a written data processing agreement under Art. 28 GDPR. So whoever holds the accounts also decides whose name sits on that responsibility. The post on the legal requirements for a business website goes through the detail.
How do you ask your provider for access?
You send a short, friendly email, and you do not justify it. This is housekeeping, roughly on the level of pulling your insurance policies together once a year. A provider who works properly answers it in an afternoon and does not take it personally. That reaction, by the way, is the most useful signal in the whole exercise.
Here is wording you can send as it stands:
Hi, we are tidying up our internal records and want to document the accounts around our website in one place. Could you tell us: which registrar holds our domain, and are we listed there as the registered holder? Who runs the DNS and the hosting? Where does the source code live? Whose account are the CMS and analytics under? And where do the contact form enquiries land? Wherever we are not currently the account owner, we would like to change that and invite you in as an admin instead.
That last sentence does the work. It turns a control question into an offer, and it tells the provider exactly what you want. If you want to widen the conversation, the questions in how to tell if a web provider is good cover what to ask before you sign. This piece covers the accounts afterwards.
Where should you keep all of this?
In the password manager your business already has, as one entry per service. Alongside it you keep a single document listing which services exist at all, who holds the owner role on each one, and when the domain renews. The password manager answers “how do I get in”. The document answers “what is there in the first place”, and that second question is the one most businesses cannot answer.
Two people in the business should have access to both. One is too few, because the person who knows everything also takes holidays and gets sick. A spreadsheet on somebody’s desktop is too little.
The point of the exercise
A business that has filled in its ten rows can do whatever it likes. Stay with its provider because the work is good. Move, if one day it is not. Bring somebody new in without three weeks of hunting for logins first. That freedom comes from one thing only: you know what your website is made of, and you know who holds the keys to each piece.
Give it half an hour. Work down the table from the top and write in what you already know. The gaps that are left are exactly the questions you send your provider. For what it looks like when ownership sits with you from day one, see who owns your website on a subscription.