# CRA e ISO 9001: cosa agganci al sistema qualità e cosa costruisci > La mappa CRA↔ISO 9001: quali meccanismi del sistema qualità estendi al Cyber Resilience Act quasi senza attrito, quali tre processi devi costruire da zero, e dove la 9001 aiuta più di quanto sembri. Con i riferimenti agli articoli del CRA e alle clausole della ISO 9001. - URL: https://albertoscarpa.com/guide/it/cra-iso-9001-mappatura/ - Lingua / Language: Italiano - Pubblicato: 2026-07-29 - Aggiornato: 2026-08-12 - Tag: CRA --- La maggior parte dei produttori industriali ha già un sistema di gestione della qualità certificato ISO 9001. È un vantaggio reale sul CRA, hai già l'ossatura organizzativa che il regolamento presuppone, ma solo se sai quali meccanismi puoi riusare e quali devi costruire da zero. Questa è la mappa: cosa aggancio al sistema qualità esistente, cosa devo costruire nuovo, e dove la 9001 aiuta più di quanto sembri. 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](/guide/it/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](/guide/it/scadenze-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 dell'autore** (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ù. Un avvertimento chiude il cerchio: agganciare la 9001 al CRA per la struttura è giusto, ma riusarla *male* — dando per scontato che la forma valga la sostanza — è l'errore che si ripete più spesso. Il punto, e perché le 24 ore dell'art. 14 non ammettono il ritmo della qualità tradizionale, l'ho isolato in [«Siamo già ISO 9001»: perché non basta per il CRA](/blog/it/cra-iso-9001/). --- *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 dell'autore sono mie interpretazioni, non testo normativo.*