Skip to content
Hosting, security & operations

Who Owns Your Website? Secure Domain and Access Now

Domain holder, hosting logins, usage rights: the inventory that precedes every relaunch - with the DENIC query, the AuthInfo procedure and a checklist.

18 min read DomainWebsite-RelaunchAnbieterwechselHildesheim

It is a conversation we have regularly in the Hildesheim region, and it almost always starts the same way: the company has been paying reliably for its website for years, the invoice arrives on time, everything runs. Then a relaunch comes up, the mail server needs to move, or a phone number simply needs changing - and suddenly it turns out that nobody in the building has the login for the domain management, that the former service provider is still registered as the domain holder, and that no contract says whether usage rights were ever granted for the custom-built part of the site. This is rarely deliberate. In the vast majority of cases it is sloppiness that grew over time, on both sides: back then it had to be quick, somebody registered the domain in passing, and after that nobody looked at it for ten years. So this article is neither an alarm nor an accusation against service providers, but an inventory in three chapters: domain, access, rights. You can work through all of it yourself - as a web agency from the Hildesheim region, what we mainly offer here is what to look at.

Key takeaways

  • Paying, administering and holding are three separate roles. The holder of a .de domain is whoever is registered as DENIC eG's contracting party; the invoice recipient plays no part in the domain contract and gains no ownership by paying for years.
  • For legal entities the DENIC domain query has shown the holder publicly again since 6 December 2025 (DENIC eG); for natural persons it lists only the registration date and provider. Outdated entries can lead to the domain being disconnected (DENIC eG).
  • A provider transfer runs on the AuthInfo code: 8 to 16 characters (DENIC eG), valid for 30 days (DENIC eG), with the domain staying reachable throughout. If no active provider remains, DENIC posts the code by registered mail to the address on file.
  • A website depends on six separate logins: domain administration, hosting, DNS, CMS admin, email and the analytics tool. Every account must map to one identifiable person (BSI, ORP.4.A1), and logins belong on company addresses rather than private mailboxes.
  • Paying for a website does not automatically transfer every right to its content. Where the types of use are not spelled out, the scope follows the purpose of the contract (Sec. 31 UrhG); photos are protected without artistic merit (Sec. 72 UrhG), custom code under Sec. 69a.
  • Hosting requires a data processing agreement covering eight mandatory points (Art. 28 GDPR); electronic form is sufficient. The full inventory of domain, logins and rights takes one afternoon, gets a date on it and is repeated after twelve months.

The uncomfortable case: paid for, but not registered

At the heart of the problem is a mix-up that looks entirely harmless day to day: who pays, who administers and who holds are three different things. A domain is not an object on a shelf, it is a contractual relationship. For a .de domain, the holder is the contracting party of DENIC eG, the cooperative that manages all .de domains. With 18 million (DENIC eG) registered .de domains - the mark was passed in June 2026 - statistically almost every sixth person in Germany holds a .de address (DENIC eG). A substantial share belongs to small companies that dealt with the registration exactly once: at the very beginning.

That is precisely why a sober look pays off. If the domain was registered years ago by the web designer of the day, by the boss's nephew or by the agency that built the first site, their name is often still on it. Not because anyone wanted to lay claim to the address, but because it was the quickest route and nobody asked about the form field. Insinuations are out of place here: most service providers hand over a domain on request. It only becomes awkward when the company does not know it should be asking - or when the provider can no longer be reached.

Three questions that get to the core

1. Who is registered as the holder? Not who pays, not who maintains it - who is in the contract with DENIC. 2. Who can reach the logins? Domain management, hosting, DNS, CMS, email, analytics: can you log into each of them today without calling anyone? 3. What is in writing about the content? Usage rights to copy, images and custom code have to be granted, otherwise the contract purpose decides in case of doubt (Sec. 31 UrhG). Anyone who can answer all three straight away does not need the rest of this article.

The moment the gap surfaces is almost always the worst one: shortly before a migration, in the middle of a relaunch, or on the day the emails stop arriving. That is when there is no time for the registered letter a provider transfer sometimes requires. An inventory taken in calm conditions, by contrast, costs one afternoon - and it is the least spectacular part of any project we know (project experience).

