Inhaltsverzeichnis
Das Wichtigste vorab
Was gehört in eine Traceability Matrix für die Validierung?
Verbinden Sie identifizierte, versionierte Anforderungen mit dem Prüfgrund, der zugehörigen Umsetzung und konkreten Ergebnisbelegen. Ergänzen Sie relevante Befunde, deren Bewertung und den aktuellen Abdeckungsstatus. Halten Sie Änderungen und die Gültigkeit vorhandener Nachweise nachvollziehbar. Die Matrix kann als Tabelle oder in einem geeigneten System geführt werden; entscheidend sind überprüfbare Beziehungen und Ergebnisse, nicht ein bestimmtes Dateiformat.
- Ein Testplan beschreibt die Prüfung; erst der ausgeführte und bewertete Nachweis beschreibt ihr Ergebnis.
- Anforderung, Konfiguration und Ergebnisbeleg brauchen einen nachvollziehbaren Versionsbezug.
- Ein Link oder eine vollständige Linkquote bedeutet noch keine fachlich ausreichende Abdeckung.
- Änderungen und offene Befunde bleiben sichtbar, bis ihre Auswirkung auf den Nachweisstand beurteilt ist.
Traceability macht die Nachweiskette prüfbar
Traceability bezeichnet hier die Nachvollziehbarkeit von Anforderungen und Validierungsnachweisen. Gemeint ist weder die Rückverfolgung einer Charge durch die Lieferkette noch die technische Codeabdeckung eines Softwaretests. Ihre Leitfrage lautet: Woher stammt dieses Soll, wie wurde es umgesetzt, und worauf stützt sich die Aussage, dass es im vorgesehenen Einsatz erfüllt wird?
Annex 11 §4.4 adressiert die Nachverfolgbarkeit der Anwenderanforderungen über den Lebenszyklus. Er schreibt dafür keine Excel-Vorlage und keine Eins-zu-eins-Zuordnung zwischen Anforderung und Test vor. Das aktuelle EudraLex-Verzeichnis nennt im Humanarzneimittelbereich weiterhin die Revision von Januar 2011. Dieser Artikel nutzt diese veröffentlichte GMP-Leitlinie, keine neuen Pflichten aus Konsultationsentwürfen.
Die folgenden Felder und Statusbegriffe sind eine eigene praktische Darstellungsform. Die URS klärt das Soll. Die Risikobewertung begründet, welche Nachweise erforderlich sind. Traceability verbindet beides mit der tatsächlichen Umsetzung und den Ergebnissen. Sie ersetzt diese Arbeit nicht, hilft aber, fehlende oder nicht mehr passende Belege rechtzeitig zu erkennen.
Mit einer eindeutigen Anforderung und ihrem Stand beginnen
Vergeben Sie stabile Kennungen und halten Sie den maßgeblichen Textstand fest. „Berechtigungen funktionieren“ lässt offen, welche Rolle welche Handlung ausführen darf. Eine prüfbare Anforderung nennt die erlaubte Handlung, betroffene Daten und relevante Einschränkungen. Die Matrix muss diese Details nicht vollständig wiederholen, benötigt aber einen zuverlässigen Verweis auf die entsprechende Fassung.
Ändert sich ein Akzeptanzkriterium, bleibt die frühere Version als früherer Bezug erkennbar. Überschreiben Sie nicht einfach den Text hinter einer unveränderten Referenz. Sonst scheint ein alter Test eine neue Erwartung abzudecken, die bei der Ausführung noch nicht existierte. Verwenden Sie beispielsweise die Kombination aus Anforderungskennung, Versionsstand und Änderungsreferenz.
Trennen Sie mehrere fachliche Kriterien innerhalb einer großen Anforderung, wenn sie unterschiedlich geprüft oder bewertet werden. Eine Sammelanforderung zu Zugriffssteuerung kann Anmeldung, Schreibrecht, fachliche Genehmigung und Administration enthalten. Ein einzelner Login-Test belegt davon nur einen Teil. Unterkriterien oder klare Zuordnungen im Prüfbeleg halten diese Unterschiede sichtbar, ohne jede Aussage künstlich in ein eigenes Dokument zu zerlegen.
Risiko und Umsetzung so verknüpfen, dass die Zuordnung etwas erklärt
Ein Risikoverweis soll erklären, warum bestimmte Kriterien vertieft geprüft werden. Verknüpfen Sie daher möglichst das konkrete Fehlerszenario statt nur die Titelseite einer Risikoanalyse. Bei einer Rollentrennung wäre dies beispielsweise die unbemerkte Genehmigung eines selbst erstellten Datensatzes. Der fachliche Grund bleibt damit auch dann erkennbar, wenn eine andere Person die Matrix später pflegt.
Führen Sie außerdem zur relevanten Umsetzung: Rollenregel, Workflowkonfiguration, Schnittstellenzuordnung oder dokumentierte Betriebsregel. Wählen Sie eine angemessene Genauigkeit. Ein kompletter Konfigurationsexport kann ein guter Ausgangsbeleg sein; die Matrix sollte darin den relevanten Bereich oder ergänzenden Prüfvermerk auffindbar machen. Allein auf den Systemnamen zu verweisen genügt für eine konkrete Änderungsanalyse häufig nicht.
Nicht jede Anforderung wird ausschließlich technisch erfüllt. Eine geregelte Prüfung kann aus einer Softwarefunktion und einer Arbeitsanweisung bestehen. Verknüpfen Sie dann beide Teile und ihre passenden Nachweise. Ob diese Kombination fachlich ausreicht, wird in der Bewertung entschieden. Traceability soll sie transparent darstellen und darf eine unbelegte technische Sperre nicht durch den bloßen Link auf eine SOP ersetzen.
Quellen: [2]
Diese Felder machen eine Matrix im Alltag nutzbar
Die nachfolgende Struktur ist eine Arbeitshilfe, kein vorgeschriebenes Formular. Sie können Felder auf mehrere miteinander verbundene Ansichten verteilen. Entscheidend ist, dass ein Leser vom aktuellen Anforderungsstand zur maßgeblichen Evidenz gelangt und die Entscheidung versteht. Eine zusätzliche Spalte ist nur hilfreich, wenn sie zuverlässig gepflegt wird.
Vermeiden Sie wiederholte Kopien von Ergebnissen. Bewahren Sie den Ergebnisbeleg an der kontrollierten Stelle auf und referenzieren Sie ihn präzise. Für die Entscheidung genügt in der Matrix ein eindeutiger Status mit relevanter Einschränkung. Wenn sich zwei Ergebniszusammenfassungen widersprechen, muss klar sein, welcher kontrollierte Beleg maßgeblich ist und wer den Widerspruch klärt.
| Baustein | Was der Eintrag beantworten soll |
|---|---|
| Anforderung und Version | Welches Soll und welche einzelnen Kriterien gelten für diesen Stand? |
| Risiko oder Prüfgrund | Welcher Fehlerweg oder welche andere Anforderung begründet den Nachweis? |
| Umsetzungsbezug | Welche Konfiguration, Funktion oder Betriebsregel erfüllt das Soll? |
| Prüfung und Ergebnis | Welcher Lauf auf welcher Umgebung belegt welches tatsächliche Verhalten? |
| Befund und Bewertung | Was ist abgewichen, welche Auswirkung wurde bewertet und durch wen? |
| Abdeckungsstatus | Belegt, teilweise belegt, offen oder für diesen Stand nicht anwendbar – mit Begründung. |
| Änderungsbezug | Welche Änderung berührt die Beziehungen und welche erneute Prüfung folgt daraus? |
Einen geplanten Test von einer tatsächlichen Prüfung unterscheiden
Ein Testskript kann sämtliche Anforderungen erwähnen und trotzdem noch nie ausgeführt worden sein. Verweisen Sie deshalb bei der Ergebnisabdeckung auf einen eindeutig identifizierten Testlauf. Dazu gehören die für seine Aussage relevanten Angaben, etwa Softwarestand, Konfiguration, Testdaten, Ausführungszeitpunkt, erwartetes Verhalten und tatsächliche Beobachtung. Der Umfang richtet sich nach der Prüfaufgabe.
Ein Screenshot kann einen sichtbaren Zustand zeigen. Er erklärt ohne Kontext jedoch nicht, welcher Benutzer gehandelt hat oder ob eine vorausgesetzte Sperre tatsächlich geprüft wurde. Verknüpfen Sie den Screenshot mit Testschritt und Ergebnisbewertung. Bei einem Schnittstellentest können Eingangsdatei, Verarbeitungsprotokoll und Zielzustand gemeinsam erforderlich sein. Ein alleiniger grüner Jobstatus beantwortet eine fachliche Zuordnungsfrage nicht.
Ein Test kann mehrere Anforderungen belegen; eine Anforderung kann mehrere Tests benötigen. Ordnen Sie möglichst die relevanten Schritte oder Kriterien zu. Vermeiden Sie Sammelverweise, deren Auswertung erneut das gesamte Projektwissen voraussetzt. Annex 15 ergänzt für seinen Qualifizierungs- und Validierungsscope die Bedeutung klarer Dokumentbeziehungen und der Bewertung von Ergebnissen gegen Akzeptanzkriterien; für Computersysteme verweist er ausdrücklich auf Annex 11.
Offene Befunde und Teilabdeckung sichtbar halten
Definieren Sie Statusbegriffe so, dass sie Entscheidungen unterstützen. „Geplant“ bedeutet, dass ein Nachweis vorgesehen ist. „Ausgeführt“ sagt noch nichts über dessen Ergebnis. „Belegt“ sollte nur für den tatsächlich abgedeckten Umfang gelten. „Teilweise belegt“ braucht eine konkrete Angabe zum offenen Kriterium. Vermeiden Sie ein einziges Häkchen, das diese Zustände zusammenfasst.
Ein fehlgeschlagener Test bleibt Teil der Nachweiskette. Verknüpfen Sie Befund, Auswirkungsbewertung, Korrektur und gegebenenfalls Wiederholungsprüfung. Der spätere erfolgreiche Lauf macht das frühere Ergebnis nicht ungeschehen. Ebenso darf ein administrativ geschlossenes Ticket nicht automatisch als bestandener Test erscheinen. Entscheidend ist, ob die fachliche Lücke durch geeignete Evidenz tatsächlich bearbeitet wurde.
Eine Quote von 100 Prozent verlinkten Anforderungen kann neben mehreren offenen kritischen Prüfungen stehen. Wenn Sie eine Kennzahl verwenden, benennen Sie ihren Nenner und ihre Aussage: verlinkt, ausgeführt oder fachlich belegt. Trennen Sie ergänzend offene relevante Kriterien und betroffene Nutzung. Diese Transparenz ist nützlicher als eine scheinbar vollständige Gesamtzahl, deren Bedeutung im Review erst erklärt werden muss.
Illustratives Beispiel: Eine Rollenänderung entwertet nicht jeden alten Test
Dieses frei konstruierte Beispiel beschreibt angenommene Zustände, keine ausgeführte Validierung und keinen Kundenfall. Anforderung R-17 in Version 1 erlaubt die fachliche Genehmigung eines Prüfdatensatzes nur berechtigten Prüfern. Der angenommene Test T-21 auf Konfiguration K-3 belegt erlaubte und verbotene Rollen. Für Version 2 kommt ein zusätzliches Kriterium hinzu: Der Ersteller darf seinen eigenen Datensatz nicht genehmigen, auch wenn er zugleich Prüfer ist.
Diese konkrete Rollentrennung ist eine Annahme des Beispiels, keine aus Annex 11 abgeleitete allgemeine Pflicht für jeden Datensatz. Das neue Fehlerszenario betrifft die Kombination zweier Rollen. T-21 bleibt als Nachweis seines ursprünglichen Umfangs erhalten. Er belegt aber nicht automatisch den neuen Ausschluss. Die Änderungsbewertung muss zusätzlich erklären, ob seine Aussage für die aktuelle Konfiguration weiterhin trägt.
Für T-22 wird ein Benutzer mit beiden Rollen und ein von ihm erstellter Datensatz vorgesehen. Die erwartete Reaktion ist die Verweigerung der eigenen Genehmigung bei weiterhin möglicher zulässiger Prüfung fremder Datensätze. Im hypothetischen ersten Lauf wird die Selbstgenehmigung erlaubt. Der Befund B-04 bleibt offen, bis Korrektur und geeignete Nachweise bewertet sind.
| Stand und Beziehung | Vorhandener Beispielbeleg | Lücke oder Entscheidung | Abdeckung |
|---|---|---|---|
| R-17 V1 → K-3 → T-21 | Angenommener bestandener Lauf: Zugriff der definierten Rollen geprüft. | Belegt den ursprünglichen Umfang; historischen Bezug erhalten. | V1 belegt |
| R-17 V2 → geplanter Stand K-4 | T-21 bleibt verfügbar, prüfte aber keine Selbstgenehmigung. | Gültigkeit für unveränderten Anteil beurteilen; T-22 zusätzlich planen. | V2 nicht vollständig belegt |
| R-17 V2 → K-4 → T-22 → B-04 | Angenommener Fehlbefund: kombinierte Rolle genehmigt eigenen Datensatz. | Auswirkung bewerten; betroffenen Prozess nicht als vollständig nachgewiesen kennzeichnen. | Kriterium offen |
| R-17 V2 → K-5 → Nachtest T-22-R1 | Korrektur und Nachtest sind im Beispiel erst geplant. | Erst Ergebnis plus nötige Regression bewerten; Planung ist kein Abschlussbeleg. | Weiterhin offen |
Änderungen über die Nachweiskette beurteilen
Beginnen Sie die Änderungsbewertung am tatsächlich geänderten Gegenstand. Bei R-17 wäre dies die Regel zur eigenen Genehmigung. Folgen Sie den Verbindungen zu Rollen, Konfiguration, Prüfszenarien und Betriebsanweisungen. Prüfen Sie anschließend die umgekehrte Richtung: Welche anderen Anforderungen hängen an derselben Konfiguration? Eine Korrektur könnte versehentlich auch zulässige Genehmigungen fremder Datensätze verhindern.
Im Beispiel kann deshalb neben T-22-R1 eine gezielte Wiederholung des betroffenen Anteils von T-21 sinnvoll sein. Ob weitere Tests nötig sind, hängt von der Änderung und ihren Abhängigkeiten ab. Es gibt weder einen Automatismus „alles erneut“ noch „nur den Fehlerfall erneut“. Halten Sie die Begründung fest, wenn bestehende Evidenz für unveränderte Teile weiter genutzt wird.
Zum Review gehört auch eine Blickrichtung vom Test zur Anforderung. Unverbundene Tests können eine übersehene Anforderung, einen technischen Prüfgrund oder einen veralteten Umfang anzeigen. Nicht jeder solcher Test ist unnötig. Klären Sie den Grund und dokumentieren Sie die passende Beziehung oder eine kontrollierte Aussonderung. Entfernen Sie historische Nachweise nicht nur, um die aktuelle Tabelle übersichtlicher erscheinen zu lassen.
Die Matrix pflegen, ohne ein zweites Dokumentationssystem aufzubauen
Legen Sie eine führende Ablage und klare Pflegeverantwortung fest. Der Fachbereich bewertet die fachliche Aussage. IT und Lieferant liefern nachvollziehbare Konfigurationsbezüge. Die Ergebnisprüfung und die Entscheidung über offene Befunde folgen Ihrem Qualitätssystem. Wer nur eine Dokumentnummer aktualisiert, sollte dadurch nicht unbemerkt eine fachliche Abdeckungsentscheidung verändern können.
Eine Tabellenkalkulation kann für einen überschaubaren Umfang passen. Bei vielen Releases und Beziehungen kann ein verknüpftes Werkzeug die Pflege erleichtern. Beurteilen Sie dessen Einsatz und Kontrollen, insbesondere Zugriffsrechte, Änderungen, Filter und Exporte. Automatisch erzeugte Links reduzieren Übertragungsarbeit; sie beurteilen nicht selbst, ob ein Test die richtige fachliche Frage beantwortet.
Prüfen Sie bei Übergabe und späteren Änderungen, ob Referenzen für die berechtigten Leser erreichbar bleiben. Ein Link in eine kurzlebige Projektablage ist kein dauerhaft verlässlicher Nachweiszugang. Für einen archivierten Projektstand müssen auch die damals referenzierten Versionen bestimmbar sein. Aufwandstreiber sind vor allem verstreute Ablagen, wechselnde Kennungen, umfangreiche Sammelanforderungen und ungeklärte Ergebniszustände – nicht allein die Zahl der Tabellenzeilen.
Checkliste: Hält die Nachweiskette einer konkreten Rückfrage stand?
Wählen Sie eine geänderte oder besonders relevante Anforderung und verfolgen Sie ihre Kette ohne mündliche Ergänzung. Prüfen Sie anschließend eine offene Abweichung in der Gegenrichtung. Die folgende Checkliste hilft, fehlende Beziehungen und unklare Statusangaben gezielt zu bearbeiten.
- Die geltende Anforderung ist eindeutig identifiziert und mit ihrem Stand verknüpft.
- Einzelne Kriterien sind erkennbar, auch wenn mehrere in einer Anforderung zusammenstehen.
- Der Prüfgrund verweist auf das konkrete Risiko oder eine andere nachvollziehbare Grundlage.
- Die relevante Umsetzung ist über passende Konfigurations- oder Verfahrensbelege auffindbar.
- Testplanung und tatsächliche Ausführung haben unterscheidbare Referenzen.
- Der Ergebnisbeleg zeigt den relevanten Systemstand und die tatsächliche Beobachtung.
- Offene Befunde, Auswirkungsbewertungen und Entscheidungen sind miteinander verbunden.
- Der Abdeckungsstatus beschreibt den belegten Umfang und verdeckt keine Teilkriterien.
- Änderungen führen zu einer Bewertung betroffener Beziehungen und vorhandener Belege.
- Historische Stände, aktuelle Referenzen und Pflegeverantwortung bleiben nachvollziehbar.
Häufige Fragen zu Traceability Matrix
Ist eine Traceability Matrix in Excel vorgeschrieben?
Nein. Annex 11 beschreibt die Nachverfolgbarkeit von Anwenderanforderungen über den Lebenszyklus, ohne dieses Dateiformat vorzuschreiben. Wählen Sie eine kontrollierte Darstellung, die zu Umfang und Pflegeprozess passt. Eine Tabelle kann genügen; ein geeignetes Werkzeug kann komplexe Beziehungen erleichtern. Entscheidend bleibt, ob ein Leser den gültigen Anforderungsstand, die passende Evidenz und offene Fragen zuverlässig erkennen kann.
Muss jede Anforderung genau einen Test haben?
Nein. Eine Anforderung kann mehrere Kriterien und damit mehrere Nachweise benötigen. Umgekehrt kann ein End-to-End-Test mehrere Anforderungen prüfen. Ordnen Sie die relevanten Schritte oder Ergebnisstellen zu, damit die Verbindung verständlich bleibt. Ein Sammellink auf ein umfangreiches Protokoll ist nur hilfreich, wenn sich daraus der tatsächliche Nachweis für das jeweilige Kriterium eindeutig finden lässt.
Was ist der Unterschied zwischen Testabdeckung und einem vorhandenen Testlink?
Ein Link zeigt zunächst nur, dass zwei Einträge verbunden wurden. Fachliche Abdeckung setzt voraus, dass die referenzierte Prüfung das relevante Kriterium im passenden Stand tatsächlich untersucht und ein bewertbares Ergebnis liefert. Prüfen Sie deshalb Ausführungsstand, Ergebnis und offene Befunde. Kennzeichnen Sie einen geplanten oder fehlgeschlagenen Test entsprechend, statt ihn durch die bloße Verknüpfung als erfüllt zu zählen.
Dürfen alte bestandene Tests nach einer Änderung weiter verwendet werden?
Ja, wenn ihre Aussage für den betrachteten unveränderten Anteil nachvollziehbar erhalten bleibt. Beurteilen Sie Anforderung, Konfiguration, Umgebung und relevante Abhängigkeiten. Ein neuer Rollenparameter kann eine zusätzliche Prüfung benötigen, ohne jeden alten Test wertlos zu machen. Dokumentieren Sie die Gültigkeitsbewertung. Der alte Lauf darf nicht nachträglich so erscheinen, als hätte er ein damals noch unbekanntes Kriterium geprüft.
Wie behandeln wir einen fehlgeschlagenen Test in der Matrix?
Verknüpfen Sie ihn mit dem Befund und dessen fachlicher Bewertung. Lassen Sie das betroffene Kriterium offen oder entsprechend eingeschränkt, bis geeignete Nachweise eine andere Entscheidung tragen. Erfassen Sie Korrektur und Nachtest zusätzlich; überschreiben Sie den ursprünglichen Lauf nicht. Ein geschlossenes Ticket genügt nur dann als Teil der Nachweiskette, wenn der erforderliche fachliche Abschluss tatsächlich nachvollziehbar ist.
Beweist eine Abdeckungsquote von 100 Prozent die erfolgreiche Validierung?
Nein. Eine Quote kann beispielsweise nur ausdrücken, dass alle Anforderungen einen Link besitzen. Definieren Sie Nenner und Zählregel, bevor Sie daraus einen Status ableiten. Separat sichtbar bleiben müssen ungeprüfte Kriterien, nicht passende Versionen und offene relevante Befunde. Eine vollständig verlinkte Matrix kann einen unvollständigen Nachweisstand dokumentieren; sie ersetzt keine fachliche Bewertung der Ergebnisse.
Wie nehmen wir Herstellerbelege in die Traceability auf?
Referenzieren Sie den konkreten Beleg mit Version, Umfang und relevanter Ergebnisstelle. Ergänzen Sie, welcher Teil Ihrer Anforderung dadurch abgedeckt wird und welche kundenspezifischen Fragen verbleiben. Ein Paketname allein reicht für diese Zuordnung nicht. Die Bewertung der Belege gehört zum Übernahmeprozess; die Matrix hält dessen Ergebnis und die Verbindung zum eigenen Anforderungsstand nachvollziehbar fest.
Quellen: [2]
Wer sollte die Traceability Matrix pflegen und fachlich prüfen?
Benennen Sie die Pflegeverantwortung und unterscheiden Sie formale Aktualisierung von fachlicher Entscheidung. Projektkoordination kann Referenzen pflegen; zuständige Fachpersonen beurteilen, ob Ergebnisse Kriterien abdecken. IT hilft beim Konfigurationsstand, QA entsprechend den Aufgaben im Qualitätssystem. Die Rollen können im KMU teilweise zusammenfallen. Befugnisse und benötigte Kompetenz müssen dennoch klar sein; eine universelle Unterschriftenliste gibt es hierfür nicht.
Was tun wir mit einer Anforderung, die nicht mehr benötigt wird?
Dokumentieren Sie die Änderung und die Begründung für den entfallenden Umfang. Prüfen Sie Abhängigkeiten, etwa zu anderen Prozessen, Daten oder Betriebsregeln. Kennzeichnen Sie den früheren Stand als historisch beziehungsweise den neuen Umfang als nicht anwendbar, statt die Zeile kommentarlos zu löschen. Ein entfallener Wunsch darf nicht mit einer weiterhin anwendbaren GMP-Anforderung verwechselt werden.
Wie prüfen wir die Matrix effizient vor einer Übergabe?
Gehen Sie gezielt eine kritische Anforderung, eine jüngste Änderung und einen offenen Befund durch. Lassen sich passende Versionen, Ist-Ergebnisse und Entscheidungen ohne Zusatzwissen finden? Kontrollieren Sie zusätzlich systematisch fehlende Referenzen und widersprüchliche Statuswerte. Eine solche Stichprobe hilft beim Review, ist aber kein pauschaler Ersatz für die benötigte fachliche Vollständigkeitsprüfung des freizugebenden Umfangs.
Quellen & fachlicher Stand
Primärquellen wurden am 6. Oktober 2026 geöffnet. Betrachtet wird die Nachvollziehbarkeit der Validierung im Humanarzneimittel-GMP. Annex 15 wird ergänzend innerhalb seines Anwendungsbereichs für Qualifizierung und Validierung eingeordnet. Tabellen, Statusbegriffe und Rollenbeispiel sind eigene illustrative Arbeitshilfen, keine durchgeführten Tests oder vorgeschriebenen Dokumentvorlagen.
- Europäische Kommission: EudraLex Volume 4 – aktuelles Verzeichnis für Humanarzneimittel-GMP
- EU-GMP Annex 11: Computerised Systems – insbesondere §4.4 und §10
- EU-GMP Annex 15: Qualification and Validation – Dokumentbeziehungen und Ergebnisbewertung
- EU-GMP Chapter 4: Documentation – Identifikation, Lenkung und Aufzeichnungen
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Anforderungen, Konfiguration und Ergebnisbelege nachvollziehbar verbinden
Daniel Herrmann Consulting unterstützt Sie dabei, vorhandene Nachweise einzuordnen, offene Beziehungen sichtbar zu machen und die Traceability für Einführung, Änderung und Betrieb praktikabel aufzubauen.
- IT-GxP-Audit →
Nachweisstand und offene Verbindungen zwischen Anforderungen, Tests und Befunden bewerten.
- IT-GxP-Consulting →
Eine pflegbare Nachweiskette für konkrete Prozesse und Systemänderungen erarbeiten.