Revisionssichere Dokumentation in SharePoint: Versionierung, Audit Trail und elektronische Unterschriften

Ist revisionssichere Dokumentation in SharePoint automatisch gegeben? Nein. SharePoint bietet wichtige Bausteine wie Versionierung, Berechtigungen, Microsoft-Purview-Audit, Aufbewahrungsrichtlinien, Records Management und eSignature-Integrationen. Revisionssicherheit entsteht aber erst durch das Zusammenspiel aus rechtlicher Anforderung, Verfahrensdokumentation, Rollenmodell, technischen Kontrollen und regelmäßigen Prüfungen. Eine aktivierte Versionshistorie allein verhindert weder unzulässige Änderungen noch beweist sie automatisch die Ordnungsmäßigkeit eines gesamten Geschäftsprozesses.

Der Begriff „revisionssicher“ wird in unterschiedlichen Zusammenhängen verwendet: steuerrelevante Unterlagen nach GoBD, regulatorische Dokumentation, Qualitätsmanagement, Vertragsnachweise oder interne Kontrollsysteme. Diese Bereiche haben nicht dieselben Anforderungen. Deshalb sollte die technische Frage immer lauten: Welche Dokumente müssen wie lange, in welcher Form, mit welchem Änderungsnachweis und für welche Prüfer verfügbar bleiben?

Rechtlicher Hinweis: Dieser Beitrag erläutert technische Funktionen und Gestaltungsprinzipien. Er ersetzt keine rechtliche, steuerliche oder branchenspezifische Prüfung.

Was revisionssichere Dokumentation rechtlich und technisch bedeutet

Ein revisionsfähiger Dokumentationsprozess benötigt typischerweise mehrere Eigenschaften:

• Vollständigkeit der relevanten Unterlagen,
• Nachvollziehbarkeit von Entstehung, Änderung und Freigabe,
• Schutz vor unbemerkter oder unberechtigter Veränderung,
• geordnete und auffindbare Ablage,
• definierte Aufbewahrung und Löschung,
• kontrollierte Zugriffsrechte,
• dokumentierte Verfahren und Zuständigkeiten,
• prüfbare Wiederherstellung und Exportierbarkeit.

Die GoBD des Bundesministeriums der Finanzen beziehen die Ordnungsmäßigkeit nicht nur auf Dateien, sondern auch auf das eingesetzte DV-Verfahren, Berechtigungen, Änderungen und Verfahrensdokumentation. Das bedeutet: Selbst ein technisch unverändertes PDF ist nicht ausreichend, wenn Herkunft, Freigabe, Ablageweg oder Berechtigungskonzept unklar sind.

Prüfkriterien in eine Kontrollmatrix übersetzen

Vor der Konfiguration sollte eine Matrix erstellt werden:

Ohne diese Zuordnung bleiben Funktionen isoliert und Prüfungen zufällig.

SharePoint-Versionierung: wie sie funktioniert und was sie nicht leistet

Versionierung speichert frühere Bearbeitungsstände von Dateien und – abhängig von Listenkonfiguration und Funktion – Listenelementen. Nutzer können Versionsverläufe ansehen und frühere Dateiversionen wiederherstellen. SharePoint Online erlaubt Administratoren außerdem, Versionslimits auf Organisations- oder Bibliotheksebene zu konfigurieren.

Wofür Versionierung geeignet ist

• versehentliche Änderungen rückgängig machen,
• Bearbeitungsstände vergleichen,
• Autor und Zeitpunkt einer Version anzeigen,
• Entwurf und Veröffentlichung unterstützen,
• Änderungen während der Zusammenarbeit nachvollziehen.

Was Versionierung allein nicht garantiert

