IT-Systeme · Praxisleitfaden

Dataverse-Auditing für GxP: Tabellen, Felder und Aufbewahrung

Auditing ist in der Umgebung aktiviert. Das kritische Feld bleibt trotzdem ohne Historie. Bei Dataverse müssen Konfiguration, Datenmodell und benötigte Nachvollziehbarkeit zusammenpassen – bis zur späteren Anzeige und Aufbewahrung der Einträge.

Daniel Herrmann
Compliance-Experte für Life Sciences
Fachlicher Stand: 7 Minuten Lesezeit
Inhaltsverzeichnis

Das Wichtigste vorab

Was muss man bei Dataverse-Auditing für GxP prüfen?

Prüfen Sie die Aktivierung auf Umgebungs-, Tabellen- und Spaltenebene, die tatsächliche Abdeckung kritischer Ereignisse und den Zugriff auf die Historie. Bewerten Sie administrative Änderungen, Aufbewahrung und Review separat. Datenänderungs-Auditing, Zugriffsprotokollierung und Aktivitätslogging sind unterschiedliche Funktionen und dürfen nicht als ein vollständiger Nachweis gleichgesetzt werden.

Den Datenprozess statt nur den Audit-Schalter betrachten

Dataverse kann die Datenplattform einer Power-Apps-Anwendung oder anderer Dynamics-Prozesse sein. Für die GxP-Bewertung zählt, welche Aufzeichnungen dort entstehen und welche Entscheidungen sie tragen. Ein allgemeiner CRM-Datensatz und ein qualitätsrelevanter Prüfdatensatz brauchen nicht dieselbe Bewertung.

Dieser Leitfaden betrachtet die aktuelle Dataverse-Online-Dokumentation. Abweichende Produkte und On-Premises-Varianten können andere Funktionen besitzen. Dokumentieren Sie Umgebung, App-Typ, Tabellen, Erweiterungen und relevante technische Identitäten. Die tatsächlich genutzte Konfiguration bleibt der Prüfgegenstand.

Annex 11 und PIC/S liefern den regulatorischen beziehungsweise datenintegritätsbezogenen Rahmen. Die folgenden Konfigurations- und Prüfvorschläge sind eigene Ableitungen. Ein Herstellerhinweis, Auditing könne Compliance unterstützen, ist keine Bestätigung, dass der konkrete Prozess alle Anforderungen erfüllt.

Quellen: [1] [2] [3]

Drei Konfigurationsebenen gemeinsam nachweisen

Microsoft beschreibt die Aktivierung auf Umgebungs-, Tabellen- und Spaltenebene. Deshalb wird für jedes kritische Feld geprüft, ob die erforderlichen Ebenen passend eingeschaltet sind. Der globale Umgebungsschalter allein genügt nicht als Abdeckungsnachweis.

Erstellen Sie eine Liste fachlicher Daten mit den technischen Namen ihrer Tabellen und Spalten. Anzeigenamen können sich ändern und sind nicht immer eindeutig. Notieren Sie, ob ein Feld Standard, kundenspezifisch, berechnet oder anderweitig besonders ist. Die Herstellerdokumentation beschreibt Unterstützung für benutzerdefinierte und viele anpassbare Tabellen und Spalten; prüfen Sie die konkrete Unterstützung.

Übernehmen Sie Auditing-Einstellungen kontrolliert zwischen Entwicklungs-, Test- und Produktionsumgebung. Ein erfolgreiches Lösungsdeployment sollte nicht mit einer ungeprüften Behauptung über jede Umgebungsoption verwechselt werden. Vergleichen Sie den tatsächlichen Zielstand und führen Sie dort die benötigten Nachweise aus.

Quellen: [3] [4]

Ereignisse und Logarten nicht vermischen

