Hör auf, Audit-Nachweise von Hand zusammenzustellen: Erstelle sie bei jedem Deploy automatisch

In jedem Compliance-Programm gibt es irgendwo jemanden, der die Woche vor einem Audit damit verbringt, Protokolle aus verschiedenen Systemen zu ziehen, nachzuverfolgen, wer Zugriff auf was hatte, und zu hoffen, dass die Screenshots mit dem übereinstimmen, was der Prüfer tatsächlich verlangt. Keine dieser Arbeiten macht das System sicherer. Sie macht lediglich die vorhandene Sicherheit für den Prüfer sichtbar.

Diese Lücke zwischen den tatsächlich vorhandenen Kontrollen und den Nachweisen, die dies belegen, ist der Grund, warum der Großteil der Vorbereitungszeit für Audits darauf entfällt. Sie zu schließen, ist kein Dokumentationsproblem. Es ist eine Frage davon, wo die Nachweise überhaupt erst generiert werden.

Warum Prüfungsnachweise meist manuelle Rekonstruktion bedeuten

Das Wichtigste zum Mitnehmen: Die meisten Compliance-Nachweise sind bereits irgendwo in deinen Systemen vorhanden. Die Arbeit besteht nicht darin, sie zu erstellen, sondern sie zu finden, zu formatieren und sicherzustellen, dass sie tatsächlich mit dem übereinstimmen, was passiert ist.

Zugriffsprotokolle befinden sich in einem Tool. Der Bereitstellungsverlauf ist in eurem CI-System gespeichert. Konfigurationsänderungen könnten in Git sein, in einer Konsole, durch die sich jemand geklickt hat, oder in einem Slack-Thread, in dem jemand vor drei Monaten eine Ausnahme genehmigt hat. Nichts davon sind fehlende Informationen. Es sind verstreute Informationen, und sie so zusammenzufügen, dass ein Reviewer sie tatsächlich überprüfen kann, ist eine manuelle, wiederholbare und völlig vermeidbare Aufgabe, die jemand in jedem einzelnen Prüfungszyklus erneut erledigt.

Der vorhersehbare Fehlermodus ist weder Betrug noch Fahrlässigkeit. Es ist die Abweichung. Eine Kontrolle, die im Januar korrekt konfiguriert war, wird im März wegen einer einmaligen Ausnahme angepasst, und niemand aktualisiert den Eintrag, der besagt, dass die Kontrolle weiterhin durchgesetzt wird. Wenn das Audit ansteht, sind die von jemandem zusammengestellten Nachweise nur eine Momentaufnahme dessen, woran sich die Leute erinnern, nicht aber eine Aufzeichnung dessen, was die ganze Zeit über tatsächlich der Fall war.

Was sich ändert, wenn Compliance eine Eigenschaft der Plattform ist und kein Schritt im Prozess

Das Wichtigste auf einen Blick: Die Bereitstellung auf einer Infrastruktur, die bereits für wichtige Frameworks zertifiziert ist, bedeutet, dass die grundlegenden Kontrollen nicht projektbezogen konfiguriert werden müssen. Sie sind bereits vorhanden, auch wenn die Compliance auf Anwendungsebene weiterhin in der Verantwortung deines Teams liegt.

Upsun Cloud ist nach ISO/IEC 27001:2022 zertifiziert, verfügt über einen jährlichen SOC-2-Typ-2-Bericht, der Sicherheit, Verfügbarkeit und Datenschutz abdeckt, und ist ein PCI-DSS-Level-1-Dienstleister. HIPAA-Workloads werden im Rahmen einer Business-Associate-Vereinbarung für die Region US-4 unterstützt. Das ist über das Zertifikat selbst hinaus von Bedeutung. 

Laut dem „2026 Cost of a Data Breach Report“ von IBM sind die weltweiten Durchschnittskosten eines Datenlecks auf einen Rekordwert von 4,99 Millionen US-Dollar gestiegen – ein Anstieg von 12 % gegenüber dem Vorjahr. Das Gesundheitswesen bleibt mit 6,64 Millionen Dollar pro Datenpanne die kostspieligste Branche, was einen Rückgang gegenüber den 7,42 Millionen Dollar des Vorjahres darstellt. Die Zertifizierung einer Infrastruktur, die bereits nach diesen Rahmenwerken aufgebaut ist, ist keine bloße Abhak-Aufgabe bei der Compliance. Es ist eine Ebene weniger, die dein Team selbst aufbauen, betreiben und nachweisen muss.