An inventory is not a vote of no confidence

Clean documentation of holdership, access and rights protects both sides. It protects the company if the service provider drops out, the business is sold or the contact person retires. And it protects the service provider from the suspicion of having wanted to hold something back. In projects we therefore draw up this list openly, together with the previous provider where they can be reached - that is usually the fastest route (project experience).

Domain: holder, contact and provider

A .de domain comes with roles that are readily thrown into one pot. The holder is DENIC's contracting party and thus the party the domain belongs to in practical terms - what people colloquially call the owner, even if lawyers would phrase it more precisely. The administrative contact is the person contacted about the domain; that is a contact role, not holdership. The provider is the DENIC member through which the domain is technically managed - the service company where it sits. And the invoice recipient is not a domain role at all, but a question of bookkeeping.

RoleWhat it meansWhat it does not mean
Holdercontracting party of DENIC eG; decides on the domain's existence, transfer and assignment (DENIC eG)not automatically whoever pays or maintains the site
Administrative contactnamed contact person for the domainno holder position, no power to dispose of the domain
ProviderDENIC member through which the domain is managed technically; generates the AuthInfo on request (DENIC eG)not the holder, even where their name shows up in the domain query
Invoice recipientwhoever carries the costno role in the domain contract - payment does not establish holdership

This distinction explains the single most common misconception: "We have been paying for it for eight years, so it is ours." The invoice proves that you carry the cost. It does not prove who is in the domain contract. Conversely, though: if the service provider is listed as the holder, that does not mean you have a problem - it means, first of all, that a formality is open, and one that can usually be corrected without drama.

The decisive question is not who paid for the domain, but who can move it if you decide to tomorrow.

The underlying idea of holdership under the DENIC domain terms

Checking where you stand: the domain query

DENIC operates a public domain query, formerly known as whois. How much it reveals has changed fundamentally twice. Since 25 May 2018 (DENIC eG) - when the GDPR became applicable - holder data of natural persons is no longer displayed; only the registration date and the managing provider remained visible. Since 6 December 2025 (DENIC eG) a new stage applies: with the national implementation of the European NIS 2 directive, data of legal entities is publicly displayed again - the holder's name and address, email address and phone number, plus registration date and provider (DENIC eG).

For your inventory this means: if your business is a GmbH, UG, AG, a cooperative or a registered association, you can look up in DENIC's domain query within seconds who is registered as the holder. If you are a sole trader or a freelancer and therefore a natural person, you will still see nothing beyond the registration date and the provider (DENIC eG) - in which case the route runs through the provider or through your own files.

  • Open the domain query: enter the domain and check whether holder data appears at all. If it does, read the name and address closely - is it your company or a service provider?
  • Note the provider: the managing DENIC member is displayed in every case (DENIC eG). They are your contact if you want the remaining data.
  • For natural persons: request an extract of your domain data from the provider. As the registered holder you have access to it - via the customer account or on request.
  • Check address and phone number: both have to be current. An address where you were reachable three moves ago is worthless when it matters.
  • Check the email address: it has to lead to a mailbox somebody reads. Old provider addresses are a classic here.
  • Write down the result: date, domain, registered holder, provider. Those four lines are the start of your inventory list.

If the query shows nothing

No reason to worry: for natural persons this is the legally intended default (DENIC eG). Ask the provider named in the query for the stored holder data. If nobody responds or the provider is no longer active, the route runs via DENIC itself - for the case that no active provider exists any more, there is a dedicated procedure in which the credentials are sent by registered mail to the address stored in the domain data (DENIC eG). Which is exactly why a current address is not a formality.

The NIS 2 implementation has a second consequence that is often overlooked in an inventory: since 6 December 2025, registration additionally requires a phone number, the classification as a natural or legal person and, for legal entities, the legal form (DENIC eG). The data is checked on a risk basis - in a first stage through syntax and plausibility checks, and from 14 April 2026 (DENIC eG) in a second stage with targeted verification requests where irregularities appear. If verification fails to happen, the domain can be disconnected and, after a deadline has been set, terminated and deleted (DENIC eG). Outdated holder data is therefore no longer a purely cosmetic matter. On a side note: the address stored in the domain data is not the same entry as the address for service in the legal notice - if the two drift apart, at least one of them is wrong. What belongs in there is covered in our article on the mandatory legal notice details under the DDG.

