Branchen-Expertise für regulierte Märkte
Regulierte Softwareentwicklung ist keine Einheitsdisziplin
Medizintechnik: MDR-Klassifizierung, IEC 62304 und ISO 14971
Maschinenbau: SIL-Ableitung nach IEC 61508 trifft auf IEC 62443
Defense: AQAP 2110/2210-Konformität und VS-NfD-fähige Infrastruktur
Public Service: NIS2, BSI-Grundschutz und AVPQ-Präqualifikation
Nachweisbarkeit statt Funktion – Auditfähigkeit in allen Branchen
Branchen-Expertise: Warum branchenspezifisches Know-how entscheidend ist
Mit seiner Branchen-Expertise entwickelt infoteam Software für Medizintechnik, Maschinenbau, Bahn, Defense und Public Service – jeweils nach den Normen der Branche, etwa IEC 62304 und MDR, IEC 61508 und IEC 62443, DIN EN 50716 oder AQAP 2110/2210. Ein Team kennt die typischen Prüffragen jeder Branche und liefert auditfähige Nachweise ab dem ersten Requirement.
Regulierte Softwareentwicklung ist keine Einheitsdisziplin. Ein Medizintechnik-Unternehmen, das eine IEC-62304-konforme Firmware entwickelt, bewegt sich in einer völlig anderen Normenwelt als ein Bahninfrastrukturanbieter, der eine Leitsystem-Software nach DIN EN 50716 zulassen muss.
Die Normen, die Audit-Strukturen, die typischen Prüffragen und die akzeptierten Nachweismethoden unterscheiden sich grundlegend. Ein Engineering-Partner ohne echte Branchenerfahrung muss sich diese Kenntnisse im laufenden Projekt erarbeiten – auf Kosten von Zeit, Budget und Zulassungssicherheit. Branchenkenntnis ist deshalb kein Nice-to-have, sondern ein direkter Hebel auf Time-to-Market und Audit-Ergebnis.
Medizintechnik und Labortechnik: Software als reguliertes Medizinprodukt
In der Medizin- und Labortechnik ist Software entweder selbst ein Medizinprodukt oder integraler Bestandteil davon – mit allen Konsequenzen für Entwicklung, Dokumentation und Zulassung. Die MDR definiert, wann Software als Klasse-I-, Klasse-IIa- oder Klasse-IIb-Produkt einzustufen ist.
IEC 62304 legt den verpflichtenden Software-Lebenszyklus fest; ISO 14971 regelt das Risikomanagement und IEC 62366-1 die Gebrauchstauglichkeit. Wer diese Normen nur aus der Lektüre kennt, unterschätzt die Tiefe der Anforderungen. Wir haben in der Kardiologie, Onkologie und In-vitro-Diagnostik Software entwickelt und durch CE-Zertifizierungen geführt – inklusive der Erfahrung, welche Formulierungen in der Risikoakte Nachfragen provozieren und welche nicht.
Maschinenbau und Anlagentechnik: Funktionale Sicherheit bis SIL 3
Im Maschinenbau und in der Anlagentechnik bestimmt IEC 61508 die Anforderungen an sicherheitsbezogene Softwaresysteme – von der Gefährdungs- und Risikoanalyse über die Ableitung des Safety Integrity Levels (SIL) bis zum Nachweis aller Lebenszyklusaktivitäten. Parallel dazu rückt IEC 62443 mit wachsender Bedeutung in den Fokus: Industrielle Steuerungssysteme sind zunehmend vernetzt, und Cyber-Security-Anforderungen sind heute fester Bestandteil von Maschinenabnahmen.
Für Hersteller wie Verpackungsanlagen- und Sondermaschinenbauer bedeutet das: Steuerungssoftware muss sowohl funktional sicher als auch cyber-resistent sein – eine Kombination, die nur mit einem Engineering-Prozess beherrschbar ist, der beide Disziplinen von Anfang an integriert.
Verteidigung und Behörden: AQAP-Standards & Verschlusssachenfähigkeit
Software für Verteidigungsanwendungen und Behörden unterliegt einem eigenen Normen- und Sicherheitsrahmen, der sich grundlegend von zivilen regulierten Märkten unterscheidet. Die NATO-AQAP-Standards (AQAP 2110 für Entwicklung, AQAP 2210 für Software) verlangen vollständige Rückverfolgbarkeit aller Konfigurationsänderungen, qualifiziertes und nachgewiesenes Testpersonal sowie ein robustes Konfigurationsmanagement über den gesamten Produktlebenszyklus.
Für Projekte mit erhöhten Geheimhaltungsanforderungen ist die Fähigkeit zur Verarbeitung von Verschlusssachen bis VS-NfD eine Grundvoraussetzung. Wir entwickeln Software für Bundeswehr- und Behördenprojekte in einer entsprechend gesicherten Infrastruktur – mit Teams, die über die erforderlichen Freigaben verfügen.
Öffentlicher Sektor und kritische Infrastruktur: NIS2 und BSI-Grundschutz
Mit der NIS2-Richtlinie und dem IT-Sicherheitsgesetz 2.0 sind die Anforderungen an Software für kritische Infrastrukturen und den öffentlichen Sektor deutlich gestiegen. Betreiber kritischer Infrastrukturen müssen nachweisen, dass ihre Systeme dem aktuellen Stand der Technik entsprechen und ein wirksames Risikomanagement betreiben. Das BSI-Grundschutz-Kompendium und die technischen Richtlinien des BSI definieren konkrete Maßnahmen für Softwaresysteme in diesem Umfeld.
Im Bereich E-Government und OZG-Umsetzung sind wir als AVPQ-präqualifizierter Dienstleister tätig und kennen die spezifischen Anforderungen öffentlicher Auftraggeber an Dokumentation, Vergabeverfahren und langfristige Wartungsverpflichtungen.
Vertrauen über alle regulierten Märkte hinweg
Unsere Referenzprojekte und ausgewählten Kunden zeigen, wie wir innovative Ideen in erfolgreiche digitale Lösungen verwandeln – partnerschaftlich, praxisnah und branchenübergreifend.
Branchen-Expertise: Warum die Norm allein nicht reicht
Zwei Unternehmen entwickeln nach derselben Norm – und trotzdem verläuft das eine Audit reibungslos, während das andere mit einer Mängelliste endet. Der Unterschied liegt oft darin, was Prüfer in der jeweiligen Branche erwarten. In der Medizintechnik prägen MDR, IEC 62304 und ISO 14971 die Nachweisführung, im Maschinenbau IEC 61508 und IEC 62443, im Defense-Bereich AQAP 2110 und 2210 und im öffentlichen Sektor NIS2, BSI-Grundschutz und AVPQ. Diese Anforderungen beeinflussen Dokumentation, Architektur, Risikobewertung und Teststrategie – und damit konkrete Entwicklungsentscheidungen.
Ein Prinzip, das branchenübergreifend gilt
Bei aller Unterschiedlichkeit verbindet diese Branchen ein gemeinsames Prinzip: Nachweisbarkeit entscheidet über die Zulassung – nicht nur die Funktion selbst. Entscheidend ist deshalb nicht nur, Normen zu kennen, sondern ihre Anforderungen richtig in Architektur, Entwicklung, Tests und Dokumentation zu übersetzen. Genau hier kombinieren wir branchenspezifische Erfahrung mit einem durchgängigen Verständnis für Auditfähigkeit, Traceability und belastbare Entwicklungsprozesse. So entstehen Lösungen, die technisch überzeugen und gleichzeitig die Anforderungen von Prüfern, Zertifizierungsstellen und Auftraggebern erfüllen.
Nehmen Sie Kontakt zu uns auf!Wer die Prüfkriterien nicht kennt, zahlt zweimal
Software ist inzwischen die häufigste Ursache für Medizinprodukt-Rückrufe – mit einem Zuwachs von 31 Prozent allein im letzten erfassten Jahr. McKinsey beziffert die branchenweiten Kosten solcher Qualitätsvorfälle auf 2,5 bis 5 Milliarden Dollar jährlich. Das Muster zeigt sich branchenübergreifend: Laut Ponemon Institute kostet Non-Compliance im Schnitt 2,71-mal mehr als die Einhaltung der Vorschriften selbst – und im Maschinenbau kann ein ungeplanter Anlagenausfall mit 1.000 bis 11.000 Dollar pro Minute zu Buche schlagen. Wer die branchenspezifischen Prüfkriterien nicht kennt, zahlt diesen Preis nicht einmal, sondern strukturell immer wieder.
Quellen: MedDeviceGuide, „Medical Device Recall Trends 2024–2026“ (FDA Medical Device Recalls Database) · Ponemon Institute / Globalscape, „The True Cost of Compliance with Data Protection Regulations“ · McKinsey & Company, „Capturing the value of good quality in medical devices“ · Senseye (Siemens), „The True Cost of Downtime“
31 %
mehr Software-Rückrufe in der Medizintechnik
10 %
Kursverlust nach größerem Rückruf
2,71x
teurer bei Non- im Vgl. zu Compliance
1–11 k
$ pro Minute bei Anlagenausfall
Technologietransfer: Was regulierte Branchen voneinander lernen können