Dies ist ein Modell der geteilten Verantwortung, und es lohnt sich, die Aufteilung genau zu klären. Das Projekt übernimmt den zertifizierten Sicherheitsstatus der zugrunde liegenden Plattform für grundlegende Infrastrukturkontrollen: physische Sicherheit, Betriebssystem-Patches, Verschlüsselung bei der Übertragung, grundlegende Audit-Protokollierung. Dein Team bleibt weiterhin verantwortlich für alles, was darüber liegt: sicherer Anwendungscode, Logik zur Benutzerautorisierung, API-Authentifizierung und die Sicherheit deiner eigenen Abhängigkeiten. Anstatt dass ein Team seine eigenen Nachweise für grundlegende Infrastrukturkontrollen von Grund auf neu zusammenstellen muss, ist diese grundlegende Ebene bereits erfüllt. Was weiterhin das Urteilsvermögen deines Teams erfordert, ist alles, was spezifisch für deine Anwendung ist.

Woher die Audit-Nachweise tatsächlich stammen

Das Wichtigste auf einen Blick: Jede Bereitstellung, jeder Code-Push und jede Konfigurationsänderung wird automatisch im Rahmen des normalen Betriebs protokolliert – nicht als separate Maßnahme zur Nachverfolgung der Compliance –, obwohl die aussagekräftigsten Nachweise entstehen, wenn ihr diese Protokolle mit eurem bestehenden Genehmigungsworkflow verknüpft.

Das ist der Teil, der tatsächlich die vielen Stunden einspart, die derzeit in der Woche vor einem Audit aufgewendet werden. Auf Upsun Cloud wird jeder Deployment, jeder Code-Push und jede Konfigurationsänderung automatisch protokolliert, sobald sie stattfindet. Das ist keine Compliance-Funktion, die der Plattform nachträglich angefügt wurde, sondern die Plattform tut einfach das, was sie ohnehin tut: aufzeichnen, was sich geändert hat, wann und wer es geändert hat.

In der Praxis bedeutet das: Die Zertifizierungen, Verantwortungsmatrizen und Auditberichte, die ein Auditor anfordert, sind im Trust Center oder auf Anfrage verfügbar – statt über Wochen hinweg aus verschiedenen Systemen zusammengetragen zu werden. Die Nachweise werden nicht im Nachhinein aus dem Gedächtnis und verstreuten Protokollen rekonstruiert. Es handelt sich um eine fortlaufende Aufzeichnung, die bereits existiert, weil die Plattform sie die ganze Zeit über verfolgt hat. Wenn ein Prüfer eine Aufzeichnung aller Konfigurationsänderungen an einer Umgebung über einen bestimmten Zeitraum anfordert, kann diese Aufzeichnung über die API und die CLI abgerufen werden, anstatt neu zusammengestellt zu werden. Abgelaufene Aktivitäten werden im Laufe der Zeit aus dem Projektaktivitätsprotokoll entfernt; Teams, die mehrjährige Nachweise benötigen, sollten die Protokolle daher in ihren eigenen Aufbewahrungsspeicher weiterleiten. 

Das wird von Jahr zu Jahr wichtiger: Eine Studie von IBM aus dem Jahr 2026 ergab, dass 68 % der von Sicherheitsverletzungen betroffenen Unternehmen keine KI-Governance-Richtlinie hatten oder noch dabei waren, eine zu entwickeln.

Es lohnt sich, genau zu unterscheiden, was dies ersetzt und was nicht: Plattformprotokolle belegen, was sich wann und von wem geändert hat. Sie beweisen jedoch nicht von sich aus, dass eine Änderung vor ihrer Durchführung genehmigt wurde. Die Kombination automatischer Deployment-Protokolle mit eurem bestehenden Git-basierten Überprüfungsprozess – bei dem ein Pull-Request vor dem Merge von einem separaten Genehmiger freigegeben werden muss – schließt diese Lücke: Das Protokoll und der Genehmigungspfad zusammen sind das, wonach Auditoren tatsächlich suchen, wenn sie nach dem Änderungsmanagement fragen – nicht das Protokoll allein.

Backups als Compliance-Nachweis, nicht nur zur Notfallwiederherstellung

