IT-Systemhäuser und Integratoren
Sie betreuen heterogene Kundenlandschaften: Server, Netzwerke, Arbeitsplätze, Fachanwendungen. Sie integrieren Standardsoftware, passen sie an, schreiben Schnittstellen, betreiben Systeme im Auftrag oder vor Ort beim Kunden. Ihre Kunden kommen aus allen Branchen - vom Mittelständler bis zur kommunalen Verwaltung.
Die regulatorische Einordnung Ihrer Arbeit ist schwieriger als bei reinen Agenturen, weil Sie selten ein einzelnes "Produkt" liefern, sondern eine Kombination aus Standardsoftware, Customizing, Skripten, Konfiguration und Betrieb. Genau diese Mischung ist es, die Sie regulatorisch in eine exponierte Lage bringt.
Typische Leistungen und ihre regulatorische Einordnung #
Customizing und Eigenentwicklungen auf Standardsoftware #
Wenn Sie ERP-, CRM-, DMS- oder Fachanwendungs-Systeme anpassen - durch Plug-ins, Module, Erweiterungen, eigene Reports oder Workflows - liefern Sie Code, der beim Kunden produktiv läuft. Unter der neuen Produkthaftungsrichtlinie (Art. 4, Art. 8) sind Sie damit Entwickler und damit Hersteller. Der CRA (Art. 3 Nr. 1) erfasst Ihre Entwicklungen als "Produkte mit digitalen Elementen", sobald sie eigenständig oder als Teil eines Produkts in Verkehr gebracht werden.
Der verbreitete Gedanke "das ist doch nur Customizing" trägt rechtlich nicht. Sobald Sie Code liefern, liefern Sie ein Produkt.
Schnittstellen und Integrationen #
Integrationsarbeit - EDI, REST-APIs, Message-Broker, ETL-Strecken - ist besonders heikel. Schnittstellen verarbeiten oft Finanz-, Personal- oder Gesundheitsdaten. Fehler in Integrationen sind eine häufige Ursache für Datenlecks. Art. 6 Abs. 1 lit. c der neuen Produkthaftungsrichtlinie nennt Datenverlust ausdrücklich als Haftungsgrund.
Infrastruktur und Betrieb #
Reine Infrastruktur-Leistung (Hosting, Managed Hardware, Netzwerkbetrieb) fällt nicht unmittelbar unter den CRA. Aber sobald Sie Software installieren, konfigurieren und betreiben, werden Sie zum Integrator - und damit in die Lieferkette Ihres Kunden eingebunden. Für NIS2-Kunden sind Sie dann unmittelbarer Anbieter nach Art. 21 Abs. 3.
On-Premise-Installationen von Open-Source-Software #
Wenn Sie Open-Source-Software (etwa ein Linux-Setup, einen Mail-Server, ein Wiki, ein Ticket-System, eine Monitoring-Plattform) beim Kunden installieren und betreuen, sind Sie verantwortlich für die Sorgfalt bei der Auswahl und Pflege dieser Komponenten. Der CRA verlangt in Art. 13 Abs. 5 "gebotene Sorgfalt" bei FOSS-Integration. Wer installiert, muss wissen, was er installiert.
Managed Services und Second-/Third-Level-Support #
Wenn Sie laufend Systeme patchen, updaten, überwachen und Fehler beheben, sind Sie in der laufenden Produktpflege. Das trifft die Update-Pflichten des CRA (Art. 13 Abs. 8) ebenso wie die Vulnerability-Handling-Pflichten (Art. 14).
Welche Gesetze greifen bei welchen Kunden #
Zwei Gesetze greifen unabhängig vom Kundensektor:
- Produkthaftungsrichtlinie (RL 2024/2853) erfasst jede Eigenentwicklung, jedes Customizing, jede Integration, sobald der Code bei einem Kunden produktiv läuft. Entwickler sind nach Art. 8 ausdrücklich Hersteller, Datenverlust ist Haftungsgrund (Art. 6 Abs. 1 lit. c), eine Haftungsobergrenze gibt es nicht (Art. 12).
- Cyber Resilience Act (VO (EU) 2024/2847) erfasst Ihre Eigenentwicklungen, Module, Schnittstellen und installierten Open-Source-Komponenten als "Produkte mit digitalen Elementen" (Art. 3 Nr. 1). Art. 13 Abs. 5 verlangt "gebotene Sorgfalt" bei FOSS-Integration, Art. 14 die Meldung und Behebung von Schwachstellen.
Systemhäuser haben traditionell besonders gemischte Kundenportfolios. Schon ein einziger Kunde aus einem regulierten Sektor zieht die gesamte Prozesslandschaft zusätzlich in DORA- oder NIS2-Betrachtungen:
- Banken, Sparkassen, Volksbanken, Versicherungen bringen DORA-Anforderungen aus der Kundenbeziehung. Ab dem Moment, in dem Sie einen einzigen Finanz-Kunden haben, werden Sie IKT-Drittdienstleister nach Art. 2 Abs. 1 lit. u DORA.
- Stadtwerke, Energieversorger, Netzbetreiber, Wasserwerke bringen NIS2-Anforderungen aus der Kundenbeziehung als wesentliche Einrichtungen.
- Krankenhäuser, Arztnetze, Pflegeeinrichtungen, Pharmaunternehmen bringen NIS2 plus besonders hohe Anforderungen an Datenschutz und Betriebssicherheit.
- Kommunen, Landesbehörden, Ämter sind unter NIS2 öffentliche Verwaltung und besonders sensibel bei Lieferantenprüfungen.
- Automotive, Maschinenbau, Halbleiter sind NIS2-Sektoren als wichtige Einrichtungen.
- Logistik, Speditionen, ÖPNV, Flughäfen sind unter NIS2 Verkehr.
- Rechenzentren, Cloud-Anbieter, TK-Unternehmen sind unter NIS2 digitale Infrastruktur.
Die Breite Ihres Kundenportfolios wird damit zum Risiko: Es genügt eine einzige Kunden-Due-Diligence, die Schwächen aufdeckt, um das Geschäft mit diesem Kunden und dessen Branchenkollegen zu gefährden.
Konkrete Konsequenzen #
Rechtlich stehen auf dem Spiel:
- Unbegrenzte Haftung nach der neuen Produkthaftungsrichtlinie für jeden von Ihnen gelieferten Code und jede Eigenentwicklung
- Bußgelder bis 15 Mio. Euro oder 2,5 % des Jahresumsatzes nach CRA (Art. 64), plus Verlust des EU-Marktzugangs bei Nicht-Konformität
- Meldepflichten nach Art. 14 CRA und Art. 23 NIS2 mit Fristen zwischen 24 und 72 Stunden
- Verlust regulierter Kundensegmente (Banken, Versicherungen, Energie, Gesundheit, Verwaltung), wenn Sie die Lieferantenprüfung nicht bestehen - bei gemischten Systemhaus-Portfolios oft der größte wirtschaftliche Schaden
- Direkte DORA-Aufsicht bis zu 1 % des weltweiten Tagesumsatzes bei kritischen IKT-Drittdienstleistern (Art. 50 DORA)
- Persönliche Haftung der Geschäftsleitung bei grober Sorgfaltsverletzung
Vertraglich werden Ihre Kunden verlangen:
- Dokumentierte Sicherheitsstrategie und Schwachstellenmanagement
- SBOM für eingesetzte und entwickelte Software, einschließlich transitiver Abhängigkeiten
- Patch-Management-Prozesse mit nachweisbaren Reaktionszeiten
- Incident-Response-Verfügbarkeit, bei DORA-Kunden typischerweise 24/7
- Ausstiegsszenario und Übergabeplan (Art. 28 Abs. 8 DORA)
- Auditzugang oder Auditunterstützung
- Haftpflichtversicherung in relevanter Höhe
Operativ müssen Sie etablieren:
- SBOM-Erstellung und -Pflege für alle Customizings und Integrationen
- Kontinuierliche Schwachstellenüberwachung aller eingesetzten Komponenten, auch der transitiven
- Responsible-Disclosure-Kanal für Meldungen aus der Community
- Dokumentierte Prozesse für Patch-Rollout bei Ihren Kunden
- Rückverfolgbarkeit: Welcher Kunde läuft mit welcher Version welcher Komponente
Finanziell kommt auf Sie zu:
- Kosten für Zertifizierungen (ISO/IEC 27001 wird zunehmend Standard)
- Aufbau interner Security-Kapazität oder Einkauf als Dienstleistung
- Versicherungsprämien, die bei nicht-dokumentierten Prozessen stark steigen
- Haftungsrisiko nach Produkthaftungsrichtlinie ohne Obergrenze
Sicherheit ist auch ohne Pflicht ein Wettbewerbsvorteil #
Systemhäuser leben von Vertrauen. Ihre Kunden geben Ihnen Zugang zu ihren wichtigsten Systemen - wer diesen Zugang verantwortungsvoll nutzen kann und das auch dokumentiert, hat einen handfesten Wettbewerbsvorteil. Selbst Kunden, die nicht unter CRA, DORA oder NIS2 fallen, fragen zunehmend nach Sicherheitsnachweisen.
Konkret bringt das: bessere Positionierung bei Ausschreibungen, stärkere Kundenbindung, höhere Tagessätze, weniger Reibung bei Audits und Versicherungen und eine deutliche Abgrenzung gegenüber Wettbewerbern, die "das machen wir schon irgendwie" noch als Geschäftsmodell betrachten.
Wie OTTRIA Systemhäuser unterstützt #
OTTRIA arbeitet im Open-Source-Teil Ihrer Lieferkette - genau dort, wo heterogene Systemhäuser die größten blinden Flecken haben:
- SBOM-Analyse und -Pflege über alle eingesetzten Open-Source-Komponenten Ihrer Customizings, Integrationen und betreuten Installationen hinweg
- Vulnerability-Monitoring aller Komponenten, auch der transitiven Abhängigkeiten, die kein Scanner vollständig abdeckt
- Silent-Fix-Detection durch aktive Code-Analyse - Sie erfahren von Problemen, die als CVE nie erfasst werden
- Fehlerbehebung direkt im Open-Source-Projekt bei Komponenten, die Sie einsetzen und die niemand sonst pflegt
- Koordinierte Reaktion bei Schwachstellen, die mehrere Ihrer Kunden gleichzeitig betreffen
- Auditfähige Dokumentation pro Kunde, vorlegbar bei Lieferantenbewertungen unter DORA und NIS2
- Steward-Rolle für Komponenten, die für mehrere Ihrer Kunden kritisch sind
Sie bleiben verantwortlich für die Installationen bei Ihren Kunden. OTTRIA sorgt dafür, dass die eingesetzten Open-Source-Komponenten überwacht, gepflegt und dokumentiert sind - so wie CRA, DORA und NIS2 es verlangen.
Zurück zur Übersicht für Software-Dienstleister
Weiterlesen