One special case in passing: if a genuine dispute over a domain arises - because somebody registered your company name as an address, say - DENIC offers the DISPUTE entry. It prevents the domain from being transferred to third parties and buys time for legal clarification; whoever applies has to demonstrate a legitimate interest, for instance name or trademark rights (DENIC eG). DENIC expressly does not decide on the legality of the claim. For a normal inventory this is not a tool but the emergency measure for the rare serious case.

Provider transfer and holder change: how it works

Suppose the check shows that the domain sits with the old service provider and should move. That is the normal case and technically unspectacular. For .de domains there is the password-protected AuthInfo procedure, which DENIC explicitly describes as keeping the domain reachable on the internet during the transfer (DENIC eG). So the website does not go offline just because the provider changes - a worry we hear constantly in conversations.

  1. The holder instructs the current provider to generate an AuthInfo. Note the wording: the instruction comes from the holder - which is why the question of who is registered logically precedes the transfer.
  2. The provider transmits the encrypted AuthInfo to DENIC and informs the holder of it (DENIC eG).
  3. The holder passes the AuthInfo to the new provider - by a route that is not the open email signature.
  4. The new provider files the transfer request with DENIC using the AuthInfo.
  5. If the AuthInfo matches, the domain is transferred immediately (DENIC eG). A holder change can run in the same step.

A few technical details worth knowing, because they drive the schedule: the AuthInfo has to be 8 to 16 characters (DENIC eG) long, and easily confused characters such as I, l, O, o, 0 and 1 are not permitted. DENIC stores only an encrypted version, the hash, and not the plaintext password (DENIC eG). And the code expires automatically after 30 days (DENIC eG) and then has to be requested again. Anyone who obtains the AuthInfo in January and plans the move for March starts over.

When there is no active provider left

If no active provider exists any more - company dissolved, contact person vanished - the new provider requests the AuthInfo directly from DENIC. DENIC sends it by registered mail to the address stored in the domain data (DENIC eG). That works reliably, but only if the address is correct and the recipient is the one who is supposed to receive the letter. If the former service provider is still listed there, the letter lands with them. This is the one point where an outdated entry becomes genuinely awkward - and the best reason to correct it in calm times.

In a holder change, the previous holder gives up their position and a new holder takes their place - contractually, the old domain contract with DENIC ends and a new one comes into being. DENIC describes two routes: either the old and the future holder jointly instruct the current provider, who updates the holder data. Or the change runs together with the provider transfer via the AuthInfo, so that provider and holder change happen in one step (DENIC eG). In practice the second route is the more convenient one when a move is happening anyway.

Reachability stays

The AuthInfo procedure is designed so the domain remains reachable during the transfer (DENIC eG). What causes outages is usually the unplanned DNS and mail changes around it - not the transfer itself.

Plan the window

The AuthInfo is valid for 30 days (DENIC eG). If the route runs via registered mail, postal times are added. Anyone tying the transfer to a fixed date plans a buffer - especially when email moves along.

Think of email

Mailboxes usually hang off the domain. What to watch for is in our article on professional email with your own domain - secure the mailboxes before anything is switched over.

The access inventory: six doors, one keyring

The second part of the inventory is the most thankless, because it looks like bureaucracy and is decisive all the same. A website does not hang off one login but six - and they are almost never with the same provider. The question is not "do we have a password somewhere?" but "can we get through each of these six doors today, without calling anyone?"

Domain management

The account with the provider through which the domain is managed: this is where the AuthInfo is generated and where the holder data sits. The most important login of them all - and the one least often held in-house.

Hosting and server

Where the files live: the customer account with the host, FTP or SFTP, database. Without this login there is no backup and no migration. What good web hosting has to deliver is a topic we cover separately.

DNS records

The distribution point: it decides which server serves the website and where email goes. DNS sometimes sits with the domain provider, sometimes with the host, sometimes with a third party.

CMS administration

The editorial login with administrator rights. An editor account is not enough: without admin rights you can neither manage users nor update extensions.

Email mailboxes

