Software Validierung / Verifizierung aus Lieferantensicht.
Fachlich präzise wird Software verifiziert - validiert wird erst das computergestützte System im Prozess des Betreibers. Der Markt nennt beides Software-Validierung - auch als Softwarevalidierung oder Validierung von Software geläufig - und wir verwenden den Begriff bewusst. Entscheidend ist die Rollenverteilung dahinter: Das regulierte Unternehmen verantwortet auch, was Sie liefern, und muss Sie deshalb bewerten. Wer darauf vorbereitet ist, macht aus der Prüfung einen Marktvorteil - Qualität, die im Audit sichtbar wird, entscheidet die Lieferantenauswahl.
Warum Ihr Kunde Sie bewerten muss.
Zuerst die Begriffe, weil an ihnen die Rollen hängen: Software wird gegen ihre Spezifikation verifiziert - validiert wird erst das computergestützte System beim Betreiber, gegen seinen Intended Use. Der Markt nennt beides "Software-Validierung"; wir folgen dem bewusst und meinen präzise: Ihre Verifizierung plus die Nachweise für die Validierung Ihres Kunden. Beides folgt demselben Lebenszyklusmodell - dem der Validierung nach GAMP 5.
Ihr Lebenszyklus ist Ihr Nachweis.
Regulierte Kunden erwarten von Softwareanbietern gute Praktiken über den gesamten Lebenszyklus - vom eigenen QMS bis zur geplanten Ablösung. Der Maßstab dabei: Gemessen werden Sie nicht am QMS Ihres Kunden, sondern an der nachweisbaren Einhaltung Ihres eigenen. Und am Produkt selbst: Audit Trail, Personenbindung und Signatur-Funktionen misst Ihr Kunde an den Anforderungen für elektronische Aufzeichnungen und Signaturen.
- 1
QMS & Qualitätsplanung
Dokumentierte Verfahren, kompetentes Personal, Nachweis der Einhaltung, kontinuierliche Verbesserung - je Produkt ein Qualitätsplan, wie das QMS konkret greift, und die formale Bewertung der eigenen Unterlieferanten.
- 2
Anforderungen & Spezifikation
Klare Anforderungen - vom Kunden bereitgestellt oder gemeinsam definiert - und eine Spezifikation, die das Produkt daran ausrichtet.
- 3
Design-Review & Entwicklung
Formales Design-Review gegen Anforderungen, Standards und identifizierte Risiken; Entwicklung und Konfiguration nach definierten Standards, inklusive Code-Review.
- 4
Test & Verifizierung
Tests nach freigegebenen Testplänen und -spezifikationen, mit nachweisbarer Abdeckung der Anforderungen - die Verifizierung, die dem Marktbegriff Software-Validierung fachlich zugrunde liegt.
- 5
Kommerzielles Release
Das Release an Kunden folgt Ihrem formalen Prozess. Die Freigabe in die GxP-Umgebung gehört ausdrücklich nicht dazu - sie bleibt Aufgabe des regulierten Unternehmens.
- 6
Betrieb, Änderungen & Ablösung
Support und Wartung nach Vertrag, ein vollständig beschriebener Änderungsprozess - so können Kunden ihren validierten Zustand aufrechterhalten - und am Ende eine geplante, dokumentierte Ablösung.
Wo steht Ihr Produkt - und was braucht Ihr Kunde von Ihnen?
Die Einbindung des Lieferanten skaliert mit der Produktart. Die GAMP-Kategorien unterscheiden die Produktarten; bei Diensten kommt es darauf an, welche Ebene Sie betreiben: die Business-Applikation, die Geschäftsprozesse und GxP-Daten trägt - oder die Plattform-Schichten darunter.
| Produktart | Typische Einbindung beim Kunden | Was Ihr Kunde von Ihnen braucht |
|---|---|---|
| Standardprodukt (GAMP-Kategorie 3) | Dokumentation, Training, Support und Wartung | Nachweis guter Entwicklungs- und Pflegepraxis - weitgehend erbracht, bevor die Kundenbeziehung beginnt |
| Konfiguriertes Produkt (Kategorie 4) | zusätzlich Unterstützung bei Spezifikation, Konfiguration, Verifizierung und Betrieb | vereinbarte, im Plan dokumentierte Verfahren - aus Ihrem QMS oder dem des Kunden |
| Individualentwicklung (Kategorie 5) | eingebunden über den gesamten Projektlebenszyklus, danach im Betriebssupport | vollständige Lebenszyklus-Nachweise nach vereinbarten Verfahren |
| Business-Applikation als Dienst (SaaS) | Sie betreiben die Applikation samt der Schichten darunter - selbst oder über eigene Lieferanten | Produkt-Evidenz und Betriebs-Nachweise zusammen, inklusive Ihrer Unterlieferanten-Kette |
| Plattform als Dienst (IaaS/PaaS) | Sie liefern die Plattform-Schichten, auf denen die Applikationen Ihrer Kunden laufen | qualifizierte Schichten und gelebte IT-Prozesse nach Ihrem eigenen QMS |
Für Plattform-Anbieter gilt ein Doppel-Nachweis: qualifizierte Schichten und die IT-Prozesse, die sie betreiben - ohne gelebtes Change- und Security-Management verliert auch die qualifizierte Umgebung ihren Zustand. Cloud-Dienste (nach NIST SP 800-145: bedarfsgesteuerter Netzzugriff auf einen gemeinsamen Ressourcen-Pool) sind dieselbe Schichtenwelt, als Dienst erbracht.
Geregelt, nicht behauptet.
Für Sie als Anbieter sind nicht die Regularien selbst verbindlich - verbindlich ist, was der Vertrag mit Ihrem Kunden daraus macht. Je mehr Ebenen Sie betreiben, desto größer die Lücke zwischen dem, was Ihr Kunde verantwortet, und dem, was er selbst in der Hand hat. Geschlossen wird sie durch einen sauberen Schnitt in drei Instrumenten, jeweils risikobasiert dimensioniert:
- Vertrag: Verantwortungsschnitt, Mitwirkungspflichten - und das Auditrecht Ihres Kunden
- Service Level Agreements: Betriebszusagen, die zum Risiko der getragenen Prozesse passen
- Qualitätsvereinbarung (Quality Agreement): die Qualitätspflichten beider Seiten - bei Cloud-Diensten ausdrücklich erwartet
Wir prüfen für die einen - und bereiten die anderen vor.
Über einhundert Audits haben wir geführt - aktuell darunter das Audit eines Cloud-Anbieters für ein Manufacturing Execution System. Dieselbe Erfahrung setzen wir auf Ihrer Seite des Tisches ein: im Mock-Audit, das Ihr nächstes Kundenaudit vorwegnimmt, im Training Ihrer Entwicklungs- und QA-Teams und im Aufbau der Nachweise, nach denen Auditoren wirklich fragen.
Die Bezugsdokumente dabei - von der verbindlichen Vorschrift bis zum Leitfaden:
Häufige Fragen aus Lieferantensicht.
Software-Validierung - auch Softwarevalidierung oder Validierung von Software - bezeichnet im Marktgebrauch den Nachweis, dass Software für ihren Einsatzzweck geeignet ist. Fachlich präzise wird Software verifiziert; validiert wird das computergestützte System im GxP-Prozess des Betreibers, gegen den Intended Use. Für Betreiber führt der Weg über die Validierung computergestützter Systeme; diese Seite nimmt die Lieferantensicht ein.
Nein - validieren kann nur der Betreiber: Validierung weist nach, dass das System im konkreten Geschäftsprozess seinen Intended Use erfüllt, und beides liegt beim regulierten Unternehmen. Der Anbieter verifiziert sein Produkt und dokumentiert den Lebenszyklus; je belastbarer diese Nachweise, desto weniger muss der Kunde für seine Validierung selbst erzeugen.
Als Baustein ja, als Ersatz nein. Das Zertifikat belegt ein Managementsystem, der SOC-2-Bericht attestiert Kontrollen - die GxP-Erwartungen vom dokumentierten Lebenszyklus bis zum Änderungsprozess decken beide nicht ab. Regulierte Unternehmen bewerten deshalb selbst, risikobasiert.
Ihr QMS und seine gelebte Anwendung: Verfahren, Kompetenz des Personals, Nachweise aus dem Alltag - produktbezogen den Lebenszyklus von den Anforderungen bis zum Änderungsmanagement, bei Diensten auch Betrieb und Unterlieferanten. Das stärkste Argument ist ein QMS, das hält, was es selbst festlegt.
So tief, wie es das Risiko der getragenen Prozesse verlangt. Gegenstand sind die qualifizierten Schichten, die IT-Prozesse, die sie im kontrollierten Zustand halten, und Ihre eigene Lieferkette. Maßgeblich ist die Kritikalität der Anwendungen auf der Plattform.
Vom Produkt zum validierten System.
Bestehen Sie das nächste Kundenaudit - bevor es stattfindet.
Im kostenfreien Erstgespräch (etwa 30 Minuten) schildern Sie Produktart und Reifegrad - wir benennen die Nachweislücken, die ein Auditor zuerst sieht, und die konkreten nächsten Schritte: vom Qualitätsplan bis zum Mock-Audit.
Erstgespräch vereinbaren
