# Computer System Validation (CSV): Grundlagen, regulatorische Anforderungen und Validierung von Cloud-Software im GxP-Umfeld

> Computer System Validation im GxP-Umfeld: Annex 11, 21 CFR Part 11, GAMP 5, CSA, Validierungslebenszyklus, Cloud- und SaaS-Validierung, vorvalidierte Software und Inspektionsbefunde. Stand November 2026.

- Quelle: https://info-pharma.de/computer-system-validation/
- Sprache: Deutsch
- Stand: 2026-11-06
- Bereich: Startseite › Regulatorische Anforderungen › Computer System Validation
- English version: https://info-pharma.de/en/computer-system-validation/index.html.md

---

*Stand: 5. November 2026*

**Kurzfassung:** Computer System Validation (CSV) ist der dokumentierte Nachweis, dass ein computergestütztes System für seinen beabsichtigten Gebrauch geeignet ist und dies über seinen gesamten Lebenszyklus bleibt. Die Pflicht dazu ergibt sich in der EU aus EudraLex Volume 4, Annex 11[1], und in den USA unter anderem aus 21 CFR 11.10(a)[2]. Die Annex-11-Revision liegt im November 2026 weiterhin nur als Entwurf vor. Die FDA-Guidance zu Computer Software Assurance (CSA) ist seit September 2025 final. Bei Cloud- und SaaS-Software sollte der Anbieter das System vorvalidiert liefern und seine IQ- und OQ-Dokumentation dem Anwender bereitstellen. Die Verantwortung für den validierten Zustand im eigenen Einsatz bleibt beim Anwender.

## 1. Was ist Computer System Validation?

Nach Annex 11 muss ein computergestütztes System validiert sein. Ersetzt es einen manuellen Prozess, darf das nicht zu einer geringeren Produktqualität, Prozesskontrolle oder Qualitätssicherung führen. Das Risikomanagement ist über den gesamten Lebenszyklus anzuwenden[1]. Die FDA definiert Softwarevalidierung als Bestätigung durch Prüfung und objektive Nachweise, dass Softwarespezifikationen den Anforderungen der Nutzer und dem beabsichtigten Gebrauch entsprechen[5]. Die PIC/S hat ihre Erwartungen an computergestützte Systeme in PI 011 zusammengefasst[3].

Verpflichtend ist CSV in GxP-Umgebungen aus drei Gründen:

- **Datenintegrität:** Daten müssen vollständig, konsistent und korrekt sein, und zwar über ihren gesamten Lebenszyklus[4].
- **Patientensicherheit:** Fehlerhafte Systeme können sicherheitsrelevante Entscheidungen verfälschen.
- **Produktqualität:** Freigabe- und Herstellentscheidungen beruhen auf systemgenerierten Daten.

**Abgrenzung der Begriffe:**

- **Qualifizierung** bezieht sich nach EU-GMP-Annex 15 auf Ausrüstung, Infrastruktur und Systemkomponenten. Sie wird in Stufen wie IQ, OQ und PQ nachgewiesen[6].
- **Validierung** belegt, dass ein Prozess oder ein System in seinem konkreten Einsatz die Anforderungen erfüllt.
- **Verifizierung** bezeichnet in GAMP 5 die Prüfung, ob einzelne Spezifikationen erfüllt sind. Sie ist ein Baustein der Validierung[7].

