SOC 2 Änderungsmanagement: Richtlinien, Prozesse und Best Practices

Wenn die SOC-2-Prüfung Ihres Unternehmens bald ansteht, hat Ihr gesamtes Team sicherlich hart gearbeitet, um das SOC-2-Zertifikat zu erhalten. Es wurden enorme Anstrengungen unternommen, um sicherzustellen, dass das Unternehmen die geltenden Trust Service Criteria (TSC) erfüllt. 

Sind Sie im Rahmen Ihres SOC-2-Zertifizierungsprozesses bereit, Nachweise für die Einhaltung der Common Criteria 8.1 zu erbringen? Können Sie darlegen, wie Richtlinien und Aktualisierungen auf Organisationsebene durchgeführt werden, um einen kontinuierlichen Datenschutz zu gewährleisten? Hier setzt das SOC-2-Änderungsmanagement an.

Dieser Artikel befasst sich detailliert mit dem SOC 2-Änderungsmanagement, den Schritten zu seiner Umsetzung, den TSC-spezifischen Details, den Best Practices und schließt mit einigen Beispielen für das SOC 2-Änderungsmanagement.

Was ist SOC 2 Änderungsmanagement?

Das SOC-2-Änderungsmanagement legt Richtlinien, Verfahren und Best Practices für Serviceorganisationen fest, um Änderungen in ihrer IT-Umgebung kontinuierlich umzusetzen. Es hilft, Risiken zu minimieren, Auditvorgaben zu erfüllen und Lücken bei Änderungen zu schließen.

Dies erfordert von Dienstleistungsorganisationen die Autorisierung, Konzeption, Entwicklung, Beschaffung, Konfiguration, Dokumentation, Prüfung, Genehmigung und Implementierung von Änderungen an Daten, Software oder Prozessen, um die Unternehmensziele zu erreichen. Es handelt sich um einen Routineprozess, der in SOC 2 Common Criteria 8.1 für geprüfte Organisationen beschrieben ist. Die Prüfer verifizieren, ob die Organisationen die Kriterien erfüllen.

Mit anderen Worten: Das Änderungsmanagement nach SOC 2 ist die Dokumentation, die die Richtlinien und Aktualisierungen beschreibt, die Unternehmen implementieren, um ein kontinuierliches Sicherheitsniveau zu gewährleisten. Sie enthält Angaben zum Grund für die Änderung/das Upgrade, zur genehmigenden Stelle, zum Mitarbeiter, der die Änderung implementiert hat, und mehr. Diese Dokumente umfassen Details zu einfachen Aufgaben bis hin zu komplexen Änderungen.

Warum ist Änderungsmanagement für SOC 2 wichtig?

Richtlinien zum Änderungsmanagement helfen Organisationen, die Effektivität ihrer Systeme, Prozesse und Kontrollen im Umgang mit Änderungen nachzuweisen. Zu diesen Änderungen gehören die Nutzung neuer Tools oder Technologien, die Aktualisierung von Prozessabläufen und Datenbankaktualisierungen innerhalb der IT-Infrastruktur. 

Ziel des Änderungsmanagements im Rahmen von SOC 2 ist die Aufrechterhaltung von Transparenz, Genauigkeit und Verantwortlichkeit im internen Kontrollsystem. 

Füllen Sie außerdem Ihre Daten im Feld aus, um eine vollständige Liste der SOC 2-Kontrollen zu erhalten.

SOC 2-Änderungsmanagementanforderungen gemäß CC8.1

Die Anforderungen an das Änderungsmanagement gemäß SOC 2 basieren auf den Common Criteria 8.1, die von Organisationen verlangen, dass sie Änderungen an Infrastruktur, Daten, Software und Verfahren autorisieren, entwerfen, entwickeln, konfigurieren, dokumentieren, testen, genehmigen und implementieren.

Für einen Auditor ist die Hauptfrage einfach: Können Sie nachweisen, dass jede wesentliche Änderung geprüft, genehmigt, getestet, implementiert und dokumentiert wurde, bevor sie sich auf die Produktion auswirkte?