• Ein berechtigter Nutzer kann je nach Konfiguration Dateien oder Versionen löschen.
• Eine Version beschreibt nicht automatisch den fachlichen Grund der Änderung.
• Versionierung ist kein vollständiges, unveränderliches Audit-Protokoll aller Zugriffe.
• Aufbewahrungsdauer und Anzahl der Versionen hängen von Einstellungen ab.
• Eine wiederhergestellte Version kann zum neuen aktuellen Stand werden; der Geschäftsprozess muss damit umgehen.
• Exporte außerhalb von SharePoint besitzen nicht automatisch dieselbe Historie.

Für kritische Dokumente sollten daher zusätzliche Metadaten wie Dokumentstatus, Freigabedatum, Freigabeverantwortlicher, fachliche Versionskennung und Änderungsgrund geführt werden.

Technische und fachliche Version nicht verwechseln

SharePoint kann Versionen wie 4.0 oder eine interne Versions-ID anzeigen. Eine Organisation kann daneben fachliche Versionen wie QM-Policy 2026.2 verwenden. Der fachliche Wert sollte beim Veröffentlichungsprozess fixiert und in Nachweisen referenziert werden. Sonst ist später unklar, welche Version tatsächlich galt.

Audit Trail in SharePoint und Microsoft Purview

Microsoft Purview Audit protokolliert Nutzer- und Administratoraktivitäten aus Microsoft-365-Diensten, darunter SharePoint und OneDrive. Je nach Audit-Lösung, Lizenz und Aufbewahrungsrichtlinie unterscheiden sich verfügbare Ereignisse und Aufbewahrungsdauern. Microsoft dokumentiert für aktiviertes Standard-Auditing eine automatische Aufbewahrung und für Audit-Premium-Funktionen erweiterte Richtlinien bis hin zu längeren Zeiträumen für entsprechend lizenzierte Nutzer.

Welche Fragen ein Audit-Protokoll beantworten kann

Abhängig vom protokollierten Ereignis kann eine Suche beispielsweise helfen festzustellen:

• wer eine Datei angesehen, geändert, heruntergeladen oder gelöscht hat,
• wer Berechtigungen oder Freigaben verändert hat,
• wann ein Link erstellt oder verwendet wurde,
• welche administrative Aktion eine Site oder Richtlinie betroffen hat.

Nicht jede denkbare fachliche Aktion wird automatisch als verständliches Ereignis protokolliert. Ein Audit-Eintrag „Datei geändert“ erklärt nicht, warum eine Vertragsklausel geändert wurde. Für fachliche Nachweise braucht es daher strukturierte Prozessdaten.

Audit-Aufbewahrung bewusst konfigurieren

Die benötigte Nachweisfrist kann länger sein als die standardmäßige Audit-Aufbewahrung. Deshalb ist zu prüfen:

1. Welche Nutzer und Workloads sind lizenziert?
2. Welche Ereignistypen werden tatsächlich erfasst?
3. Wie lange bleiben sie suchbar?
4. Benötigt die Organisation eine eigene Audit-Retention-Policy?
5. Wer darf Audit-Suchen durchführen und Ergebnisse exportieren?
6. Wie wird der Zugriff auf Auditdaten selbst protokolliert und geschützt?

Ein häufiger Fehler ist, Audit erst nach einem Vorfall zu betrachten. Dann ist die relevante Frist möglicherweise bereits abgelaufen oder das benötigte Ereignis war nicht im erwarteten Umfang verfügbar.

Aufbewahrung: Retention Policies, Labels und Records

Microsoft Purview unterscheidet unter anderem Aufbewahrungsrichtlinien und Aufbewahrungsbezeichnungen. Policies können Speicherorte breit abdecken; Labels lassen sich differenzierter auf einzelne Inhalte anwenden und können in Records-Management-Szenarien Dokumente als Record oder Regulatory Record deklarieren, sofern Funktion und Lizenz verfügbar sind.

Was bei SharePoint-Inhalten unter Retention passiert