Andere Norm – dieselbe technische Herausforderung
Medizintechnik, Maschinenbau, Defense und Public Service folgen unterschiedlichen regulatorischen Rahmenbedingungen. Dennoch stellen sich oft dieselben Fragen: Wie werden Risiken beherrscht? Wie bleiben Änderungen nachvollziehbar? Wie wird Software sicher und langfristig wartbar entwickelt? Viele Engineering-Prinzipien lassen sich deshalb übertragen. Dieser Blick über Branchengrenzen verhindert, dass Lösungen neu erfunden werden, die sich anderswo bereits bewährt haben.
Safety-Denken schafft auch außerhalb von Safety-Projekten Qualität
Funktionale Sicherheit verlangt klare Anforderungen, kontrollierte Änderungen und belastbare Verifikation. Diese Prinzipien schaffen auch außerhalb klassischer SIL-Projekte spürbaren Mehrwert in komplexen Softwareprojekten. Umgekehrt profitieren Safety-Projekte zunehmend von modernen Methoden wie CI/CD, automatisierter Code-Analyse und Security by Design.
Cyber Security verbindet zunehmend alle Märkte
Vernetzung hebt Branchengrenzen zunehmend auf. Medizinprodukte, Maschinen und öffentliche Systeme sind heute eng mit verteilten Infrastrukturen verbunden. Dadurch werden Security, Software-Lieferketten und Schwachstellenmanagement zu gemeinsamen Architekturthemen. infoteam verbindet deshalb Erfahrung aus funktionaler Sicherheit, Informationssicherheit und Cyber Security mit etablierten Grundlagen nach ISO 27001, ISO 13485 und IEC 61508.
Der Mehrwert liegt im Transfer – nicht in der Kopie
Branchenübergreifende Erfahrung bedeutet nicht, Prozesse unverändert von einem Markt in den nächsten zu übertragen. Entscheidend ist, welche Prinzipien übertragbar sind und wo regulatorische Besonderheiten andere Lösungen erfordern. So lassen sich bewährte Architektur-, Safety-, Security- und Qualitätsmethoden gezielt nutzen, ohne branchenspezifische Anforderungen zu verwässern.

