Fascicolo di sicurezza del prodotto CRA 2026 con ISO 27001

Un produttore di dispositivi connessi convoca la propria CISO, Maria, a una riunione del venerdì pomeriggio. La funzione commerciale ha appena concluso un accordo di distribuzione europeo. La funzione legale chiede se l’azienda possa sostenere la conformità al Cyber Resilience Act. L’ingegneria afferma che lo sviluppo sicuro è “per lo più coperto”, perché esistono revisioni del codice, SAST e applicazione delle patch. L’approvvigionamento sostiene che i fornitori sono “coperti da accordi di riservatezza”. I team di prodotto gestiscono le dipendenze del firmware in uno strumento, gli inventari delle API cloud in un altro e i ticket sulle vulnerabilità in Jira. La funzione compliance dispone di evidenze di certificazione ISO/IEC 27001:2022, ma sono organizzate attorno al SGSI aziendale, non attorno a ciascun prodotto immesso sul mercato UE.

Poi arriva la domanda scomoda: “Se nel 2026 un’autorità UE, un cliente, un organismo notificato o un grande distributore chiedesse il Fascicolo di sicurezza del prodotto, saremmo in grado di produrlo in una settimana?”

Per molti fornitori software, produttori di dispositivi intelligenti e prestatori di servizi connessi, la risposta onesta è no. Non perché manchino i controlli di sicurezza, ma perché le evidenze di sicurezza del prodotto sono disperse. Le registrazioni dello sviluppo sicuro sono in capo all’ingegneria. Le SBOM sono generate per build, ma non sono sottoposte a governance. La divulgazione coordinata delle vulnerabilità esiste come pagina web, ma non è sempre collegata a triage, correzioni, avvisi e monitoraggio post-commercializzazione. La sicurezza dei fornitori è sepolta nei contratti di approvvigionamento. La segnalazione degli incidenti appartiene alle operazioni di sicurezza, mentre la documentazione di conformità appartiene alla conformità di prodotto.

Il Cyber Resilience Act dell’UE cambia il modello operativo. La cibersicurezza di prodotto non è più soltanto una buona pratica o una promessa contrattuale. Diventa un obbligo di evidenza lungo il ciclo di vita. Le organizzazioni devono poter dimostrare in che modo i requisiti di cibersicurezza sono integrati nella progettazione, nello sviluppo, nel rilascio, nel trattamento delle vulnerabilità, negli aggiornamenti e nel monitoraggio dopo l’immissione del prodotto sul mercato.

È qui che ISO/IEC 27001:2022 diventa potente, se utilizzata correttamente. Non è di per sé uno schema di certificazione di prodotto, ma il suo SGSI e i controlli su rischio, asset, fornitori, sviluppo sicuro, vulnerabilità e incidenti possono fornire la struttura portante di un Fascicolo di sicurezza del prodotto CRA. L’obiettivo non è creare un altro silo di conformità. L’obiettivo è trasformare il SGSI esistente in un sistema di evidenze a livello di prodotto.

Come afferma Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec nella Fase 2, Passaggio 8, Architettura delle evidenze:

“Le evidenze non devono essere raccolte alla fine del ciclo di audit. Devono essere progettate all’interno del controllo, assegnate a un responsabile, marcate temporalmente dal processo e riutilizzabili per ogni obbligo che pone la stessa domanda con un linguaggio diverso.”

Questa frase coglie il nucleo della preparazione al CRA. La domanda non è solo: “Abbiamo uno sviluppo sicuro?” La domanda è: “Possiamo dimostrare sviluppo sicuro, conoscenza dei componenti, trattamento delle vulnerabilità e monitoraggio post-commercializzazione per questo prodotto, questa versione, questo rilascio e questo mercato?”

Il Fascicolo di sicurezza del prodotto CRA è un sistema di evidenze vivo

Un Fascicolo di sicurezza del prodotto CRA non deve essere trattato come un PDF statico prodotto una sola volta prima del rilascio e poi dimenticato. Deve essere un dossier strutturato che racconta la storia di sicurezza del prodotto, dall’ideazione alla fine del supporto.

Un fascicolo utile spiega:

1. Che cos’è il prodotto e come deve essere utilizzato.
2. Quali software, firmware, servizi cloud e dipendenze di terze parti include.
3. Quali rischi di cibersicurezza sono stati valutati.
4. Quali requisiti di sicurezza sono stati applicati.
5. Come è stato eseguito lo sviluppo sicuro.
6. Come le vulnerabilità sono ricevute, sottoposte a triage, corrette e divulgate.
7. Come sono distribuiti gli aggiornamenti sicuri.
8. Come sono controllati fornitori e componenti open source.
9. Come sono gestiti in escalation gli incidenti e le vulnerabilità sfruttate attivamente.
10. Come il prodotto è monitorato dopo l’immissione sul mercato.

Per un CISO, questa è una sfida di evidenze del SGSI. Per un responsabile della conformità di prodotto, è documentazione tecnica. Per l’ingegneria, è DevSecOps e governance dei rilasci. Per i dirigenti, è accesso al mercato e controllo della responsabilità.

L’errore è trattare questi elementi come filoni di lavoro separati. Il modello migliore consiste nel costruire un fascicolo di evidenze a livello di prodotto che mappi i controlli ISO/IEC 27001:2022 e ISO/IEC 27002:2022, quindi mappi nuovamente le stesse evidenze su NIS2, DORA, GDPR, NIST e COBIT 2019, ove pertinente.

Zenith Controls: The Cross-Compliance Guide di Clarysec descrive questo modello come una catena controllo-evidenza-auditor:

“Un fascicolo di evidenze multinorma dovrebbe mappare ciascun obbligo sul controllo operativo, sull’oggetto di evidenza ricorrente, sul responsabile incaricato e sulla prospettiva di audit che sarà utilizzata per verificarlo.”

Questa è la disciplina richiesta dalla preparazione al CRA. Il Fascicolo di sicurezza del prodotto non è semplicemente una cartella. È il livello di traduzione tra ingegneria di prodotto, governance della sicurezza, valutazione della conformità e garanzia verso il cliente.

Costruire prima la struttura portante delle evidenze di prodotto

Il fascicolo richiede una struttura coerente prima che i team inizino a caricare registrazioni. Senza una struttura portante chiara, le evidenze diventano un insieme disordinato di screenshot, esportazioni e PDF di politiche che nessun auditor riesce a seguire.

Per i workshop di preparazione al CRA, Clarysec raccomanda in genere la seguente struttura del Fascicolo di sicurezza del prodotto per le organizzazioni che già operano un SGSI ISO/IEC 27001:2022.

Questa tabella non sostituisce gli obblighi legali di documentazione tecnica. Fornisce all’organizzazione un modello operativo per dimostrarli.

Nel Zenith Blueprint, la Fase 1, Passaggio 3 si concentra sulla definizione del campo di applicazione e dei confini. Per il CRA, quel passaggio diventa specifico per il prodotto. Definire la famiglia di prodotto, le versioni software, le assunzioni di distribuzione, i ruoli utente, i servizi connessi, i canali di aggiornamento e il periodo di supporto. Se il campo di applicazione del SGSI è “SaaS aziendale e piattaforma di gestione dei dispositivi”, il fascicolo CRA deve comunque rispondere a una domanda più ristretta: “Quale prodotto con elementi digitali viene immesso sul mercato UE e che cosa è incluso in quel prodotto?”

Mappare lo sviluppo sicuro su registrazioni a livello di prodotto

Il cuore del Fascicolo di sicurezza del prodotto è l’evidenza della sicurezza fin dalla progettazione. ISO/IEC 27001:2022 fornisce il sistema di governance. ISO/IEC 27002:2022 fornisce linee guida di applicazione tramite controlli quali A.8.25 Ciclo di vita dello sviluppo sicuro, A.8.27 Architettura sicura dei sistemi e principi di ingegneria, A.8.28 Programmazione sicura e A.8.29 Test di sicurezza nello sviluppo e nell’accettazione.

Il passaggio importante è dalle dichiarazioni generiche sullo sviluppo sicuro alle registrazioni specifiche del rilascio. “Eseguiamo revisioni del codice” non basta. Il fascicolo deve mostrare quale rilascio è stato riesaminato, quali rischi sono stati considerati, quali test di sicurezza sono stati superati, quali vulnerabilità sono state accettate o corrette e chi ha approvato il rilascio.

