Tenere sotto controllo il drift: la via verso un CMDB al servizio della governance

Il CMDB dovrebbe essere la base informativa su cui appoggiare ogni decisione sul patrimonio IT: rispondere a un audit e dimostrare conformità a normative come NIS2 e DORA, valutare l’impatto di una modifica, pianificare la sicurezza, sapere cosa si ha e come si collega al resto.

Per la maggior parte delle aziende, non lo è. Solo il 36% ha oggi visibilità completa sul proprio IT stack (Flexera, 2026). Chi gestisce il CMDB lo sa: non riesce a tenerlo aggiornato al ritmo con cui l’infrastruttura cambia. E chi deve decidere lo sa altrettanto bene: scottarsi è un attimo, e da allora la fiducia nel dato è scarsa.

Il motivo ha un nome: drift – lo scarto tra quello che il CMDB dichiara e la realtà sul campo. È fisiologico: appena un dato viene registrato, inizia a invecchiare, perché tutto continua a muoversi… deploy, patch, server sostituiti. E più il contesto si fa complesso – multi-cloud, microservizi, API, M&A – più il drift genera ritardo informativo su change management, compliance, sicurezza e acquisti.

La risposta più comune è il cleanup, ovvero la bonifica dei dati, ma è un inseguimento a perdere: dura un tempo limitato, richiede sforzo manuale e lascia sempre un delta destinato a riformarsi appena l’intervento si conclude.

Il punto non è l’accesso ai dati – le fonti sono disponibili – ma la normalizzazione: discovery tool, cloud provider, ticketing e altre fonti come i database di vulnerabilità hanno solo una parte del quadro, con naming e tassonomie diversi. Un allineamento manuale o solo parzialmente automatizzato dura poco: basta che una fonte cambi – e cambiano di continuo – per farlo saltare.

Serve un motore di normalizzazione automatizzato e continuativo, ancorato a una base sempre aggiornata: solo così il CMDB smette di essere una fotografia che invecchia e diventa lo strumento su cui costruire ogni decisione di governance.