Who owns the domain if the service provider registered it?

What matters is the entry in the "domain holder" field. If the service provider is listed there, then according to the registry "the person registered has become the domain holder in fact, even if something different was perhaps agreed with you" (DENIC). A correction then runs through a change of holder, for which the previous holder terminates the contract and the future holder submits a domain application with documents that clearly identify them (DENIC domain terms). As a rule this can be settled by agreement; without cooperation it becomes laborious.

Is a paid invoice enough to prove that the website is mine?

It proves a contractual relationship, but typically neither the position of domain holder nor the scope of the rights of use granted. For the domain, the proof is the entry in the domain query, which the domain terms require the holder to check themselves (DENIC domain terms). For texts, images and code it depends on the contractual description, because without an explicit list the scope follows the purpose of the contract (Section 31(5) German Copyright Act).

What is the difference between a change of provider and a change of holder?

With a change of provider the domain holder stays the same and only the administering party changes; the order is placed through the future provider and needs the deposited password, which is valid for 30 days from deposit and can be used once (DENIC domain terms). With a change of holder the contracting party itself changes. The two can be combined but should be planned separately because otherwise a gap in availability tends to arise.

May I have the website developed further by another service provider?

That depends on the scope granted. Adaptations and transformations may in principle be published or exploited only with the consent of the author (Section 23(1) German Copyright Act), and transferring a right of use as a rule requires the author's consent (Section 34(1) German Copyright Act). For program code without a specific agreement, only use in accordance with the intended purpose, including error correction, remains free from consent (Section 69d(1) German Copyright Act). That is why adaptation and onward transfer belong expressly in the contract.

Do the texts and images created for my website belong to me?

Copyright itself cannot be transferred (Section 29(1) German Copyright Act); what is granted is a right of use in the scope the contract names. For employed authors, the provisions on rights of use also apply to works from the employment relationship (Section 43 German Copyright Act), and for computer programs from an employment relationship the employer is as a rule entitled to exercise the economic rights (Section 69b(1) German Copyright Act). For commissioned third parties the contractual provision decides.

Who Really Owns Your Website: Domain, Access, Rights

Q: Which documents should a handover contain?

Typically: proof of the domain entry, the credentials for hosting, domain administration, the content management system, analytics and mailboxes, a complete image of the source state or the repository, the image files at original resolution together with licence proof, the data processing agreements and a list of running contracts with terms and notice periods. At the end of processing on behalf of a controller, personal data must be deleted or returned at the choice of the controller (GDPR).

The question rarely comes up out of curiosity. It comes up when a business wants to change providers, when a working relationship ends, when a partner leaves the company or when an invoice becomes contentious. That is the moment it turns out that the domain is registered in someone else's name, that nobody can find the password for the domain administration and that the contract for the website contains no sentence about usage rights. This article separates the three levels that get mixed up: the domain, the credentials and the rights to the material.

Key takeaways

"The website" is not a single object. It consists of a domain contract, contracts for services, user accounts with roles and works protected by copyright - four strands that may belong to different parties.
For the domain contract, the register entry decides: whoever is listed as the domain holder is the holder, according to the registry, even if something else was agreed or intended (DENIC).
Changing the administering provider runs through a password that is valid for 30 days (DENIC domain terms) from the time it is deposited and can be used once.
Copyright itself cannot be transferred (Section 29(1) German Copyright Act). What is granted is a right of use, and without an explicit list its scope follows the purpose of the contract (Section 31(5) German Copyright Act).
Credentials are not a side issue: whoever holds the admin role holds the website. A responsibility matrix with six rows and four columns makes the gaps visible before they get expensive.

A website consists of four strands, not one

In everyday language, someone owns "the website". In substance, that single object does not exist. There is a contract for a domain, there are contracts for storage and services, there are user accounts with roles, and there are works - texts, images, design, program code - protected by copyright. These four strands can belong to different parties without anyone having done anything wrong. In our experience this only becomes visible at the moment they are supposed to be separated.

