Glossar rund um Softwareentwicklung
Fachbegriffe aus Safety, Security und regulierter Softwareentwicklung – kompakt erklärt.
Zentrale Fachbegriffe aus Safety & Security
Software-Engineering für regulierte und sicherheitskritische Märkte
Cross-Domain-Technologietransfer aus MedTech, Industry & Defense
Praxisbezug aus MedTech, Industry & Defense
100 % in Mitarbeiterhand
Glossar: Softwareentwicklung für regulierte Märkte
Regulierte Märkte – Medizintechnik, Pharma, Bahn, Automotive, Luftfahrt, Energie, öffentliche Auftraggeber – unterscheiden sich von der übrigen Softwareentwicklung nicht durch andere Technologie, sondern durch die Beweispflicht. Nicht das funktionierende Produkt zählt, sondern der dokumentierte Nachweis, dass es kontrolliert entstanden ist und seine Risiken beherrscht werden.
Dieses Glossar erklärt die Begriffe, die in Ausschreibungen, Audits und Zulassungsverfahren tatsächlich auftauchen – jeweils mit normativer Grundlage, praktischer Bedeutung im Projekt und den typischen Fehlern, die in Audits auffallen.
Hinweis zur Aktualität: Normen und Verordnungen werden fortlaufend überarbeitet, Übergangsfristen verschieben sich. Die genannten Ausgabestände und Fristen entsprechen dem Stand der Erstellung; für verbindliche Aussagen ist immer der aktuelle Rechts- bzw. Normenstand maßgeblich.
A
Anforderungsmanagement (Requirements Engineering)
Kurzdefinition: Die systematische Erhebung, Spezifikation, Freigabe, Verfolgung und Änderungskontrolle von Anforderungen über den gesamten Produktlebenszyklus.
In regulierten Projekten trägt Anforderungsmanagement die gesamte Nachweisführung: Jede Anforderung muss eindeutig, testbar, freigegeben und rückwärts wie vorwärts verfolgbar sein – zu Risiko, Architektur, Code und Testfall. Unterschieden werden Stakeholder-, System- und Softwareanforderungen sowie abgeleitete Risikokontrollmaßnahmen. Die häufigste Auditfeststellung ist der Bruch der Kette, nicht der Mangel an Anforderungen. Werkzeuggestützte Verfolgbarkeit ist ab mittlerer Projektgröße unverzichtbar.
Verwandte Einträge: Lastenheft und Pflichtenheft, Traceability, V-Modell, Verifikation
AQAP 2110
Kurzdefinition: NATO-Standard mit Qualitätssicherungsanforderungen an Lieferanten für Entwicklung, Herstellung und Prüfung wehrtechnischer Produkte.
AQAP 2110 baut auf ISO 9001 auf und ergänzt behördliche Qualitätssicherung, Konfigurationsmanagement, Risikomanagement und Zugangsrechte des Auftraggebers. Für Softwarelieferanten im Verteidigungsbereich ist die Zertifizierung meist faktische Voraussetzung für Vergabeverfahren und wird zusammen mit ISO 9001 auditiert. Der Aufwand bei bestehendem QMS ist überschaubar; deutlich aufwendiger ist die parallel nötige Geheimschutzbetreuung.
Verwandte Einträge: BAAINBw, Geheimschutzbetreuung, Konfigurationsmanagement
ALCOA+
Kurzdefinition: Akronym für die Kriterien, nach denen Aufsichtsbehörden die Integrität von Daten in GxP-regulierten Umgebungen bewerten.
ALCOA steht für Attributable, Legible, Contemporaneous, Original und Accurate; das „Plus“ ergänzt Complete, Consistent, Enduring und Available. Für die Softwareentwicklung ist das keine Dokumentationsfrage, sondern eine Architekturanforderung: Systeme, die Daten überschreiben statt versionieren oder technische Nutzerkonten ohne Personenzuordnung verwenden, verletzen die Kriterien im Datenmodell. Häufigste Audit-Befunde sind geteilte Logins und Audit Trails ohne Review-Prozess.
Verwandte Einträge: Audit Trail, Datenintegrität, FDA 21 CFR Part 11, GxP
ASPICE (Automotive SPICE)
Kurzdefinition: Prozessreferenz- und Bewertungsmodell für die Entwicklung softwarebasierter Systeme in der Automobilindustrie.
ASPICE bewertet Prozessreife auf Capability Levels von 0 bis 5; OEMs fordern von Zulieferern meist Level 2 oder 3 für den VDA-Scope entlang des V-Modells. Wichtig ist die Abgrenzung zu ISO 26262: ASPICE bewertet, ob ordentlich entwickelt wird, ISO 26262 fordert funktionale Sicherheit des Ergebnisses – beide ergänzen sich. Assessments scheitern meist an fehlender Konsistenz zwischen Artefakten, nicht an fehlenden Prozessen.
Verwandte Einträge: ISO 26262 und ASIL, Traceability, V-Modell
Audit Trail
Kurzdefinition: Fälschungssichere, chronologische Aufzeichnung aller sicherheits- oder qualitätsrelevanten Systemereignisse und Datenänderungen.
Ein belastbarer Audit Trail hält für jede Änderung fest: wer, wann, was vorher/nachher und warum. Er darf nicht deaktivier- oder löschbar sein und muss über die gesamte Aufbewahrungsfrist auswertbar bleiben (FDA Part 11, EU-GMP Annex 11). Anders als ein Betriebslog darf er nicht rotieren. Häufigster Mangel: Der Audit Trail existiert, wird aber nie im dokumentierten Review-Prozess gelesen.
Verwandte Einträge: ALCOA+, Datenintegrität, FDA 21 CFR Part 11
B
BAAINBw
Kurzdefinition: Bundesamt für Ausrüstung, Informationstechnik und Nutzung der Bundeswehr – zentrale Beschaffungsbehörde für Wehrmaterial und IT.
Das BAAINBw führt Vergabeverfahren nach dem Customer Product Management durch, mit langen Vorlaufzeiten und formalisierten Anforderungsdokumenten. Der Markteinstieg erfordert Registrierung in Vergabeplattformen, Qualitätsnachweise (ISO 9001, oft AQAP), Geheimschutzbetreuung und Lieferkettensicherheit. Der Defence-Markt ist kein kurzfristiger Umsatzkanal – bis zum ersten Auftrag vergehen oft Jahre; Unteraufträge mit Systemhäusern sind der übliche Einstieg.
Verwandte Einträge: AQAP 2110, Geheimschutzbetreuung und VS-NfD
Benannte Stelle (Notified Body)
Kurzdefinition: Von einer EU-Mitgliedstaatsbehörde benannte, unabhängige Konformitätsbewertungsstelle, die die Einhaltung EU-rechtlicher Produktanforderungen prüft.
Im Medizinproduktebereich prüft die Benannte Stelle Qualitätsmanagementsystem und technische Dokumentation; erst danach darf die CE-Kennzeichnung angebracht werden. Sie ist keine Behörde, sondern eine private Organisation unter staatlicher Aufsicht und berät nicht – Klassifizierung und Nachweisstrategie müssen Hersteller selbst klären. Seit der MDR sind Kapazitäten knapp; Wartezeiten von vielen Monaten sollten früh in die Projektplanung einfließen.
Verwandte Einträge: CE-Kennzeichnung, Konformitätsbewertung, MDR, Technische Dokumentation
BSI IT-Grundschutz
Kurzdefinition: Methodik und Bausteinkatalog des BSI zum Aufbau eines Informationssicherheitsmanagementsystems.
Der IT-Grundschutz umfasst die BSI-Standards 200-1 bis 200-4 und das Kompendium mit Bausteinen für Anwendungen, Systeme und Prozesse; er ist mit ISO/IEC 27001 kompatibel und wird von öffentlichen Auftraggebern oft als Mindeststandard gefordert, auch ohne Zertifizierungspflicht. Relevant für Softwareanbieter sind vor allem Bausteine zur sicheren Entwicklungsumgebung. Der Aufwand liegt weniger in der Technik als in Schutzbedarfsfeststellung und Risikoanalyse.
Verwandte Einträge: IEC 62443, NIS2, Qualitätsmanagementsystem
C
CE-Kennzeichnung
Kurzdefinition: Erklärung des Herstellers, dass ein Produkt allen anwendbaren EU-Rechtsvorschriften entspricht – kein Qualitätssiegel.
Die CE-Kennzeichnung ist das sichtbare Ergebnis einer erfolgreichen Konformitätsbewertung; der Hersteller erstellt eine EU-Konformitätserklärung und übernimmt die rechtliche Verantwortung. Bei höheren Risikoklassen ist eine Benannte Stelle vorgeschrieben. Für Software ist zentral, ob sie ein eigenständiges Produkt ist: Software mit medizinischer Zweckbestimmung wird selbst CE-gekennzeichnet. Häufig übersehen wird die Kumulation mehrerer Rechtsakte bei vernetzten Geräten.
Verwandte Einträge: Benannte Stelle, Konformitätsbewertung, Cyber Resilience Act, MDR
Change Control
Kurzdefinition: Formalisierter Prozess zur Bewertung, Genehmigung, Umsetzung und Dokumentation von Änderungen an einem freigegebenen System.
Anders als gewöhnliches Change Management verlangt Change Control eine verpflichtende Vorabbewertung der Auswirkung auf Sicherheit, Wirksamkeit und Validierungsstatus. Zentral ist die Rückwirkungsanalyse, die nur so gut ist wie die zugrunde liegende Traceability – fehlt diese, bleibt nur der teure vollständige Regressionstest. Auch nach Markteinführung bindend: Wesentliche Änderungen können eine erneute Konformitätsbewertung auslösen.
Verwandte Einträge: Konfigurationsmanagement, Regressionstest, Traceability
Code Coverage
Kurzdefinition: Maß dafür, welcher Anteil des Quellcodes durch die ausgeführten Tests tatsächlich durchlaufen wurde.
Gebräuchliche Stufen sind Statement-, Branch/Decision- und MC/DC-Coverage, wobei Normen die Anforderung nach Kritikalität staffeln (DO-178C: MC/DC ab DAL A). Code Coverage ist notwendig, aber nicht hinreichend – sie beweist nur, dass Code ausgeführt wurde, nicht dass er richtig ist. Anforderungsabdeckung bleibt die wichtigere Kennzahl; nicht abgedeckter Code ist entweder untestet oder tot und muss erklärt werden.
Verwandte Einträge: DO-178C, MC/DC, Regressionstest, Verifikation
Computer System Validation (CSV) und Computer Software Assurance (CSA)
Kurzdefinition: CSV ist der dokumentierte Nachweis, dass ein computergestütztes System im GxP-Umfeld seinen Zweck erfüllt; CSA der neuere, risikobasierte Ansatz.
Klassische CSV folgt dem Muster URS – Spezifikation – IQ/OQ/PQ – Validierungsbericht und erzeugt oft risikounabhängig hohe Dokumentationslast. CSA setzt auf kritisches Denken: Aufwand dorthin, wo Patientensicherheit berührt ist, sowie stärkere Nutzung von Lieferanten- und Testautomatisierung. Praktisch bedeutet das nicht weniger Verantwortung, sondern andere Verteilung – ohne begründete Risikobewertung ist reduzierter Umfang im Audit nicht verteidigbar.
Verwandte Einträge: GAMP 5, GxP, IQ/OQ/PQ, Validierung
Cyber Resilience Act (CRA)
Kurzdefinition: EU-Verordnung mit horizontalen Cybersicherheitsanforderungen an nahezu alle Produkte mit digitalen Elementen in der EU.
Der CRA verpflichtet Hersteller zu Security-by-Design, einer Software-Stückliste, Schwachstellenmanagement über den Support-Zeitraum sowie Meldepflichten bei aktiv ausgenutzten Schwachstellen. Die Anforderungen werden über die CE-Kennzeichnung durchgesetzt und gestaffelt wirksam. Für Softwarehäuser wird Sicherheit damit zur Marktzugangsvoraussetzung – besonders die Pflicht zur Schwachstellenbehebung erzwingt belastbares Patch-Management auch für Altprodukte.
Verwandte Einträge: CE-Kennzeichnung, NIS2, SBOM, IEC 62443
D
Datenintegrität
Kurzdefinition: Der Zustand, in dem Daten über ihren gesamten Lebenszyklus vollständig, konsistent, richtig und nachvollziehbar bleiben.
Datenintegrität ist der Oberbegriff, ALCOA+ das Bewertungsraster; Behörden betrachten den gesamten Lebenszyklus von Erzeugung bis Vernichtung. Für die Architektur folgen daraus unveränderliche Erstaufzeichnungen, personenbezogene Authentifizierung und geschützte Systemzeit. Häufigste reale Verstöße: Auswertungen außerhalb des validierten Systems und fehlende Backup-Restore-Tests – Behörden verfolgen solche Mängel besonders konsequent.
Verwandte Einträge: ALCOA+, Audit Trail, FDA 21 CFR Part 11, GxP
Design History File (DHF)
Kurzdefinition: Nach US-Regulierung die Zusammenstellung aller Aufzeichnungen, die den Entwicklungsverlauf eines Medizinprodukts belegen.
Der DHF dokumentiert gemäß FDA-Design-Controls, dass die Entwicklung dem geplanten Designplan folgte: Inputs, Outputs, Reviews, Verifikation, Validierung, Transfer und Änderungen – kein einzelnes Dokument, sondern ein Verweisverbund. Im europäischen Kontext übernimmt die technische Dokumentation eine vergleichbare Funktion. Bewährt hat sich, den DHF laufend als Index zu pflegen statt am Projektende zu rekonstruieren.
Verwandte Einträge: ISO 13485, Technische Dokumentation, Traceability, Validierung
DO-178C
Kurzdefinition: Der maßgebliche Leitfaden für die Zulassung von Software in der zivilen Luftfahrt.
DO-178C definiert Ziele je nach Design Assurance Level (DAL A bis E), gestaffelt nach Schwere möglicher Ausfallfolgen; MC/DC-Abdeckung ist etwa nur für DAL A gefordert. Ergänzt wird die Norm durch Supplements wie DO-330 (Werkzeugqualifizierung). Sie ist zielorientiert statt verfahrensvorschreibend – dominierender Kostenfaktor ist die Verifikation, mit mehreren Verifikationsstunden je Implementierungsstunde bei hohen DAL-Stufen.
Verwandte Einträge: Code Coverage, MC/DC, Werkzeugqualifizierung
E
EN 50716
Kurzdefinition: Europäische Normen für sicherheitsrelevante Software in Bahnanwendungen – Signaltechnik bzw. Schienenfahrzeuge.
EN 50716 ersetzt die EN 50128:2011 und EN 50657:2017 und beschreibt Anforderungen für Entwicklung, Bereitstellung und Wartung von Software für Bahnanwendungen (Anwendungen der Zugsteuerung, Zugsicherung und Signalgebung (control, command and signalling) sowie Anwendungen auf Bahnfahrzeugen).
Die Anforderungen steigen mit dem Safety Integrity Level (SIL 0–4) und schreiben ab SIL 3 eine personelle Rollentrennung von Verifizierer, Validierer und unabhängigem Assessor vor. Diese geforderte Rollentrennung ist planerisch anspruchsvoll und macht kleine Teams für SIL-3/4-Projekte praktisch ungeeignet.
Verwandte Einträge: IEC 61508, SIL, Validierung, Verifikation
EU AI Act
Kurzdefinition: EU-Verordnung zur Regulierung von KI-Systemen nach einem risikobasierten Ansatz.
Die Verordnung unterscheidet verbotene Praktiken, Hochrisiko-Systeme, Systeme mit Transparenzpflichten und minimales Risiko. KI als Sicherheitsbauteil eines bereits konformitätsbewertungspflichtigen Produkts – etwa Medizinprodukte – gilt meist als Hochrisiko und wird in die bestehende Konformitätsbewertung integriert. Für die Praxis bedeutet das: Trainingsdaten, Modellversionen und Evaluationsergebnisse unterliegen denselben Nachweispflichten wie klassischer Code.
Verwandte Einträge: MDR, Risikomanagement, Technische Dokumentation
F
FDA 21 CFR Part 11
Kurzdefinition: US-Vorschrift, unter welchen Bedingungen elektronische Aufzeichnungen und Unterschriften den papiergebundenen gleichgestellt sind.
Part 11 fordert für geschlossene Systeme Validierung, personenbezogene Zugriffskontrolle, zeitgestempelte Audit Trails und besondere Anforderungen an elektronische Unterschriften. Konform ist immer der Betreiber mit seinem validierten System, nicht die Software selbst – diese kann nur „Part-11-fähig“ sein. Für Entwickler bedeutet das: keine geteilten Konten, keine löschbaren Audit Trails, kein Export ohne Metadaten.
Verwandte Einträge: ALCOA+, Audit Trail, Datenintegrität, GxP, Validierung
FMEA und FMEDA
Kurzdefinition: Systematische Verfahren zur Analyse möglicher Fehlerarten und ihrer Auswirkungen – FMEA qualitativ, FMEDA zusätzlich quantitativ.
Die FMEA untersucht bottom-up mögliche Fehlerarten, ihre Auswirkungen und Entdeckung, bewertet über Auftretens-, Bedeutungs- und Entdeckungswahrscheinlichkeit. Die FMEDA erweitert dies um quantitative Ausfallraten und Diagnoseabdeckung, wie sie IEC 61508 und ISO 26262 für SIL/ASIL-Nachweise fordern. Für reine Software ist die FMEA nur eingeschränkt geeignet; ergänzend werden Software-FMEA oder Fehlerbaumanalyse eingesetzt.
Verwandte Einträge: IEC 61508, ISO 14971, Risikomanagement, SIL
G
GAMP 5
Kurzdefinition: Branchenleitfaden der ISPE für einen risikobasierten Ansatz bei der Validierung computergestützter Systeme in der Pharmaindustrie.
GAMP 5 ist kein Gesetz, sondern De-facto-Standard: Kern ist die Kategorisierung von Software und die daraus abgeleitete Abstufung des Validierungsaufwands – je individueller die Software, desto mehr eigener Nachweis. Die zweite Ausgabe stärkt den Bezug zu agilen Methoden und kritischem Denken. Für Anbieter ist die eigene Entwicklungsdokumentation ein Verkaufsargument, das den Validierungsaufwand beim Kunden reduziert.
Verwandte Einträge: Computer System Validation, GxP, IQ/OQ/PQ, Validierung
Geheimschutzbetreuung und VS-NfD
Kurzdefinition: Behördlich überwachtes Verfahren, das Unternehmen zur Bearbeitung staatlicher Verschlusssachen berechtigt; VS-NfD ist die niedrigste Geheimhaltungsstufe.
Die Einstufungen reichen von VS-NfD bis STRENG GEHEIM; ab VS-VERTRAULICH ist eine formelle Geheimschutzbetreuung mit Sicherheitsüberprüfungen und eigenem Sicherheitsbevollmächtigten nötig. Der Aufwand wird oft unterschätzt: Überprüfungen dauern Monate, IT muss physisch getrennt betrieben werden, Cloud-Nutzung ist stark eingeschränkt. Für Softwarehäuser ist Geheimschutz eine strategische Investition, keine projektbezogene Formalie.
Verwandte Einträge: AQAP 2110, BAAINBw, BSI IT-Grundschutz
GxP
Kurzdefinition: Sammelbegriff für die „Good Practice“-Regelwerke im Lebenswissenschaftsbereich – u.a. GMP, GLP, GCP und GDP.
GxP-Regelwerke sind rechtlich verbindlich und werden behördlich inspiziert. Jedes System, das GxP-relevante Daten erzeugt oder verarbeitet, unterliegt Validierungs- und Aufbewahrungspflichten – entschieden wird das durch den Verwendungszweck, nicht die Technik. Wichtig ist die Abgrenzung zur Medizinprodukteregulierung: GxP betrifft Prozesse und Betreiber, MDR und IEC 62304 betreffen Produkte.
Verwandte Einträge: ALCOA+, Computer System Validation, GAMP 5, FDA 21 CFR Part 11
H
Hazard Analysis (Gefährdungsanalyse)
Kurzdefinition: Systematische Ermittlung aller Gefährdungen, die von einem Produkt ausgehen können, als Ausgangspunkt jedes Risikomanagements nach ISO 14971 oder IEC 61508.
Die Gefährdungsanalyse steht am Anfang der Sicherheitsbetrachtung: Bevor Risiken bewertet oder Maßnahmen abgeleitet werden, muss vollständig erfasst sein, was überhaupt schiefgehen kann – von der falschen Dosisanzeige bis zum unerwarteten Motorstart. Typische Methoden sind Preliminary Hazard Analysis (PHA), HAZOP und die Auswertung von Vorfalldatenbanken wie MAUDE. Für Software gilt die Besonderheit, dass Fehler nicht zufällig, sondern systematisch auftreten; deshalb betrachtet die Analyse nicht Ausfallraten, sondern Fehlerursachen und Nutzungsszenarien. Praktisch bewährt: Gefährdungen unabhängig von der geplanten Architektur formulieren, sonst werden Risiken übersehen, die außerhalb des eigenen Systems entstehen.
Verwandte Einträge: FMEA und FMEDA, IEC 61508, ISO 14971, Risikomanagement
I
IEC 61508
Kurzdefinition: Grundnorm der funktionalen Sicherheit für elektrische, elektronische und programmierbare elektronische Systeme.
IEC 61508 definiert einen Sicherheitslebenszyklus von der Gefährdungsanalyse bis zur Außerbetriebnahme; zentrale Größe ist der Safety Integrity Level (SIL 1–4). Aus ihr abgeleitet sind u.a. ISO 26262 und IEC 62061. Für Software ist die systematische Fähigkeit entscheidend: Sicherheit wird über Prozessstrenge, Architektur und Verifikationstiefe nachgewiesen, nicht über Ausfallratenberechnung.
Verwandte Einträge: FMEA und FMEDA, ISO 26262 und ASIL, SIL
IEC 62304
Kurzdefinition: Internationale Norm für die Lebenszyklusprozesse von Medizinprodukte-Software.
Die Norm gliedert Software nach Sicherheitsklassen A bis C je nach möglicher Verletzungsschwere; seit 2015 dürfen Softwareelemente bei wirksamer Trennung differenziert klassifiziert werden. Gefordert werden Planung, Anforderungsanalyse, Architektur, Implementierung, Test und begleitende Prozesse wie Konfigurationsmanagement. Konsequente Isolierung sicherheitskritischer Funktionen spart erheblichen Nachweisaufwand.
Verwandte Einträge: ISO 13485, ISO 14971, MDR, SOUP, Traceability
IEC 62366-1 (Usability Engineering)
Kurzdefinition: Norm für die Anwendung des Usability Engineering auf Medizinprodukte zur systematischen Beherrschung von Anwendungsfehlern als Risikoquelle.
Anders als gestalterische Usability geht es um Sicherheit, nicht Zufriedenheit. Der Prozess umfasst Spezifikation der Anwendung, Identifikation gefährdungsbezogener Szenarien, Gestaltung der Benutzungsschnittstelle sowie formative und summative Evaluationen. Ein in der summativen Evaluation gefundener Bedienfehler zwingt zur Wiederholung von Verifikation und Validierung – der Aufwand wird oft unterschätzt.
Verwandte Einträge: IEC 62304, ISO 14971, MDR, Validierung
IEC 62443
Kurzdefinition: Normenreihe für die Cybersicherheit industrieller Automatisierungs- und Steuerungssysteme.
Die vierteilige Reihe adressiert Betreiber, Integratoren und Hersteller; besonders relevant sind IEC 62443-4-1 (sicherer Entwicklungsprozess) und -4-2 (Komponentenanforderungen), gestaffelt nach Security Levels (SL 1–4). Kennzeichnend ist das Konzept von Zonen und Conduits zur Segmentierung in Sicherheitszonen. Zertifizierungen werden von Industriekunden zunehmend wie früher ISO 9001 abgefragt und gewinnen mit dem Cyber Resilience Act zusätzlich an Bedeutung.
Verwandte Einträge: BSI IT-Grundschutz, Cyber Resilience Act, NIS2, SBOM
IQ/OQ/PQ
Kurzdefinition: Die klassischen drei Qualifizierungsstufen bei der Validierung computergestützter Systeme: Installations-, Funktions- und Leistungsqualifizierung.
Die IQ belegt, dass das System spezifikationsgemäß in der Zielumgebung installiert ist; die OQ weist spezifikationsgemäße Funktion über den Betriebsbereich nach; die PQ zeigt zuverlässigen Betrieb mit realen Anwendern und Daten. Ergänzt wird die Kette oft um Design Qualification und User Requirements Specification. Unter dem CSA-Ansatz verliert die starre Dreiteilung an Bedeutung, bleibt aber weit verbreitet.
Verwandte Einträge: Computer System Validation, GAMP 5, Validierung, Verifikation
ISO 13485
Kurzdefinition: Internationale Norm für Qualitätsmanagementsysteme bei Herstellern und Zulieferern von Medizinprodukten.
ISO 13485 basiert auf ISO 9001, verschiebt den Schwerpunkt aber auf Risikobeherrschung, Rückverfolgbarkeit und regulatorische Konformität; sie ist Grundlage der Konformitätsbewertung nach MDR. Zentrale Kapitel sind Entwicklungslenkung, Aufzeichnungslenkung und Fehlerbehandlung. ISO 13485 und IEC 62304 sind keine Alternativen, sondern ergänzen sich – ohne tragfähiges QMS bleibt IEC 62304 eine Projektinsel.
Verwandte Einträge: Design History File, IEC 62304, MDR, Qualitätsmanagementsystem
ISO 13849 und Performance Level
Kurzdefinition: Norm zur Sicherheit sicherheitsbezogener Teile von Maschinensteuerungen, mit dem Performance Level (PL a–e) als Maß der Risikominderung.
Der erforderliche PL wird über einen Risikographen bestimmt, der erreichte Level aus Architekturkategorie, Ausfallzeit und Diagnosedeckungsgrad. Für Software enthält die Norm Anforderungen an sicherheitsbezogene Anwendungssoftware, deutlich weniger detailliert als IEC 61508-3. Die neue EU-Maschinenverordnung adressiert zusätzlich Software-Updates und Cybersicherheit.
ISO 14971
Kurzdefinition: Internationale Norm für die Anwendung des Risikomanagements auf Medizinprodukte – methodischer Kern jeder Medizinprodukteentwicklung.
Die Norm beschreibt einen geschlossenen Prozess von Risikomanagementplan über Gefährdungsidentifikation bis Restrisikobewertung; die Reihenfolge der Beherrschungsmaßnahmen ist verbindlich: zuerst sichere Konstruktion, dann Schutzmaßnahmen, zuletzt Sicherheitsinformationen. Für Software ist sie Ursprung fast aller sicherheitsbezogenen Anforderungen: Jede Risikokontrollmaßnahme wird zur verifizierbaren Softwareanforderung.
Verwandte Einträge: FMEA und FMEDA, IEC 62304, MDR, Risikomanagement
ISO 26262 und ASIL
Kurzdefinition: Norm für die funktionale Sicherheit elektrischer und elektronischer Systeme in Straßenfahrzeugen; ASIL die daraus abgeleitete Anforderungsstufe.
Der ASIL wird aus Schwere, Auftretenswahrscheinlichkeit und Beherrschbarkeit bestimmt und reicht von QM bis ASIL D. Teil 6 regelt die Softwareentwicklung mit gestaffelten Anforderungen an Architektur und Verifikation. Charakteristisch sind ASIL-Dekomposition und Freedom from Interference, meist über Speicher- und Zeitpartitionierung nachgewiesen. Ergänzend regeln ISO 21448 (SOTIF) und ISO/SAE 21434 weitere Risiken.
IVDR
Kurzdefinition: EU-Verordnung über In-vitro-Diagnostika – das Gegenstück zur MDR für Labordiagnostik.
Die IVDR ersetzt die frühere Richtlinie und führt ein regelbasiertes Klassensystem (A–D) ein, wodurch der Anteil Benannte-Stelle-pflichtiger Produkte drastisch gestiegen ist. Relevant für Software, die diagnostische Ergebnisse erzeugt, auswertet oder interpretiert; die technischen Anforderungen entsprechen weitgehend der MDR. Wegen Kapazitätsengpässen bei Benannten Stellen wurden Übergangsfristen mehrfach verlängert.
Verwandte Einträge: Benannte Stelle, IEC 62304, MDR, Software as a Medical Device
J
Jitter (zeitliche Schwankung)
Kurzdefinition: Die Abweichung zwischen dem geplanten und dem tatsächlichen Zeitpunkt eines periodischen Ereignisses, etwa eines Regelzyklus oder einer Sensorabtastung.
In sicherheitsgerichteten Echtzeitsystemen zählt nicht nur, dass eine Berechnung korrekt ist, sondern auch, dass sie rechtzeitig und gleichmäßig erfolgt. Jitter entsteht durch Interrupts, Cache-Effekte, Scheduling oder Garbage Collection und kann Regelkreise instabil machen oder Messwerte verfälschen. Normen wie IEC 61508 und ISO 26262 verlangen deshalb, dass das zeitliche Verhalten spezifiziert, analysiert und nachgewiesen wird – meist über Worst-Case-Execution-Time-Analysen und Messungen unter Last. Praktisch bewährt: zeitkritische Pfade auf einen dedizierten Kern oder einen Echtzeit-Task mit fester Priorität legen und den Jitter im Systemtest als eigene Anforderung mit Toleranzgrenze prüfen.
Verwandte Einträge: IEC 61508, ISO 26262 und ASIL, Verifikation
K
Konfigurationsmanagement
Kurzdefinition: Die eindeutige Identifikation, Versionierung, Freigabe und Nachverfolgung aller Bestandteile eines Systems über dessen Lebenszyklus.
Konfigurationsmanagement beantwortet die Auditfrage, aus welchen exakten Bestandteilen eine ausgelieferte Version besteht und wie sie erzeugt wurde – inklusive Fremdkomponenten, Build-Skripten und Werkzeugversionen. Alle einschlägigen Normen fordern es explizit. Der häufigste Mangel ist der nicht reproduzierbare Build nach Jahren; containerisierte, vollständig versionierte Build-Umgebungen sind regulatorische Vorsorge, keine Kür.
Verwandte Einträge: Change Control, SBOM, SOUP, Werkzeugqualifizierung
Konformitätsbewertung
Kurzdefinition: Das formale Verfahren, mit dem nachgewiesen wird, dass ein Produkt die anwendbaren rechtlichen Anforderungen erfüllt.
Je nach Risikoklasse reichen die Verfahren von der Herstellererklärung bis zur Prüfung durch eine Benannte Stelle; die MDR beschreibt die Wege in ihren Anhängen. Für Software entscheidet die Zweckbestimmung über die Klassifizierung – Regel 11 führt oft zu Klasse IIa oder höher. Praktisch bewährt: die Zweckbestimmung so eng wie möglich formulieren, da eine weite Marketingformulierung die Klassifizierung unnötig nach oben treiben kann.
Verwandte Einträge: Benannte Stelle, CE-Kennzeichnung, MDR, Technische Dokumentation
L
Lastenheft und Pflichtenheft
Kurzdefinition: Das Lastenheft beschreibt die Anforderungen des Auftraggebers, das Pflichtenheft die vom Auftragnehmer abgeleitete Realisierungslösung.
Die Unterscheidung aus VDI/VDE 3694 ist vertraglich fest verankert: Lastenheft als Aufgabenstellung, Pflichtenheft als verbindliche Antwort. International entsprechen sie etwa User Requirements Specification und Functional/Design Specification. Beide sind Ausgangspunkt der Verfolgbarkeitskette; die häufigste Schwäche sind nicht prüfbare Anforderungen wie „benutzerfreundlich“ im Lastenheft.
Verwandte Einträge: Anforderungsmanagement, Traceability, Validierung, Verifikation
Legacy-Software
Kurzdefinition: Bestehende Software, die weiter betrieben oder übernommen wird, ohne nach heute geltenden Anforderungen entwickelt worden zu sein.
IEC 62304 erlaubt statt vollständiger nachträglicher Dokumentation einen risikobasierten Nachweis aus Feldbewährung, vorhandener Dokumentation und gezielter Lückenschließung; Vergleichbares kennen ISO 26262 (Proven in Use). Kern ist eine Gap-Analyse: Welche Nachweise fehlen und sind angesichts des Risikos wirklich nötig? Ertüchtigung ist selten günstiger als Neuentwicklung, nur risikoärmer.
Verwandte Einträge: IEC 62304, SOUP, Traceability, Werkzeugqualifizierung
M
MC/DC (Modified Condition/Decision Coverage)
Kurzdefinition: Strengstes gebräuchliches Überdeckungsmaß, bei dem jede Teilbedingung einer Entscheidung nachweislich unabhängig das Ergebnis beeinflusst.
MC/DC verlangt Testfälle, in denen jede Bedingung isoliert den Ausgang umschlägt, während andere unverändert bleiben – der Aufwand wächst linear statt exponentiell mit der Bedingungsanzahl. Gefordert vor allem in der Luftfahrt für DAL A nach DO-178C, empfohlen für ASIL D nach ISO 26262. Nebeneffekt: Wer MC/DC nachweisen muss, schreibt zwangsläufig flachere, wartbarere Bedingungslogik.
Verwandte Einträge: Code Coverage, DO-178C, ISO 26262 und ASIL, Verifikation
MDR (Medizinprodukteverordnung)
Kurzdefinition: Verordnung (EU) 2017/745 – der maßgebliche Rechtsrahmen für das Inverkehrbringen von Medizinprodukten in der EU.
Die MDR verschärft gegenüber der Vorgängerrichtlinie Klassifizierungsregeln, klinische Bewertung, Post-Market-Surveillance und technische Dokumentation. Für Software ist Regel 11 zentral: Software für diagnostische oder therapeutische Entscheidungen fällt mindestens in Klasse IIa, bei möglichem Tod in Klasse III – fast jede klinisch relevante Software benötigt daher eine Benannte Stelle. Ergänzend sind die MDCG-Leitfäden zu beachten.
Verwandte Einträge: Benannte Stelle, IEC 62304, IVDR, Konformitätsbewertung, Post-Market Surveillance
MISRA C
Kurzdefinition: Regelwerk für die sichere Verwendung der Programmiersprache C in sicherheitskritischen eingebetteten Systemen.
MISRA C schränkt den Sprachumfang ein, um undefiniertes oder schwer analysierbares Verhalten zu vermeiden, etwa bei Zeigerarithmetik oder dynamischer Speicherverwaltung. Abweichungen sind über einen formalen Deviation Process zulässig. In der Praxis ist vollständige Konformität kaum erreichbar; auditrelevant ist nicht die Zahl der Verstöße, sondern ob jede Abweichung begründet, genehmigt und nachverfolgt wurde.
Verwandte Einträge: ISO 26262 und ASIL, Statische Codeanalyse, IEC 61508
N
NIS2
Kurzdefinition: EU-Richtlinie zur Erhöhung des Cybersicherheitsniveaus, die Betreiber wesentlicher und wichtiger Einrichtungen zu Risikomanagement und Meldepflichten verpflichtet.
NIS2 erweitert den Anwendungsbereich erheblich und fordert Risikoanalyse, Vorfallbewältigung, Lieferkettensicherheit und persönliche Verantwortung der Leitungsebene, mit kurzen mehrstufigen Meldefristen. Als Richtlinie wirkt sie über nationale Umsetzungsgesetze. Für Softwareanbieter ist die Lieferkettenanforderung der wirksamste Hebel: Auch nicht direkt betroffene Zulieferer werden vertraglich von Kunden zur Einhaltung verpflichtet.
Verwandte Einträge: BSI IT-Grundschutz, Cyber Resilience Act, IEC 62443, SBOM
O
OTA-Update (Over-the-Air)
Kurzdefinition: Die Verteilung von Software- oder Firmware-Aktualisierungen über eine Netzwerkverbindung, ohne physischen Zugriff auf das Gerät.
OTA-Updates sind in regulierten Märkten Chance und Pflicht zugleich: Der Cyber Resilience Act verlangt, dass Schwachstellen über den gesamten Supportzeitraum behoben werden, und die MDR fordert dokumentierte Software-Änderungen inklusive Bewertung, ob eine erneute Konformitätsbewertung nötig ist. Technisch muss der Update-Mechanismus selbst sicher sein – signierte Pakete, verschlüsselte Übertragung, Rollback bei Fehlschlag und Schutz gegen das Einspielen alter, verwundbarer Versionen. Praktisch bewährt: den Update-Prozess als eigenständige Sicherheitsfunktion mit Threat Modeling behandeln und die Versionsstände aller Feldgeräte zentral nachverfolgen, damit eine SBOM-Abfrage jederzeit beantwortbar ist.
Verwandte Einträge: Change Control, Cyber Resilience Act, Post-Market Surveillance, SBOM
P
Post-Market Surveillance (PMS)
Kurzdefinition: Die systematische, proaktive Sammlung und Auswertung von Erfahrungen mit einem Produkt nach dem Inverkehrbringen.
Die MDR macht PMS zu einer planungspflichtigen Aufgabe mit PMS-Plan, -Bericht, Vigilanz und Sicherheitskorrekturmaßnahmen; Erkenntnisse fließen verbindlich in Risikomanagement und technische Dokumentation zurück. Für Software braucht es mehr als ein Fehlermeldesystem: auswertbare Nutzungsdaten, Sicherheitskategorisierung und einen definierten Update-Prozess, der auch Cybersicherheitsschwachstellen einbezieht.
Verwandte Einträge: Change Control, MDR, Risikomanagement, Technische Dokumentation
Q
Qualitätsmanagementsystem (QMS)
Kurzdefinition: Die dokumentierte Gesamtheit aus Organisationsstruktur, Verantwortlichkeiten, Prozessen und Ressourcen zur Sicherstellung der Qualitätsanforderungen.
In regulierten Märkten ist ein QMS rechtliche Voraussetzung, meist nachgewiesen über ISO 13485, und umfasst Dokumentenlenkung, Entwicklungslenkung, Lieferantenbewertung und Fehlerbehandlung. Entscheidend ist die Passung: Ein aus dem Anlagenbau übernommenes QMS erdrückt agile Entwicklung mit unnötigen Freigabeschleifen. Bewährt hat sich ein schlanker verbindlicher Kern mit projektspezifischen Plänen darunter.
Verwandte Einträge: ISO 13485, Konfigurationsmanagement, Regulierte Märkte
R
Regressionstest
Kurzdefinition: Die Wiederholung bereits erfolgreich durchgeführter Tests nach einer Änderung, um unveränderte Korrektheit nachzuweisen.
Der Umfang wird aus der Rückwirkungsanalyse abgeleitet und begründet dokumentiert. Ohne Testautomatisierung wächst der Änderungsaufwand mit der Produktreife so stark, dass Wartung teurer als Neuentwicklung wird – ein Grund, warum regulierte Altprodukte oft funktional einfrieren. Automatisierte Tests, deren Ergebnis als Nachweis dient, können zudem eine Werkzeugqualifizierung erforderlich machen.
Verwandte Einträge: Change Control, Code Coverage, Verifikation, Werkzeugqualifizierung
Regulierte Märkte
Kurzdefinition: Märkte, in denen der Marktzugang von Produkten an die nachweisbare Erfüllung staatlich gesetzter Anforderungen gebunden ist.
Typische Beispiele sind Medizintechnik, Luft- und Raumfahrt, Bahn, Automobil und der öffentliche Sektor; über die Zulässigkeit entscheidet eine Behörde, Benannte Stelle oder ein Auftraggeber, nicht der Markt allein. Der Dokumentationsanteil am Gesamtaufwand liegt je nach Kritikalität zwischen dreißig und sechzig Prozent. Entscheidend: Fehler in der Nachweisstruktur werden erst im teuersten Moment – im Audit – sichtbar.
Verwandte Einträge: Konformitätsbewertung, Qualitätsmanagementsystem, Traceability, V-Modell
Risikomanagement
Kurzdefinition: Der fortlaufende Prozess der Identifikation, Analyse, Bewertung, Beherrschung und Überwachung von Risiken über den gesamten Produktlebenszyklus.
Branchenübergreifend folgt Risikomanagement demselben Muster, unterscheidet sich aber im Schutzgut – Patienten bei ISO 14971, Verkehrsteilnehmer bei ISO 26262, Systeme bei IEC 62443. Für Software gilt: Risiken erzeugen Maßnahmen, Maßnahmen werden zu verifizierten Anforderungen. Ohne diese Kette bleibt die Risikoanalyse wirkungslos. Safety und Security sind heute nicht mehr trennbar zu betrachten.
Verwandte Einträge: FMEA und FMEDA, ISO 14971, IEC 62443, Post-Market Surveillance
S
SBOM (Software Bill of Materials)
Kurzdefinition: Maschinenlesbares Verzeichnis aller in einem Softwareprodukt enthaltenen Komponenten einschließlich Versionen und Abhängigkeiten.
Etablierte Formate sind SPDX und CycloneDX; eine SBOM beantwortet, ob eine neu bekannte Schwachstelle in ausgelieferten Produkten enthalten ist. Der Cyber Resilience Act verlangt sie verpflichtend. Die Schwierigkeit liegt nicht in der Erzeugung, sondern in Vollständigkeit und Pflege – transitive Abhängigkeiten und Container-Basisimages werden oft übersehen; sie muss pro Release neu erzeugt werden.
Verwandte Einträge: Cyber Resilience Act, Konfigurationsmanagement, NIS2, SOUP
SIL (Safety Integrity Level)
Kurzdefinition: Diskrete Stufe zur Angabe der erforderlichen bzw. erreichten Zuverlässigkeit einer Sicherheitsfunktion nach IEC 61508.
SIL 1 bis 4 stehen für zunehmende Risikoreduktion, jede Stufe etwa Faktor zehn. Für Hardware wird der SIL über Ausfallraten nachgewiesen, für Software über gestaffelte Prozess- und Verifikationsstrenge – die systematische Fähigkeit. Verbreiteter Irrtum: Zertifiziert werden Komponenten für die Verwendung bis zu einem SIL unter dokumentierten Annahmen, nicht „SIL-3-Software“ als solche.
Verwandte Einträge: FMEA und FMEDA, IEC 61508, ISO 26262 und ASIL
Software as a Medical Device (SaMD)
Kurzdefinition: Software, die selbst einen medizinischen Zweck erfüllt, ohne Bestandteil eines physischen Medizinprodukts zu sein.
SaMD kann auf allgemeiner Hardware wie Smartphone oder Server laufen und ist dennoch ein vollwertiges Medizinprodukt mit Konformitätsbewertung und CE-Kennzeichnung. Typische Beispiele sind Bildauswertungssoftware und Algorithmen zur Befundunterstützung; die Grenze verläuft an der Zweckbestimmung, nicht der Technik. Besondere Aufmerksamkeit erfordern unkontrollierte Betriebsumgebungen und häufige Releases im Rahmen regulatorischer Änderungskontrolle.
Verwandte Einträge: IEC 62304, IVDR, Konformitätsbewertung, MDR
SOUP (Software of Unknown Provenance)
Kurzdefinition: Softwarebestandteile ohne ausreichende Entwicklungsnachweise, etwa Open-Source-Bibliotheken oder zugekaufte Komponenten.
IEC 62304 verlangt für jede SOUP-Komponente eindeutige Identifikation, Anforderungsfestlegung, Bewertung bekannter Anomalien und Berücksichtigung im Risikomanagement. Anspruchsvollster Punkt ist die laufende Beobachtung über die gesamte Produktlebensdauer – bei hunderten transitiven Paketen ohne Automatisierung kaum leistbar. Der wirksamste Hebel ist die Architektur: SOUP aus sicherheitskritischen Pfaden heraushalten.
Verwandte Einträge: IEC 62304, Konfigurationsmanagement, Legacy-Software, SBOM
Statische Codeanalyse
Kurzdefinition: Automatisierte Untersuchung von Quellcode auf Fehler, Regelverstöße und Sicherheitslücken ohne Ausführung des Programms.
Unterschieden werden regelbasierte Prüfung, Fehlermustererkennung, Metrikerhebung und formale Verfahren wie abstrakte Interpretation. Alle relevanten Sicherheitsnormen empfehlen oder fordern sie mit steigender Kritikalität. Gefordert ist nicht die vollständige Beseitigung aller Meldungen, sondern ein nachvollziehbarer Bewertungsprozess je Abweichung. Dient das Ergebnis als Verifikationsnachweis, wird das Werkzeug selbst qualifizierungspflichtig.
Verwandte Einträge: Code Coverage, MISRA C, Verifikation, Werkzeugqualifizierung
T
Technische Dokumentation
Kurzdefinition: Die vom Hersteller vorzuhaltende Gesamtheit an Unterlagen, die die Konformität eines Produkts mit den anwendbaren Anforderungen belegt.
Die MDR beschreibt den Inhalt in den Anhängen I–III: Produktbeschreibung, Auslegungsinformationen, Nutzen-Risiko-Analyse, Verifikation und Validierung sowie Überwachung nach Inverkehrbringen – eine strukturierte Sammlung, kein einzelnes Dokument. Bewährt hat sich, Entwicklungsartefakte direkt in die geforderte Gliederung zu verweisen statt doppelt zu pflegen; Widersprüche sind der häufigste Prüfbefund.
Verwandte Einträge: Design History File, Konformitätsbewertung, MDR, Traceability
Traceability (Verfolgbarkeit)
Kurzdefinition: Die durchgängige, nachweisbare Verknüpfung zwischen Anforderungen, Risiken, Architektur, Code, Testfällen und Testergebnissen.
Vorwärtsverfolgung zeigt, dass jede Anforderung umgesetzt und geprüft wurde; Rückwärtsverfolgung deckt nicht spezifizierte Funktionalität auf. Sie ist Voraussetzung für eine belastbare Rückwirkungsanalyse und damit für begrenzten, begründeten Testumfang nach Änderungen. Häufigster Fehler ist die nachträgliche Erstellung kurz vor dem Audit – eine Matrix, die formal vollständig, aber inhaltlich wirkungslos ist.
Verwandte Einträge: Anforderungsmanagement, Change Control, Regressionstest, Verifikation
U
UDI (Unique Device Identification)
Kurzdefinition: Ein weltweit eindeutiges Kennzeichnungssystem für Medizinprodukte, das nach MDR und IVDR auf dem Produkt, der Verpackung und in der EUDAMED-Datenbank geführt wird.
Die UDI besteht aus einem Produktidentifikator (UDI-DI), der Hersteller und Modell beschreibt, und einem Produktionsidentifikator (UDI-PI) mit Chargen-, Serien- oder Versionsangaben. Für Software als Medizinprodukt gilt eine Besonderheit: Die UDI muss beim Programmstart oder in einem Info-Dialog lesbar angezeigt werden, und jede Änderung mit Auswirkung auf Sicherheit oder Leistung erfordert eine neue UDI-DI. Damit wird die Versionsstrategie zur regulatorischen Frage. Praktisch bewährt: schon im Design festlegen, welche Änderungen eine neue UDI auslösen, und die Nummer automatisiert aus dem Build-Prozess in die Software übernehmen, statt sie manuell zu pflegen.
Verwandte Einträge: IVDR, MDR, Software as a Medical Device, Technische Dokumentation
V
Validierung
Kurzdefinition: Der Nachweis, dass das richtige Produkt gebaut wurde – dass es die Bedürfnisse der Anwender in der realen Einsatzumgebung erfüllt.
Validierung prüft gegen Nutzeranforderungen und Zweckbestimmung, nicht gegen die Spezifikation, in repräsentativer Umgebung mit realen Anwendern. Die Abgrenzung zur Verifikation ist die am häufigsten verwechselte Unterscheidung: Verifikation fragt „richtig gebaut?“, Validierung „das Richtige gebaut?“. Je später Validierung stattfindet, desto teurer ihre Befunde – frühe formative Evaluationen sind der wirksamste Schutz.
Verwandte Einträge: Computer System Validation, IEC 62366-1, IQ/OQ/PQ, Verifikation
Verifikation
Kurzdefinition: Der Nachweis, dass ein Arbeitsergebnis die für es festgelegten Anforderungen erfüllt – dass das Produkt richtig gebaut wurde.
Verifikation vergleicht auf jeder Entwicklungsebene Ergebnis und Vorgabe – Architektur gegen Anforderungen, Code gegen Detailentwurf – über Tests, Reviews, Inspektionen oder formale Beweise. Im V-Modell entspricht jeder Spezifikationsebene eine Verifikationsstufe, was Vollständigkeit prüfbar macht. Ab höheren Kritikalitätsstufen fordern Normen personelle Unabhängigkeit von Verifizierenden und Erstellenden.
Verwandte Einträge: Code Coverage, Statische Codeanalyse, Validierung, V-Modell
V-Modell
Kurzdefinition: Vorgehensmodell, das jeder Spezifikations- und Entwurfsebene eine korrespondierende Prüfebene gegenüberstellt.
Auf dem absteigenden Ast stehen Anforderungen, Systemebene, Architektur und Detailentwurf, auf dem aufsteigenden Modul-, Integrations- und Systemtest sowie Validierung. Der Wert liegt in dieser Zuordnung, nicht in starrer Phasenfolge – fast alle Sicherheitsnormen sind entlang dieser Logik geschrieben. Ein verbreitetes Missverständnis: Keine Norm schließt agile Arbeitsweisen aus; AAMI TIR45 beschreibt ein „V pro Inkrement“ mit stabilen Freigabepunkten.
Verwandte Einträge: Anforderungsmanagement, Traceability, Validierung, Verifikation
W
Werkzeugqualifizierung (Tool Qualification)
Kurzdefinition: Der Nachweis, dass ein in der Entwicklung eingesetztes Softwarewerkzeug für seinen Verwendungszweck geeignet ist und keine unentdeckten Fehler einbringt.
Werkzeuge werden nach ihrem Einfluss bewertet: Kann ein Werkzeugfehler einen Produktfehler verursachen oder dessen Entdeckung verhindern? ISO 26262 nutzt dafür Tool Impact und Tool Error Detection, DO-330 unterscheidet Qualification Levels. Betroffen sind vor allem Compiler, Testwerkzeuge und Analysewerkzeuge, deren Ergebnis als Nachweis dient. Der wirksamste Hebel ist oft die Vermeidung: Wo Werkzeugausgaben unabhängig geprüft werden, sinkt die geforderte Qualifizierungstiefe.
Verwandte Einträge: DO-178C, Konfigurationsmanagement, Regressionstest, Statische Codeanalyse
X
XSS (Cross-Site Scripting)
Kurzdefinition: Eine Schwachstellenklasse in Web-Anwendungen, bei der Angreifer eigenen Skriptcode in Seiten einschleusen, die andere Nutzer im Browser ausführen.
XSS gehört seit Jahren zu den häufigsten Schwachstellen und betrifft auch regulierte Systeme, sobald sie eine Web-Oberfläche haben – vom Laborgeräte-Dashboard bis zum Service-Portal einer Anlage. Die Folgen reichen vom Diebstahl von Sitzungen bis zur Manipulation angezeigter Messwerte. Normen wie IEC 62443 und Anforderungen wie der Cyber Resilience Act verlangen einen sicheren Entwicklungsprozess, der solche Fehlerklassen systematisch verhindert: konsequentes Kodieren von Ausgaben, Content Security Policy, Eingabevalidierung und regelmäßige Tests. Praktisch bewährt: statische Codeanalyse mit Security-Regeln in die Pipeline integrieren und die OWASP Top 10 als Prüfliste im Code-Review verankern.
Verwandte Einträge: Cyber Resilience Act, IEC 62443, Statische Codeanalyse
Y
Year-2038-Problem
Kurzdefinition: Ein Zeitüberlauf in Systemen, die Zeitstempel als vorzeichenbehaftete 32-Bit-Zahl speichern: Am 19. Januar 2038 springt der Wert ins Negative.
Für kurzlebige Consumer-Software ist das Thema fern, für Medizintechnik, Bahn- und Industrieanlagen mit 15 bis 30 Jahren Betriebsdauer ist es real: Geräte, die heute ausgeliefert werden, sind 2038 noch im Feld. Betroffen sind nicht nur Betriebssysteme, sondern auch Dateiformate, Datenbanken, Protokolle und eigene Zeitberechnungen im Anwendungscode. Ein Überlauf kann Audit Trails unbrauchbar machen, Wartungsintervalle verschieben oder Sicherheitsfunktionen auslösen. Praktisch bewährt: 64-Bit-Zeittypen als Architekturvorgabe festlegen, Legacy-Komponenten und SOUP gezielt auf 32-Bit-Zeitstempel prüfen und den Datumssprung als festen Testfall in die Regressionssuite aufnehmen.
Verwandte Einträge: Audit Trail, Legacy-Software, Regressionstest, SOUP
Z
Zweckbestimmung (Intended Use)
Kurzdefinition: Die vom Hersteller festgelegte Beschreibung, wofür, für wen und unter welchen Bedingungen ein Produkt bestimmt ist – die Grundlage jeder regulatorischen Einstufung.
Die Zweckbestimmung entscheidet, ob eine Software überhaupt ein Medizinprodukt ist, in welche Risikoklasse sie fällt und welche Nachweise die Technische Dokumentation enthalten muss. Sie bestimmt außerdem den Rahmen für Risikomanagement, Usability Engineering und klinische Bewertung. Eine zu weit formulierte Zweckbestimmung treibt die Klassifizierung nach oben, eine zu enge schränkt die Vermarktung ein und kann bei abweichender Nutzung Haftungsfragen auslösen. Praktisch bewährt: die Zweckbestimmung vor der ersten Architekturentscheidung schriftlich fixieren, mit Marketing und Regulatory Affairs abstimmen und jede spätere Änderung wie eine Produktänderung mit Bewertung behandeln.
Verwandte Einträge: IEC 62366-1, ISO 14971, MDR, Software as a Medical Device
