Governance DNS nel 2026: controlli del registrar pronti per l'audit

Alle 07:42 di un lunedì mattina, il Responsabile della sicurezza delle informazioni di una scale-up fintech riceve il messaggio che nessuno vorrebbe vedere. I clienti non riescono ad accedere al portale dei pagamenti, l’help desk è sommerso dalle richieste, la posta elettronica non funziona e il SOC non ha rilevato malware, indisponibilità del firewall o incidenti presso il provider cloud.

La causa radice è più silenziosa e più imbarazzante. Un account del registrar è stato utilizzato con una credenziale amministrativa obsoleta, condivisa da diversi ex membri del personale IT. L’attaccante ha modificato i name server autoritativi, alterato i record MX, disabilitato DNSSEC e reindirizzato il traffico abbastanza a lungo da raccogliere credenziali e interrompere le API dei partner. Il portale dei pagamenti non è stato violato nel senso tradizionale. È stato compromesso l’ancoraggio di fiducia dell’azienda: il suo dominio.

Alle 09:30, la crisi operativa è diventata una crisi di conformità. Il consiglio di amministrazione chiede se il registry lock fosse abilitato. La funzione legale chiede se siano stati esposti dati personali. Il DPO chiede se si tratti di una violazione dei dati personali ai sensi del GDPR. L’autorità di vigilanza vuole sapere se sia stata interessata una funzione critica o importante. Un auditor del cliente richiede il ticket di modifica che autorizzava l’intervento DNS.

In troppe organizzazioni, la risposta è un foglio di calcolo, una casella di posta condivisa e una console del registrar che nessuno ha riesaminato negli ultimi sei mesi.

Nel 2026 la governance DNS e dei registrar di dominio non è più un tema infrastrutturale di nicchia. È parte della resilienza al ransomware, della prevenzione del phishing, della disponibilità cloud, della gestione del rischio dei fornitori, della risposta agli incidenti, della continuità operativa e della conformità basata su evidenze. Se il dominio può essere dirottato, la piattaforma SaaS può scomparire. Se i record DNS possono essere modificati senza approvazione, sicurezza della posta elettronica, SSO, certificati TLS, endpoint API e fiducia dei clienti possono essere compromessi in pochi minuti.

Perché la governance DNS e del registrar deve rientrare nel SGSI

Un nome di dominio non è solo un asset di brand. È un asset logico, una dipendenza di autenticazione, una dipendenza di instradamento e spesso un servizio gestito da un fornitore. Collega provider di identità, autenticazione della posta elettronica, validazione dei certificati TLS, endpoint cloud, portali clienti, API, servizi CDN, sonde di monitoraggio e comunicazioni sugli incidenti.

La Politica di gestione degli asset per PMI di Clarysec Politica di gestione degli asset per PMI lo esplicita nel proprio ambito di applicazione:

Credenziali e servizi digitali: nomi di dominio, certificati digitali, chiavi API, account e-mail, accessi cloud

Dalla sezione “Ambito di applicazione”, clausola 2.2.4 della policy.

La stessa policy richiede più della semplice elencazione del nome di dominio:

Titolarità, finalità, privilegi di accesso e scadenze di rinnovo devono essere documentati.

Dalla sezione “Requisiti di attuazione della policy”, clausola 6.6.2 della policy.

Per gli ambienti enterprise, la Politica di gestione degli asset di Clarysec Politica di gestione degli asset include nell’ambito anche gli asset logici:

Asset logici: nomi di dominio, licenze, account utente, baseline di configurazione

Dalla sezione “Ambito di applicazione”, clausola 2.2.5 della policy.

Questo è il punto di partenza della governance. Un inventario DNS e del registrar deve documentare:

• Nome di dominio, registro, registrar, provider di hosting DNS e name server autoritativi
• Titolare del servizio, referente tecnico, responsabile della sicurezza e approvatore di emergenza
• Finalità, ad esempio portale di produzione, API, e-mail, SSO, marketing, ambiente di test o registrazione difensiva
• Classificazione di criticità e mappatura delle dipendenze rispetto ai servizi aziendali
• Stato DNSSEC, stato dei record DS, titolarità delle chiavi e processo di rotazione delle chiavi
• Stato del registry lock e del registrar lock
• MFA e modello di accesso privilegiato per gli account del registrar e del provider DNS
• Data di rinnovo, stato del rinnovo automatico, responsabile del pagamento e avviso di scadenza
• Requisiti di controllo delle modifiche per modifiche di zona e modifiche di delega
• Logging, alerting, monitoraggio e conservazione delle evidenze