The scale behind this is considerable: at the end of 2025, around 17.7 million (DENIC) .de domains were registered worldwide, and 12.2 per cent (DENIC) of them belong to holders outside Germany. Each of these domains sits in a contract with exactly one party as the domain holder. Who that is is not decided by the way people talk in the office, but by the register entry.

The sheer spread of websites is another reason to settle the question properly: 79.01 per cent (Eurostat) of enterprises with 10 or more employees in the EU (excluding the financial sector) had a website in 2025. For businesses in Germany it also carries the mandatory provider information required by German digital services law - which puts the operator on the hook, regardless of who built the site. Which details are required in each case is set out in our article on legal notice requirements for websites.

Domain

A continuing contract with the registry. What matters is who is entered as the domain holder - not who pays and not who administers it.

Credentials

Accounts and roles for hosting, domain administration, content management, analytics and mailboxes. Whoever holds the admin role can grant and revoke everything else.

Rights

Copyright in texts, images, design and code. What is transferred is not ownership but a right of use with a defined scope.

The domain belongs to whoever is entered as the domain holder

The domain contract is concluded between the registry and the domain holder. The application is submitted either directly or through a member of the registry, and administration is usually handled by that member. The point many businesses underestimate: administration and holdership are two different things. The administering provider handles the communication - according to the registry, customer orders that change the domain data reach DENIC only through the member administering the domain (DENIC). That does not make anyone the holder.

What happens if the service provider is listed in the "domain holder" field although the business understood itself to be the holder? The registry describes this situation in its frequently asked questions with unusual clarity.

DENIC, on the other hand, cannot do anything for you in this situation, because the party entered in the register has in fact become the domain holder, even if something else may have been agreed with you or at least intended by you.

DENIC eG, FAQs for domain holders (translated from the German original)

The entry can be checked at any time. The domain terms even oblige the domain holder to do so: "Immediately after registration, the Domain Holder must check their data via DENIC’s domain query service" (DENIC domain terms), and any necessary correction must be reported to DENIC at once. Anyone who repeats this once a year usually notices an incorrect entry while it can still be corrected without a dispute. Where the domain points technically and who provides the storage is a separate question - our overview of web hosting in Germany covers that side.

An invoice is not proof of holdership

A paid invoice for "domain and hosting" proves a contractual relationship with the service provider, not the position of domain holder towards the registry. The proof is the entry in the domain query. If a different name appears there, a dispute will as a rule turn on the contractual basis you can rely on.

Changing providers runs through a password, not through goodwill

There is a fixed procedure for changing the administering provider. Under the domain terms, "it is possible for the Domain Holder to transfer administration of the domain from DENIC to a DENIC member or vice versa and also from one DENIC member to another" (DENIC domain terms), which the registry calls a provider transfer. The order is placed through the future provider, and it must quote a password that was previously deposited through the current provider. In practice this password is called AuthInfo; according to the registry, "the current provider will check if the request is issued by an appropriately authorised party (the domain holder or legal representative)" (DENIC).

Ask the current provider for the change-of-provider password for the domain concerned and announce the move.
Receive the password and note the validity period - it is valid for 30 days (DENIC domain terms) from deposit and can be used only once.
Place the transfer order with the future provider quoting the password; without it the order will not be processed.
Secure the technical data before the move: zone file, mailboxes, redirects, certificates. Administration changes hands, the content does not follow by itself.
After the move, check the entry in the domain query and update your own contact details.

Two deadlines run against each other here: the validity of the password and your own schedule. Anyone who requests the password early and places the order late ends up without a valid password and starts again. How to plan the technical part of a move without an interruption is described in our article on switching web host without downtime.

Change of provider and change of holder are two different things

With a change of provider the domain holder stays the same and only the administering party changes. With a change of holder, the registry "registers the domain in the name of the future Domain Holder once the Domain Holder to date has terminated their contract", provided that the future holder "also submits an application to register the domain, presenting documents that clearly identify them" (DENIC domain terms). The domain contract itself "is concluded for an indefinite period", and the domain holder may terminate it "at any time without prior notice" (DENIC domain terms).

Credentials: whoever holds the role holds the website

