Ein TrustTroiAI-Werkstück · CRA-Board-Perspektive

Board Assurance Checklist.

Die fünfzehn Governance-Kontrollen, die Ihr Vorstand für eine Prüfung nach dem Cyber Resilience Act braucht, in einer Sprache, die er beantworten kann.

Der Cyber Resilience Act (CRA) verpflichtet Hersteller digitaler Produkte, Cybersicherheit über den gesamten Produktlebenszyklus nachzuweisen. Diese Checkliste übersetzt die Governance-Anforderungen des CRA in fünfzehn konkrete Board-Fragen mit klaren Nachweis-Mustern.

Bereich 01

Risikomanagement und Security by Design

Ob Ihr Produkt CRA-konform entwickelt wurde, entscheidet sich nicht in der Konformitätsbewertung, sondern in der Design-Phase. Die drei Kontrollen dieses Bereichs prüfen, ob das Risiko-Denken vor dem Code existiert.

1.1

Documented Risk Assessment

Board-Frage

Können Sie die Cybersicherheits-Risikobewertung für Ihr wichtigstes Produkt in unter fünf Minuten vorzeigen, mit Datum, Verantwortlichem und Trigger-Regeln?

Nachweis-Muster

Versionskontrolliertes Dokument im Repository oder Wiki, mit Prozess-Beschreibung, Auslöser-Katalog und Verantwortlichkeits-Zuordnung.

CRA Article 13(2)

1.2

Threat Modelling as Release Gate

Board-Frage

Ist das Threat Modelling ein Release-Gate, das nicht übersprungen werden kann, oder eine Empfehlung, die im Zeitdruck entfällt?

Nachweis-Muster

Release-Checkliste mit Threat-Modelling-Punkt und dokumentierten Ausnahmen mit Genehmiger und Ablaufdatum.

CRA Annex I, Part 1

1.3

Supply Chain Risk Register

Board-Frage

Wissen Sie im Fall eines kritischen CVE innerhalb von 24 Stunden, welche Ihrer Produkte betroffen sind?

Nachweis-Muster

SBOM pro Release, automatisch gegen CVE-Feeds abgeglichen, mit Verantwortlichem für die Triage.

CRA Annex I, Part 2 (PT2.1)

Bereich 02

Governance und Dokumentation

Die technische Dokumentation nach Anhang VII muss zehn Jahre aufbewahrt werden. Die drei Kontrollen dieses Bereichs prüfen, ob diese Dokumentation lebt oder ob sie beim ersten Audit als Fassade zusammenbricht.

2.1

Current Technical File

Board-Frage

Spiegelt Ihre technische Dokumentation die derzeit ausgelieferte Produktversion wider, oder die Version von vor drei Releases?

Nachweis-Muster

Versionskontrolliertes Dokument mit Zeitstempel der letzten Aktualisierung, verknüpft mit dem aktuellen Release-Tag.

CRA Article 31, Annex VII

2.2

Named Cyber-Compliance Owner

Board-Frage

Wer trifft bei Ihnen die Meldepflicht-Entscheidung nach Artikel 14 innerhalb von 24 Stunden, wenn heute Nacht ein Zero-Day auftritt?

Nachweis-Muster

Benannte Person mit dokumentierter Vertretungs-Regelung, Zugang zur ENISA-Meldeplattform bereits eingerichtet und getestet.

CRA Article 14, applies from 11 September 2026

2.3

Board-Level Risk Integration

Board-Frage

Steht Produkt-Cybersicherheit auf der Tagesordnung Ihrer regelmäßigen Geschäftsleitungs-Prüfung, oder existiert sie parallel in einem Tools-Team?

Nachweis-Muster

Protokolle der letzten drei Geschäftsleitungs-Sitzungen mit Cybersicherheits-Tagesordnungspunkt, Cybersicherheitsrisiken im Unternehmens-Risikoregister.

CRA Article 13(1), Article 64 (penalties)

Bereich 03

Vulnerability und Patch Management

Vulnerability-Management ist die Domäne, in der Konformität in Echtzeit sichtbar wird. Die drei Kontrollen dieses Bereichs prüfen, ob Sie im Ernstfall handlungsfähig sind.

3.1

Public Vulnerability Disclosure Policy

Board-Frage

Können externe Sicherheitsforscher Sie erreichen, oder müssen sie über den allgemeinen Support-Eingang gehen?

Nachweis-Muster

Veröffentlichte CVD-Richtlinie auf der Produktwebsite, security.txt-Datei auf den öffentlichen Domänen, dokumentierter Test-Report mindestens einer echten Meldung.

CRA Annex I, Part 2 (PT2.5, PT2.6)

3.2

Vulnerability SLA Tracked and Met

Board-Frage