Per questo motivo la governance dei domini deve comparire nel campo di applicazione del SGSI e nella valutazione del rischio ISO/IEC 27001:2022. ISO/IEC 27001:2022 richiede alle organizzazioni di determinare il contesto, i requisiti delle parti interessate, gli obblighi legali e contrattuali, le interfacce e le dipendenze con organizzazioni esterne. Il DNS dipende da registrar, registri, provider di hosting DNS, provider cloud, autorità di certificazione, MSP e talvolta agenzie di marketing. Se tali interfacce sono escluse dal SGSI, la traccia di audit sarà incompleta.

Il modello di minaccia DNS nel 2026

I guasti DNS più dannosi sono spesso semplici:

1. Un dominio scade perché la responsabilità del rinnovo non era chiara.
2. Una vecchia agenzia dispone ancora dell’accesso a un account del registrar.
3. DNSSEC è abilitato, ma i record DS sono errati dopo una migrazione del provider DNS.
4. Un record wildcard indirizza il traffico verso un servizio cloud abbandonato.
5. Un record TXT viene modificato per convalidare un tenant SaaS controllato dall’attaccante o una richiesta di certificato.
6. I record MX vengono modificati durante una campagna di phishing o di intercettazione della posta elettronica.
7. Un CNAME verso una piattaforma di terze parti diventa esposto a takeover.
8. Il registry lock esiste per il dominio primario, ma non per i domini nazionali rivolti ai clienti.
9. Il SOC monitora gli endpoint, ma nessuno monitora le modifiche ai file di zona.

Le misure di sicurezza tecniche sono ben note. DNSSEC contribuisce a proteggere l’integrità dei dati DNS e l’autenticazione dell’origine. Il registry lock impone verifiche aggiuntive fuori banda per le modifiche ad alto rischio a livello di registro. Il registrar lock riduce il rischio di trasferimenti non autorizzati. MFA e riesami degli accessi privilegiati riducono la probabilità di compromissione degli account. Il controllo delle modifiche previene interruzioni accidentali. Il monitoraggio rileva modifiche non autorizzate o inattese.

La sfida di conformità è diversa: siete in grado di dimostrare che queste misure di sicurezza esistono, hanno un responsabile, sono riesaminate e funzionano durante un incidente?

È su questa domanda relativa alle evidenze che molte organizzazioni falliscono.

Mappare la governance DNS a ISO/IEC 27001:2022 e ISO/IEC 27002:2022

ISO/IEC 27001:2022 fornisce la struttura del sistema di gestione per trasformare i controlli DNS in processi ripetibili e verificabili. L’Annex A di ISO/IEC 27001:2022 e le linee guida sui controlli di ISO/IEC 27002:2022 forniscono il linguaggio di controllo atteso dagli auditor.

Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec Zenith Blueprint tratta i servizi di rete come oggetti di audit espliciti. Nella fase Controls in Action, passaggio 20, indica ai team di convalidare la sicurezza dei servizi di rete:

Elencare tutti i servizi di rete interni ed esterni (DNS, VPN, SMTP, DHCP, gateway API, ecc.).

✓ Per ciascuno, confermare che utilizzi protocolli sicuri (ad es. DNSSEC, TLS 1.2+, SSH invece di Telnet). ✓ Riesaminare come viene controllato l’accesso a ciascun servizio (ad es. whitelist IP, autenticazione, certificati). ✓ Se gestiti da terze parti (ad es. DNS, SD-WAN, VPN ospitata), riesaminare le clausole di sicurezza nello SLA o nel contratto con il fornitore. Aggiornare il Registro dei servizi e indicare dove risiedono le responsabilità di sicurezza, interne o esterne.

Dalla fase Controls in Action, passaggio 20: controlli da 8.18 a 8.26.

Questo offre un percorso di audit pratico: trattare il DNS come un servizio di rete esterno, documentare come è protetto e registrare se la responsabilità è interna, del registrar, del provider DNS o di un MSP.

Zenith Controls: The Cross-Compliance Guide di Clarysec Zenith Controls è utile perché la governance DNS raramente si mappa su un solo quadro di riferimento. La stessa decisione su DNSSEC o registry lock supporta evidenze per ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019.