Wenn aufbewahrungspflichtige Inhalte geändert oder gelöscht werden, kann SharePoint Originalinhalte in der Preservation Hold Library sichern, damit die Aufbewahrungsanforderung erfüllt wird. Diese Bibliothek ist für normale Nutzer nicht sichtbar und belegt Site-Speicher. Retention ist daher nicht nur eine logische Regel, sondern hat Auswirkungen auf Speicher, Löschprozesse und Betrieb.

Record ist nicht gleich Backup

Ein Retention- oder Record-Mechanismus schützt Inhalte innerhalb des Microsoft-365-Dienstes gemäß einer Regel. Ein Backup verfolgt andere Ziele, etwa Wiederherstellung nach Fehlkonfiguration, großflächiger Löschung oder bestimmten Katastrophenszenarien. Beide Konzepte können sich ergänzen, sind aber nicht austauschbar.

Bei der Planung sind mindestens diese Szenarien zu testen:

• berechtigter Nutzer versucht, ein aufbewahrtes Dokument zu löschen,
• Administrator ändert eine Retention-Einstellung,
• Site wird geschlossen oder gelöscht,
• Dokument wird verschoben,
• Retention-Frist endet,
• Rechtsstreit oder Hold verhindert geplante Löschung,
• Wiederherstellung wird benötigt, obwohl die Retention-Regel korrekt war.

Speicherbegrenzung statt „alles für immer“

Für personenbezogene Daten verlangt die DSGVO eine Speicherbegrenzung. Ein pauschales unbegrenztes Aufbewahren kann daher ebenso problematisch sein wie zu frühes Löschen. Der Aufbewahrungsplan muss pro Dokumentklasse Zweck, Rechtsgrundlage, Fristbeginn, Fristdauer, Hold-Ausnahmen und Löschverantwortung festlegen. Bei Personaldokumenten ist die digitale Personalakte in SharePoint ein eigener Anwendungsfall mit engeren Rollen- und Datenschutzgrenzen.

Löschen verhindern: Berechtigungen, Retention und Sperren

Es gibt mehrere Schutzebenen:

1. Berechtigungen: Nur definierte Rollen dürfen Dokumente bearbeiten oder löschen.
2. Versionierung: Frühere Stände bleiben innerhalb der konfigurierten Grenzen verfügbar.
3. Retention: Inhalte werden für eine Frist erhalten, auch wenn Nutzer löschen.
4. Record-Deklaration: Je nach Konfiguration werden Bearbeitung und Löschung stärker eingeschränkt.
5. Audit: Administrative und nutzerbezogene Aktivitäten werden protokolliert.
6. Backup/Wiederherstellung: Separater Schutz gegen bestimmte Verlustszenarien.

Diese Ebenen sollten nicht mit itembezogenen Einzelrechten für jedes Dokument umgesetzt werden. Zu viele eindeutige Berechtigungsbereiche erschweren Betrieb und Skalierung. Besser sind getrennte Sites oder Bibliotheken nach Schutzklasse und klaren Rollen.

Elektronische Unterschriften in SharePoint

Elektronische Signaturen sind ein eigenes Thema. Eine Schaltfläche „Gelesen“ oder ein Approval ist nicht automatisch eine elektronische Signatur mit dem für einen Vertrag oder eine gesetzliche Form erforderlichen Niveau.

Die eIDAS-Verordnung unterscheidet elektronische, fortgeschrittene und qualifizierte elektronische Signaturen. Eine elektronische Signatur darf nicht allein deshalb ohne Rechtswirkung oder Beweiswert bleiben, weil sie elektronisch ist. Die qualifizierte elektronische Signatur hat nach Art. 25 eIDAS die gleiche Rechtswirkung wie eine handschriftliche Unterschrift. Ob für einen konkreten Vorgang eine qualifizierte Signatur erforderlich ist, ergibt sich aus dem anwendbaren Recht und der Formvorgabe.

Microsoft 365 eSignature und Anbieterintegrationen

