--- id: "disclosure-request" kind: "glossary-term" title: "Offenlegungsantrag" language: "de" category: "Registrierungsdaten und Datenschutz" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/de/glossar/offenlegungsantrag/" translations: en: "https://tldlog.com/glossary/disclosure-request/" es: "https://tldlog.com/es/glosario/solicitud-divulgacion/" fr: "https://tldlog.com/fr/glossaire/demande-divulgation/" it: "https://tldlog.com/it/glossario/richiesta-divulgazione/" pt-BR: "https://tldlog.com/pt/glossario/solicitacao-divulgacao/" ru: "https://tldlog.com/ru/glossariy/zapros-raskrytie-dannykh/" zh-Hans: "https://tldlog.com/zh/cihui/pilu-qingqiu/" --- # Offenlegungsantrag Ein Antrag an einen Registrar oder eine Registry auf Registrierungsdaten, die öffentlich nicht sichtbar sind, etwa den Namen oder die E-Mail-Adresse des Inhabers. Die anfragende Stelle, zum Beispiel die Polizei oder ein Markenanwalt, erklärt, warum sie die Daten braucht. Der Registrar oder die Registry entscheidet, ob sie offengelegt werden. Eine Offenlegungsanfrage (Disclosure Request) ist der Weg, auf dem jemand die öffentlich verborgenen Angaben eines Domaininhabers erfragt, etwa einen Namen oder eine E-Mail-Adresse. Die Anfrage geht an das Unternehmen, das die Domain verkauft oder betreibt, und muss erklären, wer fragt und warum. Dieses Unternehmen, nicht die ICANN, entscheidet, ob es die Daten herausgibt. ## Was eine Offenlegungsanfrage ist Seit 2018 ist nach der Temporary Specification for gTLD Registration Data ein großer Teil der personenbezogenen Daten in den Registrierungseinträgen von gTLDs verborgen (abgestufter Zugang, Tiered Access). Heute regelt dies die Registration Data Policy, in Kraft seit dem 21. August 2025 und überarbeitet am 12. Mai 2026: Registrare und Registrys müssen personenbezogene Daten schwärzen, wo das Gesetz es verlangt, und dürfen es in einigen weiteren Fällen tun. Der förmliche Name bei der ICANN lautet „Reasonable Requests for Lawful Disclosure“. Die Anfrage geht an den Registrar oder den Registry-Betreiber, und wer sie erhält, entscheidet. Die ICANN trifft die Entscheidung weder selbst noch überprüft sie sie. ## Wer fragen darf und mit welcher Begründung Fragen darf jeder. Stand Oktober 2026 muss eine Anfrage mindestens enthalten: - Identität, Kontaktdaten und Art der anfragenden Stelle (Unternehmen oder Einzelperson), mit Nachweis der Vertretungsbefugnis, wenn sie für jemand anderen handelt; - die gewünschten Datenelemente; - die rechtlichen Ansprüche der anfragenden Stelle und den konkreten Grund der Anfrage; - eine Erklärung, in gutem Glauben zu handeln, und die Zusage, die Daten rechtmäßig zu verarbeiten. Der Registrar oder die Registry muss jede ordnungsgemäß gestellte Anfrage einzeln prüfen. Wo das Gesetz es verlangt, wägt er oder sie das berechtigte Interesse der anfragenden Stelle gegen die Rechte des Domaininhabers ab und kann weitere Faktoren berücksichtigen, etwa die Rechtsordnung. Während der Pilotphase von RDRS stellten Inhaber geistigen Eigentums 1.202 der 3.721 Anfragen und Strafverfolgungsbehörden 605. Stand Oktober 2026 verlangt in der Europäischen Union (EU) Artikel 28 Absatz 5 der NIS2-Richtlinie von den Mitgliedstaaten, dafür zu sorgen, dass TLD-Registrys und Registrare berechtigten Zugangsnachfragern auf einen rechtmäßigen und hinreichend begründeten Antrag bestimmte Registrierungsdaten herausgeben, im Einklang mit dem Datenschutzrecht der EU, und innerhalb von 72 Stunden antworten. ## Wie man eine Anfrage stellt, Schritt für Schritt Für einen gTLD-Namen, Stand Oktober 2026: 1. Die öffentlichen Daten mit ICANN Lookup prüfen, um zu bestätigen, dass die Daten verborgen sind, und den Registrar zu ermitteln. 2. Dem Verfahren des Registrars folgen. Jeder Registrar und jede Registry muss von der Startseite auf eine Seite verlinken, die das Format der Anfrage, den Weg der Antworten und den erwarteten Zeitrahmen nennt. 3. Oder RDRS nutzen, das kostenlos ist und ein ICANN-Konto erfordert. Die anfragende Stelle wählt eine Kategorie, beschreibt, was sie möchte, kann bis zu fünf PDF-Dateien von je bis zu 5 MB anhängen und bestätigt, dass sie das Datenschutzrecht einhalten wird. 4. Nimmt der Registrar nicht teil, kann die anfragende Stelle das Formular in RDRS als PDF speichern und direkt schicken. In jedem Fall erfolgt eine Offenlegung außerhalb von RDRS, auf dem Weg, den der Registrar wählt. Stand Oktober 2026 ist RDRS für Registrare freiwillig. Am Ende der Pilotphase im November 2025 deckten die teilnehmenden Registrare 46 % der verwalteten Domains ab. Der ICANN-Vorstand verlängerte den Dienst um bis zu zwei Jahre: bis Dezember oder November 2027, je nach ICANN-Dokument. RDRS deckt keine ccTLDs ab und ist kein Weg, eine UDRP-Beschwerde einzureichen. ccTLDs wenden ihre eigenen Regeln und ihr eigenes Recht an, daher wendet sich die anfragende Stelle an die Registry; EURid bietet zum Beispiel ein Formular für .eu-Daten an. Die Registry von .es ist weder an die Policy der ICANN noch an RDRS gebunden; bei einem .es-Namen empfiehlt sich daher eine Nachfrage bei Red.es oder einem Anwalt. ## Antwortzeiten und dringende Anfragen Stand Oktober 2026 muss ein Registrar oder eine Registry den Eingang einer ordnungsgemäß formatierten Anfrage innerhalb von 2 Werktagen bestätigen und innerhalb von 30 Kalendertagen nach der Bestätigung antworten, außer unter außergewöhnlichen Umständen. In der Pilotphase von RDRS dauerten Genehmigungen im Durchschnitt 7 Tage und Ablehnungen 17. Die RDRS-Option „Expedited“ verpflichtet den Registrar nicht zur Eile: In der Pilotphase wurden 169 von 220 solcher Anfragen auf Standard umgestellt, und in einem Notfall rät die ICANN, sich nicht darauf zu verlassen, sondern den Registrar direkt zu kontaktieren. Dringende Anfragen wurden am 12. Mai 2026 in die Policy aufgenommen. Sie kommen nur von einer authentifizierten Strafverfolgungsbehörde oder einer anderen vertrauenswürdigen Behörde, bei unmittelbar drohender Gefahr für das Leben, einer schweren Körperverletzung, einer Gefahr für kritische Infrastruktur oder der Ausbeutung von Kindern. Die Antwort wäre innerhalb von 24 Stunden fällig, mit Begründung verlängerbar auf höchstens 72 Stunden ab Eingang. Stand Oktober 2026 ist diese Regel nicht in Kraft: Sie gilt erst, wenn die ICANN eine Policy zur Authentifizierung der Anfragenden umsetzt. Die ICANN bereitet einen Test mit Strafverfolgungsbehörden vor, unter anderem mit INTERPOL und dem US Federal Bureau of Investigation (FBI). Stand Oktober 2026 verlangt das RAA von jedem gTLD-Registrar einen rund um die Uhr betreuten Missbrauchskontakt für Behörden seiner eigenen Rechtsordnung und die Prüfung ihrer begründeten Meldungen innerhalb von 24 Stunden: Es geht um Meldungen, nicht um Offenlegung. ## Was geschieht, wenn eine Anfrage abgelehnt wird Eine Ablehnung muss konkrete Gründe nennen und, wo diese Abwägung gilt, erklären, wie die Rechte des Domaininhabers gegen das Interesse der anfragenden Stelle abgewogen wurden. Ablehnungen sind häufig. Vom Start bis zum 30. Juni 2026 verzeichnete RDRS 4.275 Anfragen: 1.072 genehmigt und 2.540 abgelehnt. Die häufigsten Gründe in der Pilotphase waren, dass das Gesetz die Offenlegung verhinderte und dass die Anfrage unvollständig war. Die anfragende Stelle kann dann eine neue Anfrage mit mehr Informationen stellen oder sich bei ICANN Contractual Compliance beschweren, wenn der Registrar nicht geantwortet oder die Regeln nicht befolgt hat; die Entscheidung selbst überprüft die ICANN nicht. Am 12. März 2026 beschloss der ICANN-Vorstand, die 18 SSAD-Empfehlungen nicht anzunehmen, und drängte den GNSO-Rat, neue Arbeit innerhalb der RDRS-Verlängerung abzuschließen, die im November 2027 endet. Eine verpflichtende Teilnahme der Registrare, Servicelevel für Antworten und die Authentifizierung von Strafverfolgungsbehörden werden diskutiert; Stand Oktober 2026 ist nichts davon entschieden. ## Quellen - [Registration Data Policy](https://www.icann.org/en/contracted-parties/consensus-policies/registration-data-policy) - [Frequently Asked Questions for the Registration Data Request Service (RDRS) for Requestors](https://www.icann.org/en/system/files/files/rdrs-requestors-faqs-25apr24-en.pdf) - [RDRS Two-Year Pilot Summary Report](https://www.icann.org/en/system/files/files/rdrs-two-year-pilot-summary-report-27feb26-en.pdf) - [Approved Resolutions | Regular Meeting of the ICANN Board | 12 March 2026](https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-12-03-2026-en) ## verwandte begriffe - [Schwärzung](https://tldlog.com/de/glossar/schwaerzung/) - [RDRS](https://tldlog.com/de/glossar/rdrs/) - [Registration Data Policy](https://tldlog.com/de/glossar/registration-data-policy/)