The second level is unspectacular and, in practice, a frequent breaking point. A content management system knows roles, and the role with the widest permissions can create, change and revoke all the others. If it sits exclusively with the service provider, the business depends on their cooperation for every change - including after the relationship ends. That is why every ongoing website care arrangement should include an overview of who holds which role in which system and where the proof for it is kept.

Credential	Who should hold it	Where the proof sits	Where it typically fails
Domain administration	The business as domain holder	Entry in the domain query	The service provider sits in the holder field
Hosting and DNS	The business, with access for the provider	Contract and invoice in the business's name	Provider's umbrella contract without separate access
Content management	The business with its own admin role	User list in the system	Only one shared account, lost with the change
Code and templates	The business, with a granted right of use	Handover package and contract	No repository, only the live state on the server
Analytics	The business as controller	Data processing agreement	Account runs on the provider, data cannot be retrieved
Email and mailboxes	The business	Mailbox overview at the provider	Redirects without a documented destination

Credentials are also the point where data protection and operational safety meet. When a processing relationship ends, the contract has to ensure that the processor, "at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing" (GDPR). That presupposes knowing which systems hold personal data at all. It is worth adding the question of whether a restore has ever been tested - see our article on testing website backup restores.

A credentials register costs an hour and saves weeks

A table with five columns is enough: system, account holder, role, location of the proof, last check. Every row gets a date. Going through it once a quarter surfaces orphaned accounts and missing roles before they are needed. The data protection side is covered in our GDPR website checklist.

Rights to the material: a right of use rather than ownership

The third level is overlooked particularly often because it plays no role in day-to-day work - until someone wants to rebuild, take along or reuse the website. The principle is short: "Copyright is not transferrable" (Section 29(1) German Copyright Act), unless it passes in the execution of a testamentary disposition or to co-heirs as part of the partition of an estate. A business therefore cannot literally buy texts, photos, design or code. What it acquires is a right of use.

The statute says so explicitly: the author "may grant to another the right to use the work in a particular manner or in any manner (right of use)" (Section 31(1) German Copyright Act). A non-exclusive right permits use without excluding others; an exclusive right entitles the rightholder "to use the work in the manner permitted, to the exclusion of all other persons, and to grant rights of use" (Section 31(3) German Copyright Act). For a website that a business regards as its own presence, that difference matters.

If the types of use were not specifically designated when a right of use was granted, the types of use to which the right extends is determined in accordance with the purpose envisaged by both parties to the contract.

Section 31(5) German Copyright Act, English translation published on gesetze-im-internet.de

This purpose-of-grant rule is why a thin contract is later read narrowly: what is not named counts, in case of doubt, as not granted. Two follow-up questions arise. First, adaptation - "adaptations or other transformations of a work ... may be published or exploited only with the author’s consent" (Section 23(1) German Copyright Act); without that right a design cannot readily be developed further. Second, onward transfer - a "right of use may only be transferred with the author’s consent" (Section 34(1) German Copyright Act), which matters for a later change of provider or a business succession. For photographs the licence chain comes on top, which we set out in detail in our article on website image rights and proof.

A right of use unlimited in territory, time and content for the agreed purpose, expressly named rather than merely assumed.
Non-exclusive or exclusive - the choice belongs in the contract, not in later interpretation.
The right to adapt and develop further, including publication of the adapted version.
The right to transfer to legal successors and to grant sub-licences to future service providers.
Use beyond the website where wanted: print, trade fairs, vehicle livery, further domains.
A provision on attribution and on what happens to the works when the relationship ends.

Software and source code follow their own rules

The German Copyright Act contains special rules for computer programs, and one of them takes a considerable load off businesses: where a program is "created by an employee in the execution of his or her duties or following the instructions of his or her employer, the employer alone is entitled to exercise all economic rights in the computer program, unless otherwise agreed" (Section 69b(1) German Copyright Act). For in-house development the position is therefore usually clear. For development commissioned from third parties it is precisely not - there the contract decides.

