Inhaltsverzeichnis
Das Wichtigste vorab
Wie führen Sie eine Risikoanalyse in der Computersystemvalidierung durch?
Beschreiben Sie den vorgesehenen Prozess und mögliche Fehlerfolgen. Bewerten Sie vorhandene Kontrollen anhand ihrer tatsächlichen Wirksamkeit und Nachweise. Halten Sie Wissenslücken ausdrücklich fest. Leiten Sie zusätzliche Maßnahmen und gezielte Prüfungen ab, einschließlich relevanter Fehlerfälle. Bewerten Sie anschließend die erreichte Risikobeherrschung anhand der Ergebnisse neu. Eine Punktzahl allein begründet weder den Testumfang noch die Nutzung des Systems.
- Bewerten Sie konkrete Fehlerfolgen im Prozess, nicht nur Softwarefunktionen oder Modulnamen.
- Eine beschriebene Kontrolle zählt erst mit nachvollziehbarer Eignung und Evidenz für die betrachtete Situation.
- Fehlende Informationen bleiben Unsicherheit; sie werden nicht zu einer niedrigen Risikoklasse umgedeutet.
- Testplanung, tatsächliche Befunde und verbleibende Nutzungsgrenzen gehören zur selben Entscheidung.
Was die Risikoanalyse für Ihre Validierung entscheiden soll
Die zentrale Arbeitsfrage lautet: Welcher Fehler könnte an welcher Stelle eine unzutreffende Qualitätsentscheidung ermöglichen, und was muss dagegen nachgewiesen werden? Beginnen Sie deshalb nicht mit einer leeren FMEA-Vorlage. Beginnen Sie mit dem Ablauf: Wer erfasst Daten, welche Verarbeitung folgt, wer verwendet das Ergebnis und welche Entscheidung hängt daran?
Annex 11 §1 verbindet den Validierungsumfang mit einer begründeten Risikobewertung unter Berücksichtigung von Patientensicherheit, Produktqualität und Datenintegrität. Im am 6. Oktober 2026 geöffneten EudraLex-Verzeichnis bleibt für Humanarzneimittel die Revision von Januar 2011 referenziert. Konsultationsentwürfe werden hier nicht als geltende Anforderungen verwendet.
Die folgenden Matrizen sind eigene Arbeitshilfen. Sie ersetzen weder Ihre Prozesskenntnis noch die im Qualitätssystem geregelte Entscheidung. Der Artikel betrachtet die Tiefe und Ausrichtung der Nachweise. Die URS beschreibt das erforderliche Soll; die Traceability zeigt später, welche Belege dieses Soll tatsächlich abdecken. Eine Risikobewertung sollte diese Dokumente verbinden, statt ihre Inhalte mehrfach abzuschreiben.
Prozessgrenze und Fehlerfolge zuerst festlegen
Wählen Sie einen fachlich zusammenhängenden Ausschnitt, etwa den Import eines Laborergebnisses bis zur Verwendung im Prüfbericht. Halten Sie beteiligte Systeme, Schnittstellen, Stammdaten und Rollen fest. Ein technischer Import kann korrekt beendet sein, obwohl der Wert der falschen Probe zugeordnet wurde. „Schnittstelle funktioniert“ wäre deshalb eine zu grobe Bewertungsfrage.
Trennen Sie Ursache, Fehler und Folge. Eine geänderte Feldzuordnung ist eine mögliche Ursache. Der Import unter einer falschen Probenkennung ist der Fehler. Die Folge kann eine falsche Bewertung des Materials sein. Daneben kann derselbe Fehler eine Verzögerung verursachen. Die reine Bearbeitungszeit beschreibt jedoch nicht die mögliche Qualitätsfolge.
Prüfen Sie auch, ob der Fehler bemerkt wird, bevor jemand auf den Datensatz vertraut. Eine Warnung nach dem Versand eines Berichts schützt einen anderen Zeitpunkt als eine Sperre vor dessen Freigabe. Fragen Sie nach Sonderfällen: Teilimporte, wiederholte Dateien, manuelle Korrekturen und Vertretungsrollen. Halten Sie ausgeschlossene Abläufe mit Begründung fest, damit der betrachtete Umfang später erkennbar bleibt.
Vorhandene Kontrollen mit ihrer tatsächlichen Evidenz bewerten
„Vier-Augen-Prüfung vorhanden“ sagt wenig darüber aus, welchen Fehler diese Prüfung erkennt. Beschreiben Sie, was verglichen wird, welche unabhängige Informationsquelle zur Verfügung steht und was bei einer Abweichung geschieht. Wenn beide Personen denselben falsch erzeugten Bericht lesen, entsteht durch die zweite Unterschrift keine unabhängige Prüfung der Probenzuordnung.
Unterscheiden Sie Prävention, Erkennung und Reaktion. Eine eindeutige Zuordnungsregel verhindert einen bestimmten Verwechslungsweg. Ein Vergleich mit einem unabhängigen Probenauftrag kann eine verbleibende Fehlzuordnung erkennen. Eine dokumentierte Sperre bis zur Klärung verhindert anschließend die unberechtigte Verwendung. Diese Wirkungen dürfen nicht ohne Prüfung mehrfach für denselben Mechanismus angerechnet werden.
Als Evidenz können passende Konfigurationsnachweise, tatsächlich ausgeführte Tests und aussagekräftige Betriebsbeobachtungen dienen. Prüfen Sie deren Version, Prozessbezug und Grenzen. Eine Schulungsunterschrift belegt Teilnahme oder Bestätigung entsprechend dem Schulungsprozess; sie demonstriert allein noch nicht, dass ein ungewöhnlicher Fehler im Tagesgeschäft erkannt wird. Organisatorische Kontrollen können tragfähig sein, wenn Ausführung, Zeitfenster, Zuständigkeit und Wirksamkeit zum Risiko passen.
Mit Unsicherheit umgehen, ohne Scheingenauigkeit zu erzeugen
ICH Q9(R1) beschreibt unterschiedliche Methoden und Formalitätsgrade. Es schreibt weder für jede CSV-Bewertung eine FMEA noch eine universelle Risikoprioritätszahl vor. Die Nachvollziehbarkeit Ihrer Entscheidung ist wichtiger als eine scheinbar präzise Dezimalzahl. Eine gut begründete qualitative Einordnung kann geeigneter sein als drei frei geschätzte Zahlen, die anschließend multipliziert werden.
Wenn Sie eine Skala verwenden, definieren Sie deren Begriffe vor der Einzelbewertung. Beschreiben Sie beispielsweise, was eine schwerwiegende Folge im betrachteten Prozess bedeutet. Trennen Sie geschätzte Häufigkeit von der Wahrscheinlichkeit, dass ein Fehler rechtzeitig erkannt wird. Ändern Sie die Skala nicht, um eine gewünschte Freigabeschwelle zu erreichen.
Notieren Sie bei fehlenden Daten die konkrete Frage: Ist die Erkennung doppelter Probenkennungen konfiguriert? Wurde sie mit unterschiedlichen Dateien geprüft? Aus „kein Vorfall bekannt“ folgt ohne verlässliche Erkennung und Aufzeichnung keine belastbare Häufigkeit. Beschaffen Sie gezielt die fehlende Information. Ein knapper Termin ist kein Nachweis für ein geringeres Risiko; zusätzliche Unsicherheit kann gerade mehr fachliche Klärung verlangen.
Quellen: [3]
Eine kompakte Arbeitshilfe für begründete Testentscheidungen
Die folgende Struktur lässt sich als Tabelle oder in Ihrem vorhandenen System abbilden. Vergeben Sie eine stabile Kennung pro zusammenhängendem Fehlerszenario. Verknüpfen Sie Anforderungen und Belege über Referenzen. Schreiben Sie Beobachtungen und Annahmen getrennt, damit der nächste Bearbeiter nicht eine vermutete Kontrolle für eine geprüfte Funktion hält.
Die Bewertung sollte einen konkreten Arbeitsauftrag erzeugen: Welche Frage wird durch welchen Test oder anderen geeigneten Nachweis beantwortet? Benennen Sie außerdem, wer das Ergebnis fachlich bewertet. Ein Termin für einen Test ist noch kein Kontrollnachweis. Bis zu dessen Abschluss bleibt die zugrunde liegende Unsicherheit im Bewertungsstand sichtbar.
| Feld | Eintrag mit Entscheidungsnutzen |
|---|---|
| Prozess und Fehlerszenario | Ergebnisimport: Ein Wert wird einer anderen Probe zugeordnet. |
| Mögliche Folge | Ein Material wird auf Grundlage eines fremden Ergebnisses bewertet. |
| Kontrolle und Evidenz | Kennungsabgleich; genaue Konfiguration, Belegversion und Prüfung benennen. |
| Unsicherheit | Unbekannt, ob Wiederholungsimporte eine bereits geprüfte Zuordnung überschreiben. |
| Zusätzliche Maßnahme | Überschreiben begrenzen und Ausnahmebehandlung fachlich festlegen. |
| Nachweisentscheidung | Konfliktdatei und Wiederholung prüfen; erwartete Sperre und Datenzustand belegen. |
| Neubewertung | Befund, verbleibende Grenze, zuständige Entscheidung und Änderungsanlass festhalten. |
Aus dem Risiko gezielte Prüfungen statt Testmengen ableiten
Für eine kritische Zuordnung reicht ein erfolgreicher Standardimport kaum aus. Prüfen Sie gezielt die Wege, über die das identifizierte Fehlerszenario entstehen kann. Dazu können fehlende Kennungen, doppelte Datensätze, nicht passende Einheiten und eine Wiederholung nach Verbindungsabbruch gehören. Die Auswahl folgt Ihrer Schnittstelle und Datenstruktur; sie ist keine Pflichtliste für jede Anwendung.
Annex 11 §4.7 nennt geeignete Testszenarien einschließlich relevanter Grenzen und Fehlerbehandlung. Praktisch bedeutet das: Legen Sie neben der sichtbaren Meldung den erwarteten Datenzustand fest. Nach einem abgelehnten Import darf beispielsweise nicht unbemerkt ein Teilwert für die Bewertung verfügbar bleiben, wenn Ihr Prozess einen vollständigen, zusammenhängenden Datensatz voraussetzt.
Lieferantentests können eine begründete Nachweisquelle sein. Prüfen Sie, welche Funktion, Version und Voraussetzung sie tatsächlich abdecken. Eigene Tests konzentrieren sich dann auf die verbleibenden Fragen, etwa kundenspezifische Zuordnung und Rollen. Dokumentieren Sie ebenso eine begründete Entscheidung gegen einen zusätzlichen Test. „Standardsoftware“ oder „niedrige Punktzahl“ allein erklärt nicht, welcher passende Nachweis bereits vorhanden ist.
Illustratives Beispiel: Ein plausibler Wert landet bei der falschen Probe
Dieses frei konstruierte Beispiel ist kein Kundenfall und kein ausgeführter Produkttest. Zwei Prüfaufträge tragen die Kennungen TEST-A und TEST-B. Die illustrativen Werte lauten 98,4 und 101,2 in derselben vereinbarten Einheit. Beide liegen innerhalb eines beispielhaften Bereichs von 95,0 bis 105,0. Eine reine Plausibilitätsprüfung erkennt die Vertauschung deshalb nicht.
Die angenommene Ausgangskontrolle besteht aus einem Review des importierten Berichts. Da dieser dieselbe falsche Zuordnung enthält, bleibt ihre Unabhängigkeit unbelegt. Für das Beispiel wird zusätzlich ein Vergleich von Auftrag, Originalexport und Zielzuordnung vor der Ergebnisverwendung festgelegt. Ein eindeutiger zusammengesetzter Schlüssel aus Auftragskennung und Prüfparameter soll außerdem mehrdeutige Zuordnungen zurückweisen.
Die folgende Matrix beschreibt geplante Prüfungen und erwartete Reaktionen. Sie enthält bewusst keine behaupteten Ist-Ergebnisse. Für die reale Ausführung wären Testumgebung, Softwarestand, Quelldatei, Konfiguration, tatsächlicher Befund und Ergebnisreview zu ergänzen. Die Kontrollen müssen gerade bei einem Fehler funktionieren; ihr Vorhandensein im Konzept senkt die Bewertung noch nicht automatisch.
| Prüfsituation | Erwartetes Verhalten im Beispiel | Warum dieser Nachweis benötigt wird |
|---|---|---|
| TEST-A = 98,4; TEST-B = 101,2 korrekt übergeben | Beide Werte bleiben mit Auftrag und Prüfparameter richtig verknüpft. | Belegt den vorgesehenen Standardablauf. |
| Werte bei der Übernahme im Ziel vertauschen; der unveränderte Originalexport bleibt als Vergleich erhalten. | Der unabhängige Vergleich mit dem Originalexport erkennt die Abweichung; Verwendung bleibt gesperrt. | Prüft die Kontrolle gegen plausible, aber falsch zugeordnete Werte. |
| Auftragskennung für zwei unterschiedliche Zielproben anbieten | Keine automatische Auswahl einer beliebigen Zielprobe; Konflikt wird geklärt. | Prüft die definierte Behandlung mehrdeutiger Zuordnung. |
| Datei mit bereits verarbeitetem Ergebnis erneut importieren | Kein stilles Überschreiben eines geprüften Ergebnisses; definierte Wiederholungsbehandlung. | Deckt den anderen Fehlerweg eines Wiederholungsimports ab. |
| Vergleichsdaten für den Reviewer nicht erreichbar | Keine unbelegte Freigabe des Ergebnisses; festgelegte Eskalation. | Prüft die Abhängigkeit der Kontrolle von ihrer Informationsquelle. |
Nach der Prüfung die verbleibende Risikobeherrschung beurteilen
Angenommen, der Test zeigt hypothetisch: Eine mehrdeutige Kennung wird blockiert, aber der Reviewer sieht nur den Zielbericht. Dann ist ein Fehlerweg kontrolliert und ein anderer weiterhin offen. Ein bestandenes Teilkriterium rechtfertigt keine grüne Gesamtbewertung. Halten Sie getrennt fest, was belegt ist, welche Kontrollannahme widerlegt wurde und welcher Teil des geplanten Einsatzes betroffen bleibt.
Nach einer Korrektur prüfen Sie die geänderte Kontrolle und die berührten Nachbarabläufe. Ein neuer Schlüssel kann etwa bisher erlaubte Mehrfachprüfungen versehentlich verhindern. Die Neubewertung betrachtet deshalb auch neue Fehlerwege, die durch die Maßnahme entstehen. Der ursprüngliche Datensatz und der frühere Befund bleiben nachvollziehbar; ein Nachtest ersetzt nicht die Geschichte der Entscheidung.
Die zuständigen Funktionen entscheiden auf dieser Grundlage über verbleibende Maßnahmen und gegebenenfalls Nutzungsgrenzen. Beschreiben Sie eine Einschränkung praktisch: welcher Ablauf, welche Daten, welche Rollen und welche Voraussetzung? Risikomanagement erlaubt keine ansonsten unzulässige Praxis. Eine unterschriebene Risikoakzeptanz ersetzt daher weder erforderliche Kontrollen noch die Erfüllung anwendbarer Anforderungen.
Bewertung im KMU vorbereiten und über Änderungen aktuell halten
Bringen Sie zur Besprechung einen realistischen Prozessablauf, ausgewählte Beispieldaten, bekannte Fehler und vorhandene Belege mit. Der Fachbereich erklärt, wann ein Ergebnis verwendet wird. IT erläutert Datenwege und Eingriffsmöglichkeiten. QA ordnet Qualitätsfolgen und Nachweisanforderungen ein. Lieferanten können technische Fragen klären; die Entscheidung über den vorgesehenen Einsatz braucht die zuständigen Verantwortlichen Ihres Unternehmens.
Der Aufwand entsteht vor allem durch unbekannte Schnittstellen, uneinheitliche Stammdaten, kundenspezifische Logik und ungeklärte Kontrollabläufe. Wenige komplexe Fehlerwege können mehr Arbeit erfordern als viele gut verstandene Standardfunktionen. Sammeln Sie offene Fragen mit Verantwortlichem und konkretem Abschlussbeleg. So wird aus einem langen Workshop ein bearbeitbarer Nachweisplan.
Überprüfen Sie die Bewertung bei Änderungen, neuen Befunden oder relevanten Betriebserfahrungen. Ein Wechsel der Importquelle kann den bisherigen Vergleich entwerten. Eine zusätzliche Schicht kann die Verfügbarkeit des Reviewers verändern. Die periodische Bewertung ergänzt solche Anlässe; sie ist kein Grund, bekannte relevante Änderungen bis zum nächsten Kalendereintrag unbeurteilt zu lassen.
Checkliste: Ist die Risikobewertung entscheidungsfähig?
Prüfen Sie einen kritischen Eintrag vollständig vom Prozess bis zum Ergebnis. Wenn sich die Begründung nur aus mündlichen Erläuterungen erschließt, ergänzen Sie genau die fehlende Verbindung. Das Ziel ist eine für spätere Änderungen nutzbare Entscheidung, nicht eine möglichst umfangreiche Tabelle.
- Prozess, Systemstand, Datenfluss und betrachtete Nutzung sind eindeutig abgegrenzt.
- Ursache, Fehlerszenario und mögliche Qualitätsfolge sind unterscheidbar beschrieben.
- Vorhandene Kontrollen nennen Zeitpunkt, Verantwortlichen und Informationsgrundlage.
- Belege sind passend zu Version und Prozess zugeordnet; Grenzen bleiben sichtbar.
- Unbekannte Sachverhalte werden als Unsicherheit mit Klärungsauftrag geführt.
- Bewertungskriterien sind verständlich; Zahlen ersetzen keine fachliche Begründung.
- Zusätzliche Maßnahmen adressieren konkrete Fehlerwege und mögliche neue Risiken.
- Tests enthalten relevante Fehlerfälle, erwartete Datenzustände und geeignete Nachweise.
- Tatsächliche Befunde führen zu einer nachvollziehbaren Neubewertung und Entscheidung.
- Änderungen, Kontrollausfälle und neue Erkenntnisse haben einen benannten Bearbeitungsweg.
Häufige Fragen zu Risikoanalyse in der Validierung
Ist für die CSV-Risikoanalyse eine FMEA vorgeschrieben?
Nein. ICH Q9(R1) nennt mehrere geeignete Methoden; FMEA ist eine Möglichkeit. Wählen Sie eine Struktur, die Fehlerfolgen, Kontrollen, Unsicherheit und Entscheidungen verständlich macht. Wenn Ihr Qualitätssystem FMEA vorsieht, wenden Sie diese kontrolliert an. Für einen überschaubaren Importprozess kann eine begründete qualitative Matrix ausreichend sein, sofern sie die relevanten Fragen tatsächlich beantwortet.
Quellen: [3]
Welche Risikoprioritätszahl erlaubt weniger Tests?
Es gibt hier keinen universellen regulatorischen Grenzwert. Eine interne Schwelle ist nur mit definierten Kriterien und geeigneter fachlicher Bewertung brauchbar. Prüfen Sie zuerst, welche Fehlerwege durch passende Evidenz bereits abgedeckt sind. Reduzieren Sie zusätzliche Tests wegen dieser begründeten Abdeckung, nicht allein wegen eines Rechenprodukts. Ein schwerwiegender offener Fehler darf nicht durch niedrige andere Werte unsichtbar werden.
Dürfen wir eine unbekannte Fehlerwahrscheinlichkeit als niedrig einstufen?
Nicht allein wegen fehlender Meldungen. Klären Sie, ob Fehler überhaupt erkannt und aufgezeichnet würden. Kennzeichnen Sie fehlendes Wissen und beschaffen Sie gezielte Evidenz, etwa zur Zuordnungslogik oder Wiederholungsbehandlung. Eine vorläufige Annahme braucht erkennbare Grenzen. Bleibt die Unsicherheit entscheidungsrelevant, muss sie in Maßnahmen, Prüftiefe und Nutzungsentscheidung berücksichtigt werden.
Quellen: [3]
Senkt ein Vier-Augen-Prinzip das Risiko automatisch?
Nein. Beschreiben Sie, welchen Fehler die zweite Person vor der Verwendung erkennt und anhand welcher Quelle. Zwei Personen, die denselben fehlerhaften Zielbericht lesen, prüfen die ursprüngliche Zuordnung nicht unabhängig. Testen oder demonstrieren Sie die konkrete Kontrolle mit einem passenden Fehlerfall. Berücksichtigen Sie außerdem Vertretung, verfügbare Zeit und die Reaktion bei fehlenden Vergleichsdaten.
Muss jede Anforderung eine eigene Risikomatrixzeile erhalten?
Nicht zwingend. Zusammengehörige Anforderungen können dasselbe Fehlerszenario betreffen. Halten Sie ihre Verbindung trotzdem nachvollziehbar. Trennen Sie Einträge, wenn Folgen, Kontrollen oder Testentscheidungen unterschiedlich sind. Eine Sammelzeile „Datenintegrität“ wäre beispielsweise zu grob, wenn Probenzuordnung, Ergebnisänderung und Wiederherstellung jeweils andere Nachweise benötigen. Die Granularität soll Entscheidungen erleichtern, nicht Zeilenzahlen erhöhen.
Können wir einen Lieferantentest als Kontrollnachweis verwenden?
Ja, wenn Umfang, Version, Voraussetzungen und Aussage des Belegs zu Ihrer Frage passen. Ein Test der Importfunktion kann wertvoll sein, ohne Ihre eigene Feldzuordnung abzudecken. Dokumentieren Sie den übernommenen Anteil und die verbleibenden Fragen. Entscheidend ist die tatsächliche Evidenz, nicht das Etikett „Validierungspaket“. Ergänzen Sie gezielte Prüfungen für die kundenspezifischen Teile.
Quellen: [2]
Wie viele Negativtests braucht ein kritischer Prozess?
Die Anzahl folgt den relevanten Fehlerwegen und Kontrollen. Beim Ergebnisimport können Mehrdeutigkeit, Wiederholung und fehlende Vergleichsdaten unterschiedliche Fragen beantworten. Drei Varianten desselben einfachen Fehlers ersetzen diese Breite nicht. Beschreiben Sie für jeden ausgewählten Fall die fachliche Begründung und den erwarteten Zustand. Begründen Sie auch, welche Varianten durch vorhandene Nachweise ausreichend abgedeckt sind.
Quellen: [2]
Wann wird das Restrisiko nach einer Maßnahme neu bewertet?
Wenn die Maßnahme umgesetzt ist und ihre relevante Wirkung anhand geeigneter Ergebnisse beurteilt werden kann. Eine geplante Sperre ist noch keine wirksame Sperre. Prüfen Sie neben der gewünschten Wirkung mögliche neue Fehlerwege. Bleiben Maßnahmen offen, unterscheiden Sie den belegten aktuellen Zustand vom vorgesehenen Zielzustand. Die zuständige Entscheidung muss sich auf den aktuellen Zustand beziehen.
Quellen: [3]
Wer muss bei einer CSV-Risikobewertung mitwirken?
Beteiligen Sie die Personen, die Prozessfolgen, technische Umsetzung und Qualitätsanforderungen beurteilen können. Bei komplexen Abläufen sind dies häufig Fachbereich, IT und QA; weitere Rollen hängen vom Einsatz ab. Ein Lieferant kann technische Evidenz liefern. Legen Sie im Qualitätssystem fest, wer bewertet und entscheidet. Es gibt keine für jedes System identische Teilnehmer- oder Unterschriftenliste.
Muss die Risikoanalyse bei jedem Update vollständig neu geschrieben werden?
Nein. Prüfen Sie, welche bisherigen Annahmen, Kontrollen und Nachweise betroffen sind. Eine geänderte Schnittstelle kann eine erneute Bewertung und gezielte Regressionstests benötigen, während unberührte Begründungen bestehen bleiben. Dokumentieren Sie auch eine nachvollziehbare Entscheidung ohne zusätzlichen Test. Ein unverändertes Versionsetikett oder fehlende sichtbare Bedienänderungen belegen allein keine fehlende fachliche Auswirkung.
Quellen & fachlicher Stand
Primärquellen wurden am 6. Oktober 2026 geöffnet. Betrachtet wird die Computersystemvalidierung im Humanarzneimittel-GMP. Tabellen, Testentscheidungen und Ergebnisimport sind eigene illustrative Arbeitshilfen; sie beschreiben keine durchgeführten Tests und keine allgemeingültigen Risikoschwellen.
- Europäische Kommission: EudraLex Volume 4 – aktuelles Verzeichnis für Humanarzneimittel-GMP
- EU-GMP Annex 11: Computerised Systems – §§1, 4 und Lebenszykluskontrollen
- ICH Q9(R1): Quality Risk Management – EMA Step 5, 2023
- EMA: GMP/GDP Questions and Answers – Annex 11, Fragen 5 und 7
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Risikoanalyse und konkrete Nachweise zusammenführen
Daniel Herrmann Consulting unterstützt QA, IT und Fachbereich dabei, kritische Fehlerwege zu bewerten und daraus einen nachvollziehbaren Nachweisplan für den vorgesehenen Einsatz zu entwickeln.
- IT-GxP-Audit →
Vorhandene Risikobewertungen und Kontrollnachweise auf offene Entscheidungsfragen prüfen.
- IT-GxP-Consulting →
Fehlerszenarien, geeignete Maßnahmen und konkrete Prüfungen gemeinsam ausarbeiten.