PSIRT aufbauen: Rollen, Prozesse und erste Schritte für CRA- und NIS2-konforme Organisationen

Warum kein Medizinprodukt-Hersteller heute noch ohne PSIRT auskommt

Als wir im Rahmen unseres MDR- und NIS2-Forschungsprojekts am Universitätsklinikum den ersten externen Auditor empfingen, hatte ich erwartet, dass die Eingangsfrage sich um Risikoklassen oder klinische Bewertungsdaten drehen würde. Stattdessen fragte er schlicht: „Wer in Ihrem Unternehmen kann eine gemeldete Schwachstelle innerhalb von 24 Stunden koordinieren – und wie ist das dokumentiert?"

Die Stille im Raum sagte alles.

Diese Anekdote ist kein Einzelfall. Sie spiegelt eine regulatorische Realität wider, die mit dem Cyber Resilience Act (CRA) und der NIS2-Richtlinie endgültig Einzug in den MedTech-Sektor gehalten hat: strukturiertes Vulnerability Management ist keine Kür mehr, sondern regulatorische Pflicht. Wer als Hersteller oder Betreiber wesentlicher Einrichtungen kein dediziertes Product Security Incident Response Team (PSIRT) vorweisen kann, riskiert empfindliche Bußgelder — bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes unter NIS2 — und im schlimmsten Fall den Marktzugangsverlust für das betroffene Produkt.

Ein PSIRT ist damit funktional vergleichbar mit einem Qualitätsmanagementsystem nach ISO 13485: Niemand würde ein Medizinprodukt ohne QMS in Verkehr bringen. Die analoge Denkweise muss jetzt für Cybersecurity gelten.

Was ein PSIRT eigentlich ist – und was es nicht ist

Bevor man mit dem Aufbau beginnt, lohnt eine präzise Begriffsklärung — gerade im Healthcare-Umfeld, wo IT-Abteilungen und Qualitätsmanagement häufig parallel existieren und Zuständigkeiten verschwimmen.

Ein PSIRT ist explizit auf produktbezogene Sicherheitslücken ausgerichtet. Es ergänzt das klassische IT-SIRT (Security Incident Response Team), ersetzt es aber nicht. Die Abgrenzung ist operativ entscheidend:

• Das IT-SIRT behandelt interne Infrastrukturvorfälle: kompromittierte Server, Phishing-Angriffe auf Mitarbeitende, Ransomware im Kliniknetzwerk.
• Das PSIRT koordiniert externe Schwachstellenmeldungen zu ausgelieferten Produkten — also zu Software und Firmware, die bereits beim Kunden oder Patienten im Einsatz sind.

Ein konkretes Beispiel aus unserem Projektalltag: Eine Schwachstelle in der Steuerungssoftware eines vernetzten Infusionspumpensystems fällt klar in den PSIRT-Scope. Ein kompromittiertes Mitarbeiter-Notebook in der Beschaffungsabteilung fällt in den des IT-SIRT. Beide Vorfälle erfordern unterschiedliche Prozesse, unterschiedliche Meldepflichten und unterschiedliche Kommunikationswege — sie unter einem Dach zu vermischen, erzeugt gefährliche Blindstellen.

Rollen und Verantwortlichkeiten: Das Grundgerüst

Ein funktionsfähiges PSIRT braucht kein großes Team — aber es braucht klar definierte Rollen. Folgende Kernfunktionen sind nicht verhandelbar:

• PSIRT Lead: Koordiniert alle eingehenden Schwachstellenmeldungen, entscheidet über Eskalationsstufen und ist erste Ansprechperson für das Management.
• Vulnerability Analyst: Bewertet Schwachstellen technisch, erstellt CVSS-Scores und priorisiert Maßnahmen nach Ausnutzbarkeit und klinischer Auswirkung.
• Disclosure Manager: Verantwortet die externe Kommunikation — gegenüber Sicherheitsforschern, Behörden und im Ernstfall der Öffentlichkeit.
• Legal/Regulatory Liaison: Stellt sicher, dass Meldepflichten nach NIS2 Artikel 23, MDR Anhang I sowie gegenüber dem BfArM und der zuständigen Benannten Stelle eingehalten werden.

Wichtig für die Praxis: In der Aufbauphase können diese Rollen durchaus in Personalunion besetzt werden — ein fünfköpfiges PSIRT ist kein realistisches Ziel für den Startschuss. Was jedoch von Tag eins an schriftlich dokumentiert sein muss, sind die Eskalationspfade. Eine RACI-Matrix schützt vor den typischen Zuständigkeitslücken, die in Matrixorganisationen — wie sie in Kliniken und MedTech-Unternehmen die Regel sind — sonst unvermeidlich entstehen.

Kernprozesse: Von der Meldung bis zur koordinierten Offenlegung

Fünf Prozesse machen ein PSIRT operativ arbeitsfähig:

1. Intake & Triage: Eingehende Meldungen werden klassifiziert, priorisiert und dem richtigen Analyst zugewiesen. Hier entscheidet sich, ob die 24-Stunden-Frist nach NIS2 für die Erstmeldung eingehalten werden kann — oder nicht.
2. Technische Analyse & CVSS-Bewertung: Schweregrad und Ausnutzbarkeit werden bewertet. Im MedTech-Kontext ist dabei auch die klinische Risikoauswirkung zu berücksichtigen — eine Netzwerklücke in einem Bildarchivierungssystem ist anders zu gewichten als dieselbe Lücke in einem lebenswichtigen Monitoring-Gerät.
3. Interne Eskalation: Bei hohem CVSS-Score oder klinischer Relevanz müssen Entwicklung, Regulatory Affairs und Management zeitnah eingebunden werden.
4. Remediation Tracking: Patches, Workarounds und Field Safety Corrective Actions (FSCAs) werden nachverfolgt und dokumentiert — auch für spätere Audits.
5. Coordinated Vulnerability Disclosure (CVD) gemäß ISO/IEC 29147: Der strukturierte, abgestimmte Veröffentlichungsprozess schützt Nutzer, wahrt Herstellerinteressen und entspricht dem Stand der Technik.

NIS2 schreibt für wesentliche und wichtige Einrichtungen eine Erstmeldung signifikanter Vorfälle innerhalb von 24 Stunden vor. Im MedTech-Umfeld kommt parallel die Meldepflicht gegenüber BfArM und Benannter Stelle hinzu. Beide Meldestränge müssen Ihre Prozesse gleichzeitig bedienen können — das ist keine Redundanz, das ist regulatorische Realität.

Tooling und Infrastruktur: Was man wirklich braucht

Die gute Nachricht: Ein PSIRT braucht zum Start keine komplexe Toollandschaft. Das Minimum Viable Toolset besteht aus:

• Einem dedizierten Eingangskanal — idealerweise security@ihredomaene.de — mit definierter Erreichbarkeit und Reaktionszeit.
• Einem Ticketsystem mit Vertraulichkeitsstufen, das Schwachstelleninformationen intern schützt, bis eine koordinierte Offenlegung erfolgt.
• Einer internen Wissensdatenbank für bekannte Schwachstellen, Bewertungshistorien und Lösungsansätze.

In unserem Pilotprojekt nutzen wir TrustSource, das SBOM-basiertes Vulnerability Tracking direkt in den PSIRT-Workflow integriert — eine erhebliche Effizienzgewinn, wenn man bedenkt, wie viele Drittkomponenten in typischer Medizingeräte-Software stecken.

Oft unterschätzt, aber regulatorisch relevant: eine security.txt nach RFC 9116 auf allen Produktwebseiten. Ohne diesen Eintrag sind Sie für externe Sicherheitsforscher schlicht nicht auffindbar — und eine Schwachstelle, die nicht gemeldet werden kann, wird irgendwann anders publik.

Mittelfristig lohnt es sich, den CNA-Status (CVE Numbering Authority) bei MITRE anzustreben. Das stärkt die Position gegenüber Behörden, der Forschungscommunity — und signalisiert regulatorische Reife.

Häufige Stolpersteine beim PSIRT-Aufbau

Aus der Begleitung verschiedener Aufbauprojekte — und aus eigener Projekterfahrung — kristallisieren sich drei wiederkehrende Fehler heraus:

1. Fehlende Managementunterstützung. Ein PSIRT ohne Budget- und Entscheidungskompetenz kann Schwachstellen identifizieren, aber nicht beheben. Wenn Patches nicht priorisiert werden, weil die Entwicklung ausgelastet ist, und niemand auf Leitungsebene entscheiden kann, ist das PSIRT wirkungslos. Das Commitment der Geschäftsführung ist nicht verhandelbar.

2. Fehlende oder unklare Disclosure-Policy. Ohne schriftlich fixierte CVD-Policy werden Offenlegungsentscheidungen unter Zeitdruck ad hoc getroffen — mit entsprechendem rechtlichem und reputativem Risiko für alle Beteiligten. Die Policy muss vor dem ersten Vorfall existieren, nicht danach.

3. Perfektionismus in der Aufbauphase. Ich habe Teams erlebt, die sechs Monate an einem umfassenden PSIRT-Framework gearbeitet haben — und nie produktiv gegangen sind, weil immer noch ein Prozess fehlte. Ein schlankes, funktionsfähiges PSIRT in 90 Tagen schlägt ein perfektes Framework, das niemand lebt.

Erste Schritte und Take-aways: So starten Sie heute

Der regulatorisch nachweisbare PSIRT-Kern lässt sich mit vier Quick Wins etablieren:

• security.txt einrichten — heute, nicht nächste Woche.
• Eingangskanal definieren und kommunizieren (security@).
• Eine verantwortliche Person namentlich benennen und intern bekannt machen.
• Eine einseitige Triage-Checkliste erstellen: Was ist ein signifikanter Vorfall? Wer wird wann informiert?

Bauen Sie dabei auf etablierten Standards auf: ISO/IEC 29147 für Disclosure, ISO/IEC 30111 für internes Handling, das FIRST PSIRT Services Framework sowie der BSI-Leitfaden zur Koordinierten Schwachstellenoffenlegung bieten solide Blaupausen, die nicht neu erfunden werden müssen.

Die EACG begleitet Unternehmen beim strukturierten PSIRT-Aufbau — von der initialen Gap-Analyse über Prozessdesign und Toolauswahl bis zur regulatorischen Abnahme. Wenn Sie wissen möchten, wo Sie heute stehen und welche Schritte als nächstes sinnvoll sind, starten Sie mit einem kostenlosen Erstgespräch.

Der Auditor fragt. Die Frage ist nicht ob — sondern wann.

Zur Person

Pilotiert TrustSource in einem MDR + NIS2 Forschungsprojekt am Universitätsklinikum.

Co-Autorschaft. Pilotiert TrustSource im Forschungsprojekt. Nicht vergütet.