Datenänderungs-Auditing kann bestimmte Erstellungs-, Änderungs-, Lösch- und weitere unterstützte Ereignisse erfassen. Schemaänderungen und gewöhnliche Abruf- oder Exportvorgänge sind damit nicht pauschal als derselbe Auditdatensatz abgedeckt. Für weitere Aktivitäten beschreibt Microsoft zusätzliche Logging-Funktionen und Voraussetzungen.

Ordnen Sie deshalb jeder fachlichen Frage eine konkrete Quelle zu: Wer änderte den Grenzwert? Wer rief Daten ab? Wer änderte eine Spaltendefinition? Die Antworten können aus unterschiedlichen kontrollierten Verfahren oder Protokollen stammen. Lizenz, Umgebung und technische Verfügbarkeit sind dabei ausdrücklich zu prüfen.

Ein Änderungsgrund ist ebenfalls eine eigene Anforderung. Prüfen Sie, ob die Anwendung ihn erfasst und eindeutig mit dem Eingriff verbindet. Ein separater Kommentar ohne sicheren Bezug zur Änderung liefert nicht automatisch die benötigte Begründung.

Eigene Abdeckungsmatrix nach fachlicher Frage
FrageMögliche NachweisquelleZusätzliche Prüfung
Wer änderte einen Messwert?Dataverse-Datenänderungs-AuditingTabelle, Spalte, alter/neuer Wert, Identität
Wer löschte eine Aufzeichnung?Unterstütztes Löschereignis und KontextHistorischer Bezug bleibt verständlich
Wer las oder exportierte Daten?Geeignetes zusätzliches AktivitätsloggingLizenz, Umgebung, Ereignisumfang und Ziel prüfen
Wer änderte das Datenmodell?Kontrollierte Änderung und geeignete technische NachweiseNicht als automatisch vom Daten-Audit erfasst annehmen
Warum wurde korrigiert?Anwendungsfunktion für ÄnderungsgrundEindeutige Zuordnung und Review

Quellen: [3] [4] [1]

Beispiel: ein Feld bleibt unbemerkt außerhalb der Historie

Das Szenario ist konstruiert. Eine App speichert Probe P-31 mit Messwert, Einheit und Entscheidungsstatus. Umgebung und Tabelle sind für Auditing aktiviert. Die Spalte für den Entscheidungsstatus wurde nachträglich angelegt und ist nicht passend konfiguriert. Eine Messwertänderung erscheint in der Historie, der Statuswechsel nicht.

Der Test wird deshalb feldbezogen durchgeführt. Ein berechtigter Benutzer ändert zunächst den Messwert von 9,8 auf 10,2 mg und danach den Entscheidungsstatus. Ein Prüfer sucht beide Ereignisse. Das Soll verlangt im Beispiel die Nachvollziehbarkeit beider Änderungen mit Bezug zur Probe. Das fehlende Statusereignis wird als konkrete Abdeckungslücke dokumentiert.

Nach der Korrektur werden beide Fälle erneut geprüft. Zusätzlich werden andere relevante Felder und verwendete Schreibwege betrachtet, damit die Ursache nicht nur an einer Stelle behoben wird. Bei bereits erfolgter Nutzung wird die Bedeutung der früher fehlenden Historie gesondert bewertet. Die neue Aktivierung erzeugt keine nachträgliche Aufzeichnung alter Ereignisse.

Quellen: [3] [1]

Aufbewahrungswechsel mit dem tatsächlich verwendeten Weg prüfen

Die Microsoft-Dokumentation unterscheidet Konfigurationswege. Bei der beschriebenen Einstellung, die Auditdatensätze mit der jeweils aktiven Aufbewahrungsdauer versieht, gilt ein später geänderter Wert zunächst für neu erzeugte Einträge. Ältere Einträge behalten dort ihre ursprüngliche Frist. Gleichzeitig nennt Microsoft eine weitere Konfigurationsmöglichkeit über die Security-Seite, die eine Anwendung auf bestehende Logs ermöglicht.