Per il monitoraggio dei fornitori, Zenith Controls mappa il controllo 5.22 di ISO/IEC 27002:2022, monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori, come controllo preventivo a supporto di riservatezza, integrità e disponibilità. Per il DNS, significa che il registrar e il provider DNS non sono fornitori da configurare e dimenticare. Il loro livello di sicurezza, le modifiche dei servizi, le indisponibilità, i sub-responsabili e le prassi di notifica devono essere riesaminati.

Per DNSSEC e l’integrità crittografica, Zenith Controls mappa il controllo 8.24 di ISO/IEC 27002:2022, uso della crittografia, come controllo preventivo allineato alla configurazione sicura. DNSSEC non cifra il traffico DNS, ma fornisce assurance crittografica sull’integrità dei dati DNS e sull’autenticazione dell’origine.

Per le modifiche alle zone DNS, Zenith Controls mappa il controllo 8.32 di ISO/IEC 27002:2022, Gestione delle modifiche, come controllo preventivo a supporto di riservatezza, integrità e disponibilità. Una modifica DNS è una modifica di configurazione. L’aggiornamento di un record DS, la modifica di un record MX, la migrazione di un CNAME, l’aggiornamento SPF o DMARC, il cutover CDN o la modifica della delega dei name server devono avere un ticket, una valutazione del rischio, un’approvazione, un esito di test e un piano di rollback.

DNSSEC, registry lock e gestione delle chiavi per domini critici

Non tutti i domini hanno lo stesso profilo di rischio. Un dominio difensivo utilizzato solo per prevenire impersonificazioni può richiedere monitoraggio e disciplina nel rinnovo. Un dominio primario di un portale clienti richiede i controlli più robusti disponibili.

Per i domini critici, Clarysec raccomanda in genere questa baseline:

• DNSSEC abilitato e validato dove supportato da registro, registrar e provider DNS
• Record DS riesaminati dopo qualsiasi migrazione del provider DNS
• Processo documentato di rollover KSK e ZSK, quando le chiavi sono gestite dal cliente
• Registry lock abilitato per domini primari di produzione, identità, API, pagamenti ed e-mail
• Registrar lock abilitato per tutti i domini, salvo eccezione temporanea documentata
• MFA applicata a tutti gli utenti del registrar e del provider DNS
• Utenti privilegiati limitati, nominativi, approvati e riesaminati
• Accesso break glass documentato e testato
• Monitoraggio dei file di zona con alert su modifiche NS, DS, DNSKEY, MX, TXT, A, AAAA, CNAME, CAA e wildcard
• Monitoraggio esterno da più resolver e regioni
• Evidenze conservate nel repository documentale del SGSI

La Politica sui controlli crittografici enterprise di Clarysec Politica sui controlli crittografici fornisce l’aggancio di governance per le chiavi DNSSEC:

Deve essere mantenuto un registro centralizzato di gestione delle chiavi per registrare tutte le chiavi crittografiche, il loro stato nel ciclo di vita, i custodi assegnati e i contesti di utilizzo.

Dalla sezione “Requisiti di governance”, clausola 5.2 della policy.

Se l’organizzazione gestisce direttamente le chiavi DNSSEC o controlla la pubblicazione dei record DS presso il registrar, il registro di gestione delle chiavi deve documentare custodia, stato del ciclo di vita, date di rollover e autorità di approvazione. Se il provider DNS gestisce le chiavi DNSSEC, la scheda del fornitore deve descrivere tale responsabilità e includere evidenze di assurance.

Governance degli accessi al registrar: MFA, principio del privilegio minimo e controllo di emergenza

Gli account del registrar vengono spesso creati nelle prime fasi di vita di un’azienda e poi dimenticati mentre l’organizzazione matura. Fondatori, agenzie, sviluppatori, utenti dell’area finance e MSP possono tutti disporre di accessi storici. Questa è una grave debolezza di controllo.

La Politica di gestione degli account utente e dei privilegi per PMI di Clarysec Politica di gestione degli account utente e dei privilegi per PMI stabilisce:

I privilegi elevati o amministrativi richiedono un’ulteriore approvazione da parte del Direttore generale o del Referente IT e devono essere documentati, limitati nel tempo e soggetti a riesame periodico.