Mailboxes and forwarders - including the question of which address is actually stored in the domain data. Often it is one nobody checks any more.

Analytics tool

Reach measurement and statistics. The login is rarely urgent, but it carries your data. Without your own administrator access you lose the history when you switch.

There is nothing to invent about how to order such access cleanly: the BSI describes it in its IT-Grundschutz module ORP.4 on identity and access management. Two basic requirements from it are immediately practical for small companies. First, it must be regulated how user IDs are set up and deleted, and every ID must be uniquely assignable to one person (BSI, ORP.4.A1). That is the end of the shared "info@" login used by four people. Second, IDs and permissions may only be granted on the basis of actual need - the principle of least privilege and the need-to-know principle - and when staffing changes, IDs and permissions that are no longer needed must be removed (BSI, ORP.4.A2).

  • Draw up the list: six lines, one per login: provider, account name, who in-house gets in, who maintains it externally. The first version needs no more than that.
  • Individual accounts instead of shared ones: every person gets their own ID so it stays uniquely assignable (BSI, ORP.4.A1). Shared logins make any later traceability impossible.
  • Company email instead of private: register accounts on an address of your own domain, not on the private mailbox of an employee or service provider. Otherwise the login walks out of the door with the person.
  • Separate permission levels: editors need editor rights, not administrator rights. Permissions beyond the standard only after justification and review (BSI, ORP.4.A2).
  • Document and review: which IDs and rights profiles exist must be documented and regularly reviewed against the actual state (BSI, ORP.4.A3). Once a year is enough for most companies.
  • Follow up on departures: when somebody leaves - internal or external - the access is removed (BSI, ORP.4.A2). This is the point that most often slips in practice.

Passwords: what the BSI says

A separate password for every system, no reuse, and passwords may only be known to the user personally; the use of a password manager should be examined (BSI, ORP.4.A8). For emergency deposit a password may be written down - it then has to be stored securely (BSI, ORP.4.A8). Translated into everyday operations: the note in the boss's desk is not wrong per se, as long as it is the documented emergency route and not the main way in. The access list itself must also be protected against unauthorised access (BSI, ORP.4.A3).

The test that takes ten minutes

Sit down at a machine where nobody is logged in and try to log into all six accounts one after another - no help, no phone call. Whatever fails is your to-do list. In our projects, domain management is the login most often missing, followed by DNS (project experience). Anyone having the site maintained technically anyway should reconcile this list once with their website maintenance.

Rights to copy, images and code

The third part is the one fewest companies have on their radar. Paying for a website does not automatically acquire all rights to its content. German copyright law knows no sale of the copyright itself; it stays with the author. What is transferred are usage rights. Sec. 31 UrhG puts it this way: the author may grant others the right to use the work, and this usage right may be granted as a simple or an exclusive right and may be limited in territory, time or content (Sec. 31 UrhG). A simple usage right permits use without excluding others; the exclusive right entitles the holder to use the work to the exclusion of all other persons (Sec. 31 UrhG).

Copy

Content written by a copywriter or agency is protected by copyright where it reaches the required level of originality. Whether you may keep using it after a switch depends on the usage rights granted (Sec. 31 UrhG) - not on the invoice.

Images

Photos are protected even without artistic ambition: Sec. 72 UrhG protects photographs by applying the provisions for photographic works accordingly, the right belongs to the photographer and expires fifty years after publication (Sec. 72 UrhG). That covers the quick shot from the building site too.

Custom code

Custom-programmed parts are computer programs under Sec. 69a UrhG - all forms of expression including design material are protected, ideas and principles are not. Quality or aesthetics expressly do not matter for protection (Sec. 69a UrhG).

The rule that matters most in practice is in Sec. 31 (5) UrhG - the purpose-of-transfer rule. Where the types of use are not expressly designated individually, the scope of the usage right is determined by the contract purpose taken as a basis by both parties (Sec. 31 UrhG). This also applies to the question of whether the right is simple or exclusive and what limitations apply. In plain terms: if the contract is silent, it is construed narrowly in case of doubt - the author gives only as much as the contract purpose requires. Whoever commissions a website will be allowed to run it; whether they may also pass on the code, equip a sister company with it or move the copy into an entirely new site is not settled by that.

This too is rarely deliberate