Zum regulatorischen Rahmen der guten Herstellungspraxis siehe auch unseren Beitrag zur [GMP](https://info-pharma.de/gmp/).

## 2. Regulatorischer Rahmen

### EU GMP Annex 11 (2011) und Revisionsentwurf (2025)

Der geltende Annex 11 ist seit dem 30. Juni 2011 anzuwenden[1]. Für die CSV sind drei Bereiche zentral:

- **Lieferanten (Abschnitt 3):** Bei Dritten sind formelle Vereinbarungen mit klar geregelten Verantwortlichkeiten nötig. Kompetenz und Zuverlässigkeit des Lieferanten sind Schlüsselfaktoren. Ob ein Audit erforderlich ist, ergibt sich aus der Risikobewertung. Die Dokumentation zu Standardprodukten muss der Anwender prüfen.
- **Validierung (Abschnitt 4):** Die Validierung umfasst die relevanten Lebenszyklusschritte und beruht auf einer User Requirements Specification. Der Anwender muss angemessen sicherstellen, dass das System nach einem geeigneten Qualitätsmanagementsystem entwickelt wurde.
- **Periodische Überprüfung (Abschnitt 11):** Systeme sind regelmäßig daraufhin zu bewerten, ob sie im validierten Zustand und GMP-konform bleiben.

**Status der Revision:** Die Europäische Kommission hat am 7. Juli 2025 einen Entwurf veröffentlicht, gemeinsam mit einem revidierten Kapitel 4 und einem neuen Annex 22 zu künstlicher Intelligenz. Der Entwurf umfasst 19 Seiten und 17 Abschnitte, darunter „Supplier and Service Management“, „Periodic Review“ und „Security“[8]. Die Konsultation ist abgeschlossen[9]. Am 5. November 2026 führt die EudraLex-Übersicht weiterhin Annex 11 mit dem Vermerk „revision January 2011“. Ein finaler Text und ein Anwendungsdatum sind nicht veröffentlicht[6]. Alle Aussagen in diesem Artikel zum Entwurf beschreiben deshalb absehbare Erwartungen und keine geltenden Anforderungen.

### 21 CFR Part 11 und weitere FDA-Vorgaben

21 CFR 11.10(a) verlangt, Systeme zu validieren, um Genauigkeit, Zuverlässigkeit, eine gleichbleibende bestimmungsgemäße Leistung und die Erkennbarkeit ungültiger oder veränderter Datensätze sicherzustellen[2]. Details behandelt unser Beitrag zu [21 CFR Part 11](https://info-pharma.de/21-cfr-part-11/).

Für Medizinprodukte gilt seit dem 2. Februar 2026 die Quality Management System Regulation (QMSR). Sie übernimmt ISO 13485:2016 per Referenz in 21 CFR 820. ISO 13485 verlangt in den Abschnitten 4.1.6 und 7.5.6 eine Softwarevalidierung, die dem Risiko angemessen ist[10].

### ICH E6(R3) und EMA-Leitlinie zu computergestützten Systemen in klinischen Prüfungen

Die Principles und Annex 1 von ICH E6(R3) gelten in der EU seit dem 23. Juli 2025, Annex 2 ab dem 15. Januar 2027[13][14]. E6(R3) widmet der Data Governance einen eigenen Abschnitt 4. Danach beruht die Validierung computergestützter Systeme auf einer Risikobewertung (4.3). Der Sponsor führt ein Verzeichnis der wichtigen Systeme mit deren Validierungsstatus (3.16.1(x))[13]. Die EMA-Guideline on computerised systems and electronic data in clinical trials wurde im März 2023 veröffentlicht und ist seit September 2023 anzuwenden. Sie konkretisiert die Erwartungen an Validierung, Verantwortlichkeiten und an Dienstleister, ausdrücklich auch bei Cloud-Lösungen[15]. Siehe auch [GCP](https://info-pharma.de/gcp/).

### PIC/S und ISPE GAMP 5

PIC/S PI 041-1 zu Datenmanagement und Datenintegrität ist seit dem 1. Juli 2021 in Kraft. Abschnitt 9 behandelt computergestützte Systeme und verweist für die gute Praxis auf PI 011[16][3]. ISPE GAMP 5 Second Edition (Juli 2022) behält den risikobasierten Rahmen bei. Die Neuauflage betont die Rolle von Dienstleistern, iterative Entwicklung und „critical thinking“ erfahrener Fachleute. Regulierte Unternehmen sollen Lieferanten möglichst stark einbinden, um deren Wissen, Erfahrung und Dokumentation zu nutzen[7].

### FDA Computer Software Assurance (CSA)

Die FDA hat die Guidance „Computer Software Assurance for Production and Quality System Software“ im September 2025 final veröffentlicht. Die Bekanntmachung im Federal Register erfolgte am 24. September 2025[11][12]. Die Guidance ersetzt Abschnitt 6 der „General Principles of Software Validation“ und richtet sich formal an Medizinproduktehersteller[11]. In der Pharma-Praxis dient sie als Orientierung, nicht als bindende Vorgabe.

## 3. Der Validierungslebenszyklus

GAMP 5 ordnet Software in Kategorien ein:

- Kategorie 1: Infrastruktursoftware
- Kategorie 3: nicht konfigurierte Produkte
- Kategorie 4: konfigurierte Produkte
- Kategorie 5: individuell entwickelte Anwendungen

Je höher die Kategorie und das Risiko, desto umfangreicher werden Spezifikation und Test[7]. Das V-Modell stellt jeder Spezifikationsebene eine Prüfebene gegenüber: URS zu PQ/UAT, Funktionsspezifikation zu OQ, Designspezifikation zu IQ. GAMP 5 Second Edition betont, dass dieser Ansatz auch iterative und agile Entwicklung trägt[7]. Der Annex-11-Entwurf verlangt eine dokumentierte Traceability zwischen Anforderungen, Spezifikationen und Testfällen. Testfälle ohne Bezug zu einer Anforderung erfüllen die Anforderungen an Qualifizierung und Validierung nicht (9.5)[8].

**Phasen des CSV-Lebenszyklus**

| Phase | Zweck | Typische Dokumente | Verantwortlich |
| --- | --- | --- | --- |
| Validierungsplanung | Umfang, Strategie und Rollen festlegen | Validierungsplan | System Owner, QA |
| Anforderungen | Beabsichtigten Gebrauch beschreiben | User Requirements Specification (URS) | Prozessverantwortliche, Anwender |
| Risikobewertung | Prüftiefe nach Risiko für Patient, Produkt und Daten steuern | Risikobewertung (z. B. FMEA) | System Owner, QA, Fachexperten |
| Spezifikation | Funktionen und Konfiguration beschreiben | Funktions-, Design- und Konfigurationsspezifikation | Lieferant, IT, System Owner |
| IQ | Korrekte Installation nachweisen | IQ-Protokoll und -Bericht | Lieferant oder IT |
| OQ | Funktionen gemäß Spezifikation nachweisen | OQ-Protokoll und -Bericht | Lieferant oder Anwender |
| PQ / UAT | Eignung im realen Prozess nachweisen | PQ-/UAT-Skripte und -Berichte | Anwender |
| Traceability | Anforderungen mit Tests verknüpfen | Traceability Matrix | Validierungsverantwortliche |
| Freigabe | Eignung bestätigen | Validierungsbericht | System Owner, QA |
| Betrieb | Validierten Zustand erhalten | Change-Control-Records, Berichte der periodischen Überprüfung | System Owner, QA |
| Außerbetriebnahme | Daten erhalten und Lesbarkeit sichern | Stilllegungsplan, Migrations- und Archivierungsnachweise | System Owner, QA, IT |

Annex 11 verlangt, Änderungen kontrolliert umzusetzen (Abschnitt 10) und Systeme periodisch zu bewerten (Abschnitt 11)[1]. Nach dem Entwurf richtet sich die Häufigkeit der periodischen Überprüfung nach dem Risiko. Wird ein System außer Betrieb genommen, ist eine abschließende Überprüfung durchzuführen (14.3)[8].

## 4. CSV und CSA: was sich praktisch ändert

CSA ersetzt die Validierungspflicht nicht. Die Guidance setzt aber andere Schwerpunkte:

- Ausgangspunkt sind der beabsichtigte Gebrauch und die Frage, ob eine Softwarefunktion ein hohes Prozessrisiko birgt („high process risk“) oder nicht.
- Daraus folgt, wie stark abgesichert werden muss. Für Funktionen mit geringerem Risiko sind ungeskriptete Verfahren wie Ad-hoc-, explorative oder fehlerorientierte Tests ausdrücklich zulässig. Skriptbasierte Tests konzentrieren sich auf Funktionen mit hohem Risiko.
- Nachweise sollen nur so umfangreich sein wie nötig und dürfen digital geführt werden[11].

GAMP 5 Second Edition verfolgt denselben Ansatz und stellt das kritische Denken erfahrener Fachleute über die bloße Menge an Testdokumentation[7]. Für Anwender bedeutet das weniger Screenshots bei Funktionen mit geringem Risiko. Dafür müssen Risikobegründungen nachvollziehbar dokumentiert sein, und der Testaufwand konzentriert sich auf Funktionen, die Datenintegrität und Produktqualität tragen.

## 5. Validierung von Cloud- und SaaS-Software

**Geteilte Verantwortung:** Der Anbieter verantwortet Entwicklung, Infrastruktur, Release-Tests und Betrieb. Der Anwender verantwortet Intended Use, Konfiguration, PQ/UAT, Prozesse und Nutzerverwaltung. Der Annex-11-Entwurf stellt klar, dass der Anwender voll verantwortlich bleibt, wenn er sich auf die Qualifizierung oder den Betrieb durch einen Anbieter stützt (7.1). Bei SaaS darf der Anbieter die Anforderungsspezifikation liefern. Der Anwender muss sie aber prüfen, genehmigen und übernehmen (6.3)[8].

**Lieferantenbewertung und -audit:** Je nach Risiko und Kritikalität ist ein Audit oder eine gründliche Bewertung durchzuführen. Sie soll klären, ob die Verfahren und die Dokumentation des Anbieters ausreichen und ob sie genutzt werden können, statt Tätigkeiten zu wiederholen (7.2)[8].

**Qualitätsvereinbarung:** Der Entwurf zählt Mindestinhalte auf (7.5):

- zu liefernde Tätigkeiten und Dokumentation
- Service Level Agreements und KPIs
- Bedingungen für Audits
- Unterstützung bei Inspektionen
- Kommunikation von Qualitäts- und Sicherheitsproblemen
- eine Exit-Strategie, damit der Anwender die Kontrolle über seine Daten behält
- ein Freigabeprozess für neue Versionen mit der Möglichkeit, diese vorab zu testen[8]

**Häufige Releases:** Der Anwender muss jedes Release auf Auswirkungen auf seinen validierten Zustand bewerten. Werkzeuge dafür sind Release Notes, Risikoeinstufungen des Anbieters und Testumgebungen vor dem Release. Regressionstests richten sich nach dem Risiko.

**Multi-Tenant-Umgebungen:** Mehrere Kunden teilen sich eine Plattform. Konfigurationen sind daher strikt kundenspezifisch zu dokumentieren. Validierungsnachweise des Anbieters gelten für die gemeinsame Codebasis, nicht für die Konfiguration des einzelnen Kunden.

**Datenhaltung und Datenintegrität:** Der Entwurf verlangt, kritische Daten bei Bedarf in ein entfernt gelegenes zweites Rechenzentrum zu replizieren (15.6) und Disaster-Recovery-Pläne zu testen (15.7)[8]. PI 041 behandelt Datenintegrität bei ausgelagerten Tätigkeiten ausdrücklich[16]. Im klinischen Umfeld gelten die EMA-Leitlinie von 2023 und ICH E6(R3) Abschnitt 4[15][13]. Zur Ablage validierungsrelevanter Studiendokumente siehe [TMF und eTMF](https://info-pharma.de/tmf-etmf/).

## 6. Vorvalidierte Software: warum sie gerade bei Cloud-Lösungen Standard sein sollte

**Vorvalidierung als Standard:** Software, gerade Cloud-Software, sollte vorvalidiert sein. Bei SaaS hat der Anwender keinen Zugriff auf Installation, Infrastruktur und Codebasis und kann IQ sowie wesentliche Teile der OQ gar nicht selbst sinnvoll durchführen. GAMP 5 Second Edition fordert ausdrücklich, Wissen, Erfahrung und Dokumentation von Lieferanten so weit wie möglich zu nutzen[7].

**IQ- und OQ-Berichte des Anbieters:** Umfangreiche IQ- und OQ-Berichte des Anbieters müssen vorhanden sein und dem Anwender zur Verfügung gestellt werden. Bereits Annex 11 (2011) verlangt, die Lieferantendokumentation zu prüfen und die Qualität der Entwicklung sicherzustellen (3.3, 4.5)[1]. Nach dem Entwurf darf Qualifizierungs- und Validierungsdokumentation ganz oder teilweise vom Anbieter stammen. Der Anwender muss sie aber prüfen, ihre Nutzung autorisieren und am eigenen Standort erklären können (9.9, 7.4)[8].

**Vorlagen für PQ und UAT:** Solche Vorlagen sind ebenfalls sehr hilfreich. Sie strukturieren und beschleunigen den anwenderspezifischen Teil der Validierung, weil sie an die URS anknüpfen und die Traceability zur Anbieterdokumentation vorbereiten.

**Schneller einsatzbereit:** Vorvalidierte Software ist deshalb immer schneller einsatzbereit. Der Anwender baut auf der geprüften Lieferantendokumentation auf, statt Kernfunktionen selbst zu testen. Genau diese Nutzung „rather than repeating the activities“ sieht der Annex-11-Entwurf vor (7.2)[8].

**Verantwortung des Anwenders:** Fair ergänzt: Die Verantwortung für den validierten Zustand im eigenen Einsatz bleibt beim Anwender[8]. Dazu gehören Intended Use, Konfiguration, PQ/UAT, Schulung, Nutzerverwaltung und die begleitenden Prozesse.

### Beispiele für Anbieter mit Validierungsdokumentation (alphabetisch, ohne Wertung)

Die folgenden Beispiele stammen aus unterschiedlichen Softwarekategorien und zeigen, dass Vorvalidierung kategorieübergreifend relevant ist. Die Angaben beruhen ausschließlich auf Herstellerquellen.

**Docuply (docuply.io), Kategorie: eQMS mit integriertem eTMF.** Docuply ist ein cloudbasiertes elektronisches Qualitätsmanagementsystem mit integriertem Trial Master File und Hosting in der EU-Cloud. Laut Preisseite wird das System vorvalidiert (IQ & OQ) für den sofortigen Einsatz bereitgestellt. Die kostenpflichtigen Tarife umfassen die Computersystemvalidierung (Installation & Operational Qualification) sowie die Aufwände für die initiale Vendor Qualification[18].

**Harbor (runharbor.com), Kategorie: EDC- und Datenplattform für klinische Studien.** Harbor wurde 2025 von Albert Cai und Nathan H. Leung gegründet, gehört zum Y-Combinator-Batch Spring 2026 und beschreibt sich im YC-Profil inzwischen als „AI-native CRO“[21]. Laut Website erhält jeder Lizenznehmer ein Verification-and-Validation-Paket mit Risiko- und Traceability-Matrizen. Nach Herstellerangabe werden Anforderungen, Traceability-Matrix und Testberichte für jedes Release automatisch erzeugt[19][20]. Der Hersteller weist selbst darauf hin, dass der Sponsor die studienspezifische Konfiguration validieren muss, üblicherweise per UAT[20].

**Veeva Vault RIM (veeva.com), Kategorie: Regulatory Information Management.** Vault RIM ist eine Anwendungssuite, unter anderem mit Registrations und Submissions, auf der Multi-Tenant-Cloud-Plattform Veeva Vault[23][22]. Laut Validation Features Brief führt und dokumentiert Veeva IQ und OQ für jedes Major Release. Je Release stellt Veeva ein Validierungspaket bereit (Validierungsplan, Anforderungsdokumente, Testprotokoll, IQ/OQ, Traceability-Matrizen, Validierungsbericht) sowie UAT-Skripte, die sich für die PQ anpassen lassen. Neue Versionen erscheinen nach Herstellerangabe „approximately every four months“, vorab gibt es ein Release Impact Assessment und Pre-Release-Vaults[22].

## 7. Typische Inspektionsbefunde zu computergestützten Systemen

**EMA:** Im Jahresbericht 2024 der GCP Inspectors Working Group stehen für 67 von der CHMP angeforderte Inspektionen 335 Major- und Critical-Befunde. In der Kategorie „Computer System“ waren es 14 Major-Befunde, davon 12 bei Sponsoren. Im Datenmanagement nennt der Bericht unter anderem „Inadequate data migration and system validation“[24].

**FDA:** Warning Letters unter 21 CFR 211.68(b) betreffen regelmäßig fehlende Zugriffskontrollen und Audit Trails:

- Guangxi Yulin Pharmaceutical (30. September 2025): Geräten für UV-Vis- und IR-Spektroskopie fehlte eine Audit-Trail-Funktion, und Analysten konnten Daten löschen und verändern. Es handelte sich um eine Wiederholungsbeobachtung aus 2016[25].
- International Laboratories Corp (10. März 2025): Analysten hatten Administratorrechte, mit denen sich Daten sowie Datum und Uhrzeit von Tests verändern ließen[26].
- Wisconsin Pharmacal (22. August 2025): Administratorrechte für das Ändern und Löschen von Dateien in einem Chromatographie-Datensystem waren nicht angemessen kontrolliert[27].

Gemeinsam genutzte Logins sind nach der FDA-Guidance zur Datenintegrität nicht CGMP-konform, weil sich dann keine eindeutige Person identifizieren lässt[17]. Ajay Babu Pazhayattil, Marzena Ingram und Koti Reddy Bhimavarapu haben in einer Gastkolumne in Pharmaceutical Online (15. Dezember 2025) 85 Warning Letters an Arzneimittelhersteller ausgewertet, die zwischen dem 1. Januar und dem 9. Dezember 2025 veröffentlicht wurden. 15 % der Schreiben nannten Datenintegritätsprobleme, bei Standorten in Indien 60 %, in China 21 % und in den USA 10 %. Es handelt sich um eine Branchenanalyse, nicht um eine FDA-Statistik[28].

## FAQ

### Was ist Computer System Validation?

CSV ist der dokumentierte Nachweis, dass ein computergestütztes System für seinen beabsichtigten Gebrauch geeignet ist und über seinen Lebenszyklus in einem validierten Zustand bleibt. Grundlagen sind unter anderem Annex 11 und 21 CFR 11.10(a)[1][2].

### Was ist der Unterschied zwischen IQ, OQ und PQ?

Die IQ belegt die korrekte Installation, die OQ das spezifikationsgemäße Funktionieren und die PQ die Eignung im realen Prozess des Anwenders[6].

### Was ist der Unterschied zwischen CSV und CSA?

CSA ist ein risikobasierter Ansatz innerhalb der Validierungspflicht. Der Aufwand richtet sich nach dem Prozessrisiko, und für Funktionen mit geringerem Risiko sind ungeskriptete Tests zulässig. Die FDA-Guidance ist seit September 2025 final und richtet sich formal an Medizinproduktehersteller[11].

### Muss Cloud-Software validiert werden?

Ja. Annex 11 gilt unabhängig davon, ob ein System selbst entwickelt, gekauft oder als Service bezogen wird. Der Revisionsentwurf stellt das ausdrücklich klar (6.1)[8].

### Was bedeutet vorvalidierte Software?

Der Anbieter hat IQ und OQ für das Standardprodukt durchgeführt und stellt die Dokumentation bereit. Der Anwender prüft sie, nutzt sie und ergänzt die anwenderspezifische Validierung wie PQ und UAT[7][8].

### Wer ist für die Validierung von SaaS-Software verantwortlich?

Der regulierte Anwender. Er darf sich auf die Dokumentation des Anbieters stützen, bleibt aber voll verantwortlich (Annex-11-Entwurf 7.1, 9.9)[8]. Zur Aufsicht über Dienstleister in klinischen Studien siehe [CRO Sponsor Oversight](https://info-pharma.de/cro-sponsor-oversight/).

## Literaturverzeichnis

1. Europäische Kommission: EudraLex Volume 4, Annex 11: Computerised Systems (Revision 1, anzuwenden ab 30.06.2011). https://health.ec.europa.eu/system/files/2016-11/annex11_01-2011_en_0.pdf (abgerufen am 05.11.2026)
2. eCFR: 21 CFR Part 11 – Electronic Records; Electronic Signatures, § 11.10(a). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 (abgerufen am 05.11.2026)
3. PIC/S: PI 011-3, Good Practices for Computerised Systems in Regulated „GxP“ Environments. https://picscheme.org/en/publications (abgerufen am 05.11.2026)
4. MHRA: ‘GXP’ Data Integrity Guidance and Definitions, Revision 1, März 2018. https://assets.publishing.service.gov.uk/media/5aa2b9ede5274a3e391e37f3/MHRA_GxP_data_integrity_guide_March_edited_Final.pdf (abgerufen am 05.11.2026)
5. FDA: General Principles of Software Validation; Final Guidance (2002). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation (abgerufen am 05.11.2026)
6. Europäische Kommission: EudraLex Volume 4 – GMP Guidelines (Übersicht inkl. Annex 11 und Annex 15). https://health.ec.europa.eu/medicinal-products/eudralex/eudralex-volume-4_en (abgerufen am 05.11.2026)
7. ISPE: GAMP 5 Guide, 2nd Edition: A Risk-Based Approach to Compliant GxP Computerized Systems (Juli 2022). https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition (abgerufen am 05.11.2026)
8. Europäische Kommission: Annex 11: Computerised Systems, Konsultationsentwurf (Juli 2025). https://health.ec.europa.eu/document/download/40231f18-e564-4043-94de-c031f813d38b_en?filename=mp_vol4_chap4_annex11_consultation_guideline_en.pdf (abgerufen am 05.11.2026)
9. Europäische Kommission: Stakeholders’ Consultation on EudraLex Volume 4 – Chapter 4, Annex 11 and New Annex 22 (geschlossen). https://health.ec.europa.eu/consultations/stakeholders-consultation-eudralex-volume-4-good-manufacturing-practice-guidelines-chapter-4-annex_en (abgerufen am 05.11.2026)
10. Federal Register: Medical Devices; Quality System Regulation Amendments, Final Rule, 89 FR 7496 (02.02.2024; wirksam ab 02.02.2026). https://www.federalregister.gov/documents/2024/02/02/2024-01709/medical-devices-quality-system-regulation-amendments (abgerufen am 05.11.2026)
11. FDA: Computer Software Assurance for Production and Quality System Software, Final Guidance (September 2025). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-system-software (abgerufen am 05.11.2026)
12. Federal Register: Computer Software Assurance for Production and Quality System Software; Availability, 90 FR 45945 (24.09.2025). https://www.federalregister.gov/documents/2025/09/24/2025-18468/computer-software-assurance-for-production-and-quality-system-software-guidance-for-industry-and (abgerufen am 05.11.2026)
13. EMA: ICH E6(R3) Guideline for good clinical practice (GCP), Step 5. https://www.ema.europa.eu/en/documents/scientific-guideline/ich-e6-r3-guideline-good-clinical-practice-gcp-step-5_en.pdf (abgerufen am 05.11.2026)
14. Europäische Kommission, ACT EU: Good clinical practice modernisation. https://accelerating-clinical-trials.europa.eu/our-work/good-clinical-practice-modernisation_en (abgerufen am 05.11.2026)
15. EMA: Guideline on computerised systems and electronic data in clinical trials (EMA/INS/GCP/112288/2023). https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/guideline-computerised-systems-electronic-data-clinical-trials_en.pdf (abgerufen am 05.11.2026)
16. PIC/S: PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments (01.07.2021). https://picscheme.org/docview/4234 (abgerufen am 05.11.2026)
17. FDA: Data Integrity and Compliance With Drug CGMP – Questions and Answers (Dezember 2018). https://www.fda.gov/media/119267/download (abgerufen am 05.11.2026)
18. Docuply: Preise. https://docuply.io/preise/ (abgerufen am 05.11.2026)
19. Harbor: The intelligent EDC (Website). https://runharbor.com/ (abgerufen am 05.11.2026)
20. Harbor (A. Cai): Compliance Without Compromise: How Harbor Ships Fast and Stays Constantly Validated (19.09.2025). https://runharbor.com/blog/2025-09-19-software-validation (abgerufen am 05.11.2026)
21. Y Combinator: Harbor – Company Profile. https://www.ycombinator.com/companies/runharbor (abgerufen am 05.11.2026)
22. Veeva Systems: Veeva Vault Validation Features Brief. https://www.veeva.com/resources/veeva-vault-validation-product-brief/ (abgerufen am 05.11.2026)
23. Veeva Systems: More than 200 Companies Select Veeva Vault RIM Applications (Pressemitteilung, 2020). https://www.veeva.com/wp-content/uploads/2020/06/More-than-200-Companies-Select-Veeva-Vault-RIM-Applications-to-Streamline-Regulatory-Operations.pdf (abgerufen am 05.11.2026)
24. EMA: Annual Report of the GCP Inspectors’ Working Group 2024 (EMA/INS/GCP/37608/2025). https://www.ema.europa.eu/en/documents/report/annual-report-good-clinical-practice-inspectors-working-group-2024_en.pdf (abgerufen am 05.11.2026)
25. FDA: Warning Letter Guangxi Yulin Pharmaceutical Group Co. Ltd., MARCS-CMS 710422 (30.09.2025). https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/guangxi-yulin-pharmaceutical-group-co-ltd-710422-09302025 (abgerufen am 05.11.2026)
26. FDA: Warning Letter International Laboratories Corp, MARCS-CMS 698522 (10.03.2025). https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/international-laboratories-corp-698522-03102025 (abgerufen am 05.11.2026)
27. FDA: Warning Letter Wisconsin Pharmacal Company, LLC, MARCS-CMS 710329 (22.08.2025). https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/wisconsin-pharmacal-company-llc-710329-08222025 (abgerufen am 05.11.2026)
28. Pazhayattil, A. B.; Ingram, M.; Bhimavarapu, K. R.: What 2025 FDA Warning Letters Tell Us About GMP Compliance. Pharmaceutical Online, 15.12.2025. https://www.pharmaceuticalonline.com/doc/what-fda-warning-letters-tell-us-about-gmp-compliance-0001 (abgerufen am 05.11.2026)