La Politica di sviluppo sicuro Enterprise di Clarysec è progettata per imporre questa traccia di evidenze. Nella clausola 6.1, Requisiti del ciclo di vita dello sviluppo sicuro, stabilisce:

“Ogni rilascio di prodotto o servizio deve mantenere evidenze documentate dei requisiti di sicurezza, del riesame della progettazione, delle attività di programmazione sicura, dei test di sicurezza, delle decisioni di remediation delle vulnerabilità e dell’approvazione del rilascio prima della distribuzione in produzione.”

Questa clausola è utile per il CRA perché trasforma lo sviluppo sicuro in uno schema di evidenze ripetibile. Un auditor non deve dedurre che lo sviluppo sicuro sia avvenuto. Può esaminare la registrazione del rilascio.

Per un termostato intelligente, un dispositivo IoT medicale, un sensore industriale o un prodotto connesso a SaaS, le evidenze di sviluppo sicuro dovrebbero includere:

• Requisiti di sicurezza del prodotto mappati sui rischi identificati.
• Modello di minaccia o analisi dei casi di abuso per il prodotto e i servizi connessi.
• Riesame dell’architettura, inclusi confini di fiducia e interfacce esterne.
• Standard di programmazione sicura e prova della presa d’atto o della formazione degli sviluppatori.
• SAST, DAST, Software Composition Analysis, scansione dei segreti e analisi del firmware, ove applicabile.
• Ticket di remediation per le risultanze ad alto rischio.
• Registrazioni di accettazione del rischio con approvazione aziendale e di sicurezza.
• Checklist del punto di controllo di rilascio che dimostri il soddisfacimento dei criteri di sicurezza.
• Evidenze di firma crittografica e di integrità degli aggiornamenti.
• Assunzioni sul periodo di supporto e sul fine vita.

Altri standard rafforzano il metodo. ISO/IEC 27005 supporta l’approccio al rischio alla base di queste registrazioni. ISO/IEC 27017 è utile quando i servizi cloud fanno parte dell’ecosistema di prodotto. ISO/IEC 27035 supporta la gestione degli incidenti. ISO/IEC 29147 e ISO/IEC 30111 sono particolarmente rilevanti per la divulgazione delle vulnerabilità e il trattamento delle vulnerabilità. ISO/IEC 27036 supporta la sicurezza dei fornitori, che è importante quando il prodotto include software esternalizzato, moduli embedded, servizi cloud gestiti o librerie di terze parti.

In Zenith Controls, le evidenze CRA relative allo sviluppo sicuro sono di norma mappate attorno a temi di controllo ISO/IEC 27002:2022 quali sicurezza delle informazioni nella gestione dei progetti, ciclo di vita dello sviluppo sicuro, programmazione sicura, test di sicurezza, gestione delle modifiche e gestione delle vulnerabilità tecniche. La guida collega inoltre tali elementi all’inventario degli asset e ai controlli sui fornitori, perché nessun processo di sviluppo sicuro è completo se l’organizzazione non è in grado di identificare i componenti che distribuisce.

Trattare la SBOM come evidenza regolamentata di prodotto

La Software Bill of Materials è spesso trattata come un artefatto tecnico. Ai fini della preparazione al CRA, deve essere trattata come evidenza di prodotto.

Una SBOM utile indica quali componenti sono presenti nel prodotto, quali versioni sono utilizzate, da dove provengono, quali licenze si applicano, quali vulnerabilità li interessano e quali rilasci li contengono. Per firmware e prodotti embedded, ciò può includere pacchetti del sistema operativo, bootloader, librerie, driver, container, moduli di terze parti e dipendenze lato cloud necessarie al funzionamento del prodotto.

Il problema è che molte organizzazioni generano SBOM ma non le governano. Una pipeline di build può produrre un file SPDX o CycloneDX, ma nessuno ne valida la completezza. Gli strumenti di sicurezza possono segnalare vulnerabilità, ma i risultati non sono collegati alle versioni di prodotto. L’approvvigionamento può approvare un fornitore, ma l’elenco dei componenti di quel fornitore non è riconciliato con il prodotto rilasciato.

La Politica di gestione degli asset Enterprise di Clarysec affronta questa lacuna di governance nella clausola 5.2, Inventario delle informazioni e degli asset associati:

