Ein RAG-Bericht (Rot-Gelb-Grün-Bericht) ist ein strukturiertes Bewertungsdokument, das ein dreifarbiges Ampelsystem verwendet, um den Konformitätsstatus jeder einzelnen Anforderung einer anwendbaren EU-Richtlinie oder -Verordnung in Bezug auf das aktuelle Produktdesign zu kommunizieren. Er ist das Standardformat für die Ergebnisse von Lückenanalysen zur Hardwarekonformität, genau deshalb, weil er komplexe, richtlinienübergreifende technische Bewertungen in eine für die Führungsebene verständliche Zusammenfassung umwandelt, die zur Priorisierung von Abhilfemaßnahmen und zur Rechtfertigung des Entwicklungsbudgets verwendet werden kann.
Die drei RAG-Klassifizierungen
| Farbe | Bedeutung | Erforderliche Maßnahme |
|---|---|---|
| 🟢 Grün | Die Anforderung wird vom aktuellen Design vollständig erfüllt. Nachweise sind dokumentiert (Prüfbericht, Design-Review, Materialdeklaration usw.). | Keine – Nachweise in der technischen Dokumentation ablegen |
| 🟡 Gelb | Die Anforderung ist teilweise erfüllt oder die Konformität ist an Bedingungen geknüpft bzw. nicht verifiziert. Das Design kann konform sein, aber es fehlen Nachweise oder eine Annahme muss validiert werden. | Untersuchung erforderlich – entweder die fehlenden Nachweise erbringen oder das gekennzeichnete Element überarbeiten |
| 🔴 Rot | Die Anforderung wird vom aktuellen Design nicht erfüllt. Es besteht eine konkrete Lücke, die ohne eine Designänderung, den Austausch von Komponenten oder eine Prozessänderung nicht geschlossen werden kann. | Abhilfemaßnahme erforderlich – die Lücke muss geschlossen werden, bevor das Produkt rechtmäßig die CE-Kennzeichnung tragen darf |
Struktur eines RAG-Berichts zur Hardwarekonformität
Für ein vernetztes Hardwareprodukt, das mehreren Richtlinien unterliegt, ist der RAG-Bericht typischerweise wie folgt strukturiert:
RAG-Konformitätsbericht – [Produktname] Rev. [X]
Erstellt von: [Name des Ingenieurs, Qualifikation]
Überprüft von: [Leitender Sicherheitsarchitekt / Compliance-Verantwortlicher]
Datum: [JJJJ-MM-TT]
1. ANWENDUNGSBEREICH
- Produktbeschreibung und Verwendungszweck
- Liste der bewerteten anwendbaren Richtlinien und Verordnungen
- Bewertungsmethodik und referenzierte Normen
2. ZUSAMMENFASSUNG FÜR DIE FÜHRUNGSEBENE
- Übersichtstabelle: Gesamtanzahl Grün / Gelb / Rot pro Richtlinie
- Gesamturteil zur Konformität
- Empfohlene Prioritätsreihenfolge für Abhilfemaßnahmen
3. DETAILLIERTE ERGEBNISSE – pro Richtlinie
[Für jede anwendbare Richtlinie eine Tabelle der Anforderungen:]
| Anforderung | Artikel / Klausel | RAG-Status | Ergebnisse | Nachweis / Empfehlung |
|---|---|---|---|---|
| Hardware-Vertrauensanker | CRA Anhang I § 1(a) | 🔴 Rot | MCU (STM32F4) hat kein Secure Element oder TrustZone. Gemeinsamer Schlüssel im Flash-Speicher abgelegt. | MCU durch STM32U5 (TrustZone-M) ersetzen und STSAFE-A110 Secure Element hinzufügen |
| Eindeutige Gerätekennung | CRA Anhang I § 1(b) | 🔴 Rot | MAC-Adresse als Kennung verwendet – klonbar. | Implementierung der Provisionierung von Gerätezertifikaten mit STSAFE-A110 in der Fertigung |
| Authentifizierung von OTA-Updates | CRA Anhang I § 2(c) | 🟡 Gelb | OTA-Mechanismus vorhanden, aber Signaturschlüssel in Software gespeichert. | Hardware-Schlüsselspeicherung erforderlich – gelöst, sobald STSAFE-A110 hinzugefügt wird |
| Richtlinie zur Offenlegung von Schwachstellen | CRA Art. 13(6) | 🟢 Grün | security.txt auf der Produktdomäne vorhanden, PSIRT-Kontakt eingerichtet | In der technischen Dokumentation dokumentieren |
4. KOMPONENTEN-RISIKOMATRIX
[Tabelle auf Stücklistenebene, die angibt, welche Komponenten bestehen, nicht bestehen oder ersetzt werden müssen]
5. ABHILFEPLAN
- Priorisierte Liste der erforderlichen Änderungen
- Geschätzter Entwicklungsaufwand (Personentage)
- Geschätzter Kostenrahmen
- Zeitplan bis zur Erreichung der vollständigen Konformität
6. REFERENZEN
- Verweise auf Richtlinien und Verordnungen mit Veröffentlichungsdatum
- Verweise auf Normen mit AusgabedatumWarum RAG-Berichte über die Konformität hinaus wichtig sind
Das Format des RAG-Berichts dient drei Zielgruppen gleichzeitig:
Für das Entwicklungsteam: Eine präzise Spezifikation auf Anforderungsebene, was geändert werden muss und warum – beseitigt Unklarheiten zwischen der Konformitätsabsicht und der Implementierung.
Für den CTO / Entwicklungsleiter: Ein evidenzbasierter Business Case für Investitionen in die Neuentwicklung. Die „Gesamtzahl der roten Ergebnisse“ und die Kostenschätzung für die Abhilfemaßnahmen liefern die Daten, die zur Rechtfertigung des Budgets erforderlich sind, insbesondere gegenüber dem Gegenargument „ein Firmware-Update wird das Problem beheben“.
Für die Regulierungsbehörde: Wenn eine Marktüberwachungsbehörde die Konformität in Frage stellt, belegt der RAG-Bericht die gebotene Sorgfalt (Due Diligence) – der Hersteller hat die Konformität aktiv bewertet, Lücken identifiziert und Korrekturmaßnahmen ergriffen. Produkte, für die kein RAG-Bericht oder eine gleichwertige strukturierte Bewertung vorgelegt werden kann, unterliegen einem wesentlich höheren Risiko von Vollzugsmaßnahmen.