Kundenstimmen aus Engineering-Praxis seit 1983
Inhouse-IVD-Konformität nach IVDR
Unsere proprietäre Profiler-Software ist die Grundlage für das lifespin General Health Assessment zur Bewertung von Gesundheitszuständen, das als SaaS und in naher Zukunft auch über die lifespin Cloud angeboten wird. Als zuverlässiges und kompetentes Unternehmen mit viel Erfahrung in regulierter Softwareentwicklung ist infoteam der ideale Partner, um uns auf diesem Weg zu begleiten.
Dr. Michael Helou – Leitung Produktentwicklung, lifespin GmbH
FDA-Cybersecurity für Röntgengeräte
infoteam hat uns hervorragend und sehr professionell dabei unterstützt, die neuen Anforderungen der FDA an Cybersicherheit für die Zulassung unserer Medizinprodukte für den US-amerikanischen Markt zu erfüllen. Obwohl die Aufgabe herausfordernd und der Zeitplan knackig waren, haben wir es gemeinsam geschafft. Herzlichen Dank.
Christof Fleischmann – Director R&D Software, Ziehm Imaging GmbH
Softwareerweiterung für ein Kraftwerks-Diagnosesystem
In einem komplexen technischen Umfeld führten die agilen Methoden von infoteam zu einem überzeugenden Ergebnis und damit zu einem Erfolg der Aufgabe.
Dr. Stephan Schuh – Framatome Deutschland