“Gli asset informativi e i componenti tecnologici associati devono essere identificati, assegnati a un responsabile, classificati ove applicabile e mantenuti in un inventario che supporti la valutazione del rischio, la gestione delle vulnerabilità, il controllo delle modifiche e le evidenze di audit.”

Per il CRA, quella clausola diventa specifica per il prodotto. La SBOM fa parte dell’inventario dei componenti tecnologici associati. Richiede un responsabile, una regola di conservazione, un processo di validazione e un collegamento con la gestione delle vulnerabilità.

Una regola pratica per le evidenze SBOM è semplice: ogni versione di prodotto rilasciata deve avere un inventario dei componenti approvato e riconducibile all’artefatto di rilascio. Se l’organizzazione non può collegare la SBOM all’immagine firmware esatta, al pacchetto applicativo, al digest del container o al rilascio SaaS, la SBOM costituisce un’evidenza debole.

Se più di due righe non superano la verifica, di solito il problema non è lo strumento SBOM. È la governance. Il Fascicolo di sicurezza del prodotto dovrebbe registrare un’azione correttiva nel SGSI, perché la debolezza delle evidenze CRA è anche un problema di efficacia dei controlli ISO/IEC 27001:2022.

Collegare la CVD al trattamento delle vulnerabilità e alla governance dei rilasci

La divulgazione coordinata delle vulnerabilità è una delle aree più visibili della preparazione al CRA, perché ricercatori esterni, clienti e autorità possono verificarla direttamente. Pubblicare una pagina di vulnerability disclosure o un file security.txt è utile, ma rappresenta solo il punto di ingresso. Il Fascicolo di sicurezza del prodotto deve dimostrare che i processi interni funzionano.

Un insieme difendibile di evidenze per CVD e trattamento delle vulnerabilità dovrebbe includere:

• Canale pubblico di divulgazione e istruzioni di invio.
• Processo di conferma di ricezione per i ricercatori.
• Criteri di triage, inclusa valutazione di gravità e sfruttabilità.
• Analisi dell’impatto sul prodotto.
• Titolarità della remediation e tempistiche obiettivo.
• Modelli di avviso ai clienti e comunicazione degli aggiornamenti.
• Evidenze dello sviluppo e dei test sicuri delle patch.
• Registrazioni della pubblicazione coordinata, ove applicabile.
• Lezioni apprese e analisi delle tendenze ricorrenti delle vulnerabilità.

La Politica di gestione delle vulnerabilità Enterprise di Clarysec, clausola 6.3, Presa in carico, triage e remediation delle vulnerabilità, stabilisce:

“Le vulnerabilità segnalate devono essere registrate, valutate rispetto agli asset e ai prodotti interessati, prioritizzate in base al rischio e alla sfruttabilità, assegnate a un responsabile e tracciate fino a remediation, verifica, comunicazione e chiusura.”

Questa clausola collega la CVD a SBOM, inventario degli asset, ticket di ingegneria, gestione dei rilasci e monitoraggio post-commercializzazione. È anche la clausola che gli auditor testeranno naturalmente: mostrare la registrazione di presa in carico, mostrare i prodotti interessati, mostrare il triage, mostrare la correzione, mostrare la comunicazione al cliente, mostrare la chiusura.

La Politica di gestione degli incidenti di sicurezza delle informazioni esistente dovrebbe essere estesa anche alle vulnerabilità di prodotto che diventano incidenti o richiedono una notifica esterna. ISO/IEC 27002:2022 A.5.24 copre la pianificazione e preparazione della gestione degli incidenti, A.5.25 copre la valutazione e decisione sugli eventi di sicurezza delle informazioni, A.5.26 copre la risposta agli incidenti di sicurezza delle informazioni e A.5.27 copre l’apprendimento dagli incidenti.

In Zenith Controls, la gestione delle vulnerabilità è trattata sia come controllo preventivo sia come controllo correttivo. Il lato preventivo include inventario, sviluppo sicuro, monitoraggio dei fornitori e configurazione sicura. Il lato correttivo include rilevazione, triage, applicazione delle patch, comunicazione ed escalation degli incidenti. Questa distinzione è importante perché il trattamento post-commercializzazione delle vulnerabilità fa parte dell’obbligo del ciclo di vita del prodotto, non è un’attività accessoria.

Le evidenze dei fornitori sono la debolezza nascosta

