Software-Entwicklungshäuser

Sie entwickeln Individualsoftware, mobile und Desktop-Anwendungen, Backend-Systeme, APIs, Embedded Software und oft kritische Kernanwendungen Ihrer Kunden. Ihre Arbeit ist selten sichtbar von außen, aber regulatorisch stehen Sie im Zentrum: Sie produzieren Code, der Geschäftsprozesse trägt.

Keine andere Gruppe ist so eindeutig von der neuen Regulierung erfasst. Die Produkthaftungsrichtlinie nennt Entwickler ausdrücklich als Hersteller (Art. 8), der CRA behandelt jede entwickelte Software als Produkt mit digitalen Elementen (Art. 3 Nr. 1), und als Zulieferer kritischer Geschäftsfunktionen sind Sie unmittelbar in DORA- und NIS2-Lieferketten eingebunden.

Typische Projekte und ihre regulatorische Einordnung #

Individualsoftware für Geschäftsprozesse #

Ob Sie ein Warenwirtschaftssystem, ein Produktionsleitsystem, ein Buchhaltungsmodul oder eine Branchenlösung entwickeln - diese Software ist nach CRA ein Produkt mit digitalen Elementen. Ihre Kunden betreiben sie als Kernbestandteil ihres Geschäfts. Fällt sie aus oder enthält sie Schwachstellen, greift die Produkthaftung unmittelbar.

Bei DORA-Kunden wird solche Software oft als "kritische Funktion" eingestuft (Art. 28 Abs. 5 DORA) - mit entsprechend verschärften Anforderungen an Qualität, Dokumentation und Ausstiegsfähigkeit.

Mobile Apps für Endkunden und Mitarbeiter #

Apps sind eindeutige CRA-Produkte. Wenn sie für regulierte Kunden gebaut werden - Banking-Apps, Versicherungs-Apps, Gesundheits-Apps - kommen DORA oder NIS2 hinzu. Apps, die Zahlungsverkehr, Authentifizierung oder Gesundheitsdaten verarbeiten, fallen außerdem in den "kritischen" CRA-Bereich nach Anhang III und IV der Verordnung.

Backends, APIs und Microservices #

Backend-Entwicklung ist oft unsichtbar, aber regulatorisch am problematischsten: Backends verarbeiten die sensibelsten Daten und tragen die zentralen Geschäftsprozesse. Ein fehlerhaftes Backend kann einen kompletten Betrieb stilllegen oder Daten im großen Stil kompromittieren - Art. 6 Abs. 1 lit. c der Produkthaftungsrichtlinie (Datenverlust als Haftungsgrund) adressiert genau diese Fälle.

Embedded Software #

Embedded-Entwicklung für Industrie, Medizin, Automotive oder Energie fällt in mehreren Dimensionen unter die neuen Gesetze: CRA als Software in Produkten, Produkthaftung als Teil eines sicherheitsrelevanten Produkts, NIS2 als Zulieferung für kritische Sektoren. In der Regel kommen noch sektorspezifische Anforderungen hinzu - etwa die Maschinen- Verordnung, IEC 62443, MDR oder UN-R 155.

Core Banking, Insurance Core, Health-Systeme #

Wenn Sie Kernsysteme für Finanzinstitute, Versicherungen oder Krankenhäuser entwickeln, arbeiten Sie am schärfsten regulierten Ende des Spektrums. DORA betrachtet solche Systeme als "kritische IKT-Services" (Art. 28 Abs. 5), die Lieferantensteuerung ist maximal. Sie werden im DORA-Informationsregister Ihres Kunden prominent geführt.

Welche Gesetze greifen bei welchen Kunden #

Zwei Gesetze greifen immer, unabhängig davon, für wen Sie entwickeln:

Produkthaftungsrichtlinie (RL 2024/2853) macht Sie als Entwickler zum Hersteller (Art. 8). Datenverlust ist eigener Haftungsgrund (Art. 6 Abs. 1 lit. c), die Haftung ist nicht gedeckelt (Art. 12), und die Beweislast wird zugunsten Geschädigter erleichtert (Art. 10). Kein Vertrag gegenüber dem Kunden schützt Sie vor Direktansprüchen Dritter.
Cyber Resilience Act (VO (EU) 2024/2847) erfasst jede von Ihnen entwickelte Software als "Produkt mit digitalen Elementen" (Art. 3 Nr. 1). Sie unterliegen Sorgfaltspflichten bei FOSS-Integration (Art. 13 Abs. 5), Vulnerability-Handling (Art. 14) und mindestens fünf Jahren Support-Periode.

Weil Software-Entwicklungshäuser oft zentrale Kernanwendungen liefern, kommen zusätzlich DORA und NIS2 über die Kundenseite ins Spiel:

Finanzsektor (Banken, Versicherungen, Fonds, Zahlungsdienstleister, Kryptodienstleister) bringt DORA in voller Schärfe. Art. 28 DORA mit Informationsregister, Due Diligence, Exit-Strategie, TLPT-Einbezug.
Gesundheitswesen (Krankenhäuser, Labore, Medizinprodukte- Hersteller, digitale Gesundheitsanwendungen) bringt NIS2 plus MDR-Last plus besonders hohe Datenschutzanforderungen.
Energie und Versorgung (Stadtwerke, Übertragungsnetzbetreiber, Gasversorger) bringt NIS2 als wesentliche Einrichtungen.
Industrie (Automotive, Maschinenbau, Halbleiter, Chemie) bringt NIS2 als wichtige Einrichtungen, oft kombiniert mit Produktsicherheits- Anforderungen der Maschinen-Verordnung.
Öffentliche Verwaltung und Bundesbehörden bringen NIS2 und oft zusätzlich BSI-spezifische Anforderungen (ITSiG, BSI-KritisV).
Telekommunikation und digitale Infrastruktur sind NIS2-Sektor.

Auch ohne regulierte Endkunden gilt für alle Ihre Auftragsentwicklungen die Produkthaftungsrichtlinie. Die Vorstellung, "das ist Sache des Kunden", trägt rechtlich nicht.

Konkrete Konsequenzen #

Rechtlich stehen auf dem Spiel:

Unbegrenzte Haftung nach der Produkthaftungsrichtlinie - bei Softwarehäusern regelmäßig der wirtschaftlich gefährlichste Punkt, weil Ihre Software oft Kernprozesse trägt und Fehler katastrophale Folgen haben können
Bußgelder bis 15 Mio. Euro oder 2,5 % des Jahresumsatzes nach CRA (Art. 64)
Verlust des EU-Marktzugangs: Software, die den CRA nicht erfüllt, darf nicht mehr in Verkehr gebracht werden, bestehende Auslieferungen können zurückgerufen werden (Art. 52, 53 CRA)
24-/72-Stunden-Meldepflichten bei aktiv ausgenutzten Schwachstellen und Sicherheitsvorfällen (Art. 14 CRA, Art. 23 NIS2, Art. 19 DORA)
Beweislasterleichterung nach Art. 10 Produkthaftungsrichtlinie, wenn die Sorgfaltsdokumentation fehlt - im Zweifel gegen Sie
Verlust regulierter Kundensegmente wie Finanzdienstleister, Gesundheitsversorger oder KRITIS-Betreiber
Direkte DORA-Aufsicht bis 1 % des weltweiten Tagesumsatzes bei kritischen IKT-Drittdienstleistern (Art. 50 DORA)

Vertraglich werden Ihre Kunden verlangen:

Entwicklungsprozesse nach dem Stand der Technik (ISO/IEC 27001, ISO/IEC 18974 "Open Source Ready"), dokumentiert und prüfbar
SBOM für jede Lieferung, einschließlich aller Abhängigkeiten
Secure Coding, Code-Reviews, dokumentierte Teststrategien
Vulnerability-Handling nach Art. 14 CRA mit klaren Reaktionszeiten
Responsible-Disclosure-Prozess, öffentlich erreichbar
Bei DORA-Kunden: Aufnahme ins Informationsregister, Due-Diligence- Unterstützung, Exit-Strategie, TLPT-Mitwirkung

