Change-Management-Nachweise, die Auditoren akzeptieren

In einem SOC 2 Type II-Audit ist Change Management (CC8.1) eine der am häufigsten stichprobenartig geprüften Kontrollen: Der Auditor wählt Änderungen aus dem gesamten Prüfzeitraum aus und verlangt den Nachweis, dass jede einzelne vor dem Produktivbetrieb autorisiert, getestet und genehmigt wurde. ISO 27001 (A.8.32), PCI DSS (6.5.1, 6.5.2) und die Durchführungsverordnung zu NIS2 (Punkt 6.4) verlangen dasselbe, nur mit anderen Worten. Die Entwicklungsteams leisten meist die eigentliche Arbeit; woran es fehlt, ist der Nachweis.

Was Auditoren prüfen

Bei einer Stichprobe von Änderungen wollen sie Folgendes sehen:

1. Die Änderung wurde angefordert und beschrieben: ein Ticket oder Pull Request, das Was und Warum festhält.
2. Sie wurde von einer anderen Person als dem Autor geprüft: Trennung von Aufgaben.
3. Sie wurde vor dem Produktivbetrieb getestet, mit dokumentierten Ergebnissen.
4. Sie wurde vor der Bereitstellung genehmigt.
5. Was bereitgestellt wurde, entspricht dem Genehmigten: Kein ungeprüfter Code gelangte in den Produktivbetrieb.
6. Die Grundgesamtheit ist vollständig: Jede Produktivänderung durchlief den Prozess, einschließlich Infrastruktur und Konfiguration.

Nachweise, die bestehen

• Branch Protection: Der Hauptbranch verlangt vor dem Merge mindestens eine Genehmigung durch eine andere Person als den Autor sowie bestandene Prüfungen. Exportieren Sie die Einstellungen und zeigen Sie, dass sie sich im Prüfzeitraum nicht geändert haben.
• Nur Bereitstellung über die Pipeline: Produktivbereitstellungen erfolgen ausschließlich aus dem geschützten Branch über CI/CD; Entwickler können nicht direkt pushen.
• Verknüpfte Datensätze: Jede Bereitstellung verweist auf den zusammengeführten Pull Request, der wiederum mit seinem Ticket verknüpft ist.
• Infrastructure as Code nach denselben Regeln, sodass Infrastrukturänderungen dieselbe Nachweiskette hinterlassen.
• Eine vollständige Änderungsliste aus dem Bereitstellungswerkzeug für den Zeitraum, aus der der Auditor Stichproben ziehen kann.

Notfalländerungen

Jeder Prozess braucht einen schnellen Weg für Vorfälle, und Auditoren erwarten einen solchen. Definieren Sie ihn: wer genehmigen darf, wie schnell die nachträgliche Prüfung erfolgt (innerhalb von ein bis zwei Arbeitstagen ist üblich) und wie die Änderung mit dem Vorfall verknüpft wird. Stellen Sie anschließend sicher, dass Notfalländerungen tatsächlich selten bleiben.

Was Audits scheitern lässt

• Administratoren mit direktem Produktivzugriff, die die Pipeline gelegentlich umgehen.
• Selbst genehmigte Pull Requests oder Prüfungen ausschließlich durch Bots.
• Konfigurationsänderungen, die in einer Konsole ohne Protokoll vorgenommen wurden.
• Branch Protection, die im Prüfzeitraum „vorübergehend“ deaktiviert wurde.
• Keine Testnachweise außer „CI bestanden“, obwohl die Änderung mehr erforderte.

Stichproben: Was der Auditor tatsächlich tut

Bei einem SOC 2 Type II fordert der Auditor typischerweise die vollständige Grundgesamtheit der Produktivänderungen im Prüfzeitraum an, wählt eine Stichprobe aus (deren Umfang von der Grundgesamtheit und der Methodik des Auditors abhängt) und verlangt für jede ausgewählte Änderung den Nachweis: die Anforderung, die Prüfung durch eine andere Person als den Autor, die Testergebnisse, die Genehmigung und dass das Bereitgestellte mit dem Genehmigten übereinstimmt.

Daraus ergeben sich zwei praktische Konsequenzen. Erstens muss die Grundgesamtheit vollständig und exportierbar sein: Können Änderungen auf mehr als einem Weg in den Produktivbetrieb gelangen, braucht jeder Weg einen Nachweis. Zweitens wird jede ausgewählte Änderung ohne Nachweis im Bericht zur Feststellung. Es ist günstiger, den Prozess so zu gestalten, dass Nachweise automatisch entstehen, als sie während des Audits nachträglich zu rekonstruieren.

Die SOC-2-CC8.1-Seite zeigt, wie das Kriterium auf ISO 27001, PCI DSS und NIS2 abgebildet wird.

Ein Prozess, alle Frameworks

In unseren Daten sind Anforderungen an Change Management framework-übergreifend verknüpft:

Richtung	Zugeordnet	Lose verwandt	Keine Zuordnung
Haben SOC 2 → benötigen NIS2	47 von 49 (96%)	1	1	Bericht →
Haben NIS2 → benötigen SOC 2	37 von 61 (61%)	0	24	Bericht →

Ein pull-request-basierter Prozess mit geschützten Branches und ausschließlicher Bereitstellung über die Pipeline erfüllt SOC 2, ISO 27001, PCI DSS und NIS2 gemeinsam. PCI DSS verlangt darüber hinaus einige zusätzliche Anforderungen: die Trennung von Vorproduktions- und Produktivumgebung (6.5.3), das Fernhalten echter Kontodaten aus Testumgebungen (6.5.5) und die Bestätigung der Sicherheitsanforderungen nach wesentlichen Änderungen (6.5.2).

Siehe das Thema Secure Development für verwandte Anforderungen und unseren Beitrag zur Wiederverwendung von Nachweisen für SOC 2, ISO 27001 und PCI DSS.

Fragen

Zählen Pull Requests für SOC 2 als Change-Genehmigung?

In der Regel ja, wenn das Repository vor dem Merge eine Prüfung durch eine andere Person als den Autor erzwingt, die Bereitstellung auf den genehmigten Code beschränkt ist und Sie dies für eine Stichprobe von Änderungen über den gesamten Zeitraum nachweisen können.

Wie sollten Notfalländerungen für das Audit behandelt werden?

Mit einem definierten Notfallprozess: bei Bedarf zuerst beheben, danach innerhalb einer festgelegten Frist nachträglich prüfen und genehmigen und ein Protokoll führen, das die Änderung mit dem Vorfall verknüpft, der sie veranlasst hat.