---
id: "disclosure-request"
kind: "glossary-term"
title: "solicitud de divulgación"
language: "es"
category: "Datos de registro y privacidad"
updated: "2026-10-10T10:28:55Z"
canonical: "https://tldlog.com/es/glosario/solicitud-divulgacion/"
translations:
  en: "https://tldlog.com/glossary/disclosure-request/"
  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/"
---

# solicitud de divulgación

Petición a un registrador o a un registro de datos de registro que no están a la vista del público, como el nombre o el correo electrónico del titular. El solicitante, por ejemplo la policía o un abogado de marcas, explica por qué los necesita. El registrador o el registro decide si los divulga.

Una solicitud de divulgación es la forma de pedir los datos del titular de un dominio que no se muestran al público, como su nombre o su correo electrónico. Se dirige a la empresa que vende o gestiona el dominio y debe explicar quién pide los datos y para qué. Es esa empresa, y no la ICANN, la que decide si los entrega.

## Qué es una solicitud de divulgación

Desde 2018, con la Especificación Temporal para los datos de registro de los gTLD, buena parte de los datos personales de los gTLD está oculta (acceso por niveles). Hoy lo regula la Política de Datos de Registro, en vigor desde el 21 de agosto de 2025 y revisada el 12 de mayo de 2026: registradores y registros deben ocultar los datos personales cuando la ley lo exige y pueden hacerlo en otros casos.

La política habla de «solicitudes razonables de divulgación lícita». La solicitud se envía al registrador o al operador de registro, y quien la recibe decide. La ICANN no toma la decisión ni la revisa.

## Quién puede pedir datos y con qué fundamento

Cualquiera puede presentar una solicitud. A octubre de 2026, debe incluir como mínimo:

- la identidad del solicitante, sus datos de contacto y si es una empresa o un particular, con un poder u otra prueba si actúa en nombre de otro;
- los datos concretos que pide;
- los derechos legales que invoca y el motivo específico de la petición;
- una declaración de buena fe y el compromiso de tratar los datos de forma lícita.

El registrador o el registro debe estudiar cada solicitud bien formulada según sus méritos. Cuando la ley lo exige, pondera el interés legítimo del solicitante frente a los derechos del titular, y puede tener en cuenta otros factores, como la jurisdicción.

En el piloto del RDRS, los titulares de propiedad intelectual enviaron 1.202 de las 3.721 solicitudes, y las fuerzas de seguridad, 605.

A octubre de 2026, en la Unión Europea (UE), el artículo 28.5 de la Directiva SRI 2 (NIS2) obliga a los Estados miembros a exigir que registros y registradores den acceso a datos concretos a los «solicitantes de acceso legítimos», previa «solicitud lícita y debidamente justificada» y conforme a la normativa de protección de datos de la UE, y que respondan en 72 horas.

## Cómo presentar una solicitud, paso a paso

Para un dominio gTLD, a octubre de 2026:

1. Consultar los datos públicos en ICANN Lookup, para confirmar que están ocultos y saber cuál es el registrador.
2. Seguir el procedimiento del registrador. Todo registrador y todo registro debe enlazar desde su página principal a otra que indique el formato de las solicitudes, cómo se envía la respuesta y el plazo previsto.
3. O usar el RDRS, gratuito y con una cuenta de la ICANN. Se elige una categoría, se describe lo que se pide, se pueden adjuntar hasta cinco PDF de 5 MB cada uno y se confirma el cumplimiento de la normativa de protección de datos.
4. Si el registrador no participa, el RDRS permite guardar el formulario en PDF para enviárselo directamente. En todo caso, la divulgación, si la hay, se hace fuera del RDRS, por el medio que elija el registrador.

A octubre de 2026, la participación en el RDRS es voluntaria para los registradores. Al acabar el piloto, en noviembre de 2025, los participantes cubrían el 46 % de los dominios gestionados. La Junta Directiva lo prorrogó hasta dos años: hasta diciembre o noviembre de 2027, según el documento de la ICANN. El RDRS no sirve para los ccTLD ni para presentar una demanda UDRP.

Los ccTLD aplican sus propias normas y su propia ley, así que hay que dirigirse al registro; EURid, por ejemplo, ofrece un formulario para los datos de .eu. El registro de .es no está sujeto a la política de la ICANN ni al RDRS: para un dominio .es, conviene consultar a Red.es o a un abogado.

## Plazos de respuesta y solicitudes urgentes

A octubre de 2026, el registrador o el registro debe acusar recibo de una solicitud con el formato correcto en 2 días hábiles y responder en 30 días naturales desde el acuse, salvo circunstancias excepcionales. En el piloto del RDRS, las aprobaciones tardaron 7 días de media y las denegaciones, 17. La opción «Expedited» (tramitación acelerada) del RDRS no obliga al registrador a darse prisa: en el piloto, 169 de 220 solicitudes así marcadas pasaron a la vía ordinaria, y en una emergencia la ICANN recomienda no confiar en ella y contactar directamente con el registrador.

Las solicitudes urgentes se añadieron a la política el 12 de mayo de 2026. Solo pueden presentarlas fuerzas de seguridad u otras autoridades autenticadas, ante una amenaza inminente para la vida, de lesiones graves, para infraestructuras críticas o de explotación infantil. La respuesta debería llegar en 24 horas, prorrogables con motivos hasta un máximo de 72 horas desde la recepción. A octubre de 2026 esta regla no está en vigor: solo se aplicará cuando la ICANN implante una política para autenticar a los solicitantes. La ICANN prepara una prueba con fuerzas de seguridad, entre ellas INTERPOL y el FBI (Buró Federal de Investigaciones de EE. UU.).

A octubre de 2026, el RAA obliga a todo registrador de gTLD a tener un contacto de abusos atendido las 24 horas para las autoridades de su jurisdicción y a revisar en 24 horas sus denuncias bien fundadas: denuncias, no divulgación.

## Qué ocurre si se deniega la solicitud

La denegación debe dar motivos concretos y, cuando proceda esa ponderación, explicar cómo se han sopesado los derechos del titular frente al interés del solicitante.

Las denegaciones son frecuentes. Desde su lanzamiento hasta el 30 de junio de 2026, el RDRS registró 4.275 solicitudes: 1.072 aprobadas y 2.540 denegadas. En el piloto, los motivos más habituales fueron que la ley impedía la divulgación y que la solicitud estaba incompleta.

El solicitante puede enviar una nueva solicitud con más información o reclamar al departamento de Cumplimiento Contractual de la ICANN si el registrador no respondió o no siguió las normas; la ICANN no revisará la decisión en sí.

El 12 de marzo de 2026, la Junta Directiva de la ICANN decidió no adoptar las 18 recomendaciones sobre el SSAD e instó al Consejo de la GNSO a terminar el nuevo trabajo dentro de la prórroga del RDRS, que acaba en noviembre de 2027. Se debaten la participación obligatoria de los registradores, niveles de servicio para las respuestas y la autenticación de las fuerzas de seguridad; a octubre de 2026, nada de ello está decidido.

## Fuentes

- [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)

## términos relacionados

- [ocultación](https://tldlog.com/es/glosario/ocultacion/)
- [RDRS](https://tldlog.com/es/glosario/rdrs/)
- [Política de Datos de Registro](https://tldlog.com/es/glosario/politica-datos-registro/)
