Was ist zu tun, wenn ein E-signierter Bericht revidiert wird?
Verändern Sie die signierte Datei nicht. Öffnen Sie mit Begründung eine neue Revision; bewahren Sie die vorherige signierte Version, deren Prüfsumme und die Verifizierungsnachweise. Führen Sie die neue Version erneut durch die technische Genehmigung, signieren Sie sie und erfassen Sie die Verbindung zwischen beiden Versionen im Vorgangsverlauf.
So bleibt der aktuelle Bericht leicht auffindbar; die alte Kopie verschwindet nicht still oder erscheint nicht als neue Version. Die E-Signatur sichert die Integrität der signierten Version. Ändert sich der Inhalt, ist statt der Übertragung der alten Signatur auf die neue Datei ein neuer Signaturzyklus erforderlich.
Mit welcher Struktur wird die Revisionshistorie bewahrt?
Kurze Antwort: Unter einer unveränderlichen Berichtsidentität muss jede veröffentlichte Version ein eigenes, unveränderliches Objekt sein; die Versionen werden über „Vorgänger“- und „Nachfolger“-Verbindungen miteinander verknüpft.
| Datensatz | Zu bewahrende Information | Technische Konsequenz |
|---|---|---|
| Hauptbericht | Unveränderliche Systemidentität, Arbeitsauftrag und Umfang | Die Versionen desselben Auftrags sind in einer Kette auffindbar |
| Veröffentlichte Version | Revisionscode, Dateiprüfsumme, Anhangsliste, Veröffentlichungszeit und Status | Die Version ist auch bei geändertem Dateinamen verifizierbar |
| Änderungsdatensatz | Begründung, geänderte Felder, Anforderer und Auswirkungsbewertung | Warum die Revision eröffnet wurde, ist erläuterbar |
| Genehmigung und Signatur | Prüfender, genehmigender Person, Signaturergebnis, Richtlinie und Verifizierungszeit | Jede Version trägt ihren eigenen Entscheidungs- und Signaturnachweis |
| Verteilung | Empfänger, Kanal, gesendete Version und Benachrichtigungsergebnis | Die für alte Kopien erforderliche Information ist nachvollziehbar |
Die ISO/IEC 17020:2026 ist die aktuelle Ausgabe, die für Inspektionsorganisationen neue Bestimmungen zur Kontrolle von Daten und Informationen einführt. In der Software bedeutet dies: nicht allein die Berichtsdatei zu speichern, sondern auch die sie erzeugenden Aufzeichnungen, Entscheidungen, Zugriffe und Versionsverbindungen kontrolliert zu halten. Die anwendbaren Anforderungen der Organisation sind zusätzlich anhand ihres Scopes und Übergangsplans zu bewerten.

