Hai già la ISO 9001? I pezzi del CRA che puoi agganciare al sistema qualità (e quelli che no)
29 luglio 2026·7 min di lettura·Alberto Scarpa
Messo davanti a un CRA che richiede processi documentati, gestione delle non conformità e audit interni, un produttore certificato reagisce quasi sempre allo stesso modo: “queste cose le abbiamo già, siamo ISO 9001”. È vero a metà. Il sistema di gestione della qualità è un vantaggio concreto, hai già l’ossatura organizzativa che al CRA serve. Ma è anche la fonte dell’illusione più costosa: pensare che “conforme ISO 9001” significhi “quasi conforme CRA”. Non lo significa. La differenza sta in tre processi che la 9001 non prevede, e che se non li vedi ti trovi scoperto proprio dove il CRA morde.
Questa è la mappa: cosa aggancio al sistema qualità esistente, cosa devo costruire nuovo, e dove il riuso è pericoloso. Fra parentesi i riferimenti: articoli e allegati del Regolamento (UE) 2024/2847 (CRA) per gli obblighi, clausole della ISO 9001:2015 per il sistema qualità. Dove interpreto o consiglio, lo segnalo. Do per noto il quadro generale del CRA; se serve, il punto di partenza è Il CRA in un’ora.
Cosa aggancia davvero
Il CRA non chiede di reinventare il modo in cui governi l’azienda. Chiede di applicarlo alla sicurezza del prodotto. Se hai un sistema qualità maturo, diversi suoi meccanismi si estendono al CRA quasi senza attrito.
Il controllo delle informazioni documentate (ISO 9001, punto 7.5) è il caso più diretto. La 9001 impone già di gestire versioni, approvazioni e archiviazione controllata. La documentazione tecnica che il CRA richiede (art. 31 e Allegato VII), inclusa la valutazione dei rischi di cibersicurezza, vive sullo stesso impianto. Non serve un secondo sistema: serve estenderlo ai nuovi contenuti.
La gestione delle non conformità e delle azioni correttive (ISO 9001, punto 10.2) è la struttura mentale giusta per gestire una vulnerabilità. Rilevo un problema, ne valuto l’impatto, decido un’azione, verifico che abbia funzionato, tengo traccia. Il ciclo è lo stesso richiesto dal CRA per affrontare e correggere le vulnerabilità (Allegato I, parte II, punti 2 e 8). Cambia l’oggetto, un difetto di sicurezza invece di un difetto di produzione, e cambiano i tempi, ma il meccanismo organizzativo esiste già.
Gli audit interni (ISO 9001, punto 9.2) e il riesame della direzione (punto 9.3) diventano i luoghi dove la sicurezza del prodotto entra nel governo aziendale, invece di restare un tema tecnico confinato in R&D. Se la direzione già riesamina la qualità ogni trimestre, aggiungere lo stato della conformità CRA a quel tavolo costa poco e vale molto.
La gestione dei fornitori (ISO 9001, punto 8.4) è il gancio per la parte più trascurata del CRA: i componenti di terze parti. Il CRA impone la dovuta diligenza sui componenti integrati, compresi quelli open source, perché non compromettano la sicurezza del prodotto (art. 13, par. 5). La 9001 ti fa già qualificare e monitorare i fornitori; il CRA aggiunge una domanda nuova, come è gestito sul piano della sicurezza questo componente software, ma la relazione contrattuale e il processo di qualifica su cui appoggiarla ci sono.
La gestione delle competenze (ISO 9001, punto 7.2), infine, ti dà il registro dove annotare che qualcuno, in azienda, ha la formazione per fare threat modeling o per gestire una notifica. Il CRA presuppone competenze che la 9001 non nomina, ma il posto dove tracciarle esiste.
Cosa devi costruire da zero
Qui finisce il riuso e comincia il lavoro nuovo. Sono tre processi, e non a caso sono gli stessi tre obblighi che nessuna norma di gestione generalista prevede.
Il vulnerability handling non ha equivalente nella 9001. Il CRA lo impone come requisito di gestione delle vulnerabilità (Allegato I, parte II) per tutta la durata del periodo di assistenza (art. 13, par. 8). Non è la gestione di una non conformità di prodotto: è un processo che monitora attivamente le vulnerabilità dei componenti integrati, anche quelle scoperte anni dopo la vendita. La 9001 reagisce a ciò che rilevi tu; il vulnerability handling ti obbliga a cercare fuori, in continuazione.
L’incident reporting verso ENISA è ancora più lontano dal mondo qualità. Una vulnerabilità attivamente sfruttata va notificata entro 24 ore dalla scoperta, con notifica completa entro 72 (art. 14, par. 2), tramite la piattaforma unica di segnalazione (art. 16). Nessun processo ISO 9001 lavora su questi tempi, e nessuno prevede una notifica obbligatoria a un’autorità esterna con un canale definito. Va costruito: chi è autorizzato a notificare, con quale account, con quale procedura interna, e dove resta l’evidenza di cosa hai notificato e quando, perché è la prima cosa che un audit andrà a cercare. Quella scadenza, l’11 settembre 2026, e le altre due sono in fila in Le scadenze del CRA.
La distinta base del software (SBOM) è l’inventario dei componenti software del prodotto, richiesto dal CRA con almeno le dipendenze di primo livello (Allegato I, parte II, punto 1; definizione all’art. 3, punto 39). La 9001 conosce la distinta base meccanica; non conosce quella del software. Generarla e mantenerla aggiornata è un processo tecnico nuovo, che tocca la toolchain di sviluppo, non l’ufficio qualità.
A questi tre si aggiunge il processo di sviluppo sicuro in senso stretto: security by design e valutazione dei rischi di cibersicurezza del prodotto (art. 13, par. 2 e 3; Allegato I, parte I). La 9001 governa come sviluppi (punto 8.3), non ti dice come renderlo sicuro. È il livello dove IEC 62443-4-1, se scegli di adottarlo, si aggancia, coprendo il requisito CRA e dando una certificazione spendibile.
Dove la 9001 aiuta più di quanto sembri
Un punto poco notato, e che gioca a tuo favore. Il CRA prevede, tra le procedure di valutazione della conformità, un modulo basato sulla garanzia della qualità totale (modulo H, Allegato VIII, parte IV), che poggia su un sistema qualità approvato per progettazione, sviluppo, prova e gestione delle vulnerabilità. Chi ha già un sistema qualità maturo parte avvantaggiato proprio sul percorso di conformità dei prodotti importanti, non solo sull’organizzazione interna.
Nota operativa (mia lettura, non testo di legge). Il modulo H non ti regala la conformità: ti chiede di estendere il sistema qualità alla sicurezza e alla gestione delle vulnerabilità, sotto sorveglianza di un organismo notificato. Ma se la 9001 la vivi davvero, e non come un raccoglitore per l’audit, questa è la strada dove il tuo investimento pregresso rende di più.
Dove il riuso diventa pericoloso
Un avvertimento, perché è l’errore che si ripete più spesso. Non è riusare troppo poco il sistema qualità, è riusarlo male, dando per scontato che la forma valga la sostanza. Un processo di gestione non conformità che misura i tempi in settimane non diventa un processo di incident reporting solo perché ci scrivi sopra “cybersecurity”. Le 24 ore dell’art. 14 non ammettono il ritmo della qualità tradizionale. Se agganci l’incident reporting al ciclo delle non conformità senza ridisegnare tempi e responsabilità, hai un processo che sembra conforme sulla carta e che salta al primo caso reale.
La regola pratica è semplice: riusa la 9001 per la struttura (documenti, audit, riesame, fornitori, competenze) e costruisci nuovo per i tre processi che vivono in ore e guardano fuori dall’azienda. Chi confonde i due piani non risparmia lavoro: lo scopre in ritardo, nel momento peggiore.
Se sei ISO 9001 parti avvantaggiato. Ma il vantaggio è l’ossatura, non i muscoli, e i muscoli del CRA vanno costruiti apposta.
Riferimenti: Regolamento (UE) 2024/2847 (CRA), articoli 3, 13, 14, 16, 31, 32 e Allegati I, VII, VIII; ISO 9001:2015, punti 7.2, 7.5, 8.3, 8.4, 9.2, 9.3, 10.2; IEC 62443-4-1. Le note segnalate come operative sono mie interpretazioni, non testo normativo.