Dalla sezione “Requisiti di attuazione della policy”, clausola 6.2.2 della policy.

Applicate questo criterio in modo diretto agli accessi al registrar e al provider DNS:

• Nessun account amministratore del registrar condiviso
• MFA per ogni utente, preferibilmente resistente al phishing ove supportato
• Contatti di emergenza nominativi con autorità documentata
• Separazione, ove possibile, tra utenti di fatturazione e amministratori tecnici
• Revoca immediata degli accessi di ex dipendenti, agenzie e fornitori
• Riesame trimestrale degli accessi privilegiati per i domini critici
• Eccezioni registrate con date di scadenza
• Procedure di sblocco e ripristino di emergenza testate, che non generino modifiche non sicure in produzione

Le evidenze del registry lock devono includere screenshot o attestazioni del registrar che dimostrino lo stato abilitato, i contatti autorizzati, il processo di sblocco e la data dell’ultimo riesame.

Controllo delle modifiche di zona: piccole modifiche DNS, grande impatto aziendale

Le modifiche DNS sono ingannevolmente piccole. Un record TXT può convalidare la titolarità di una piattaforma SaaS. Un CNAME può reindirizzare i clienti verso un nuovo ambiente. Un record MX può reinstradare la posta. Un record CAA può influire sull’emissione dei certificati. Un record DS errato può impedire la validazione di un dominio firmato.

La Politica di gestione delle modifiche per PMI di Clarysec Politica di gestione delle modifiche per PMI stabilisce:

Tutte le modifiche devono essere presentate come richiesta di modifica (e-mail, modulo o ticket help desk).

Dalla sezione “Requisiti di governance”, clausola 5.1.1 della policy.

Per i clienti enterprise, la Politica di gestione delle modifiche di Clarysec Politica di gestione delle modifiche aumenta l’aspettativa sulle evidenze:

Tutte le richieste di modifica, i riesami, le approvazioni e le evidenze a supporto devono essere registrati nel Sistema centralizzato di gestione delle modifiche.

Dalla sezione “Requisiti di attuazione della policy”, clausola 6.1.1 della policy.

Lo Zenith Blueprint rafforza questo requisito nella fase Controls in Action, passaggio 21:

Selezionare 2–3 modifiche recenti di sistema o di configurazione e verificare se sono state gestite tramite il vostro flusso di approvazione formale per la gestione delle modifiche.

✓ I rischi sono stati valutati? ✓ Le approvazioni sono state documentate? ✓ Era incluso un piano di rollback?

Validare che le modifiche siano state attuate come pianificato e che eventuali incidenti o impatti inattesi siano stati registrati. Riesaminare log, differenze nei sistemi di controllo delle versioni o tracce di audit da strumenti come ServiceNow, Jira o Git. Acquisire questo processo in un Log riepilogativo delle registrazioni di modifica come riferimento per l’audit.

Dalla fase Controls in Action, passaggio 21: controlli da 8.27 a 8.34.

Un ticket di modifica specifico per il DNS deve includere dominio e zona interessati, tipo di record, valori precedenti e successivi, motivazione aziendale, valutazione del rischio, finestra di attuazione, approvatore, esecutore, verificatore, controlli di propagazione DNS, validazione DNSSEC, piano di rollback, monitoraggio post-modifica ed evidenze esportate.

Il principio di audit è semplice: le modifiche DNS devono essere tracciabili dalla richiesta all’approvazione, dall’attuazione alla verifica.

Monitoraggio e logging: rilevare la modifica DNS prima dei clienti

Un programma maturo di governance DNS presume che la prevenzione possa fallire. Il monitoraggio deve rilevare rapidamente le modifiche inattese, così da supportare la risposta agli incidenti.

La Politica di sicurezza della rete per PMI di Clarysec Politica di sicurezza della rete per PMI è esplicita:

Il logging DNS deve essere abilitato per supportare il threat hunting e la risposta agli incidenti

Dalla sezione “Requisiti di attuazione della policy”, clausola 6.6.3 della policy.

La Politica di logging e monitoraggio enterprise Politica di logging e monitoraggio parte dalla stessa aspettativa operativa:

Tutti i sistemi coperti devono generare log che acquisiscano:

Dalla sezione “Requisiti di attuazione della policy”, clausola 6.1.1 della policy.