Operativ müssen Sie etablieren:

SBOM-Automatisierung in der CI/CD-Pipeline
Kontinuierliches Monitoring aller eingesetzten Komponenten über den gesamten Lebenszyklus der ausgelieferten Software
Patch-Bereitstellung und -Kommunikation an Kunden, auch Jahre nach Projektabschluss (die CRA-Support-Periode beträgt mindestens fünf Jahre)
Incident-Response mit 24/7-Bereitschaft bei DORA-Kunden
Beweissicherung und Dokumentation aller Sicherheitsentscheidungen für mögliche Audits oder Haftungsfälle

Finanziell kommt auf Sie zu:

Aufbau oder Zukauf von Security-Engineering-Kapazität
Laufende Pflegekosten für ausgelieferte Software, die Sie nicht mehr vollständig auf Neukundenprojekte umlegen können
Versicherungsprämien, die ohne nachweisbare Prozesse steil ansteigen
Unbegrenzte Haftung nach Produkthaftungsrichtlinie

Sicherheit ist auch ohne Pflicht ein Wettbewerbsvorteil #

Wer Kernsoftware entwickelt, konkurriert gegen andere Entwicklungshäuser, die im Pitch ähnlich gut klingen. Der Unterschied entsteht dort, wo Professionalität nachweisbar wird: dokumentierte SBOM, nachvollziehbares Schwachstellenmanagement, ein funktionierender Responsible-Disclosure-Prozess, Entwicklung nach ISO/IEC 18974.

Das ist nicht nur Compliance - es ist ein Qualitätssignal, das im Verkauf wirkt: bessere Abschlussquoten bei anspruchsvollen Kunden, höhere Tagessätze, günstigere Versicherungsprämien, stärkere Kundenbindung. Ihre besten Entwicklerinnen und Entwickler bleiben lieber dort, wo die Prozesse sauber sind. Die Investition zahlt sich mehrfach aus - auch ohne regulatorischen Druck.

Wie OTTRIA Software-Entwickler unterstützt #

Kein Entwicklungshaus kann die Sicherheit aller eingesetzten Open-Source-Komponenten intern tragen. Moderne Projekte haben Hunderte bis Tausende transitiver Abhängigkeiten in oft mehreren Programmiersprachen. OTTRIA übernimmt diesen Teil:

SBOM-Analyse und -Pflege über alle Ihre Projekte und Versionen hinweg, einschließlich transitiver Abhängigkeiten
Vulnerability-Monitoring in Echtzeit, mit Fokus auf Komponenten, die in Ihren Projekten tatsächlich eingesetzt sind
Silent-Fix-Detection durch aktive Code-Analyse und Commit-Überwachung
Fehlerbehebung direkt im Open-Source-Projekt bei Komponenten, die keinen aktiven Maintainer haben oder die Sie selbst nicht beheben können
Frühwarnung durch OTTRIAs Rolle als Open Source Steward - Sie erfahren von kritischen Schwachstellen vor der öffentlichen CVE-Veröffentlichung
Responsible-Disclosure-Kanal für Ihre Produkte als Service
Auditfähige Dokumentation pro Projekt und pro Kunde, vorlegbar bei DORA- und NIS2-Lieferantenbewertungen
Unterstützung bei Exit-Strategien - OTTRIAs öffentliche Arbeit in den Open-Source-Projekten bleibt verfügbar, auch wenn Sie aus einem Projekt ausscheiden

Sie konzentrieren sich auf das, was Ihr Kerngeschäft ist: Software entwickeln. OTTRIA liefert den Open-Source-Sorgfaltsteil, den kein Entwicklungshaus alleine bewältigen kann.

Erstgespräch vereinbaren

Zurück zur Übersicht für Software-Dienstleister