Welche Ereignisse sollte der Vorgangsverlauf erfassen?
Kurze Antwort: Die Information „wer hat wann geändert?“ allein genügt nicht. Vorher- und Nachher-Zustand, Begründung, betroffene Version, Befugnisergebnis und im Fehlerfall der Fehlerstatus sollten gemeinsam erfasst werden.
- Eröffnung der Revisionsanforderung, deren Begründung und Quelldatensatz
- Erstellung des Entwurfs und aus der Vorversion übernommene Felder
- Feld- und Anhangsänderungen; gesicherte Referenz für alte und neue Werte
- Technische Prüfung, Rückgabe, Genehmigung und Kontrollen der Aufgabentrennung
- Prüfsumme der zur Signatur vorgelegten Datei und Ergebnis des Signaturvorgangs
- Zertifikat, Sperrstatus, Zeitstempel und Ergebnis der angewandten Verifizierungsrichtlinie
- Veröffentlichung, Portalsichtbarkeit, Download und externe Verteilungsereignisse
- Übergang der alten Version in den Status „neue Revision veröffentlicht“
Der Vorgangsverlauf sollte die Felder Anwendungsbenutzer, verlässliche Zeit, Ereignistyp, Objektidentität, Ergebnis und Begründung tragen. Administratorrechte dürfen nicht die Befugnis geben, die Historie still umzuschreiben; ein zu korrigierender Logeintrag muss durch einen neuen Gegeneintrag erläutert werden. Bei Ereignissen mit personenbezogenen Daten ist der Zugriff nach Rolle und Bedarf einzuschränken.
Wie werden alte und neue Signatur verifiziert?
Jede Version ist unabhängig zu verifizieren. Selbst wenn die Signatur der alten Version gültig ist, bedeutet das nicht, dass die Version noch aktuell ist; die Aktualität der neuen Version macht den alten Signaturnachweis ebenfalls nicht ungültig.
Die BTK erläutert, dass die sichere elektronische Signatur die Feststellung ermöglicht, ob die signierten Daten nachträglich verändert wurden, und dass die verifizierende Partei qualifiziertes Zertifikat, Gültigkeit oder Sperrstatus und Nutzungseinschränkungen prüfen muss. Die ETSI EN 319 102-1 V1.4.1 definiert den Verifizierungsprozess, die ETSI TS 119 102-2 V1.4.1 die strukturierte Berichterstattung des Verifizierungsergebnisses. Die Anwendung sollte das Ergebnis mindestens in gültig, ungültig und unklar/Nachweis fehlt unterscheiden; einen Dienstfehler darf sie nicht als Erfolg werten.
- Dateiprüfsumme und Signaturcontainer der angeforderten Version werden abgeglichen.
- Signaturintegrität, Zertifikatskette, Status zum Signaturzeitpunkt und Nutzungsgrenzen werden bewertet.
- Vorhandene Zeitstempel und Nachweise der Langzeitverifizierung werden geprüft.
- Das Ergebnis wird mit Verifizierungszeit, Richtlinie/Version und Fehlerbeschreibung an der Versionsaufzeichnung verknüpft.
- Eine separate Geschäftsregel bestimmt den Status aktuell, abgelöst, storniert oder Entwurf.
Was schützen Zeitstempel und Archivpaket?
Der Zeitstempel hilft nachzuweisen, dass elektronische Daten zu einem bestimmten Zeitpunkt bereits existierten; er ist allein kein Versionsmanagement oder Archiv. Für künftige Verifizierungen sollten signierte Datei, Zertifikatskette, Sperrstatusnachweis, Zeitstempel, Verifizierungsbericht und angewandte Richtlinie gemeinsam bewahrt werden.
Das BTK-Leitfaden zu Verwendungsprofilen elektronischer Signaturen unterscheidet Signaturformen mit Verifizierungsdaten sowie Langzeit- und Archivsignaturen. Die Archivstrategie sollte auch die Erneuerung von Nachweisen bei veralteten kryptografischen Verfahren oder Richtlinien als dokumentierten Vorgang behandeln. Die Erneuerung verändert den alten Berichtsinhalt nicht; sie fügt dem bestehenden Nachweispaket einen neuen, historisierten Schutznachweis hinzu.
Wie wird die alte Version im Portal und in der Verteilung angezeigt?
Die aktuelle Revision sollte hervorgehoben werden; die alte Version muss für berechtigte Nutzer auffindbar bleiben und ausdrücklich den Status „neue Revision veröffentlicht“ zeigen.
- Eine alte URL oder ein alter Verifizierungsverweis soll nicht stillschweigend die neue Datei ausliefern.
- Dem Nutzer sollen die angesehene Berichtsidentität, Revision, das Veröffentlichungsdatum und der Aktualitätsstatus angezeigt werden.
- Es soll eine gesicherte Verbindung zur aktuellen Version bereitgestellt werden; sensible Änderungsbegründungen sollen nicht öffentlich zugänglich sein.
- Ist für Empfänger alter Kopien eine Information oder ein Rückruf erforderlich, sollen empfängerbezogene Aufgaben erstellt werden.
- Ein Verteilungsfehler darf nicht wie ein erfolgter Versand abgeschlossen werden.
Für die Felder der öffentlichen Verifizierungsansicht siehe Leitfaden zur QR-Verifizierungsseite von Berichten lesen.
Wie sollten Befugnisse und Datensicherheit für personenbezogene Daten aufgebaut werden?
Die Befugnisse zum Eröffnen von Revisionen, Ändern von Inhalten, technischen Genehmigen, Signieren, Veröffentlichen und Zugreifen auf die Historie sollten an getrennte Rollen gebunden werden. Die KVKK verlangt technische und administrative Maßnahmen, die rechtswidrigen Zugriff auf personenbezogene Daten verhindern und deren Schutz sicherstellen; statt eines einzigen Sicherheitsmodells fordert sie dem Risiko von Aufgabe und Daten angemessene Vorkehrungen.
Deshalb darf der Vorgangsverlauf keine für jedermann lesbare Datei sein. Befugnismatrix, starke Authentifizierung, Zugriffsprotokoll, unveränderliche Sicherung, Wiederherstellungstest und Verfahren zur Ereignisuntersuchung müssen zusammenwirken. Die Aufbewahrungsfrist ist nach Berichtsart, Vertrag, anwendbarer Gesetzgebung und Verarbeitungszweck festzulegen und nicht als universell und unbefristet anzusehen.
Welche Szenarien sollten im VizyonTech-Pilot getestet werden?
Beim Evaluieren der Lösung Vizyon Periyodik sollten Sie in einer einzigen Berichtsfamilie neben der normalen Revision auch Fehlerszenarien testen. Erfolgskriterium ist nicht allein das Erzeugen einer neuen PDF, sondern dass das System die Veröffentlichung der falschen Version und den Abschluss ohne vollständige Nachweise verhindert.
- Versuchen Sie, die signierte Datei an Ort und Stelle zu verändern; das System sollte das Öffnen einer neuen Revision verlangen.
- Senden Sie ohne Änderungsbegründung zur Genehmigung; der Ablauf sollte gesperrt werden.
- Verändern Sie die Dateiprüfsumme vor der Signatur; der Signaturvorgang sollte abgebrochen werden.
- Untersuchen Sie das Verifizierungsergebnis, wenn der Zertifikatsstatus nicht abrufbar ist; das Ergebnis sollte unklar bleiben.
- Öffnen Sie die Verifizierungsseite einer alten Revision; ihre Nichtaktualität und die Verbindung zur neuen Version sollten sichtbar sein.
- Verfolgen Sie für die verteilte alte Kopie die Benachrichtigungsaufgabe und den Zustellungsnachweis.
Für die breitere Genehmigungs- und E-Signatur-Architektur können Sie auch den Leitfaden zur Digitalisierung des Prozesses wiederkehrender Prüfungen heranziehen.
Quellen
- BTK — Allgemeine Informationen zur elektronischen Signatur (Seitenaktualisierung: 16. Januar 2026; Zugriff: 24. Juli 2026).
- BTK — Rechtsvorschriften zur elektronischen Signatur und Leitfaden zu Verwendungsprofilen elektronischer Signaturen (Seite zu Rechtsvorschriften/Profilen; Zugriff: 24. Juli 2026).
- ETSI — EN 319 102-1, Verfahren zur Erstellung und Validierung von AdES-Signaturen (V1.4.1, Juni 2024).
- ETSI — TS 119 102-2, Signaturvalidierungsbericht (V1.4.1, Juni 2023).
- ISO — ISO/IEC 17020:2026, Anforderungen an Inspektionsorganisationen (3. Ausgabe: März 2026; korrigierte Fassung: Juni 2026).
- KVKK — Pflichten zur Datensicherheit und Leitfaden zur Sicherheit personenbezogener Daten (Zugriff: 24. Juli 2026).
Die anzuwendende Signaturform, Revisionsgenehmigung, Aufbewahrungsfrist und Benachrichtigungsmethode sind unter Bewertung von Berichtsart, Vertrag, Organisationsumfang und aktueller Gesetzgebung festzulegen.