Per la governance DNS e del registrar, i sistemi coperti devono includere portali del registrar, console di hosting DNS, gestione DNS basata su API, pipeline CI/CD che rilasciano DNS as code, alert SIEM e strumenti di monitoraggio esterni.

Il monitoraggio deve essere integrato nella risposta agli incidenti. Un alert DNS senza owner, classificazione di gravità o runbook è solo rumore.

NIS2, DORA e GDPR: governance DNS come evidenza regolatoria

NIS2 Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi per i sistemi informativi e di rete e ridurre al minimo l’impatto degli incidenti. La governance DNS si mappa in modo naturale su gestione degli asset, controllo degli accessi, crittografia, sicurezza della catena di fornitura, gestione degli incidenti, continuità operativa e valutazione dell’efficacia.

NIS2 Article 20 attribuisce inoltre al management body la responsabilità della cibersicurezza. I consigli di amministrazione non devono approvare ogni record TXT, ma devono comprendere se i domini critici sono protetti da DNSSEC, registry lock, MFA, monitoraggio e ripristino testato. Per gli incidenti significativi, NIS2 Article 23 introduce una segnalazione per fasi, inclusi preallarme entro 24 ore, notifica dell’incidente entro 72 ore e relazione finale non oltre un mese dalla notifica dell’incidente.

Per le entità finanziarie regolamentate, DORA si applica dal 17 gennaio 2025 e opera come quadro di riferimento settoriale per la resilienza ICT quando si sovrappone a NIS2. Il DNS supporta spesso funzioni critiche o importanti, quali applicazioni di pagamento, mobile banking, portali di trading, identità dei clienti, sistemi antifrode, gateway API e integrazioni con terze parti. Le evidenze DORA devono mostrare la mappatura delle dipendenze degli asset ICT, la classificazione degli incidenti, i test di resilienza, la gestione del rischio delle terze parti e la pianificazione del ripristino per scenari di guasto DNS e del registrar.

Un incidente DNS non costituisce automaticamente una violazione dei dati personali ai sensi del GDPR. Può diventarlo se gli utenti vengono reindirizzati verso un sito di phishing, le credenziali vengono raccolte, la posta elettronica contenente dati personali viene reinstradata, il traffico verso sistemi di trattamento di dati personali viene intercettato o la disponibilità dei dati personali è materialmente compromessa. GDPR Article 5 richiede integrità, riservatezza e accountability. Article 32 richiede misure di sicurezza adeguate per il trattamento. La governance DNS fornisce evidenza che l’instradamento dei domini e i servizi dipendenti dal DNS sono protetti con misure tecniche e organizzative proporzionate.

Costruire un pacchetto di evidenze DNS in una settimana

Un piano pratico di remediation della governance DNS può essere completato rapidamente se guidato dalle evidenze.

Giorno 1: creare il registro dei domini e dei servizi DNS

Partire dal requisito della Politica di gestione degli asset per PMI di documentare titolarità, finalità, privilegi di accesso e scadenze di rinnovo.

Giorno 2: riesaminare accessi e privilegi

Esportare gli utenti del registrar e del provider DNS. Rimuovere gli account obsoleti. Applicare MFA. Identificare gli amministratori. Registrare le evidenze di approvazione per gli utenti privilegiati e documentare l’accesso di emergenza.

Giorno 3: validare DNSSEC e locking

Per ogni dominio critico, verificare la validazione della catena DNSSEC, l’accuratezza dei record DS, la visibilità DNSKEY, il registrar lock e il registry lock. Se DNSSEC è gestito dal provider, documentare la responsabilità del provider. Se è gestito dal cliente, aggiungere chiavi DNSSEC e custodi al registro di gestione delle chiavi.

Giorno 4: trasformare le modifiche DNS in registrazioni formali di modifica

Selezionare le ultime tre modifiche DNS e verificarle rispetto ai criteri dello Zenith Blueprint passaggio 21: rischio valutato, approvazione documentata, piano di rollback incluso, attuazione conforme al piano e impatto inatteso registrato. Creare un Log riepilogativo delle registrazioni di modifica.

Giorno 5: collegare il monitoraggio alla risposta agli incidenti

Confermare log e alert per accessi al registrar, modifiche di zona, modifiche DNSSEC, modifiche NS, modifiche MX, modifiche TXT, modifiche CAA e notifiche del provider. Inviare alert di test al SOC o al responsabile IT. Allegare le evidenze al repository documentale del SGSI.