Ein SOC 2-konformer Änderungsmanagementprozess sollte folgende Anforderungen erfüllen:

Voraussetzungen:	Was es bedeutet	Nachweise, die Prüfer anfordern können
Änderungsanforderung	Jede Änderung sollte mit einer formellen Anfrage beginnen.	Jira-Ticket, GitHub-Issue, Service-Desk-Ticket, Änderungsantragsformular
Genehmigung	Die Änderung muss vor Beginn der Arbeiten von einer autorisierten Person genehmigt werden.	Genehmigungsprotokoll, Ticketunterzeichnung, Genehmigung durch den Manager
Folgenabschätzung	Das Team sollte bewerten, wie sich die Änderung auf Sicherheit, Verfügbarkeit, Vertraulichkeit, Datenschutz oder Verarbeitungsintegrität auswirkt.	Risikohinweise, Folgenabschätzung, Liste der betroffenen Systeme
Design und Entwicklung	Änderungen sollten in einer kontrollierten Umgebung entworfen und entwickelt werden.	Pull-Requests, Designnotizen, Entwicklungsdokumentation
Tests	Änderungen sollten vor der Veröffentlichung getestet werden.	Testprotokolle, QA-Freigabe, automatisierte Testergebnisse, Staging-Validierung
Genehmigung vor dem Einsatz	Änderungen in der Produktion sollten vor der Veröffentlichung die endgültige Genehmigung erhalten.	Änderungsgenehmigung, Freigabegenehmigung, CAB-Genehmigung, sofern zutreffend
Aufgabentrennung	Eine einzelne Person sollte nicht ohne Überprüfung eine sensible Änderung beantragen, genehmigen, testen und implementieren können.	Rollenberechtigungen, Peer-Review-Protokolle, Filialschutzregeln
Bereitstellungsverfolgung	Die Organisation sollte nachverfolgen, was wann und von wem eingesetzt wurde.	Bereitstellungsprotokolle, CI/CD-Protokolle, Versionshinweise
Notfalländerungsprozess	Dringende Änderungen sollten dennoch geprüft, dokumentiert und nachträglich genehmigt werden.	Notfalländerungsticket, Überprüfung nach der Implementierung

Diese Anforderungen gelten für Änderungen in der gesamten Infrastruktur, bei Anwendungen, Datenbanken, Cloud-Konfigurationen, Produktions-Repositories, Zugriffsregeln und geschäftskritischen Abläufen.

Bei SOC 2 Typ 2 ist Konsistenz entscheidend. Die Prüfer kontrollieren nicht nur das Vorhandensein der Richtlinie, sondern untersuchen stichprobenartig Änderungen während des Beobachtungszeitraums und verifizieren, ob der dokumentierte Prozess jedes Mal eingehalten wurde. Eine fehlende Genehmigung, ein fehlender Testbericht, eine nicht dokumentierte Notfallkorrektur oder eine nicht protokollierte Produktionsbereitstellung können zu einer Ausnahme im Audit führen.

Zusätzliche Überlegungen gemäß den Kriterien für Vertrauensdienste

Je nach den relevanten Kriterien des Trust Service sollte das Änderungsmanagement auch Folgendes berücksichtigen:

• Verfügbarkeit: Testen Sie, ob sich Änderungen auf Ausfallsicherheit, Verfügbarkeit, Failover, Datensicherung oder Wiederherstellung auswirken.
• Vertraulichkeit: Stellen Sie sicher, dass vertrauliche Daten während der Entwicklung, des Testens, der Bereitstellung und von Konfigurationsänderungen geschützt bleiben.
• Datenschutz: Beschränken Sie die Verwendung personenbezogener Daten bei Systemänderungen und vermeiden Sie eine unnötige Verarbeitung personenbezogener Daten.
• Sicherheit: Unbefugte Änderungen lassen sich durch Zugriffsbeschränkungen, Peer-Reviews, Genehmigungen, Überwachung und Kontrollen der Produktionsbereitstellung verhindern.