Microsoft dokumentiert eine in SharePoint integrierte eSignature-Funktion für unterstützte Dokumente sowie Integrationen mit Anbietern wie Adobe Acrobat Sign und DocuSign. Nach aktuellem Dokumentationsstand können Signaturanfragen aus SharePoint gestartet und signierte Kopien wieder in SharePoint gespeichert werden. Für PDF-Anfragen nennt Microsoft unter anderem unverschlüsselte PDFs und begrenzte Empfängerzahlen; Anbieter, Regionen, Kosten und Funktionsgrenzen müssen vor Einführung aktuell geprüft werden.

Für einen belastbaren Signaturprozess sind diese Punkte entscheidend:

• Welche Signaturart erzeugt der Dienst?
• Wie wird die Identität des Unterzeichners geprüft?
• Welche Beweisdaten und Zertifikate werden geliefert?
• Wo werden Dokumente während des Signaturprozesses verarbeitet?
• Wie wird die signierte Fassung mit der Ausgangsversion verbunden?
• Welche Retention-Regel gilt für Original, signierte Fassung und Audit-Zertifikat?
• Wie werden abgebrochene oder abgelehnte Anfragen dokumentiert?
• Wie werden externe Unterzeichner und Conditional Access behandelt?

Signatur und interne Freigabe trennen

Eine interne fachliche Freigabe kann vor der Signatur erfolgen. Beide Schritte sollten getrennte Statuswerte und Nachweise besitzen. Beispiel:

1. Dokumententwurf erstellt.
2. Inhalt fachlich freigegeben.
3. Signaturanfrage gestartet.
4. alle erforderlichen Signaturen abgeschlossen.
5. signierte Fassung veröffentlicht.
6. Retention Label angewendet.

So ist erkennbar, ob ein Dokument inhaltlich genehmigt, aber noch nicht wirksam unterzeichnet ist.

Verfahrensdokumentation: der oft fehlende Teil

Technische Einstellungen sind nur dann prüfbar, wenn sie dokumentiert sind. Eine Verfahrensdokumentation sollte mindestens enthalten:

• Zweck und Geltungsbereich,
• Dokumentklassen und Metadaten,
• Rollen und Berechtigungsgruppen,
• Erstellungs-, Prüf-, Freigabe- und Signaturprozess,
• Versionierungs- und Veröffentlichungsregeln,
• Aufbewahrungs- und Löschplan,
• Audit-Konfiguration und Zugriff,
• Backup- und Wiederherstellungsverfahren,
• Schnittstellen und Automatisierungen,
• Änderungsmanagement für Konfigurationen,
• Test- und Kontrollplan,
• Vorgehen bei Störungen und Sicherheitsvorfällen.

Auch Änderungen an der Lösung selbst müssen nachvollziehbar sein. Wer Retention Labels, Berechtigungsgruppen oder Freigabeflows ändert, beeinflusst den Nachweisprozess. Für Richtlinien, die an definierte Zielgruppen verteilt und bestätigt werden müssen, beschreibt Richtlinienverteilung mit SharePoint und Power Automate ein konkretes Nachweismodell.

Typische Fehlerbilder

„Versionierung ist aktiviert, also kann nichts verloren gehen“

Versionen können begrenzt, reduziert oder je nach Berechtigung gelöscht werden. Außerdem schützt Versionierung nicht vor allen Site- oder Tenant-Ereignissen. Retention und Wiederherstellung müssen separat geprüft werden.

„Das Audit Log enthält alles“

Audit-Ereignisse und Aufbewahrung sind lizenz- und workloadabhängig. Fachliche Gründe und Inhalte einer Entscheidung müssen oft im Prozessdatensatz erfasst werden.

„Ein Approval ist eine Unterschrift“

Approval dokumentiert eine Antwort innerhalb eines Workflows. Es erfüllt nicht automatisch die Anforderungen an fortgeschrittene oder qualifizierte Signaturen.

„Retention bedeutet, dass niemand mehr löschen kann“

