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 ein weit verbreitetes Format für die Ergebnisse von Lückenanalysen zur Hardwarekonformität – kein vom EU-Recht vorgeschriebenes –, 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 |
|---|---|---|---|---|
| Vertraulichkeit gespeicherter Schlüssel und Daten | CRA Anhang I Teil I(2)(e) | 🔴 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 |
| Schutz vor unbefugtem Zugriff (Authentifizierung) | CRA Anhang I Teil I(2)(d) | 🔴 Rot | MAC-Adresse als Kennung verwendet – klonbar. | Implementierung der Provisionierung von Gerätezertifikaten mit STSAFE-A110 in der Fertigung |
| Integrität der Software und sichere Verbreitung von Aktualisierungen | CRA Anhang I Teil I(2)(f), Teil II(7) | 🟡 Gelb | OTA-Mechanismus vorhanden, aber Signaturschlüssel in Software gespeichert. | Hardware-Schlüsselspeicherung erforderlich – gelöst, sobald STSAFE-A110 hinzugefügt wird |
| Strategie für die koordinierte Offenlegung von Schwachstellen und Kontaktadresse | CRA Anhang I Teil II(5)–(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: Marktüberwachungsbehörden verlangen die technische Dokumentation und die EU-Konformitätserklärung, keinen RAG-Bericht. Ein RAG-Bericht kann diese Dokumentation unterstützen, indem er zeigt, dass der Hersteller jede Anforderung bewertet, Lücken identifiziert und Korrekturmaßnahmen ergriffen hat.