Deshalb wäre die pauschale Aussage „Änderungen gelten immer nur für neue Logs“ zu weitgehend. Dokumentieren Sie, welchen Weg, welche Funktion und welchen Stand Sie tatsächlich verwenden. Prüfen Sie die Wirkung auf Alt- und Neueinträge gezielt. Eine längere sichtbare Standardfrist bestätigt nicht automatisch, dass bereits vorhandene Daten länger erhalten bleiben.

Das konstruierte Beispiel nutzt den zuerst beschriebenen Weg: Einträge unter einer kurzen Testfrist und Einträge nach deren Verlängerung werden getrennt verfolgt. Das Soll richtet sich nach der dokumentierten Funktion. Ein solcher Test wird in einer geeigneten Testumgebung mit entbehrlichen Testdaten geplant; produktiv benötigte Historie wird dafür nicht absichtlich gelöscht.

Eigene Arbeitshilfe für einen Retention-Wechsel
DatengruppeZu klärende FunktionErwarteter Nachweis
Einträge vor dem WechselUrsprünglich zugewiesene Frist und gewählter ÄnderungswegTatsächliche Wirkung auf vorhandene Logs
Einträge nach dem WechselAktive Frist bei EntstehungPassende Behandlung neuer Einträge
Alternative Security-KonfigurationUnterstützte Anwendung auf vorhandene LogsGezielt belegte Wirkung statt Annahme
Manuelle LöschbefugnisRollen und administrative FunktionenKontrollierter Zugriff und Eingriff
Archivierte HistorieKontext, Lesbarkeit und RechercheNutzbarkeit über erforderliche Dauer

Quellen: [3]

Rollen, Historienabruf und Review als Prozess testen

Ein vorhandener Auditdatensatz hilft wenig, wenn der zuständige Prüfer ihn nicht sehen oder dem richtigen Vorgang zuordnen kann. Prüfen Sie deshalb die tatsächliche Review-Rolle mit repräsentativen Daten. Administratorzugriff ist dafür kein Ersatz.

Bewerten Sie getrennt, wer Daten ändern, Auditing konfigurieren, Historie lesen und relevante Logs löschen kann. Technische Administratorrechte können weit reichen. Die benötigten Befugnisse werden kontrolliert vergeben und ihre Verwendung passend überwacht. Eine Rollenbezeichnung allein zeigt nicht den effektiven Zugriff.

Der Review betrachtet fachliche Bedeutung, etwa Korrekturen nach einer Entscheidung oder ungewöhnliche Statusfolgen. Legen Sie Zeitpunkt, Umfang und Umgang mit Auffälligkeiten nach Risiko fest. Eine exportierte Logdatei ohne fachliche Bewertung ist noch kein abgeschlossener Review.

Quellen: [1] [2] [3]

Konkrete Abnahmekriterien für die Anwendung festlegen

Für jedes kritische Ereignis werden Ausgangszustand, Aktion, erwartete Historie und tatsächliches Ergebnis dokumentiert. Ergänzen Sie Erstellen, Ändern, Löschen und die relevanten Anwendungs- beziehungsweise Schnittstellenwege. Prüfen Sie auch fehlende Berechtigung und den Abruf älterer Einträge.

Halten Sie Grenzen ausdrücklich fest. Wenn ein Exportereignis nicht über die verwendete Funktion erfasst wird, darf der Bericht keine vollständige Zugriffsprotokollierung behaupten. Bewerten Sie, ob diese Aussage für den konkreten Prozess benötigt wird und welche ergänzende Lösung geeignet ist.

Änderungen am Datenmodell, an Lösungen, Rollen oder Retention-Einstellungen lösen eine Auswirkungsbewertung aus. Der laufende Betrieb braucht einen Eigentümer für die Audit-Konfiguration und einen fachlichen Verantwortlichen für den Review. Nur so bleibt die Nachvollziehbarkeit nach dem ersten Projekt erhalten.

Quellen: [1] [3]

Häufige Fragen zu Dataverse: Auditing

