Un RAG Report (Red-Amber-Green Report, rapporto rosso-giallo-verde) è un documento di valutazione strutturato che utilizza un sistema a semaforo a tre colori per comunicare lo stato di conformità di ciascun singolo requisito di una direttiva o di un regolamento UE applicabile rispetto al progetto attuale di un prodotto. È un formato di deliverable ampiamente utilizzato per le analisi delle lacune di conformità hardware — non un formato prescritto dal diritto dell’UE — perché converte complesse valutazioni tecniche multi-direttiva in una sintesi chiara per la direzione aziendale, utilizzabile per dare priorità alle azioni correttive e giustificare il budget ingegneristico.
Le tre classificazioni RAG
| Colore | Significato | Azione richiesta |
|---|---|---|
| 🟢 Verde | Il requisito è pienamente soddisfatto dal progetto attuale. Le evidenze sono documentate (rapporto di prova, design review, dichiarazione dei materiali, ecc.) | Nessuna — documentare le evidenze nella Documentazione tecnica |
| 🟡 Giallo | Il requisito è parzialmente soddisfatto, oppure la conformità è condizionata / non verificata. Il progetto potrebbe essere conforme, ma mancano le evidenze o un’assunzione necessita di validazione. | Indagine richiesta — fornire le evidenze mancanti oppure riprogettare l’elemento segnalato |
| 🔴 Rosso | Il requisito non è soddisfatto dal progetto attuale. Esiste una lacuna concreta che non può essere risolta senza una modifica del progetto, la sostituzione di un componente o una modifica di processo. | Azione correttiva richiesta — la lacuna deve essere colmata prima che il prodotto possa legittimamente recare la marcatura CE |
Struttura di un RAG Report sulla conformità hardware
Per un prodotto hardware connesso soggetto a più direttive, il RAG Report è in genere strutturato come segue:
Rapporto RAG di conformità — [Nome del prodotto] Rev. [X]
Redatto da: [Nome e qualifica dell’ingegnere]
Revisionato da: [Responsabile dell’architettura di sicurezza / della conformità]
Data: [AAAA-MM-GG]
1. AMBITO
- Descrizione del prodotto e uso previsto
- Direttive e regolamenti applicabili oggetto di valutazione
- Metodo di valutazione e norme di riferimento
2. SINTESI PER LA DIREZIONE
- Tabella riepilogativa: totale verde / giallo / rosso per direttiva
- Valutazione complessiva della conformità
- Ordine di priorità degli interventi correttivi
3. RISULTATI DI DETTAGLIO — per direttiva
[Per ciascuna direttiva applicabile, una tabella dei requisiti:]
| Requisito | Articolo / Clausola | Stato RAG | Risultati | Evidenze / Raccomandazione |
|---|---|---|---|---|
| Riservatezza delle chiavi e dei dati conservati | CRA Allegato I, Parte I(2)(e) | 🔴 Rosso | L’MCU (STM32F4) non dispone di Secure Element o TrustZone. Chiave condivisa nella flash. | Sostituire l’MCU con STM32U5 (TrustZone-M) e aggiungere un Secure Element STSAFE-A110 |
| Protezione dall’accesso non autorizzato (autenticazione) | CRA Allegato I, Parte I(2)(d) | 🔴 Rosso | L’indirizzo MAC viene usato come identità ed è clonabile. | Predisporre il provisioning dei certificati STSAFE-A110 durante la produzione |
| Integrità del software e distribuzione sicura degli aggiornamenti | CRA Allegato I, Parte I(2)(f), Parte II(7) | 🟡 Giallo | Esiste un meccanismo OTA, ma la chiave di firma è conservata nel software. | Il progetto richiede la conservazione delle chiavi in hardware, da risolvere con l’aggiunta di STSAFE-A110 |
| Politica di divulgazione coordinata delle vulnerabilità e contatto | CRA Allegato I, Parte II(5)–(6) | 🟢 Verde | security.txt presente sul dominio del prodotto; contatto PSIRT definito | Documentare nel fascicolo tecnico |
4. MATRICE DEI RISCHI DEI COMPONENTI
[Tabella della BOM: componenti conformi, non conformi o da sostituire]
5. PIANO DEGLI INTERVENTI CORRETTIVI
- Elenco delle modifiche necessarie in ordine di priorità
- Impegno ingegneristico stimato (giorni-persona)
- Intervallo dei costi stimati
- Scadenze per raggiungere la piena conformità
6. RIFERIMENTI
- Direttive e regolamenti con le date di pubblicazione
- Norme con le date delle edizioniPerché i RAG Report sono importanti al di là della conformità
Il formato RAG Report serve simultaneamente tre tipi di destinatari:
Per il team di ingegneria: una specifica precisa, a livello di requisito, di ciò che deve essere modificato e del perché — elimina l’ambiguità tra l’intento di conformità e l’implementazione.
Per il CTO / direttore tecnico: un business case basato sulle evidenze per l’investimento in riprogettazione. Il conteggio totale dei “rilievi Rossi” e la stima dei costi di intervento forniscono i dati necessari a giustificare il budget, soprattutto a fronte della controargomentazione del “lo risolverà un aggiornamento firmware”.
Per il regolatore: le autorità di vigilanza del mercato richiedono la documentazione tecnica e la dichiarazione di conformità UE, non un RAG Report. Un RAG Report può supportare tale documentazione mostrando che il fabbricante ha valutato ciascun requisito, individuato le lacune e adottato azioni correttive.