Kennen Sie Ihre eigene Zeit von Vulnerability-Meldung bis Patch-Release, und liegt sie öfter innerhalb Ihrer SLA als außerhalb?

Nachweis-Muster

Vulnerability-Tracking-Board mit Schweregrad, Verantwortlichem, Zielterminen und tatsächlicher Behebungszeit, Trend-Auswertung der letzten drei Monate.

CRA Annex I, Part 2 (PT2.2, PT2.7)

3.3

Article 14 Reporting Playbook Tested

Board-Frage

Wurde Ihr Meldepflicht-Prozess mindestens einmal an einem realen Sicherheitsereignis getestet, oder ist er ein Papier-Prozess?

Nachweis-Muster

Dokumentierte Meldepflicht-Entscheidung für mindestens ein Ereignis, mit Zeit-Stempel und Begründung, auch bei Nicht-Meldepflicht.

CRA Article 14, applies from 11 September 2026

Bereich 04

Produktlebenszyklus

Der Unterstützungszeitraum ist die längste vertragliche Verpflichtung im CRA. Die drei Kontrollen dieses Bereichs prüfen, ob Sie diese Verpflichtung mit Ressourcen und Prozessen unterlegen können.

4.1

Support Period Decision Record

Board-Frage

Ist das Ende-Datum des Unterstützungszeitraums für jedes Ihrer Produkte zum Kaufzeitpunkt sichtbar, und ist die Wahl begründet?

Nachweis-Muster

Support Period Decision Record pro Produkt mit Begründung der Dauer, Enddatum sichtbar auf Produktseite oder Datenblatt.

CRA Article 13(8), Article 13(19)

4.2

Secure Update Mechanism

Board-Frage

Werden Ihre Sicherheitsupdates kryptographisch signiert, sicher verteilt und mit Rollback-Möglichkeit ausgeliefert, oder sind sie ein einfaches Datei-Ersetzen?

Nachweis-Muster

Dokumentierter Update-Prozess mit Signierung, Integritätsprüfung, Rollback-Testfall aus dem letzten Release-Zyklus.

CRA Annex I, Part 1 (PT1.2.c), Part 2 (PT2.7, PT2.8)

4.3

End-of-Life Communication Plan

Board-Frage

Wissen Ihre Nutzer, was passiert, wenn der Unterstützungszeitraum endet, und gibt es einen Migrations-Pfad?

Nachweis-Muster

End-of-Life-Plan-Vorlage mit Kommunikations-Fahrplan, Migrations-Anleitung und dokumentierten früheren EOL-Kommunikationen.

CRA Article 13, Annex II

Bereich 05

Awareness und Skills

Ohne kompetentes Team bleiben alle anderen Kontrollen Papier. Die drei Kontrollen dieses Bereichs prüfen, ob die Menschen, die die Konformität herstellen sollen, die Voraussetzungen dafür haben.

5.1

Secure Coding Baseline Enforced

Board-Frage

Existiert ein Secure-Coding-Standard für Ihren Haupt-Stack, ist er in der CI-Pipeline durchgesetzt, und wird er tatsächlich befolgt?

Nachweis-Muster

Einseitige Basis-Datei im Repository, SAST-Regeln, die zu den verbotenen Mustern passen, PR-Checkliste mit Verweis auf die Basis.

CRA Annex I, Part 1 (PT1.2.a), Part 2 (PT2.3)

5.2

Peer Review for Security-Sensitive Changes

Board-Frage

Können sicherheitsrelevante Änderungen an Authentifizierung, Kryptografie oder externen Schnittstellen ohne ein zweites Paar Augen in Produktion gehen?

Nachweis-Muster

CODEOWNERS-Datei mit sicherheitsrelevanten Pfaden, geschützte Branches mit PR-Review-Anforderung, Beleg der Durchsetzung im letzten Release.

CRA Annex I, Part 2 (PT2.3)

5.3

Continuous Learning Loop

Board-Frage

Wenn ein Vorfall passiert, wird die Erkenntnis in Design und Prozess zurückgeführt, oder bleibt sie im Gedächtnis der Beteiligten?

Nachweis-Muster

Post-Incident-Review-Vorlage, mindestens ein Backlog-Element aus einer Review im letzten Quartal, Aktualisierung der Risikobewertung dokumentiert.

CRA Recital 15, Annex I Part 2 (PT2.3)

Von der Checkliste zum Werkstück.

Wenn eine Kontrolle noch nicht sitzt, erkennt Inspektor die Lücke direkt in Ihrem Jira und liefert die signierte Vorlage über Cronos.

Inspektor für Jira installieren

PDF-Version

Die Checkliste als PDF für Ihr Board.

Sechs Seiten, druckfertig, mit derselben Struktur und Attribution.

PDF herunterladen