Die effektivsten Change-Management-Programme integrieren die Dokumentation von Audits in den normalen Entwicklungsprozess. Änderungstickets, Pull-Requests, Peer-Reviews, Testprotokolle, CI/CD-Protokolle und Deployment-Protokolle sollten die vollständige Änderungshistorie abbilden, ohne dass die Teams diese während des Audits manuell nachbilden müssen.

Vorlage für eine SOC-2-Richtlinie zum Änderungsmanagement

Eine SOC-2-Richtlinie zum Änderungsmanagement dokumentiert, wie Ihr Unternehmen Änderungen anfordert, prüft, genehmigt, testet, implementiert und nachverfolgt. Sie bietet Mitarbeitern einen einheitlichen Prozess und liefert Prüfern den Nachweis, dass Änderungen kontrolliert werden.

Ihre Richtlinie zum Änderungsmanagement sollte Folgendes beinhalten:

1. Zweck

Erläutern Sie den Zweck dieser Richtlinie. Bei SOC 2 besteht der Zweck darin, sicherzustellen, dass Änderungen an Systemen, Infrastruktur, Daten, Software und Verfahren autorisiert, getestet, genehmigt, dokumentiert und sicher implementiert werden.

2. Geltungsbereich

Definieren Sie, welche Änderungen abgedeckt sind. Dies kann Folgendes umfassen:

• Änderungen der Anwendung
• Infrastrukturveränderungen
• Aktualisierungen der Cloud-Konfiguration
• Datenbankänderungen
• Produktionsbereitstellungen
• Änderungen der Zugangskontrolle
• Sicherheits-Patches
• Änderungen an Drittanbietersystemen
• Notfallreparaturen
• Prozess- oder Workflowänderungen, die das System betreffen

3. Rollen und Verantwortlichkeiten

Listen Sie auf, wer für die Anforderung, Prüfung, Genehmigung, das Testen, die Bereitstellung und die Überwachung von Änderungen verantwortlich ist. Dies sollte gegebenenfalls die Bereiche Entwicklung, IT, Sicherheit, Compliance und die Geschäftsleitung umfassen.

4. Änderungsantragsprozess

Definieren Sie, wie ein Änderungsantrag gestellt werden soll. Jeder Antrag sollte Folgendes enthalten:

• Grund für die Änderung
• betroffene Systeme
• Geschäftsinhaber
• Risiko- oder Folgenabschätzung
• Implementierungsplan
• Rücknahmeplan, falls zutreffend
• Testanforderungen
• Genehmigungsstatus
• geplanter Einsatztermin

5. Prüf- und Zulassungsanforderungen

Legen Sie fest, dass Änderungen vor der Produktionsbereitstellung getestet werden müssen. Die Richtlinie sollte außerdem definieren, wer Änderungen genehmigen kann und wann eine zusätzliche Prüfung erforderlich ist.

Bei Änderungen mit hohem Risiko sind Nachweise wie Peer-Review, QA-Validierung, automatisierte Testergebnisse, Sicherheitsüberprüfung oder die Genehmigung durch den Change Advisory Board erforderlich.

6. Bereitstellungskontrollen

Dokumentieren Sie, wie genehmigte Änderungen bereitgestellt werden. Fügen Sie Regeln für den Produktionszugriff, die Funktionstrennung, den Schutz von Zweigen, CI/CD-Kontrollen und die Bereitstellungsprotokollierung hinzu.

7. Notfalländerungen

Legen Sie fest, wie mit dringenden Änderungen umgegangen wird. Notfalländerungen erfordern möglicherweise eine beschleunigte Genehmigung, sollten aber dennoch dokumentiert, nach Möglichkeit getestet und nach der Implementierung überprüft werden.

8. Aufbewahrung von Nachweisen und Aufzeichnungen

Legen Sie fest, welche Aufzeichnungen für SOC-2-Audits aufbewahrt werden müssen. Dazu gehören beispielsweise:

• Wechselgeld
• Genehmigungsunterlagen
• Anfragen ziehen
• Peer-Review-Protokolle
• Testergebnissen
• Bereitstellungsprotokolle
• Notfalländerungsaufzeichnungen
• Rollback-Datensätze
• Überprüfungen nach der Implementierung