Giorno 6: riesaminare gli obblighi dei fornitori

Utilizzare le indicazioni dello Zenith Blueprint passaggio 23 per le procedure di modifica e monitoraggio dei fornitori:

Stabilire una procedura semplice e scalabile per valutare le modifiche ai servizi dei fornitori (5.21), quali migrazione al cloud, nuovi sub-responsabili o riprogettazione dell’infrastruttura. Definire i trigger che richiedono una rivalutazione della sicurezza. Quindi, attuare una cadenza ricorrente di monitoraggio dei fornitori (5.22), assegnando proprietari ai fornitori critici e assicurando che prestazioni, conformità e rischi siano riesaminati almeno annualmente.

Dalla fase Controls in Action, passaggio 23: controlli organizzativi da 5.19 a 5.37.

La Politica di sicurezza delle terze parti e dei fornitori enterprise di Clarysec Politica di sicurezza delle terze parti e dei fornitori fornisce l’ancoraggio contrattuale:

I contratti con i fornitori devono includere:

Dalla sezione “Requisiti di governance”, clausola 5.3 della policy.

Giorno 7: eseguire un’esercitazione tabletop

Simulare una modifica non autorizzata del record NS. Il team deve rilevarla, classificarla, escalarla, contattare il registrar, invocare le procedure di registry lock se necessario, ripristinare la delega corretta, validare DNSSEC, notificare le parti interessate, valutare l’impatto GDPR e decidere se le soglie di segnalazione NIS2 o DORA siano soddisfatte. Acquisire le lezioni apprese e aggiornare le procedure.

Domande di audit, rilievi comuni e metriche per il consiglio di amministrazione

Un audit della governance DNS raramente viene condotto da una sola prospettiva.

I rilievi più comuni sono prevedibili.

I consigli di amministrazione e i team di direzione hanno bisogno di metriche DNS espresse nel linguaggio della resilienza. Misure utili includono la percentuale di domini critici con DNSSEC abilitato e validato, la percentuale con registry lock, il numero di amministratori del registrar, la percentuale di utenti privilegiati riesaminati nell’ultimo trimestre, il numero di modifiche DNS attuate senza ticket formali, il tempo medio di rilevamento di una modifica DNS non autorizzata, il tempo medio di ripristino della configurazione DNS corretta, i domini in scadenza entro 90 giorni, i riesami dei fornitori completati e gli alert di monitoraggio DNS non risolti.

Trasformare il DNS da rischio nascosto a evidenza pronta per l’audit

Se la vostra organizzazione non ha riesaminato la governance di domini e DNS negli ultimi sei mesi, presumete che esista deriva. Iniziate dai domini critici di produzione, quindi estendete il perimetro a domini regionali, domini difensivi, domini di test, domini acquisiti e domini gestiti da agenzie o controllate.

Clarysec può aiutarvi a passare da screenshot sparsi del registrar a un pacchetto strutturato di evidenze utilizzando:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint per la validazione passo-passo di servizi di rete, gestione delle modifiche, logging, monitoraggio e controlli sui fornitori
• Zenith Controls: The Cross-Compliance Guide Zenith Controls per mappare DNSSEC, registry lock, monitoraggio dei fornitori e governance delle modifiche di zona nelle prospettive ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST e COBIT 2019
• Modelli di policy Clarysec, inclusi Politica di gestione degli asset per PMI, Politica di gestione delle modifiche per PMI, Politica di gestione degli account utente e dei privilegi per PMI, Politica di sicurezza della rete per PMI, Politica di gestione degli asset, Politica di gestione delle modifiche, Politica di logging e monitoraggio, Politica sui controlli crittografici e Politica di sicurezza delle terze parti e dei fornitori

Il dominio è la porta d’ingresso del vostro business digitale. Nel 2026, auditor, autorità di vigilanza, clienti e consigli di amministrazione si aspetteranno che dimostriate che quella porta è chiusa, monitorata, recuperabile e governata.

Scaricate il toolkit Clarysec, eseguite l’esercizio di una settimana per il pacchetto di evidenze DNS oppure prenotate un assessment Clarysec per trasformare la governance DNS e del registrar in evidenze pronte per l’audit prima della vostra crisi del lunedì mattina.