--- id: "disclosure-request" kind: "glossary-term" title: "richiesta di divulgazione" language: "it" category: "Dati di registrazione e privacy" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/it/glossario/richiesta-divulgazione/" translations: en: "https://tldlog.com/glossary/disclosure-request/" es: "https://tldlog.com/es/glosario/solicitud-divulgacion/" de: "https://tldlog.com/de/glossar/offenlegungsantrag/" fr: "https://tldlog.com/fr/glossaire/demande-divulgation/" 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/" --- # richiesta di divulgazione Una richiesta a un registrar o a un registro di dati di registrazione non visibili al pubblico, come il nome o l'email del titolare. Chi la presenta, per esempio la polizia o un avvocato esperto di marchi, spiega perché ne ha bisogno. Il registrar o il registro decide se comunicarli. Una richiesta di comunicazione dei dati è il modo in cui qualcuno chiede i dati del titolare di un dominio che sono nascosti al pubblico, come un nome o un indirizzo email. La richiesta va all'impresa che vende o gestisce il dominio e deve spiegare chi la presenta e perché. È quell'impresa, non l'ICANN, a decidere se consegnare i dati. ## Che cos'è una richiesta di comunicazione dei dati Dal 2018, in base alla Specifica temporanea (Temporary Specification for gTLD Registration Data), gran parte dei dati personali nei record di registrazione dei gTLD è nascosta (accesso a più livelli). Oggi la materia è regolata dalla Registration Data Policy, in vigore dal 21 agosto 2025 e rivista il 12 maggio 2026: registrar e registri devono oscurare i dati personali dove la legge lo richiede, e possono farlo in alcuni altri casi. Il nome formale usato dall'ICANN è «Reasonable Requests for Lawful Disclosure». La richiesta va al registrar o al gestore del registro, e decide chi la riceve. L'ICANN non prende la decisione e non la riesamina. ## Chi può chiedere e su quali basi Chiunque può presentare una richiesta. A ottobre 2026, una richiesta deve contenere almeno: - l'identità del richiedente, i suoi recapiti e il tipo di richiedente (impresa o persona fisica), con la prova dei poteri quando agisce per conto di altri; - i dati richiesti; - i diritti del richiedente e il motivo specifico della richiesta; - una dichiarazione di buona fede e l'impegno a trattare i dati in modo lecito. Il registrar o il registro deve esaminare nel merito ogni richiesta presentata correttamente. Dove la legge lo richiede, bilancia l'interesse legittimo del richiedente con i diritti dell'assegnatario, e può considerare altri fattori, come la giurisdizione. Nel corso della fase pilota dell'RDRS, i titolari di diritti di proprietà intellettuale hanno inviato 1.202 delle 3.721 richieste e le forze dell'ordine 605. A ottobre 2026, nell'Unione europea (UE), l'articolo 28, paragrafo 5, della direttiva NIS2 impone agli Stati membri di far sì che i registri dei TLD e i registrar forniscano dati di registrazione specifici ai soggetti legittimati che ne fanno richiesta in modo lecito e debitamente motivato, nel rispetto del diritto dell'UE sulla protezione dei dati, e che rispondano entro 72 ore. ## Come inviare una richiesta, passo per passo Per un nome in un gTLD, a ottobre 2026: 1. Controllare i dati pubblici con ICANN Lookup, per confermare che i dati sono nascosti e individuare il registrar. 2. Seguire la procedura del registrar. Ogni registrar e registro deve inserire nella propria home page un link a una pagina che indichi il formato della richiesta, come vengono inviate le risposte e i tempi previsti. 3. In alternativa, usare l'RDRS, che è gratuito e richiede un account ICANN. Il richiedente sceglie una categoria, descrive che cosa vuole, può allegare fino a cinque file PDF di massimo 5 MB ciascuno e conferma che rispetterà la normativa sulla protezione dei dati. 4. Se il registrar non partecipa, l'RDRS consente al richiedente di salvare il modulo in PDF per inviarlo direttamente. In ogni caso, l'eventuale comunicazione dei dati avviene fuori dall'RDRS, con il metodo scelto dal registrar. A ottobre 2026, la partecipazione all'RDRS è facoltativa per i registrar. Alla fine della fase pilota, nel novembre 2025, i registrar partecipanti coprivano il 46% dei domini gestiti. Il Consiglio di amministrazione dell'ICANN l'ha prorogato fino a due anni: fino a dicembre o novembre 2027, a seconda del documento dell'ICANN. L'RDRS non copre i ccTLD e non è un modo per presentare un ricorso UDRP. I ccTLD applicano regole e leggi proprie, quindi il richiedente deve rivolgersi al registro; EURid, per esempio, offre un modulo per i dati .eu. Il registro di .es non è vincolato dalla policy dell'ICANN né dall'RDRS, quindi per un nome .es è bene informarsi presso Red.es o un avvocato. ## Tempi di risposta e richieste urgenti A ottobre 2026, un registrar o un registro deve confermare la ricezione di una richiesta formulata correttamente entro 2 giorni lavorativi e rispondere entro 30 giorni di calendario dalla conferma, salvo circostanze eccezionali. Durante la fase pilota dell'RDRS, le richieste accolte hanno richiesto in media 7 giorni e quelle respinte 17. L'opzione «Expedited» (accelerata) dell'RDRS non obbliga il registrar ad affrettarsi: nella fase pilota, 169 delle 220 richieste di questo tipo sono state trasformate in richieste ordinarie, e in caso di emergenza l'ICANN raccomanda ai richiedenti di non farvi affidamento e di contattare direttamente il registrar. Le richieste urgenti sono state aggiunte alla policy il 12 maggio 2026. Possono provenire solo da forze dell'ordine o da un'altra autorità affidabile autenticate, per una minaccia imminente alla vita, di lesioni fisiche gravi, alle infrastrutture critiche o di sfruttamento di minori. La risposta sarebbe dovuta entro 24 ore, prorogabili con motivazione fino a un massimo di 72 ore dalla ricezione. A ottobre 2026 questa regola non è in vigore: si applica solo quando l'ICANN avrà attuato una policy per l'autenticazione dei richiedenti. L'ICANN sta preparando un test con le forze dell'ordine, tra cui INTERPOL e il Federal Bureau of Investigation (FBI) degli Stati Uniti. A ottobre 2026, il RAA impone a ogni registrar di gTLD di mantenere un contatto per gli abusi presidiato 24 ore su 24 per le autorità della propria giurisdizione e di esaminare le loro segnalazioni fondate entro 24 ore: si tratta di segnalazioni, non di comunicazione dei dati. ## Che cosa succede quando una richiesta viene respinta Un rifiuto deve indicare motivi specifici e, quando si applica quel bilanciamento, spiegare come i diritti dell'assegnatario sono stati valutati rispetto all'interesse del richiedente. I rifiuti sono frequenti. Dal lancio al 30 giugno 2026, l'RDRS ha registrato 4.275 richieste: 1.072 accolte e 2.540 respinte. I motivi più comuni nella fase pilota erano che la legge impediva la comunicazione e che la richiesta era incompleta. Il richiedente può allora inviare una nuova richiesta con più informazioni, oppure presentare un reclamo alla Conformità contrattuale dell'ICANN se il registrar non ha risposto o non ha rispettato le regole; l'ICANN non riesaminerà la decisione in sé. Il 12 marzo 2026 il Consiglio di amministrazione dell'ICANN ha deciso di non adottare le 18 raccomandazioni SSAD e ha esortato il Consiglio della GNSO a concludere nuovi lavori entro la proroga dell'RDRS, che termina a novembre 2027. Sono in discussione la partecipazione obbligatoria dei registrar, i livelli di servizio per le risposte e l'autenticazione delle forze dell'ordine; a ottobre 2026, nulla è stato deciso. ## Fonti - [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) ## termini correlati - [oscuramento dei dati](https://tldlog.com/it/glossario/oscuramento-dati/) - [RDRS](https://tldlog.com/it/glossario/rdrs/) - [Registration Data Policy](https://tldlog.com/it/glossario/registration-data-policy/)