Il Fascicolo di sicurezza del prodotto sarà spesso messo alla prova con maggiore intensità nei punti in cui il produttore dipende da altri. Ciò include moduli embedded, sviluppo firmware esternalizzato, componenti white-label, hosting cloud, SDK mobili, servizi di pagamento, librerie crittografiche e prestatori di servizi gestiti.

Il modello di fallimento più comune è l’astrazione contrattuale. Il produttore afferma: “Il nostro fornitore è responsabile di questo”. Sotto scrutinio di sicurezza del prodotto, non è sufficiente. L’organizzazione deve dimostrare che il rischio dei fornitori è identificato, i requisiti di sicurezza sono comunicati, le evidenze sono raccolte, le vulnerabilità sono coordinate e le modifiche sono controllate.

La Politica di sicurezza delle terze parti e dei fornitori Enterprise di Clarysec, clausola 7.1, Requisiti di sicurezza dei fornitori, stabilisce:

“I fornitori che sviluppano, gestiscono, trattano, supportano o incidono materialmente su sistemi informativi, prodotti o servizi devono essere valutati in base al rischio e soggetti a requisiti di sicurezza relativi ad accesso, gestione delle vulnerabilità, notifica degli incidenti, subappalto, continuità e fornitura di evidenze.”

Per il CRA, l’espressione “incidono materialmente sui prodotti” è critica. Se un componente del fornitore può introdurre una vulnerabilità, interrompere gli aggiornamenti, esporre dati dei clienti o compromettere l’integrità del dispositivo, deve rientrare nel Fascicolo di sicurezza del prodotto.

La stessa politica può supportare anche la contrattualizzazione della SBOM. La clausola 7.3 stabilisce:

“Per tutti i componenti software, le librerie o i sistemi operativi di terze parti da integrare nei ‘Prodotti con elementi digitali’ dell’azienda, il fornitore deve fornire, su richiesta, una Software Bill of Materials (SBOM) leggibile automaticamente in un formato standard come SPDX o CycloneDX. Questo requisito deve essere inserito in tutti i contratti di approvvigionamento e con i fornitori.”

Un pacchetto solido di evidenze sui fornitori dovrebbe includere classificazione dei fornitori in base all’impatto sul prodotto, requisiti di sicurezza nei contratti, evidenze di sviluppo sicuro del fornitore per i componenti critici, impegni del fornitore sulla divulgazione delle vulnerabilità, SBOM o dichiarazioni sui componenti ove possibile, tempistiche di supporto alle patch e di fine vita, registrazioni dei riesami periodici e percorsi di escalation per vulnerabilità originate dal fornitore.

ISO/IEC 27002:2022 A.5.19, A.5.20 e A.5.21 forniscono i principali temi di controllo sui fornitori. ISO/IEC 27036 aggiunge profondità alla sicurezza dei rapporti con i fornitori. In termini di conformità multinorma, NIS2 enfatizza catena di fornitura e trattamento delle vulnerabilità. DORA enfatizza il rischio ICT di terze parti per gli enti finanziari. GDPR diventa rilevante quando il prodotto o i suoi servizi cloud trattano dati personali. COBIT 2019 inquadra la governance dei fornitori come tema di governo della tecnologia aziendale, non solo come tema di operazioni di sicurezza.

Il monitoraggio post-commercializzazione trasforma le evidenze in operatività

Le organizzazioni più mature nella sicurezza di prodotto guardano oltre il rilascio. Si chiedono: “Come sapremo che questo prodotto è diventato rischioso dopo essere stato installato sul campo?”

Il monitoraggio post-commercializzazione dovrebbe acquisire segnali da feed di vulnerabilità, informazioni sugli exploit, assistenza clienti, telemetria, bug bounty o segnalazioni dei ricercatori, notifiche dei fornitori, log cloud, registrazioni degli incidenti e dati sulle prestazioni sul campo. Dovrebbe includere anche un riesame periodico del rischio di prodotto quando cambiano le condizioni di minaccia.

La Politica di registrazione e monitoraggio Enterprise di Clarysec, clausola 5.4, Monitoraggio e riesame della sicurezza, stabilisce:

“Gli eventi rilevanti per la sicurezza devono essere raccolti, riesaminati, gestiti in escalation e conservati in modo da supportare rilevazione tempestiva, indagine, risposta agli incidenti, reportistica di conformità e miglioramento continuo.”

