--- id: "disclosure-request" kind: "glossary-term" title: "disclosure request" language: "en" category: "Registration data and privacy" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/glossary/disclosure-request/" translations: es: "https://tldlog.com/es/glosario/solicitud-divulgacion/" de: "https://tldlog.com/de/glossar/offenlegungsantrag/" 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/" --- # disclosure request A request to a registrar or registry for registration data that is hidden from public view, such as the owner's name or email. The requester, for example police or a trademark lawyer, explains why they need it. The registrar or registry decides whether to disclose. A disclosure request is how someone asks for the details of a domain owner that are hidden from public view, such as a name or an email address. The request goes to the company that sells or runs the domain and must explain who is asking and why. That company, not ICANN, decides whether to hand the data over. ## What a disclosure request is Since 2018, under the Temporary Specification for gTLD Registration Data, much of the personal data in gTLD registration records has been hidden (tiered access). Today the Registration Data Policy governs it, in force since 21 August 2025 and revised on 12 May 2026: registrars and registries must redact personal data where the law requires it, and may do so in some other cases. ICANN's formal name for it is "Reasonable Requests for Lawful Disclosure". The request goes to the registrar or the registry operator, and the one that receives it decides. ICANN neither takes the decision nor re-examines it. ## Who can ask and on what grounds Anyone may ask. As of October 2026, a request must contain at least: - the requester's identity, contact details and type (business or individual), with proof of authority when acting for someone else; - the data elements wanted; - the requester's legal rights and the specific reason for the request; - a statement of good faith and an agreement to process the data lawfully. The registrar or registry must consider each properly formed request on its merits. Where the law requires it, it weighs the requester's legitimate interest against the registrant's rights, and it may consider other factors, such as jurisdiction. Over the RDRS pilot, intellectual property holders sent 1,202 of the 3,721 requests and law enforcement 605. As of October 2026, in the European Union (EU), Article 28(5) of the NIS2 Directive requires member states to make TLD registries and registrars give specific registration data to legitimate access seekers on a lawful and duly justified request, in line with EU data protection law, and to answer within 72 hours. ## How to send a request, step by step For a gTLD name, as of October 2026: 1. Check the public data with ICANN Lookup, to confirm the data is hidden and find the registrar. 2. Follow the registrar's process. Every registrar and registry must link from its homepage to a page giving the request format, how answers are sent and the expected timeline. 3. Or use RDRS, which is free and needs an ICANN account. The requester picks a category, describes what it wants, may attach up to five PDF files of up to 5 MB each, and confirms it will comply with data protection law. 4. If the registrar does not take part, RDRS lets the requester save the form as a PDF to send directly. In every case, any disclosure happens outside RDRS, by the method the registrar chooses. As of October 2026, RDRS is voluntary for registrars. At the end of its pilot in November 2025, participating registrars covered 46% of domains under management. The ICANN Board extended it for up to two years: to December or November 2027, depending on the ICANN document. RDRS does not cover ccTLDs and is not a way to file a UDRP complaint. ccTLDs apply their own rules and law, so the requester contacts the registry; EURid, for example, offers a form for .eu data. The .es registry is not bound by ICANN's policy or by RDRS, so for a .es name check with Red.es or a lawyer. ## Response times and urgent requests As of October 2026, a registrar or registry must acknowledge a properly formatted request within 2 business days and answer within 30 calendar days of acknowledgement, barring exceptional circumstances. During the RDRS pilot, approvals took 7 days on average and denials 17. The RDRS "Expedited" option does not oblige the registrar to hurry: in the pilot, 169 of 220 such requests were changed to standard, and in an emergency ICANN tells requesters not to rely on it and to contact the registrar directly. Urgent requests were added to the policy on 12 May 2026. They come only from an authenticated law enforcement or other trusted authority, for an imminent threat to life, of serious bodily injury, to critical infrastructure or of child exploitation. The answer would be due within 24 hours, extendable with reasons to at most 72 hours from receipt. As of October 2026 this rule is not in force: it applies only once ICANN implements a policy for authenticating requesters. ICANN is preparing a test with law enforcement, including INTERPOL and the US Federal Bureau of Investigation (FBI). As of October 2026, the RAA requires every gTLD registrar to keep an abuse contact monitored around the clock for authorities of its own jurisdiction and to review their well-founded reports within 24 hours: reports, not disclosure. ## What happens when a request is refused A refusal must give specific reasons and, where that balancing applies, explain how the registrant's rights were weighed against the requester's interest. Refusals are frequent. From launch to 30 June 2026, RDRS recorded 4,275 requests: 1,072 approved and 2,540 denied. The most common reasons in the pilot were that the law prevented disclosure and that the request was incomplete. The requester can then send a new request with more information, or complain to ICANN Contractual Compliance if the registrar did not answer or did not follow the rules; ICANN will not reconsider the decision itself. On 12 March 2026 the ICANN Board decided not to adopt the 18 SSAD recommendations and urged the GNSO Council to finish new work within the RDRS extension, which ends in November 2027. Mandatory registrar participation, response service levels and law enforcement authentication are under discussion; as of October 2026, none is decided. ## Sources - [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) ## related terms - [redaction](https://tldlog.com/glossary/redaction/) - [RDRS](https://tldlog.com/glossary/rdrs/) - [Registration Data Policy](https://tldlog.com/glossary/registration-data-policy/)