Damit Branchenwissen im Projekt wirkt, muss es mehr liefern als Normenkenntnis.
Branchenerfahrung zahlt sich dann aus, wenn Ihre Software …
die Prüfkriterien Ihres Marktes erfüllt
die richtigen Nachweise von Anfang an erzeugt
von Erfahrungen aus anderen Branchen profitiert
Branchenerfahrung heißt: die Fragen des Auditors kennen, bevor sie gestellt werden.
Von der Branchenkenntnis zur Projektsicherheit: Risiken erkennen, Anforderungen richtig gewichten

Engineering-Risiken früh erkennen
Je früher technische und regulatorische Risiken sichtbar werden, desto gezielter lassen sie sich beherrschen. Deshalb lohnt sich eine frühe Bewertung von Architektur, Schnittstellen, Abhängigkeiten und Nachweisführung, bevor sich Schwachstellen tief im System verankern. Reviews, Assessments und technische Voranalysen schaffen Transparenz darüber, wo echte Risiken liegen – und wo nicht.
So lassen sich Fehlentwicklungen vermeiden, bevor sie hohe Folgekosten verursachen. Gleichzeitig wird früh klar, welche Maßnahmen für Qualität, Security, Safety und Auditfähigkeit tatsächlich notwendig sind. Das reduziert Nacharbeiten, verbessert die Planbarkeit und schafft eine belastbare Grundlage für technische Entscheidungen.
Software-Risiken früh erkennenBranchenspezifische Anforderungen richtig priorisieren
Nicht jede regulatorische Anforderung hat in jedem Projekt dieselbe Bedeutung. Entscheidend ist, welche Risiken, Nachweise und Prüfkriterien im jeweiligen Markt tatsächlich im Fokus stehen. In der Medizintechnik kann das Risikomanagement dominieren, im Maschinenbau funktionale Sicherheit, im Defense-Umfeld Konfigurationskontrolle und im Public Service Informationssicherheit und Vergabefähigkeit.
Diese Priorisierung beeinflusst Architektur, Tests, Dokumentation und Projektplanung unmittelbar. Wer die branchenspezifischen Schwerpunkte früh kennt, kann Aufwand gezielt dort investieren, wo er für Zulassung, Audit und Betrieb wirklich relevant ist – statt Prozesse unnötig aufzublähen.
Regulatorik in Engineering übersetzen
Vier Branchen, vier eigene Normenwelten
Ein Auditor in der Bahntechnik stellt andere Fragen als einer in der Medizintechnik – hier branchenweise im Detail.
1
Medizintechnik & Labortechnik
Wann ist Software selbst ein Medizinprodukt? Wie IEC 62304, ISO 14971 und die MDR-Klassifizierung konkret über den Zulassungsweg entscheiden.
2
Maschinenbau & Anlagentechnik
SIL-Ableitung nach IEC 61508 trifft auf IEC 62443: Warum funktionale Sicherheit und Cyber Security im Maschinenbau heute zusammen gedacht werden müssen.
3
Defense & Behörden
AQAP 2110 und 2210, Verschlusssachen und Sicherheitsüberprüfungen: Welche Nachweise Software für Verteidigung und Behörden zusätzlich zur Technik erbringen muss.
4
Öffentlicher Sektor & kritische Infrastruktur
NIS2, BSI-Grundschutz und AVPQ-Präqualifikation: Was Software für Behörden und KRITIS-Betreiber heute konkret nachweisen muss.
5
Welche Norm gilt für Sie?
In 4 Fragen zu Branche, Symptomen und Dringlichkeit erhalten Sie eine kostenfreie Diagnose mit konkreten nächsten Schritten – ohne Verpflichtung.
6
Ihre Branche fehlt hier?
Vier Branchen im Detail sind nur ein Ausschnitt unserer Praxis. Sprechen Sie mit uns über Ihre spezifische Normenwelt – unverbindlich und ohne Verkaufsdruck.
Branchenübergreifend: Was alle regulierten Märkte gemeinsam haben
1
Nachweisbarkeit statt Funktion
Dokumentation entscheidet über die Zulassung.
In regulierten Märkten genügt es nicht, dass Software zuverlässig funktioniert. Entscheidend ist der lückenlose Nachweis, wie sie entwickelt, getestet und dokumentiert wurde. Erst das Zusammenspiel aus Technik und Nachweis schafft die Grundlage für eine erfolgreiche Zulassung.
2
Auditfähigkeit als Qualitätsmerkmal
Risikomanagement muss nachvollziehbar sein.
Ein wirksames Risikomanagement endet nicht bei der Analyse. Risiken müssen konkreten Softwarekomponenten, Anforderungen und Testfällen eindeutig zugeordnet werden. Nur eine vollständige Rückverfolgbarkeit schafft Sicherheit und hält Audits zuverlässig stand.
Ideal für audit- und normkonforme Softwareentwicklung.
3
Branchenübergreifendes Engineering
Ein Prinzip und Grundsatz für alle regulierten Märkte.
Ob Medizintechnik, Maschinenbau, Bahn, Verteidigung oder öffentlicher Sektor – technische Exzellenz muss immer von nachweisbarer Prozessqualität begleitet werden. Dieses Prinzip bildet seit Jahrzehnten das Fundament unserer Engineering-Arbeit in regulierten Projekten.
Engineering mit Fokus auf Qualität und Nachweis.