Das Wichtigste zum Mitnehmen: Eine tragfähige Compliance-Strategie muss den Datenschutz kontinuierlich nachweisen und belegen, dass Daten tatsächlich wiederhergestellt werden können – es reicht nicht, eine Richtlinie für backups nur auf dem Papier zu beschreiben.

Backup- und Wiederherstellungsfähigkeiten sind eine Kontrollmaßnahme, deren Nachweis die meisten Rahmenwerke – einschließlich SOC 2 und PCI DSS – von einer Organisation erwarten, nicht nur die bloße Behauptung, und dieser Nachweis bedeutet mehr, als nur zu zeigen, dass ein Backup gelaufen ist. Prüfer erwarten gemäß den Verfügbarkeitskriterien von SOC 2 den Nachweis, dass Wiederherstellungsverfahren tatsächlich getestet wurden, nicht nur, dass ein Backup-Job termingerecht abgeschlossen wurde. 

Der IBM-Bericht aus dem Jahr 2026 unterstreicht, warum das wichtig ist: Nur 37 % der von Datenlecks betroffenen Unternehmen gaben an, sensible Daten sowohl im Ruhezustand als auch während der Übertragung zu verschlüsseln, und nur 34 % hatten einen Überblick über ihre kryptografischen Ressourcen. Gerade bei den grundlegenden Sicherheitsmaßnahmen – backups eingeschlossen – sind die meisten Unternehmen nach wie vor anfällig.

Upsun Cloud führt standardmäßig einmal täglich ein automatisiertes Backup der Produktionsumgebungen durch, das zwei Tage lang aufbewahrt wird. Sowohl das Intervall als auch die Anzahl der aufbewahrten Backups sind je nach Umgebungstyp konfigurierbar, sodass der Zeitplan genau auf eure spezifischen Compliance-Anforderungen abgestimmt werden kann, anstatt bei der Standardeinstellung zu bleiben. 

Da der Backup-Prozess automatisch und konsistent abläuft, ist der Nachweis, dass er stattgefunden hat – und zwar termingerecht –, ein Nebenprodukt des normalen Plattformbetriebs und keine manuelle Aufgabe, an die sich jemand erinnern und die separat protokolliert werden muss. Das Testen der Wiederherstellung selbst – also der Nachweis, dass ein Backup tatsächlich wiederhergestellt werden kann – lohnt es sich, in deinen eigenen Überprüfungsrhythmus zu integrieren, anstatt davon auszugehen, dass dies durch die Ausführung des Backups bereits abgedeckt ist.

Dies ist ein kleines Beispiel für ein größeres Muster: Eine automatisierte Kontrollmaßnahme liefert ihren eigenen Nachweis. Eine Kontrollmaßnahme, die davon abhängt, dass jemand daran denkt, ein Skript auszuführen, liefert nur dann einen Nachweis, wenn jemand auch daran denkt, zu dokumentieren, dass er es ausgeführt hat.

Was das für die Release-Geschwindigkeit bedeutet

Das Wichtigste auf einen Blick: Wenn Compliance-Nachweise kontinuierlich vorliegen und nicht erst nachträglich rekonstruiert werden müssen, müssen Releases nicht mehr auf einen manuellen Freigabeprozess warten, der nur existiert, weil niemand darauf vertraut hat, dass die Nachweise bereits vorhanden sind.

Der Grund, warum Compliance-Anforderungen Releases verlangsamen, ist in der Regel nicht die Anforderung selbst. Es ist der manuelle Verifizierungsschritt, der existiert, weil die Nachweise nicht ohne Weiteres verfügbar sind. Ein Release wird für eine Compliance-Prüfung zurückgehalten, weil jemand Zeit braucht, um zu bestätigen, dass die richtigen Zugriffskontrollen vorhanden sind, die richtige Protokollierung erfolgt und die richtigen Genehmigungen erfasst wurden. Wenn diese Nachweise bereits kontinuierlich vorliegen und wenn die Genehmigungswege bereits mit dem Deployment-Protokoll verknüpft sind, ist die Prüfung keine Rechercheaufgabe, sondern ein Nachschlagen.

Das bedeutet nicht, die Überprüfung abzuschaffen. Es bedeutet, die Woche der Nachweissammlung zu eliminieren, die derzeit stattfinden muss, bevor die Überprüfung beginnen kann. Die Compliance-Abteilung hakt weiterhin die Kästchen ab und trifft nach wie vor die Entscheidungen bezüglich Umfang, Ausnahmen und Risiken. Sie ist nur nicht mehr diejenige, die die Quellen zusammenstellt.