Retention kann eine Löschung aus Nutzersicht zulassen und die aufbewahrungspflichtige Kopie im Hintergrund erhalten. Das Verhalten hängt von Policy, Label und Record-Status ab. Es muss mit Testkonten geprüft werden.

„Alle Dokumente behalten wir unbegrenzt“

Das kann Datenschutz- und Löschpflichten verletzen und erzeugt unnötige Kosten. Fristen müssen dokumentbezogen begründet sein.

Testplan für eine revisionsfähige SharePoint-Lösung

Dokumentlebenszyklus

• Entwurf anlegen und ändern.
• fachliche Version veröffentlichen.
• ältere Version wiederherstellen.
• abgelöste Version kennzeichnen.
• Dokument verschieben und Metadaten prüfen.

Zugriff und Änderung

• Leser versucht zu bearbeiten.
• Bearbeiter versucht zu löschen.
• Site Owner verändert Berechtigung.
• externe Freigabe wird blockiert oder protokolliert.
• vertrauliches Dokument erscheint nicht in unzulässigen Suchergebnissen.

Retention und Records

• Label anwenden.
• Änderung und Löschung mit mehreren Rollen testen.
• Preservation-Hold-Verhalten prüfen.
• Ablauf und Disposition mit Testinhalten simulieren.
• Legal-Hold-Ausnahme prüfen.

Audit

• definierte Aktionen ausführen.
• Ereignisse mit erwarteter Verzögerung suchen.
• Export und Zugriffsschutz prüfen.
• Aufbewahrungsdauer gegen Anforderung abgleichen.

eSignature

• interne und externe Unterzeichner testen.
• Ablehnung und Abbruch testen.
• signierte Kopie, Zertifikat und Ausgangsdokument verknüpfen.
• Conditional Access und externe Identität testen.
• Aufbewahrung auf signierte Fassung anwenden.

Rückfallweg

Ein Rückfallweg beschreibt, wie Dokumente weiter verarbeitet werden, wenn Approval, eSignature oder Power Automate ausfallen. Er darf die Beweiskette nicht unterbrechen. Mögliche Elemente sind ein kontrolliertes Notfallformular, manuelle Ablage mit Vier-Augen-Freigabe, nachträgliche Erfassung der Störung und ein Abgleich aller während des Ausfalls bearbeiteten Dokumente.

Wann SharePoint allein ausreicht und wann ein DMS sinnvoller ist

SharePoint kann ausreichen, wenn Anforderungen mit Microsoft-365-Berechtigungen, Versionierung, Purview-Retention, Audit, dokumentierter Automatisierung und geeigneter Signaturintegration vollständig abgedeckt und geprüft werden können.

Ein dediziertes DMS oder Facharchiv ist eher angezeigt, wenn:

• branchenspezifische Zertifizierungen oder unveränderliche Archivformate verlangt werden,
• Massenscanning und beweissicheres ersetzendes Scannen zentral sind,
• komplexe Aktenpläne und Verfügungsprozesse benötigt werden,
• sehr feingranulare, objektbezogene Rechte dominieren,
• Langzeitformate, qualifizierte Zeitstempel oder spezialisierte Archivschnittstellen erforderlich sind,
• die Organisation einen bereits etablierten führenden Records-Prozess besitzt.

Die Entscheidung sollte anhand einer Anforderungsliste erfolgen, nicht anhand des Produktnamens.

Was SharePoint nativ leistet und wo Revisionssicherheit externe Maßnahmen braucht

SharePoint stellt eine starke technische Basis bereit, aber kein einzelner Schalter erzeugt Revisionssicherheit. Versionierung schützt Bearbeitungsstände, Audit protokolliert Aktivitäten, Retention erhält Inhalte nach Regeln, Records Management kann Änderungen stärker kontrollieren und eSignature bindet Signaturdienste ein. Erst eine dokumentierte Anforderungsmatrix, ein geprüftes Rollenmodell, definierte Fristen und wiederholbare Kontrollen verbinden diese Bausteine zu einem belastbaren Nachweisverfahren.