Per i prodotti connessi, questa disposizione deve essere interpretata con attenzione. Il monitoraggio deve rispettare privacy, minimizzazione dei dati e vincoli legali, in particolare quando la telemetria include dati personali o dati operativi del cliente. La mappatura su GDPR è importante. I team di sicurezza di prodotto dovrebbero collaborare con i team privacy per definire quale telemetria è necessaria per la sicurezza, come viene minimizzata, per quanto tempo viene conservata e come i clienti vengono informati.

Le evidenze di monitoraggio post-commercializzazione dovrebbero includere un piano di monitoraggio della sicurezza del prodotto, fonti di intelligence sulle vulnerabilità, canali di presa in carico delle segnalazioni dei clienti, canali di notifica dei fornitori, ambito di riesame di telemetria o log, verbali di riesame periodico del rischio di prodotto, tracciamento dell’adozione delle patch, analisi delle tendenze degli incidenti e input per il riesame della direzione.

Nel Zenith Blueprint, la Fase 5, Passaggio 30 si concentra sul miglioramento continuo e sulla preparazione alla sorveglianza. Per il CRA, è qui che il Fascicolo di sicurezza del prodotto diventa un fascicolo vivo. Ogni rilascio di prodotto, vulnerabilità, modifica del fornitore e segnale dal campo dovrebbe aggiornare la registrazione delle evidenze.

Un solo fascicolo di evidenze, molte domande di conformità

Un Fascicolo di sicurezza del prodotto CRA ben progettato riduce le duplicazioni perché le stesse evidenze rispondono a più domande di conformità. Il linguaggio cambia, ma la realtà dei controlli è spesso simile.

Zenith Controls è progettato per questo riutilizzo. Mappa i temi di controllo ISO/IEC 27002:2022 su attributi quali finalità preventiva, di rilevamento e correttiva del controllo, concetti di cibersicurezza, capacità operative e proprietà di sicurezza. Per il CRA, questo aiuta un CISO a spiegare perché un singolo oggetto di evidenza, come un riesame di sicurezza del rilascio, supporta sviluppo sicuro, trattamento del rischio, controllo delle modifiche, gestione delle vulnerabilità e capacità di dimostrare la conformità in sede di audit.

Prepararsi a prospettive di audit diverse

Un Fascicolo di sicurezza del prodotto CRA può essere contestato da un auditor ISO, da un gruppo di audit interno, da un team di assurance cliente, da un revisore della conformità di prodotto, da un’autorità di regolamentazione, da un valutatore orientato a NIST o da un auditor COBIT formato ISACA. Ciascuno porrà domande simili attraverso una prospettiva diversa.

Lo stesso punto debole sarà esposto in modi diversi. Se le SBOM sono generate ma non conservate, l’auditor ISO vede un problema di controllo delle registrazioni e di controllo operativo. Il valutatore NIST vede una debolezza nella gestione degli asset e delle vulnerabilità. L’auditor COBIT vede una governance debole sugli asset informativi. Il revisore di prodotto vede documentazione tecnica insufficiente.

Una roadmap in 30 passaggi, adattata alla preparazione al CRA

Il Zenith Blueprint impedisce ai team di conformità di passare direttamente alla raccolta documentale. Per il CRA, la roadmap in 30 passaggi diventa un programma di evidenze per la sicurezza di prodotto.

La Fase 1 inizia con la mappatura di obblighi e campo di applicazione. Identificare quali prodotti, versioni, componenti, servizi cloud e processi di supporto rientrano nell’ambito. Confermare uso previsto, categorie di utenti, mercati e periodo di supporto alla sicurezza.

La Fase 2 costruisce l’architettura delle evidenze. Definire l’indice del Fascicolo di sicurezza del prodotto, i responsabili delle evidenze, i requisiti di conservazione, la struttura del repository e il flusso di lavoro di approvazione. Allinearsi ai sistemi di ingegneria invece di imporre caricamenti manuali.

La Fase 3 applica i controlli operativi. Sviluppo sicuro, generazione della SBOM, trattamento delle vulnerabilità, evidenze dei fornitori, punti di controllo di rilascio, aggiornamenti sicuri ed escalation degli incidenti devono funzionare come processi reali.

