NIS2 Art. 28: WHOIS e dati di registrazione dei domini (taglio legal/privacy)
In breve
L’Art. 28 mira a rafforzare sicurezza e resilienza del DNS imponendo a registry/registrar (e servizi di registrazione domini) di raccogliere e mantenere dati di registrazione accurati e completi in un database dedicato, nel rispetto del diritto UE in materia di protezione dei dati.
Inoltre impone la pubblicazione dei soli dati “non personali” e la fornitura di accesso a dati specifici su richieste lecite e adeguatamente motivate, con obbligo di risposta entro 72 ore.
“WHOIS” è il termine comune usato nel settore per indicare la disponibilità/consultazione dei dati di registrazione (in varie forme e interfacce).
Obblighi chiave (cosa devi implementare)
1) Database dedicato e qualità del dato
- Tenere un database dedicato con dati accurati e completi di registrazione domini.
- Raccogliere le informazioni minime per identificare/contattare titolare dominio e punto di contatto amministrativo.
- Avere policy e procedure (incluse verifiche) per prevenire/correggere dati inesatti e rendere tali policy pubbliche.
2) Pubblicazione e disclosure
- Pubblicare “senza indebito ritardo” i dati di registrazione che non sono dati personali.
- Gestire accesso a dati specifici (inclusi dati personali quando richiesto) solo su richiesta lecita e debitamente motivata da richiedenti legittimi.
- Rispondere alle richieste di accesso senza indebito ritardo e comunque entro 72 ore.
3) Cooperazione e non-duplicazione
- Cooperare tra registry e registrar per evitare duplicazioni nella raccolta dei dati.
Impostazione privacy-by-design (legal & DPO)
Art. 28 è “privacy-sensitive”: serve un modello che separi chiaramente (a) dati pubblicabili perché non personali e (b) dati accessibili solo su richiesta legittima, con controlli e logging.
| Elemento | Scelta di design | Output/Evidenza |
|---|---|---|
| Data separation | Due viste: “Public dataset (non-personal)” vs “Restricted dataset (access-controlled)”. | Schema dati + regole di pubblicazione + test periodici. |
| Verifica dati | Procedure di verifica e correzione (almeno un contatto verificato, se tecnicamente e legalmente praticabile). | Procedura + log dei controlli e delle correzioni. |
| Transparency | Informative chiare su quali dati sono raccolti, quali sono pubblicati e quali possono essere divulgati su richiesta. | Privacy notice + changelog. |
| Retention | Retenzione documentata e proporzionata, differenziando dataset pubblico vs ristretto e log delle disclosure. | Retention schedule + evidenza purge. |
| Security & access control | Accesso nominativo, least privilege, auditing, cifratura dove opportuno. | IAM/PAM + audit log + evidenze di review accessi. |
Nota: l’interpretazione concreta (es. cosa è “non personale”, quali verifiche sono “proporzionate”, e chi è “legitimate access seeker”) dipende anche dalla trasposizione nazionale e dalle policy dell’organizzazione.
Accesso ai dati: richieste e SLA 72 ore
Processo consigliato (end-to-end)
- Ricezione: portale o casella dedicata (es.
whois-access@...) con ticket ID e timestamp. - Validazione: controllo formale: richiesta “lecita e motivata”, scopo, dati richiesti, e identificazione del richiedente.
- Decisione: matrice “approve/deny/partial” con regole predefinite e escalation a Legal/DPO nei casi dubbi.
- Risposta: fornire i dati autorizzati o motivare il diniego; rispettare SLA “entro 72 ore”.
- Logging: registrare chi ha richiesto, cosa è stato fornito, base documentale e approvatore.
Matrice decisionale (esempio)
| Tipo richiesta | Dati richiesti | Decisione | Owner |
|---|---|---|---|
| Accesso a dati “non personali” | Dataset pubblico | Automatica (se già pubblicata) | Ops |
| Accesso a “dati specifici” | Dataset ristretto | Valutazione + rilascio controllato o diniego motivato | Legal/DPO + Security |
Suggerimento operativo: definire in policy un “SLA interno” più stringente (es. 48 ore) per avere margine su weekend/festivi e richieste incomplete.
Checklist e evidenze (audit trail)
Checklist (entro 30-60-90 giorni)
- 30 giorni: mappare dati raccolti, dataset pubblicabile, dataset ristretto, e flusso richieste accesso.
- 60 giorni: pubblicare policy e procedure (incluse verifiche), attivare canale richieste e registro disclosure.
- 90 giorni: testare end-to-end (richiesta simulata), misurare tempi e migliorare playbook.
Evidenze minime
- Policy “Domain Registration Data & Disclosure” (pubblica) + versione e data di ultima revisione.
- Procedura di verifica/correzione dati + log esecuzione.
- Registro richieste accesso (ticket, timestamp, esito, approvatore) e prove di risposta entro SLA.
- Misure di sicurezza del database (access control, audit log, backup, protezioni anti-tampering).
FAQ
Art. 28 impone di rendere pubblici i dati personali?
No: la pubblicazione riguarda i dati di registrazione che non sono dati personali; l’accesso a dati specifici (che possono includere dati personali) avviene su richiesta lecita e adeguatamente motivata, nel rispetto del diritto UE sulla protezione dei dati.
Qual è il rischio principale lato privacy?
Gestire disclosure senza regole e senza logging: serve un processo tracciabile (chi, cosa, perché, quando) per dimostrare “accountability”.