Reicht es, Auditing in der Dataverse-Umgebung einzuschalten?

Für Datenänderungen müssen zusätzlich die benötigten Tabellen und Spalten passend konfiguriert sein. Prüfen Sie den tatsächlichen Ereignisumfang mit gezielten Änderungen. Ein Screenshot des Umgebungsschalters zeigt die globale Einstellung, aber nicht die vollständige Abdeckung kritischer Felder.

Quellen: [3]

Werden Datenexporte im selben Audit-Trail erfasst?

Datenänderungs-Auditing ist nicht mit vollständiger Abruf- und Exportprotokollierung gleichzusetzen. Microsoft beschreibt zusätzliche Aktivitätslogging-Funktionen mit eigenen Voraussetzungen. Ordnen Sie die benötigte Aussage einer konkreten Funktion zu und prüfen Sie deren Umfang in Ihrer Umgebung.

Quellen: [4] [3]

Verlängert eine neue Retention-Frist automatisch alte Auditdaten?

Das hängt vom verwendeten Konfigurationsweg ab. Bei der im Artikel beschriebenen datensatzbezogenen Fristzuweisung bleiben ältere Fristen zunächst bestehen. Microsoft nennt auch einen Weg über die Security-Seite für bestehende Logs. Prüfen Sie deshalb die konkrete Wirkung, statt aus einem sichtbaren neuen Wert eine pauschale Aussage abzuleiten.

Quellen: [3]

Kann nachträglich aktiviertes Auditing fehlende Historie rekonstruieren?

Es erzeugt keine rückwirkenden Auditereignisse für frühere nicht erfasste Änderungen. Bewerten Sie die Bedeutung der Lücke und vorhandene andere belastbare Nachweise. Für die Zukunft werden Konfiguration und Prüffälle korrigiert; die Vergangenheit braucht eine gesonderte fachliche Bewertung.

Ist ein Systemadministrator als Audit-Reviewer geeignet?

Entscheidend sind fachliche Kompetenz, geeigneter Zugriff und die benötigte Unabhängigkeit der Kontrolle. Administrative Rechte allein qualifizieren nicht für die fachliche Bewertung. Prüfen Sie außerdem mögliche Interessenkonflikte, wenn dieselbe Person relevante Eingriffe vornimmt und deren Überwachung verantwortet.

Quellen: [1]

Muss jedes Ereignis einen Änderungsgrund enthalten?

Leiten Sie den Bedarf aus Aufzeichnung, Risiko und anwendbaren Anforderungen ab. Wo ein Grund benötigt wird, muss die Anwendung ihn geeignet erfassen und der Änderung zuordnen. Nehmen Sie nicht an, dass jede Standard-Auditfunktion diese fachliche Anforderung bereits vollständig erfüllt.

Quellen: [1]

Quellen & fachlicher Stand

Stand: 14. Oktober 2026. Regulatorische Einordnung und Herstellerfunktionen sind getrennt belegt. Beispiele, Testmatrizen und Vorlagen sind eigene Arbeitshilfen; sie werden für den tatsächlichen Einsatzzweck angepasst.

  1. Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)
  2. PIC/S: PI 041-1, Good Practices for Data Management and Integrity (2021)
  3. Microsoft: Manage Dataverse auditing
  4. Microsoft: Dataverse auditing overview

Zuletzt fachlich geprüft am 14.10.2026.

Daniel Herrmann, Daniel Herrmann Consulting

Daniel Herrmann Consulting

Wie wir Sie dabei unterstützen

Daniel Herrmann Consulting verbindet die fachliche Bewertung mit der Arbeit am konkreten System. Im Erstgespräch klären wir Ihren Einsatzzweck, vorhandene Nachweise und den nächsten sinnvollen Schritt.

  • IT-GxP-Consulting →

    Anforderungen, Tests und Umsetzung für Ihren konkreten Systemprozess zusammenführen.

Ihr Vorhaben besprechenEinblicke in unsere Projektarbeit →