• Überprüfe das Modell der geteilten Verantwortung und den Zertifizierungsumfang im Trust Center
• Schätze deine Plattformkosten mit dem Preisrechner

Häufig gestellte Fragen (FAQ)

Ersetzt das die Notwendigkeit eines Compliance-Teams? 
Nein. Rahmenwerke wie SOC 2 und PCI DSS erfordern nach wie vor menschliches Urteilsvermögen: die Auslegung des Umfangs, die Festlegung von Richtlinien, die Verwaltung von Ausnahmen und die Erstellung der eigentlichen Bescheinigungen. Was sich ändert, ist die Arbeit der Evidenzsammlung, die diesen Entscheidungen zugrunde liegt. Ein Compliance-Team verbringt weniger Zeit damit, den Ablauf nachzuverfolgen, und mehr Zeit mit den Ermessensentscheidungen, die tatsächlich sein Fachwissen erfordern.

Wie funktioniert das über mehrere Umgebungen oder Regionen hinweg? 
Compliance-Kontrollen, die auf der Plattformebene angesiedelt sind, gelten einheitlich, unabhängig davon, in welcher Region oder bei welchem Anbieter eine Workload ausgeführt wird. Du kannst auf AWS, Azure, Google Cloud, IBM Cloud oder OVHcloud in bestimmten Regionen bereitstellen, um Anforderungen an den Datenaufbewahrungsort zu erfüllen, wobei der Zertifizierungsumfang je nach Region und Anbieter variiert. Einige Zertifizierungen sind regionsspezifisch: HIPAA- und TX-RAMP-Workloads laufen beispielsweise ausschließlich in der US-4-Region von Upsun Cloud, daher sollte bei der Regionsauswahl berücksichtigt werden, welche Zertifizierungen eine bestimmte Workload tatsächlich benötigt.

Was passiert bei einem tatsächlichen Audit mit diesem Modell? 
Auditoren können aktuelle Compliance-Dokumentation, Sicherheitsrichtlinien und Auditberichte aus dem Trust Center oder auf Anfrage erhalten, anstatt ein Dokument, das dein Team speziell für diese Überprüfung zusammengestellt hat. Protokolle zu Bereitstellungen, Code-Pushes und Konfigurationsänderungen sind auf Abruf verfügbar, was die Phase der Beweissicherung verkürzt, verglichen mit der manuellen Rekonstruktion derselben Aufzeichnungen. Prüfer erwarten dennoch, dass diese Protokolle mit eurem eigenen Genehmigungs- und Änderungsmanagement-Workflow verknüpft sind und diesen nicht ersetzen.

Ist der Zeitplan für das Backup für jede Umgebung gleich? 
Nein, er ist konfigurierbar. In Produktionsumgebungen kann ein anderer Zeitplan für das Backup gelten als in Staging- oder Entwicklungsumgebungen, und der Zeitplan lässt sich an das Wiederherstellungsziel anpassen, das dein spezifisches Compliance-Framework oder deine internen Richtlinien vorschreiben. Wiederherstellungstests, mit denen bestätigt wird, dass ein Backup tatsächlich wiederhergestellt werden kann, sind eine Praxis, die sinnvollerweise zusätzlich zum Zeitplan selbst durchgeführt werden sollte.

Bedeutet automatisierte Compliance weniger Kontrolle über unsere spezifischen Richtlinien? 
Nein. Die grundlegenden Kontrollen, die sich aus der Zertifizierung auf Plattformebene ergeben (Verschlüsselung, Zugriffsverwaltung, Patching), sind die Mindestanforderungen, nicht die Obergrenze. Die Teams legen weiterhin ihre eigenen Zugriffsrichtlinien, Genehmigungsworkflows und Ausnahmebehandlungen auf Basis dieser Grundvoraussetzungen fest und sind nach wie vor selbst für die Compliance auf der Anwendungsebene verantwortlich: für euren eigenen Code, eure Autorisierungslogik und eure Abhängigkeiten von Drittanbietern. Was sich ändert, ist, dass die grundlegende Infrastrukturebene nicht mehr von jedem Team bei jedem Projekt separat aufgebaut und geprüft werden muss.