In most contracts for small websites, nothing at all is said about usage rights. Not because anyone wanted to hold something back, but because nobody thinks about copyright when quoting for a handful of subpages. The accusation is out of place here - the question is not. As a rule, a short written confirmation of which usage rights are granted settles the point after the fact and without conflict. On larger projects that clause belongs in the quote from the start; how we handle it in our web design work is something we discuss before a project begins.

Three special cases belong on the same line of your inventory list. First, stock material: if images or fonts were bought under a licence, everything hangs on its terms - licences often run to the buyer and are not readily transferable. So do not only ask whether you may use the images, but who the licence runs to. Second, the standard system: if the site runs on a widespread content management system, the rights question does not concern its core but the individually built parts - templates, extensions, adjustments. Where the line between standard and custom work runs is one of the differences between a website builder and an agency solution that you only notice when you switch. Third, machine-generated content: having copy or images produced by an AI tool raises not only the rights question but additionally the AI labelling obligation from August 2026 - both belong on the same line of the list.

Data processing: the contract that goes with hosting

One point is still missing, and it is readily overlooked because it sounds like data protection rather than ownership: whoever hosts your website processes personal data of your visitors on your behalf - server logs, form entries, mailboxes. That makes you the controller and the host your processor. Art. 28 (1) GDPR requires that you only work with processors providing sufficient guarantees for appropriate technical and organisational measures (Art. 28 GDPR). And paragraph 3 requires a contract or other legal act setting out the subject matter, duration, nature and purpose of the processing, the type of data and the categories of data subjects - along with eight points (Art. 28 GDPR) that have to be regulated.

  • a) Documented instructions: processing only on documented instructions from the controller (Art. 28 GDPR).
  • b) Confidentiality: persons authorised to process the data are committed to confidentiality (Art. 28 GDPR).
  • c) Security: all measures required under Art. 32 GDPR are taken (Art. 28 GDPR).
  • d) Sub-processors: the conditions for engaging them under paragraphs 2 and 4 are respected (Art. 28 GDPR).
  • e) Data subject rights: assisting the controller with requests from data subjects (Art. 28 GDPR).
  • f) Obligations under Art. 32 to 36: assisting with security, notification duties and data protection impact assessment (Art. 28 GDPR).
  • g) Deletion or return: after the end of the service the data is deleted or returned (Art. 28 GDPR).
  • h) Evidence and audits: the processor makes available the information needed to demonstrate compliance and allows for audits (Art. 28 GDPR).

Two details are worth a look. The contract has to be in writing, and an electronic format is permitted (Art. 28 GDPR) - a contract concluded inside a customer account is therefore sufficient if the content fits. And on sub-processors: your host may not engage another processor without your authorisation; with a general authorisation they have to inform you of changes and give you the opportunity to object (Art. 28 GDPR). If they do engage a sub-processor, the same data protection obligations must be imposed on them, and the processor remains liable where the sub-processor fails to fulfil its obligations (Art. 28 GDPR).

In practice this is no great feat: reputable hosts provide a data processing agreement, usually as a document in the customer account concluded with a click. So the item for your inventory is not "draft a DPA" but simply: do we have one, and is it at hand? The same goes for every other service processing data on your behalf - mail, forms, reach measurement. A DPA is not proof of security, by the way, but the documented basis; what needs securing technically belongs in the ongoing maintenance of the website. And how the processing is explained to the outside world is in turn a matter for the privacy policy and the cookie banner - a separate chapter that has nothing to do with the ownership question.

The inventory in one afternoon

