Il sollievo di un numero
Il 13 luglio 2026 ENISA ha pubblicato lo SME Cyber Resilience Maturity Assessment Model. Il nome è quello che è, ma lo strumento merita attenzione. È pensato per le micro, piccole e medie imprese che fabbricano o immettono sul mercato prodotti con elementi digitali, e può essere usato anche da integratori e service provider. Copre cinque domini: governance e documentazione, risk management e security by design e by default, gestione delle vulnerabilità e delle patch, ciclo di vita del prodotto, consapevolezza e competenze. Ogni criterio viene valutato su cinque livelli, da pratiche inesistenti o informali a processi governati e migliorati continuamente. Il risultato confluisce in tre profili: Basic, Intermediate, Advanced.
C’è anche un foglio Excel ufficiale. Guida la compilazione, calcola il punteggio e permette di ripetere l’autovalutazione nel tempo. Per una software house di quindici persone che ha passato gli ultimi due anni a sentire il CRA raccontato come una nube minacciosa di articoli, allegati, standard ancora in formazione e date che cambiano, è difficile immaginare qualcosa di più rassicurante. Finalmente un oggetto finito. Lo apri, rispondi, scopri dove sei. Torni dopo sei mesi e misuri quanto ti sei mosso.
Il sollievo è legittimo. Lo strumento è gratuito, leggibile e molto più vicino alla vita di una PMI di tanti framework costruiti per organizzazioni con un CISO, un ufficio legale interno e persone che possono dedicare il venerdì pomeriggio alla governance. ENISA non tratta la mancanza di risorse come una colpa morale. Prova a trasformare un regolamento complesso in un percorso che un’azienda piccola possa affrontare senza fingere di essere una banca.
E lo fa con più rigore di quanto suggerisca la parola autovalutazione. Il documento dice che il punteggio deve basarsi su evidenze oggettive — procedure documentate, pratiche implementate, comportamenti osservabili — e non su impressioni o assunzioni informali. Non chiede semplicemente «secondo voi siete bravi?». Chiede di guardare ciò che esiste. Chi liquida il modello come un questionario burocratico non lo ha letto.
Proprio perché è costruito bene, però, il numero che restituisce sarà facilissimo da usare male.
La frase che ENISA ha scritto in anticipo
ENISA mette l’avvertenza decisiva nell’executive summary e la ripete negli obiettivi del modello. Anche un livello di maturità Advanced non sostituisce gli obblighi legali e non deve essere considerato prova di conformità. Non è una nota difensiva aggiunta dagli avvocati alla fine del documento. È un confine di progetto: lo strumento misura una cosa e il CRA ne chiede un’altra.
La distinzione sembra intuitiva finché non compare uno score. Le parole Basic, Intermediate e Advanced descrivono un’organizzazione; appena finiscono in una cella colorata assumono l’aria di un giudizio. Advanced non suona come «abbiamo pratiche abbastanza strutturate». Suona come «abbiamo superato». E se sopra il foglio c’è il logo dell’Agenzia dell’Unione europea per la cibersicurezza, la trasformazione semantica è quasi inevitabile. Un indicatore interno diventa una credenziale esterna senza che nessuno abbia formalmente deciso che lo sia.
Ma ENISA non sta sminuendo il proprio lavoro. Sta dicendo qualcosa di più interessante: la maturità è una condizione favorevole alla conformità, non la conformità stessa. Un’organizzazione capace di assegnare responsabilità, governare le vulnerabilità, produrre documentazione e rivedere i processi parte molto meglio di una che vive nella memoria di due persone. Eppure può avere un prodotto non conforme. Allo stesso modo, un’organizzazione ancora poco matura può riuscire a dimostrare la conformità di un prodotto semplice e ben circoscritto, magari al prezzo di uno sforzo manuale che non saprà ripetere sul prodotto successivo.
Il maturity score risponde alla domanda «quanto è affidabile il modo in cui lavoriamo?». La valutazione di conformità risponde alla domanda «questo prodotto, in questa configurazione, soddisfa questi requisiti applicabili?». Sono domande vicine. Non sono intercambiabili.
Due autovalutazioni, due oggetti
Qui serve una correzione, perché il modo più rapido di spiegare la differenza è anche quello giuridicamente sbagliato. Si potrebbe dire che il modello ENISA è un’autovalutazione, mentre la conformità è qualcosa che certifica un soggetto esterno. Il racconto funzionerebbe bene. Il CRA, però, non dice questo.
La Commissione europea riassume le procedure in modo netto. Per la categoria predefinita, che comprende gran parte dei prodotti con elementi digitali, il produttore può ricorrere al controllo interno. È il modulo A dell’allegato VIII: il produttore prepara la documentazione tecnica, assicura che progettazione, sviluppo, produzione e gestione delle vulnerabilità rispettino i requisiti essenziali, redige la dichiarazione UE di conformità e se ne assume la responsabilità. Per alcune classi di prodotti importanti l’uso del controllo interno dipende dall’applicazione di standard armonizzati, specifiche comuni o schemi di certificazione; per prodotti importanti di classe II e prodotti critici entrano in gioco procedure di terza parte o schemi europei applicabili. Il dettaglio varia con la categoria. Il principio no: l’articolo 32 del CRA non identifica la conformità con la presenza di un auditor.
Quindi sì, in molti casi entrambe le operazioni sono autovalutazioni. Può perfino essere la stessa persona a coordinarle. Ma l’oggetto della dichiarazione cambia tutto.
Nel modello di maturità l’oggetto è l’organizzazione e la consistenza delle sue pratiche. I criteri attraversano prodotti, team e processi. Il modello stesso avverte che, prima di compilarlo, bisogna identificare quali prodotti rientrano nel CRA, classificarli e determinare la procedura di valutazione applicabile; poi precisa che lo score non distingue tra le diverse categorie di prodotto. Non è un difetto. È il prezzo della sua funzione trasversale.
Nella valutazione di conformità l’oggetto è invece un prodotto identificato. Non «gestiamo bene le vulnerabilità», ma «questa versione del prodotto, con queste componenti, durante questo support period, soddisfa i requisiti applicabili e possiamo mostrare perché». La dichiarazione UE non è un voto. È un atto con cui il fabbricante collega il proprio nome a quella proposizione e si assume la responsabilità che sia vera.
La differenza non è chi compila il foglio. È cosa sta affermando, su quale oggetto e con quali conseguenze.
Quello che il numero perde
Ogni score è una macchina di compressione. Prende una realtà complessa, elimina quasi tutto e conserva un valore confrontabile. È esattamente ciò che lo rende utile: nessun amministratore delegato vuole ricevere ogni trimestre quattrocento pagine di log per capire se l’azienda sta migliorando. Ma l’informazione eliminata durante la compressione è precisamente quella che serve quando bisogna dimostrare la conformità.
Prendiamo la gestione delle vulnerabilità. Un’organizzazione può avere ruoli definiti, un processo documentato, fonti esterne monitorate, SLA di patching e revisioni periodiche. Nel modello ENISA questo giustifica un livello alto, se le evidenze lo confermano. Niente garantisce però che il processo abbia funzionato su ogni prodotto. Una segnalazione può essere rimasta nel backlog sbagliato. La SBOM di una release può non essere stata generata. Una dipendenza può essere presente nel pacchetto distribuito e assente nell’inventario. Una vulnerabilità può essere stata classificata come non sfruttabile senza che nessuno abbia conservato il ragionamento.
Il livello di maturità continua a descrivere qualcosa di vero sull’organizzazione. Ma per dichiarare conforme quel prodotto serve la catena che lo score non contiene: versione esaminata, valutazione dei rischi, distinta delle componenti, segnalazioni ricevute, tempi reali di presa in carico e correzione, test, decisioni motivate, periodo di supporto, responsabilità e date. Serve anche poter ricostruire come la catena è cambiata tra una release e la successiva.
Questo è il punto più facile da perdere: ENISA chiede evidenze oggettive per assegnare il punteggio, e fa bene. Ma l’esistenza di evidenze non rende il punteggio una loro procura generale. Bisogna ancora verificare che siano pertinenti al prodotto, complete rispetto ai requisiti che gli si applicano, aggiornate alla versione immessa sul mercato e mantenute per il periodo richiesto. Il numero dice che una casa ha un buon metodo per tenere l’archivio. Non dice che dentro l’archivio ci sia il fascicolo che stiamo cercando.
Il mercato adora i surrogati
Nei prossimi mesi quello score finirà nelle gare, nelle qualifiche fornitore e nelle brochure commerciali. Non serve immaginare una frode. Basta seguire gli incentivi.
Il reparto commerciale vuole una frase che chiuda la domanda sulla preparazione al CRA. «Profilo Advanced nel modello ENISA» occupa una riga, porta un nome autorevole e non costringe nessuno a spiegare la differenza tra un prodotto della categoria predefinita e uno importante di classe II. Il buyer vuole ridurre cento fornitori a una tabella confrontabile. Chiedere lo score costa poco; aprire fascicoli tecnici, verificare campioni di evidenze e discutere il perimetro costa molto. Il consulente vuole una prestazione replicabile. La compilazione assistita di un Excel ha un inizio, una fine e un deliverable che si fotografa bene nella slide conclusiva.
Nessuno dei tre deve mentire perché il surrogato si affermi. È sufficiente che ciascuno preferisca il numero alla domanda successiva.
È la forma classica della legge di Goodhart: quando una misura diventa un obiettivo, smette di essere una buona misura. Se Advanced diventa un requisito informale di procurement, le organizzazioni inizieranno a ottimizzare il modo in cui rispondono. Non necessariamente falsificando. Sceglieranno il perimetro più favorevole, interpreteranno «applicato con coerenza» nel modo più generoso, prepareranno le evidenze che fanno salire il livello e rinvieranno quelle che chiudono davvero il rischio sul prodotto. Il modello nato per far emergere le lacune verrà usato per rendere presentabile la loro media.
L’autorevolezza di ENISA aumenta il pericolo, non perché ENISA abbia sbagliato, ma perché il suo nome sopravvive alla nota che definisce i limiti dello strumento. Sul documento resterà il logo. Nel passaggio dalla pagina alla brochure sparirà la frase «non è prova di conformità».
Dallo score al fascicolo
Il modo corretto di usare il modello è trattare ogni risposta come l’inizio del lavoro, non come la sua conclusione. Se il criterio dice che le vulnerabilità vengono tracciate e prioritizzate, la domanda successiva non è «quanti punti vale?». È: su quali prodotti, dentro quale sistema, con quale identificativo, rispetto a quale requisito, alimentato da quale evento, verificato da chi e aggiornato quando?
Da lì nasce una catena. Criterio, prodotto, requisito, evidenza, owner, data, storia delle modifiche. Se uno di questi collegamenti manca, lo score può ancora essere utile per la roadmap interna, ma non può essere promosso a scorciatoia probatoria. Se i collegamenti esistono e vengono alimentati dal lavoro normale — la SBOM dalla build, il registro delle vulnerabilità dal ticketing, le decisioni dal processo di rilascio — allora il punteggio diventa quasi secondario. L’organizzazione non ha soltanto dichiarato di essere matura: ha costruito il modo per dimostrarlo prodotto per prodotto.
È il passaggio dal registro compilato all’inventario vivo, e non lo risolve un documento più elegante. Lo risolve la compliance come architettura: evidenze generate dai sistemi reali, collegate alle decisioni, conservate abbastanza a lungo da sopravvivere alle persone che le hanno prese.
Qui si misura anche il valore della consulenza. Compilare il modello al posto del cliente significa produrre una versione più ordinata della percezione del cliente. Verificare un campione di risposte, aprire i repository, seguire una vulnerabilità dalla segnalazione alla patch, confrontare la SBOM con l’artefatto distribuito e costruire i collegamenti mancanti significa trasformare una diagnosi in capacità probatoria. Sono due mestieri diversi. Il primo consegna uno score. Il secondo lascia un’infrastruttura che continuerà a generare evidenze quando il consulente non sarà più nella stanza.
Lo specchio e la finestra
Lo strumento ENISA non è la risposta al Cyber Resilience Act. È la domanda fatta bene. Chiede a una PMI di guardare cinque parti del proprio lavoro che troppo spesso restano separate e le offre un linguaggio comune per decidere da dove cominciare. Se viene usato così, il profilo conta meno del divario che rende visibile. Basic, Intermediate e Advanced sono coordinate su una mappa, non timbri su un passaporto.
Il CRA chiede un passo diverso. Chiede che, prima di immettere un prodotto sul mercato, il fabbricante possa chiudere il ragionamento su quell’oggetto e firmarlo. A volte lo farà da solo, con il modulo A. A volte dovrà coinvolgere un organismo notificato o usare un’altra procedura ammessa. In entrambi i casi, la qualità della risposta dipenderà dalle evidenze che il modello di maturità ha aiutato a cercare, non dal livello scritto nella cella finale.
ENISA ha costruito uno specchio. Uno specchio serve a vedere dove siamo, e questo è già molto. Chi lo userà per guardarsi ricaverà una roadmap onesta, priorità e costi reali. Chi lo appenderà davanti agli altri come se fosse una finestra scoprirà che dall’altra parte non si vede nessun prodotto, nessun requisito e nessuna evidenza. Si vede soltanto la propria convinzione di essere pronto.
Cosa ti porti a casa
Il modello ENISA è un ottimo strumento diagnostico: valuta cinque domini, chiede che le risposte siano fondate su evidenze oggettive e rende visibili le aree in cui una PMI deve investire prima.
Il profilo Advanced non è una prova di conformità, come ENISA dichiara esplicitamente. Descrive la maturità delle pratiche dell’organizzazione, non la conformità di una versione identificata di uno specifico prodotto.
La distinzione non è tra autovalutazione e verifica esterna. Il CRA consente il controllo interno del modulo A per molti prodotti, ma quella procedura richiede documentazione tecnica, responsabilità sul prodotto e una dichiarazione UE di conformità.
Uno score perde il collegamento tra criterio, prodotto, requisito ed evidenza. È proprio questa compressione a renderlo utile per orientarsi e pericoloso quando viene allegato a una gara o a una brochure come surrogato di un certificato.
Il passaggio dallo score al fascicolo è una catena verificabile: per ogni risposta servono prodotto, requisito CRA, evidenza, owner, data e storia delle modifiche. Il consulente crea valore costruendo quella catena, non compilando l’Excel al posto del cliente.
Domande e risposte
Che cosa misura il modello di maturità ENISA per il CRA?
Misura quanto sono strutturate, applicate e migliorate nel tempo le pratiche di sicurezza di un’organizzazione in cinque domini: governance e documentazione, risk management e security by design, gestione delle vulnerabilità e delle patch, ciclo di vita del prodotto, competenze. È una diagnosi organizzativa pensata per aiutare soprattutto le PMI a capire dove si trovano e cosa affrontare prima.
Un livello Advanced ENISA dimostra la conformità al Cyber Resilience Act?
No. ENISA lo esclude espressamente: anche il profilo Advanced non sostituisce gli obblighi legali e non deve essere considerato prova di conformità. Il punteggio descrive la maturità delle pratiche; la conformità va dimostrata per uno specifico prodotto, rispetto ai requisiti e alla procedura che gli si applicano.
La conformità al CRA richiede sempre un organismo notificato?
No. Per i prodotti della categoria predefinita il produttore può usare il controllo interno del modulo A e dichiarare sotto la propria responsabilità che il prodotto soddisfa i requisiti essenziali. Per alcune categorie di prodotti importanti o critici il CRA richiede invece procedure più rigorose, che possono coinvolgere standard armonizzati, certificazione o un organismo notificato.
Quali evidenze servono oltre al maturity score?
Servono evidenze legate al prodotto e alla sua versione: valutazione dei rischi, documentazione tecnica, SBOM generata dalla build, registro delle vulnerabilità, tempi reali di presa in carico e correzione, decisioni motivate, test, support period e storia delle modifiche. Il foglio ENISA può indicare dove cercarle, ma il numero finale non le sostituisce.
Come dovrebbe usare una PMI lo strumento ENISA?
Come una roadmap, non come uno scudo. Ogni risposta dovrebbe essere collegata ai prodotti interessati, ai requisiti CRA applicabili, alle evidenze disponibili e a un owner responsabile di mantenerle vive. Il valore dello score sta nel divario che rende visibile e nel lavoro che permette di prioritizzare.
L'autore