Without a contract, little remains. In the absence of special contractual provisions, only those acts do not require authorisation that are "necessary for the use of the computer program in accordance with its intended purpose, including for the correction of errors" (Section 69d(1) German Copyright Act). Operating, yes; fixing faults, yes - rebuilding, extending or handing over to another service provider is not covered. For employed authors outside software, the provisions on rights of use also apply where the author created the work "in the fulfilment of obligations resulting from an employment or service relationship" (Section 43 German Copyright Act).

handover.json

{
  "domain": {
    "holder": "the business",
    "proof": "domain query, extract dated 2026-09-16",
    "administration": "service provider",
    "password_requested": false
  },
  "source_code": {
    "location": "repository held by the business",
    "right_of_use": "exclusive, unlimited in time, adaptation included",
    "contract_clause": "annex 2, item 4"
  },
  "images": {
    "origin": "commissioned production",
    "licence_proof": "photographer contract, annex 3",
    "consent_of_persons": true
  },
  "analytics": {
    "account_holder": "the business",
    "processing_agreement": "signed 2026-03-04"
  }
}

Such a list is not a formality but the basis of every later check: for each component it names the holder, the location of the proof and the contract clause. Anyone who keeps it can say within minutes what moves along in a change of provider and what does not. How the same idea applies to content is shown in our article on the content audit for an existing site.

What belongs in the contract so the question does not arise later

Disputes frequently arise not from bad faith but from omission. A quotation describes services and a price; the question of who owns what does not appear in it because at the time of signing it presses on no one. In our experience a two-page annex is enough to change that. How we make scope and minimum term visible is set out on our pricing overview.

The domain holder is the business, with the name and address as in the register; administration may sit with the service provider.
Credentials and roles are named, and the business holds at least one role with full permissions in every system.
The scope of the right of use is listed explicitly, including adaptation, transfer and sub-licence.
For third-party material the licence chain is documented: origin, licence type, permitted use, location of the proof.
A data processing agreement exists wherever personal data is processed, with a provision on return and deletion.
For the end of the relationship it is described what is handed over, in which format and within which period.

Two provisions form the frame that applies anyway. First the mandatory provider information: for commercial digital services that are usually offered against payment, service providers must keep certain details easily recognisable, directly accessible and permanently available (Section 5(1) German Digital Services Act) - and the operator is responsible, not the party doing the design. Second, processing on behalf of a controller under the General Data Protection Regulation, which governs return or deletion at the end. Which of this belongs to which service is set out in our services overview.

The handover: what should be in place on the cut-off date

A handover has succeeded when the business can carry on without asking a question. That can be tested, and before the relationship ends. Three queries show within seconds where a domain points, which name servers are responsible and whether delivery works - shown here on an example address from the namespace reserved for documentation.

Terminal

$ dig +short NS beispiel.example

ns1.hoster.example. ns2.hoster.example.

$ dig +short beispiel.example

203.0.113.10

$ curl -sI https://www.beispiel.example | head -n 1

HTTP/2 200

Knowing the answers also shows what is missing: a name server still pointing at the previous provider, an address without a certificate, a redirect without a destination. A handover further includes the credentials in a format the business can manage itself, the repository or a complete image of the source state, the image files at their original resolution together with licence proof, and a list of running contracts with terms and notice periods. If a season is coming up, the date should not fall into the middle of it - the article on preparing the online shop for the Christmas season describes how tight that period gets.

We set up new projects so that the domain runs on the business from the start, every credential is documented and the scope of the rights of use is stated in the annex to the contract. For existing websites we clarify the three levels in a stocktake and name what can be changed without the cooperation of third parties and what cannot. If you would like to settle this point for your website, talk to us.

The simplest test takes five minutes

Open the domain query and read the holder field. Then sign in to the content management system with an account that runs on your business and check whether you could create another user. Finally, search the contract for the words "right of use". Three results, three levels - and a solid answer to the question of who owns the website.

This article draws on data from: DENIC domain terms, DENIC domain statistics and FAQs for domain holders, the German Copyright Act (Sections 23, 29, 31, 34, 43, 69b, 69d), the General Data Protection Regulation (Article 28), the German Digital Services Act (Section 5) and Eurostat.