Let us put all of it into a list you can work through without us. You need a document, access to your files and the willingness to ask two or three uncomfortable questions. Most companies get through in an afternoon; whatever remains open afterwards is usually exactly the point that made it worth doing.

  • Check the domain: open DENIC's domain query. For legal entities you see the holder directly, for natural persons you ask the provider displayed (DENIC eG).
  • Update the holder data: bring the address, email and - mandatory since 6 December 2025 - phone number up to date (DENIC eG). Incorrect data can lead as far as disconnection.
  • Initiate a holder change if somebody else is registered: via the current provider or together with the provider transfer using the AuthInfo (DENIC eG).
  • Test the six logins: domain management, hosting, DNS, CMS admin, email, analytics. Log in, do not just look them up.
  • Move accounts to company email and create a uniquely assignable ID for each person (BSI, ORP.4.A1).
  • Tidy up permissions: remove IDs and permissions no longer needed, document rights profiles and review them regularly (BSI, ORP.4.A2, ORP.4.A3).
  • Settle usage rights in writing: which types of use are granted for copy, images and custom code? Without express designation the contract purpose decides (Sec. 31 UrhG).
  • Check licences: who do stock images and fonts run to, and are they transferable?
  • File the DPA: for hosting and every other service processing data on your behalf - in writing, electronic format is enough (Art. 28 GDPR).
  • Put a date underneath and set a reminder twelve months out. An inventory nobody repeats ages just like the one that never happened.

This list is deliberately not a sales argument. It works with any service provider, and entirely without one. The point where we usually come in is a different one: this very inventory stands at the beginning of every relaunch and every provider switch. Before anyone talks about design, structure or copy, it has to be clear who owns the domain, who can reach the logins and what may be carried over from the existing content. If you would like this part sorted without driving it yourself, the orderly takeover of domain, hosting and content is a fixed part of our work on a website relaunch.

And if it turns out in the end that everything is clean - domain on the company, logins in-house, rights settled - then you have invested an afternoon and will know it for certain from now on. That is not a bad outcome. The companies that call us years later because they can no longer get at their own address would have liked to have had that afternoon. If you get stuck on one of the points, we will look at it with you: an initial conversation usually clarifies within twenty minutes whether there is anything to do at all. Individual legal questions - on existing contracts, say - should be checked with a lawyer in case of doubt; the technical and organisational side is ours.

This article is based on data from: DENIC eG with the information on provider transfers for .de domains (AuthInfo procedure, length of 8 to 16 characters, excluded characters, storage exclusively as a hash, automatic expiry after 30 days, reachability of the domain during the transfer and dispatch by registered mail to the stored address where no active provider exists any more), DENIC eG on holder changes for .de domains (giving up the holder position, instruction by both parties via the current provider or a combined provider and holder change in one step via AuthInfo), DENIC eG on the domain query (whois) with the changes of 25 May 2018 following the GDPR and the new legal requirements since 6 December 2025 arising from the national implementation of the NIS 2 directive (display of name, address, email address and phone number for legal entities, still only registration date and provider for natural persons), DENIC eG on the changes to .de domain registration (phone number as a new mandatory detail, classification as a natural or legal person, legal form, risk-based checking in phase I as well as verification from 14 April 2026 in phase II and disconnection through to termination and deletion where verification fails), DENIC eG on domain statistics with the mark of 18 million .de domains passed in June 2026 and the ratio of statistically almost every sixth person in Germany, DENIC eG on the DISPUTE entry (protection against transfer to third parties, evidence of a legitimate interest, no decision by DENIC on the legality of the claim), Sec. 31 of the German Copyright Act (UrhG) on gesetze-im-internet.de on the granting of usage rights (simple and exclusive right, limitation in territory, time and content as well as the purpose-of-transfer rule in paragraph 5), Sec. 69a UrhG on the protection of computer programs including design material and the exclusion of qualitative or aesthetic criteria, Sec. 72 UrhG on the protection of photographs and the term of protection of fifty years after publication, Art. 28 of the General Data Protection Regulation (GDPR) on EUR-Lex on processing on behalf of a controller (sufficient guarantees under paragraph 1, authorisation of sub-processors under paragraphs 2 and 4, the eight minimum contents under paragraph 3 points a to h as well as the written form including electronic format under paragraph 9) and the German Federal Office for Information Security (BSI), IT-Grundschutz module ORP.4 identity and access management with the basic requirements ORP.4.A1 (unique assignment of every user ID to one person), ORP.4.A2 (allocation on the basis of necessity, principle of least privilege, withdrawal when staffing changes), ORP.4.A3 (documentation of IDs and rights profiles, regular review, protection of the documentation) and ORP.4.A8 (a separate password per system, no reuse, examination of a password manager, written record only for secure emergency deposit). This article is guidance for taking your own stock and does not replace legal advice in an individual case.

Related Articles