Siamo ormai nel quarto trimestre del 2026 e la scadenza del febbraio 2027 per la conformità totale NIS2 si avvicina rapidamente. Come System Administrator che gestisce infrastrutture di hosting, ho visto crescere la pressione normativa intorno ai requisiti di supply chain security e alla verifica identitativa Know Your Customer (KYC) prevista dall’Article 28 della NIS2 Directive. In questa guida vi mostro come ho implementato queste misure nella mia pratica operativa quotidiana.
La NIS2 non è più una prospettiva lontana: è una realtà legale attiva con enforcement attivo, e poiché il deadline di transposizione nazionale (17 ottobre 2024) è passato, le aziende devono ora conformarsi pienamente agli obblighi NIS2. Per gli hosting provider, la situazione è ancora più critica perché la NIS2 classifica i provider di cloud e hosting come entità essenziali, la categoria a più alto rischio.
Perché NIS2 Supply Chain Security è Diverso Dai Vecchi Audit di Sicurezza
Nei miei anni come IT Specialist, ho sempre gestito vendor security attraverso questionari annuali e sporadiche verifiche. Con NIS2, questo approccio è diventato legalmente insufficiente. La NIS2 rende la supply chain security una misura baseline obbligatoria, non opzionale.
All’inizio non capivo bene la portata: pensavo riguardasse solo i grandi fornitori cloud. In realtà, la NIS2 include requisiti di supply chain security, il che significa che i fornitori di terze parti devono anche soddisfare standard di sicurezza appropriati, e la gestione del rischio dei vendor non è più opzionale.
Article 28: KYC e Verifica Identitativa per Domain Registrar e DNS Provider
Se il vostro hosting provider offre servizi di registrazione dominio o DNS, dovete prestare particolare attenzione all’Article 28. L’Article 28 affronta la responsabilità dei domain name registrar e DNS provider, e introduce il principio “Know Your Customer” (KYC) nel processo di registrazione dei nomi di dominio, richiedendo ai registrar di raccogliere, verificare e in alcuni casi divulgare informazioni accurate e complete sui clienti.
Nel mio ambiente di produzione, ho implementato una procedura formale di verifica contatti che copre:
- Raccolta dati accurati: I registri TLD e i provider di servizi di registrazione dominio devono raccogliere e mantenere dati accurati e completi di registrazione dei nomi di dominio, con la dovuta diligenza, secondo le leggi di protezione dei dati dell’UE
- Informazioni essenziali da acquisire: nome di dominio, data di registrazione, nome del registrante, email di contatto, numero di telefono, contatti amministrativi
- Procedure di verifica obbligatorie: I registri e i provider di servizi devono disporre di politiche e procedure di verifica chiare e regolarmente aggiornate per mantenere l’accuratezza dei dati, e devono essere pubblicamente disponibili
Come Ho Implementato KYC Verification in Plesk
Nel mio hosting environment basato su Plesk, ho configurato un workflow di verifica kontatti integrato con le nostre API di registrazione dominio. La verifica avviene tramite:
- Email verification: link di conferma inviato all’indirizzo di contatto registrato
- Phone verification: SMS o chiamata vocale per il numero di telefono
- Identity verification: per utenti aziendali, caricamento documentazione aziendale (partita IVA, certificato camerale)
Ho aggiunto nella configurazione Plesk una custom rule che blocca l’attivazione del dominio fino al completamento di tutte le verifiche. I dati vengono archiviati in un database separato con log di audit immutabile, per dimostrare la conformità in caso di ispezione normativa.
Supply Chain Risk Assessment: La Metodologia che Funziona
La NIS2 richiede che le misure di gestione dei rischi di sicurezza cibernetica includano la sicurezza della supply chain e le aspetti di sicurezza relativi ai rapporti con i fornitori diretti, tenendo conto delle vulnerabilità specifiche di ciascun fornitore, nonché della qualità complessiva dei prodotti e delle pratiche di sicurezza informatica di ciascun fornitore.
Ho sviluppato una procedura strutturata a tre livelli:
Fase 1: Mapping della Supply Chain
Per prima cosa, ho creato un inventario completo di tutti i fornitori diretti che hanno accesso ai nostri sistemi informatici critici. Le aziende devono mappare fornitori e sub-fornitori con accesso a dati o sistemi critici, includendo clausole contrattuali stringenti e controlli tecnici mirati, con l’obiettivo di proteggere l’intera supply chain dalla selezione dei partner alla gestione degli incidenti con terze parti.
Nel foglio di calcolo che uso (ho optato per simplicità su un file strutturato in Plesk DataBase piuttosto che uno strumento enterprise), includo:
- Nome fornitore e categoria (cloud, software, hardware, servizi professionali)
- Tipo di accesso ai sistemi (rete, database, filesystem, amministrativo)
- Criticità del servizio (critica, importante, supporto)
- Data ultima valutazione di sicurezza
- Status certificazione (ISO 27001, SOC 2, NIS2-ready)
Fase 2: Risk Assessment Proporzionato
L’Article 21 della NIS2 richiede analisi dei rischi, gestione degli incidenti, misure di continuità aziendale, sicurezza della supply chain, politiche di controllo d’accesso, MFA, crittografia e gestione delle vulnerabilità, con obblighi documentati di sicurezza di terze parti e monitoraggio continuo.
Ho stratificato i fornitori per criticità:
- Tier 1 (Critica): Fornitori di infrastruttura cloud, servizi DNS, registratori di dominio, provider di backup. Richiedono valutazione annuale approfondita, questionario NIS2-compliant, certificazione ISO 27001 o equivalente, SLA di incident notification (massimo 4 ore).
- Tier 2 (Importante): Provider di software di monitoraggio, strumenti di sicurezza, consulenti. Valutazione biennale, questionario standard, SLA incident 24 ore.
- Tier 3 (Supporto): Fornitori di materiali, vendor secondari. Valutazione ogni 3 anni, verifica di base.
Fase 3: Clausole Contrattuali Obbligatorie
Ho aggiornato i miei template contrattuali con i requisiti NIS2 specifici. I contratti devono includere questionnari di sicurezza e audit durante l’approvvigionamento e annualmente dopo, clausole su misure di sicurezza, notifica di incidenti entro ore, gestione delle vulnerabilità, approvazione del subcontracting e diritti di audit, certificato ISO 27001, riassunti di test di penetrazione, SBOM, timeline di patch e aspettative di sviluppo sicuro.
Elemento critico che ho aggiunto: clausola di incident notification. Il fornitore deve comunicarmi qualsiasi incidente di sicurezza entro 4 ore da quando lo scopre, perché io devo poi rispettare i tempi di escalation NIS2 (24 ore early warning, 72 ore full notification).
Verifica Identitativa: Oltre i Domain Registrar
L’Article 28 si concentra su domain registrar e DNS provider, ma la verifica identitativa è richiesta anche per gli accessi amministrativi interni e agli account di servizio sensibili. Ho implementato:
- Multi-factor authentication (MFA) obbligatoria per tutti gli accessi Plesk admin e API
- Identity verification per nuovi account admin: documento d’identità, verifica lato server
- Continuous monitoring: log di ogni accesso amministrativo con alert anomalie (IP insoliti, timing anomali)
- Annual re-verification: riconferma annuale dell’identità per staff con accesso critico
Deadline e Tappe Intermedie: Cosa Scade a Febbraio 2027
Nella mia timeline di implementazione, febbraio 2027 rappresenta il completamento di tutti gli obblighi di conformità. Tuttavia, ci sono deadline intermedie cruciali:
- Dicembre 2026 (ora imminente): Completamento documentazione supply chain, contratti aggiornati, assessment base di tutti i fornitori Tier 1
- Gennaio 2027: Completamento configurazione KYC per tutti i servizi di registrazione dominio/DNS, log di verifica disponibili
- Febbraio 2027: Conformità totale dimostrata tramite audit interno, evidenza di monitoraggio continuo, incident response plan testato
Strumenti che Uso per Gestire Questo Compliance
Nel mio environment:
- Inventory Management: Spreadsheet con macro custom + Plesk API per sincronizzazione automatica dei vendor con accesso admin
- Risk Assessment: Matrice NIST + spreadsheet di scoring personalizzato (likelihood x impact)
- Contract Management: Template Word con checkboxes dei requisiti NIS2, versioned in git
- Monitoring Continuo: Script bash che ejecuta API calls ai vendor ogni settimana per verificare stato certificazioni, aggregando i dati in Plesk database
- Audit Trail: Tous les changements de configuration sono loggati automaticamente in Plesk audit log + backup mensile
Non ho usato piattaforme enterprise di TPRM (Third-Party Risk Management) costose perché, per hosting provider di medie dimensioni, una struttura leggera ben documentata è più sostenibile e altrettanto conforme.
FAQ
Se sono un hosting provider sotto i 50 dipendenti, devo comunque rispettare Article 28?
Sì, se offrite servizi di registrazione dominio o DNS provider, siete in scope indipendentemente dalla dimensione. Alcune tipologie di entità sono in scope in qualsiasi dimensione, inclusi provider di servizi DNS, registri di dominio di primo livello, provider di servizi fiduciari qualificati e organizzazioni che sono il solo fornitore di un servizio critico per la società. Inoltre, se fornite servizi di hosting a clienti NIS2-regulated (banche, ospedali, energia), dovete soddisfare i loro requisiti di conformità tramite contract, indipendentemente dai vostri dipendenti.
Quant’è rigorosa la verifica KYC per domain registrants?
Dipende dal vostro registro TLD e dalle normative nazionali di transposizione NIS2. Nel caso standard europeo, la verifica è richiesta per tutti i dettagli di contatto (indirizzo email e numero di telefono) dell’account holder e del proprietario del dominio, con verifica del numero di telefono tramite SMS o chiamata vocale, e verifica dell’email tramite link di conferma. Alcuni registri possono richiedere documentazione aggiuntiva (ID, certificato aziendale) a seconda del profilo di rischio del registrant.
Cosa succede se scopro che un fornitore Tier 1 non è conforme NIS2?
First, non panico: avete opzioni. Dovete creare una politica di sicurezza della supply chain che stabilisca requisiti di sicurezza minimi per i fornitori, comunicated direttamente ai fornitori e integrate nelle politiche di procurement, con focus sulle loro pratiche di sicurezza informatica, capacità di soddisfare le vostre esigenze di sicurezza e qualità e resilienza dei prodotti e servizi ICT, e la politica deve essere regolarmente aggiornata e rivista. Potete negoziare un piano di conformità con timeline, aumentare il monitoring durante la transizione, o pianificare una migrazione verso alternative conformi. Documentate tutto.
Article 28 riguarda solo domain registrar o anche hosting provider puri?
Article 28 si concentra specificamente su domain registrar e DNS provider e sulla verifica identitativa dei registranti. Tuttavia, la NIS2 include requisiti di supply chain security che significano che i vostri fornitori di terze parti devono anche soddisfare standard di sicurezza appropriati, inclusa la sicurezza della supply chain e gli aspetti di sicurezza legati alle relazioni con i fornitori diretti. Per un hosting provider “puro”, Article 28 KYC non è direttamente applicabile, ma tutta la filosofia supply chain security lo è.
Come faccio a dimostrare la conformità a febbraio 2027 durante un audit?
Il regolatore (nel caso italiano, l’ACN – Agenzia per la Cybersicurezza Nazionale) vuole evidenza documentale. Dovete mantenere questionnari di sicurezza e audit durante l’approvvigionamento e annualmente dopo, clausole contrattuali su misure di sicurezza e notifica di incidenti entro ore, e prove quali certificato ISO 27001, riassunti di test di penetrazione, SBOM e timeline di patch. Io mantengo una cartella strutturata per ogni vendor (Tier 1) con: contratto firmato, ultima valutazione di sicurezza, certificazioni, SLA documented, log di incidenti (se applicabile). Tutto versionato e datato.
Collegamento con il Vostro Ecosistema di Hosting Più Ampio
Se operate infrastrutture complesse, potete applicare i principi NIS2 supply chain anche ad altri aspetti. Avete già letto il nostro articolo su Come Implementare Confidential Computing Architectures per Hosting Provider 2026? Molti clienti NIS2-regulated richiedono anche enclave criptografiche (Intel SGX, AMD SEV) come requisito di sicurezza aggiuntivo. Abbinare confidential computing a supply chain security NIS2-compliant è un vantaggio competitivo solido.
Similmente, la nostra checklist NIS2 per PMI italiane copre le misure di base, ma questo articolo vi dà la visione specializzata per hosting provider con obblighi Article 28 più stringenti.
Conclusione: La Supply Chain Security Non È Più Opzionale
La deadline di febbraio 2027 non è teorica: è vincolante. I provider di hosting sono classificati come entità essenziali, soggetti agli obblighi più stringenti: incident reporting in 24 ore, responsabilità a livello di board, requisiti di sicurezza della supply chain e multa fino a €10M o 2% del fatturato globale.
Ho implementato questi obblighi attraverso tre pilastri: (1) supply chain mapping e risk tiering, (2) contratti aggiornati con clausole NIS2-specific, (3) KYC verification formale per domain registration e accesso amministrativo. È richiesta anche una mentalità di monitoraggio continuo, non verifiche annuali spot.
Il punto chiave che ho imparato dalla mia esperienza: la compliance NIS2 non è delegabile a un consultant esterno. Dovete comprenderla operativamente, integrarla nei vostri workflow quotidiani di Plesk e infrastruttura, e documenti ogni decisione. Febbraio 2027 arriva velocemente.
Avete iniziato il vostro assessment supply chain NIS2? Che sfide avete incontrato nella verifica KYC? Condividete le vostre esperienze nei commenti. Posso aggiornarvi con implementazioni supplementari basate su ciò che funziona davvero in produzione.