Persönlicher Zugang statt Vertriebsfunnel – 60 Minuten Engineering-Sparring
Ihre Anforderungen aus IEC 62304, ISO 13485, IEC 61508 oder MDR sind Engineering-Aufgaben. Sprechen Sie deshalb direkt mit Daniel Blümel über Ihre konkrete Roadmap. Sie erhalten eine ehrliche Einschätzung, ob und wie wir Sie als Engineering-Partner unterstützen können.
Was Sie aus dem Gespräch mitnehmen:
Norm-spezifische Einschätzung Ihrer Roadmap (IEC 62304 / ISO 13485 / IEC 61508 / MDR)
2-3 konkrete Hebel, die Sie mit oder ohne uns nutzen können
Klare Empfehlung: passt infoteam – oder eher ein anderer Partner?
Softwareentwicklung für regulierte Märkte: Unsere Expertise im Überblick
Unsere Expertise verbindet regulatorische Sicherheit, technologische Exzellenz und langfristige Verlässlichkeit – entscheidende Faktoren für erfolgreiche Audits und anspruchsvolle Ausschreibungen.
100 % Mitarbeiter-Eigentum
Als vollständig mitarbeitergeführtes Unternehmen stehen wir für außergewöhnliche Kontinuität, minimale Fluktuation und langfristige Verantwortung – unabhängig von externen Investoren oder kurzfristigen Renditeinteressen.
Normative Souveränität:
ISO 13485 & IEC 61508
Wir entwickeln sicherheitskritische Software nach ISO 13485 und IEC 61508 und integrieren Functional Safety sowie Cyber Security in einen durchgängigen Engineering-Prozess. Entwickelt für regulierte und sicherheitskritische Märkte.
Interdisziplinärer
Technologietransfer
Durch den Transfer bewährter Engineering-Methoden zwischen MedTech, Industrial Applications, Transportation und Public Service reduzieren wir Entwicklungsrisiken und beschleunigen Innovationen in regulierten Märkten.
Häufige Fragen zu regulierter Softwareentwicklung und Branchen-Expertise
?
Warum ist Branchenkenntnis bei regulierter Softwareentwicklung so wichtig?
Regulierte Softwareentwicklung folgt je nach Markt unterschiedlichen Normen, Prüfstrukturen und Nachweismethoden. Entscheidend ist deshalb nicht nur, eine Norm zu kennen, sondern zu verstehen, wie ihre Anforderungen in Architektur, Entwicklung, Testing und Dokumentation umgesetzt werden müssen. Branchenerfahrung reduziert Fehlinterpretationen, Nacharbeiten und Risiken im Audit.
?
Für welche regulierten Branchen
entwickelt infoteam Software?
infoteam arbeitet unter anderem für Medizintechnik und Labortechnik, Maschinen- und Anlagenbau, Defense und Behörden sowie den öffentlichen Sektor. Je nach Branche stehen unterschiedliche Anforderungen an funktionale Sicherheit, Cyber Security, Risikomanagement, Traceability, Dokumentation und Zulassung im Mittelpunkt.
?
Welche Normen und regulatorischen
Anforderungen sind besonders relevant?
Je nach Markt spielen unter anderem IEC 62304, ISO 14971, IEC 61508, IEC 62443, AQAP 2110, AQAP 2210, NIS2 und BSI-Grundschutz eine wichtige Rolle. Entscheidend ist immer der konkrete regulatorische Kontext des Projekts und die Frage, welche Nachweise für Entwicklung, Freigabe oder Zulassung tatsächlich erforderlich sind.
?
Was unterscheidet regulierte Softwareentwicklung von klassischer Softwareentwicklung?
In regulierten Projekten muss Software nicht nur funktionieren. Es muss auch nachvollziehbar belegt werden, warum sie sicher, korrekt und regelkonform entwickelt wurde. Anforderungen, Risiken, Architekturentscheidungen, Änderungen und Testergebnisse müssen deshalb über den gesamten Lebenszyklus strukturiert dokumentiert und miteinander verknüpft werden.
?
Welche Rolle spielt Auditfähigkeit
in regulierten Projekten?
Auditfähigkeit bedeutet, dass Entwicklungsentscheidungen, Änderungen und Nachweise jederzeit nachvollziehbar sind. Dazu gehören klare Anforderungen, dokumentierte Architekturentscheidungen, Traceability, reproduzierbare Tests und kontrollierte Freigaben. Eine auditfähige Entwicklung entsteht nicht erst kurz vor der Prüfung, sondern muss im täglichen Engineering-Prozess verankert sein.
?
Wie lassen sich regulatorische
Projektrisiken frühzeitig reduzieren?
Risiken lassen sich besonders wirksam reduzieren, wenn Architektur, Schnittstellen, Anforderungen und Nachweisführung früh bewertet werden. Reviews, Assessments und technische Analysen schaffen Transparenz über Schwachstellen, bevor sie sich im System verfestigen. Dadurch können notwendige Maßnahmen gezielt priorisiert und spätere Nacharbeiten vermieden werden.
?
Können Erfahrungen aus einer regulierten Branche auf andere Märkte übertragen werden?
Ja, viele Engineering-Prinzipien sind branchenübergreifend nutzbar. Dazu gehören beispielsweise strukturierte Risikoanalyse, kontrollierte Änderungen, Traceability, automatisierte Tests, Safety-Methoden und Security by Design. Entscheidend ist jedoch, diese Prinzipien nicht einfach zu kopieren, sondern an die regulatorischen Besonderheiten des jeweiligen Marktes anzupassen.
?
Wann ist ein externer Engineering-Partner für regulierte Software sinnvoll?
Ein externer Partner ist besonders sinnvoll, wenn spezifische Normenkenntnis, zusätzliche Engineering-Kapazität oder Erfahrung mit Audits und Zulassungen benötigt wird. Das kann beim Projektstart, bei Architektur- oder Prozessfragen, vor einem Audit oder während einer Modernisierung relevant sein. Ziel ist dabei nicht, bestehende Teams zu ersetzen, sondern fehlende Erfahrung gezielt zu ergänzen.

Autorin: Elke Honrich – Director BU Siemens
Elke Honrich verbindet als Director BU Siemens tiefes Verständnis für industrielle Anforderungen mit langjähriger Erfahrung in anspruchsvollen Softwareprojekten. Ihr Fokus liegt auf der praxisnahen Übersetzung technischer und regulatorischer Anforderungen in belastbare Entwicklungsprozesse und zukunftsfähige Softwarelösungen. Dabei stehen Qualität, Nachvollziehbarkeit sowie die Verbindung von Technologie und Branchenwissen im Mittelpunkt. So entstehen Lösungen, die technisch überzeugen und den Anforderungen regulierter und industrieller Märkte gerecht werden.