9. Überprüfungsrhythmus der Richtlinien

Geben Sie an, wie oft die Richtlinie überprüft und aktualisiert wird. Eine jährliche Überprüfung ist üblich, Organisationen sollten die Richtlinie jedoch auch nach wesentlichen Änderungen an Systemen, Prozessen oder dem Prüfungsgegenstand aktualisieren.

Beispiel einer Grundsatzerklärung

Nutzen Sie dies als Ausgangspunkt:

Alle Änderungen an Produktionssystemen, Infrastruktur, Daten, Software und geschäftskritischen Abläufen müssen gemäß dem Änderungsmanagementprozess des Unternehmens beantragt, geprüft, genehmigt, getestet, dokumentiert und implementiert werden. Notfalländerungen müssen dokumentiert und nach der Implementierung überprüft werden. Nachweise über Genehmigung, Test, Implementierung und Überprüfung von Änderungen müssen zu Prüfungszwecken aufbewahrt werden.

Beispiele für SOC 2-Änderungsmanagement 

Hier sind einige Beispiele dafür, wie Sie Veränderungsmanagement in Geschäftsaktivitäten implementieren können:

• Führen Sie einen Prozess für das Änderungsmanagement ein und überprüfen Sie ihn regelmäßig (halbjährlich oder jährlich). 
• Protokollieren Sie Änderungsmanagementprozesse wie ein Ticketsystem, ein Code-Repository zur Versionskontrolle und Testlösungen.
• Für Entwicklung, Produktion, Tests und Staging sollten separate Umgebungen eingerichtet werden. 
• Der Zugriff zum direkten Einspielen von Änderungen auf Produktionsservern sollte eingeschränkt werden.
• Führen Sie nach der Implementierung eine Überprüfung durch, um die erreichte Effizienz mit der gewünschten Effizienz zu vergleichen.

Anzeichen eines ineffektiven SOC-2-Änderungsmanagementsystems

Hier einige Beispiele, die ein Bild von einem ineffektiven Änderungsmanagementsystem zeichnen:

• Eine Änderung wurde vor der Bereitstellung nicht autorisiert, wird aber trotzdem bereitgestellt.
• Eine Änderung wird nicht während ihres gesamten Lebenszyklus verfolgt und weist Dokumentationslücken auf.
• Die Änderung erfüllt nicht die von der Systemanforderungen aufgeführten Anforderungen. AICPA
• Es existiert kein Protokoll, das die von Benutzern vorgenommenen Änderungen aufzeichnet. Mit anderen Worten: Informationen über die Benutzer, die Änderungen vorgenommen haben, sind nicht verfügbar. 
• Geplante Änderungen werden nicht rechtzeitig umgesetzt.
  Die für die Änderung genehmigte Konfiguration stimmt nicht mit der tatsächlich durchgeführten Änderung überein.
• Für Notfallanfragen gibt es kein festgelegtes Verfahren.
• Änderungen, die im Produkt vorgenommen werden, werden nicht protokolliert.

Dies sind nur einige Beispiele, aber es gibt viele weitere Wege, wie Veränderungsmanagementsysteme ihre Wirksamkeit verlieren und keine starke Führungskompetenz demonstrieren können. Sicherheitshaltung. 

Fazit 

Die manuelle Verwaltung, Nachverfolgung und Dokumentation aller Aktionen im gesamten Ökosystem ist nicht nur zeitaufwändig, sondern auch fehleranfällig. Zu viele Fehler können dazu führen, dass ein Bericht Ihre Geschäftsziele um Monate oder schlimmer noch, sogar Jahre zurückwirft.

Sprinto automatisiert alle denkbaren Aufgaben zur Änderungsverwaltung. Es dokumentiert alles revisionssicher, ermöglicht die Nachverfolgung von Änderungen über ein zentrales Dashboard, löst Warnmeldungen bei unautorisierten Änderungen aus und vieles mehr. Sprechen Sie noch heute mit unseren Experten Um einen Einblick zu erhalten, wie Sie Ihre SOC 2-Reise mühelos bewältigen können. 

Häufig gestellte Fragen