La Fase 4 verifica la capacità di dimostrare la conformità in sede di audit. Selezionare un rilascio di prodotto ed eseguire un audit simulato. Il team riesce a recuperare la SBOM? Riesce a dimostrare i test di sicurezza? Riesce a mostrare come una vulnerabilità è stata sottoposta a triage? Riesce a collegare le evidenze del fornitore ai componenti di prodotto?

La Fase 5 integra sorveglianza e miglioramento. Monitoraggio post-commercializzazione, analisi delle tendenze delle vulnerabilità, riesami dei fornitori e input per il riesame della direzione mantengono aggiornato il fascicolo.

Questo sprint di solito fa emergere rapidamente la realtà. Le organizzazioni raramente falliscono perché mancano di tutti i controlli. Falliscono perché i controlli non sono collegati a livello di prodotto.

Lacune comuni nella preparazione al CRA prima del 2026

Tra fornitori software, produttori di dispositivi e prestatori di servizi connessi, le lacune ricorrenti sono costanti.

Primo, il campo di applicazione del SGSI è troppo aziendale. Copre l’organizzazione, ma non dettaglia abbastanza il ciclo di vita del prodotto. La soluzione è creare allegati e fascicoli di evidenze a livello di prodotto.

Secondo, le SBOM esistono ma non sono affidabili. Sono generate da strumenti, ma non riesaminate, approvate, conservate o collegate alle decisioni sulle vulnerabilità. La soluzione è la governance della SBOM, non soltanto la produzione della SBOM.

Terzo, la CVD è esposta al pubblico ma non è operativamente matura. Le segnalazioni arrivano, ma criteri di triage, obiettivi di risposta, approvazioni degli avvisi ed evidenze di chiusura sono incoerenti. La soluzione è integrare la CVD con gestione delle vulnerabilità, gestione degli incidenti e gestione dei rilasci.

Quarto, le evidenze sui fornitori sono troppo superficiali. I fornitori critici sono approvati commercialmente, ma non valutati per l’impatto sulla sicurezza del prodotto. La soluzione è la classificazione dei fornitori in base al rischio di prodotto e l’obbligo di evidenze per i componenti critici.

Quinto, il monitoraggio post-commercializzazione è reattivo. I team rispondono alle vulnerabilità urgenti, ma non eseguono riesami periodici del rischio di prodotto. La soluzione è un riesame programmato della sicurezza post-commercializzazione collegato alla reportistica alla direzione.

Sesto, le evidenze di audit sono eccessivamente manuali. I team di conformità inseguono screenshot. La soluzione è progettare le evidenze nei processi, utilizzando sistemi di ingegneria, flussi di lavoro di ticketing e repository come fonti autorevoli.

Costruire il fascicolo delle evidenze prima che sia la scadenza a imporlo

Il Cyber Resilience Act premia le organizzazioni che possono dimostrare la sicurezza di prodotto come disciplina operativa. Crea rischio per le organizzazioni che trattano le evidenze come un esercizio di conformità dell’ultimo minuto.

Iniziare da un prodotto. Costruire un Fascicolo di sicurezza del prodotto. Mapparlo su ISO/IEC 27001:2022 e ISO/IEC 27002:2022. Allegare evidenze di sviluppo sicuro, SBOM, registrazioni CVD, garanzia di sicurezza dei fornitori e monitoraggio post-commercializzazione. Eseguire una simulazione di audit prima che lo faccia un soggetto esterno.

Clarysec può aiutarti ad accelerare questo percorso con Zenith Blueprint, Zenith Controls, la Politica di sviluppo sicuro Enterprise, la Politica di gestione delle vulnerabilità, la Politica di gestione degli asset, la Politica di sicurezza delle terze parti e dei fornitori, la Politica di registrazione e monitoraggio e la Politica di gestione degli incidenti di sicurezza delle informazioni.

La domanda più importante per il CRA 2026 non è: “Abbiamo controlli di sicurezza?”

È: “Possiamo dimostrare la sicurezza di prodotto, rilascio per rilascio, componente per componente, vulnerabilità per vulnerabilità, dopo che il prodotto è già sul mercato?”

Costruisci ora il fascicolo delle evidenze, collegalo al tuo SGSI e rendi ogni futuro rilascio di prodotto pronto per l’audit fin dalla progettazione.