SOC 2

SOC 2 ist ein unabhängiger Prüfbericht darüber, wie ein Dienstleister die Daten und Systeme schützt, die er für Kunden betreibt. Das Regelwerk stammt vom American Institute of Certified Public Accountants (AICPA), den Bericht selbst verfasst eine zugelassene CPA-Prüfungsgesellschaft. SOC steht für System and Organization Controls und hat trotz der ähnlichen Abkürzung nichts mit einem Security Operations Center zu tun.

Maßstab sind die Trust Services Criteria: Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz. Die Sicherheit ist immer Teil des Berichts, und die Organisation wählt aus den übrigen vier diejenigen, die zu ihrem Angebot passen. Der Prüfer untersucht dann die Systembeschreibung der Geschäftsleitung und die Kontrollen, die die Kriterien stützen, und gibt ein Urteil ab.

SOC 2 ist weder ein Gesetz noch ein Zertifikat. Niemand muss es haben, und der Prüfer vergibt keine Bestehensnote: Der Bericht sagt, ob die Kontrollen die Kriterien erfüllt haben, und nennt festgestellte Ausnahmen. Käufer verlangen ihn, weil er einen externen Blick auf die Datensicherheit eines Lieferanten bietet, den ein Fragebogen nicht liefern kann.

Ein SOC-2-Bericht steht am Ende eines Prozesses und ist nicht der Prozess selbst. Die Prüfung ist kurz im Vergleich zur Vorbereitung, und der größte Teil der Arbeit liegt vor dem Eintreffen des Prüfers:

1. 1

   Umfang und Kriterien festlegen

   Entscheiden, welche Dienste, Systeme und Standorte erfasst werden und welche Kategorien neben Security hinzukommen.

2. 2

   Bereitschaft prüfen

   Die vorhandenen Kontrollen mit den Kriterien abgleichen und Lücken auflisten, bevor ein Prüfer sie findet.

3. 3

   Betreiben und dokumentieren

   Lücken schließen, dann die Kontrollen im Alltag leben und Nachweise sichern: Tickets, Logs, Zugriffsprüfungen, Freigaben.

4. 4

   Die Prüfung durchlaufen

   Eine unabhängige CPA-Gesellschaft prüft die Systembeschreibung und testet die Kontrollen gegen die Kriterien.

5. 5

   Bericht erhalten und weitergeben

   Der Bericht enthält das Urteil des Prüfers, wird Kunden meist unter NDA zur Verfügung gestellt und in regelmäßigem Turnus erneuert, häufig jährlich.

Sicherheit ist Pflicht und bildet die gemeinsamen Kriterien: Zugriff, Änderungsmanagement, Risikobewertung, Überwachung und Reaktion auf Vorfälle. Die anderen vier kommen nur hinzu, wenn der Dienst dazu Zusagen macht:

SOC 2 verlangt, dass eine Organisation zeigen kann, wer an Kundendaten gelangt, wie dieser Zugriff geschützt ist und wie Änderungen an Systemen festgehalten werden. Anexet ist kein Prüfwerkzeug, doch die Konsole führt einige dieser Aufzeichnungen: Berechtigungen werden pro Benutzergruppe vergeben, das Speichern der Administratorkonsole-Einstellungen kann ein zusätzliches Passwort erfordern, und Konsolensitzungen enden nach einer festgelegten Zeit automatisch, und das Journal protokolliert Administratoraktionen. Ereignisse lassen sich außerdem an ein SIEM weiterleiten, um sie zentral zu überwachen.

1 / 3

• 
• 
• 

Ein Type-I-Bericht beschreibt die Kontrollen und enthält das Urteil des Prüfers, ob sie zu einem einzigen Zeitpunkt angemessen gestaltet sind. Ein Type-II-Bericht deckt einen Zeitraum ab, meist einige Monate bis ein Jahr, und ergänzt die Tests des Prüfers, ob die Kontrollen über die gesamte Zeit tatsächlich wirksam waren.

Für Käufer hat Type II mehr Gewicht: Eine Kontrolle, die existiert, ist nicht dasselbe wie eine, die jede Woche funktioniert hat. Viele Anbieter beginnen mit Type I, um etwas vorzeigen zu können, und gehen dann zu Type II über. Kunden fragen zudem nach einem Bridge Letter, einer kurzen Erklärung der Geschäftsleitung zur Zeit zwischen dem Ende des Zeitraums und heute. Sie stammt vom Anbieter selbst und ist keine Prüfung.

SOC 1 betrifft Kontrollen, die für die Finanzberichterstattung eines Kunden wichtig sind, SOC 2 die Trust Services Criteria, und SOC 3 ist eine kurze Zusammenfassung für die Allgemeinheit zu derselben Art von Auftrag wie SOC 2, jedoch ohne die detaillierten Tests, weshalb sie veröffentlicht werden darf.

ISO/IEC 27001 ist das andere Dokument, das Käufer verlangen. Es ist die Zertifizierung eines Informationssicherheits-Managementsystems (ISMS) durch eine akkreditierte Stelle, während SOC 2 ein Testatsbericht über Kontrollen ist, die die Organisation selbst beschreibt. Das eine ersetzt das andere nicht, aber ein gemeinsamer Bestand an Nachweisen, der über das Compliance-Management gepflegt wird, kann beiden dienen.

Die meisten Probleme entstehen, wenn SOC 2 als Gütesiegel statt als Arbeitsweise behandelt wird. Sorgfältige Kunden lesen Umfang, Zeitraum und Ausnahmen vor dem Urteil, denn die Lücken eines Lieferanten werden zu ihrem eigenen Compliance-Risiko. Die Muster wiederholen sich:

• Ein Unternehmen als „SOC-2-zertifiziert“ zu bezeichnen, obwohl es kein Zertifikat gibt, sondern nur einen Bericht
• Den Umfang so eng zu fassen, dass der Bericht das Produkt auslässt, das der Kunde tatsächlich nutzt
• Nachweise nach Ende des Zeitraums rekonstruieren zu wollen, obwohl ein Type-II-Test den ganzen Zeitraum abdeckt
• Nur das Urteil zu lesen und die Ausnahmen sowie die vom Kunden selbst zu betreibenden Kontrollen zu überspringen
• Anzunehmen, das Kriterium Datenschutz belege die Einhaltung eines Datenschutzgesetzes wie der DSGVO

Beginnen Sie bei dem, was Kunden tatsächlich verlangen, nicht bei den Kriterien. Wählen Sie den Dienst, den sie kaufen, als Umfang, starten Sie mit Security und fügen Sie weitere Kategorien erst hinzu, wenn ein Kunde sie braucht. Danach folgt eine Bereitschaftsprüfung, und die Kontrollen brauchen genug Zeit, um Spuren zu hinterlassen, bevor der Prüfzeitraum beginnt.

Lassen Sie die Systeme die Nachweise als Nebenprodukt der normalen Arbeit erzeugen: Zugriffslisten, Änderungsprotokolle und planmäßige Sicherheitsberichte, statt Screenshots, die am Ende in Eile gesammelt werden. Ein Bericht, der sich günstig erneuern lässt, wird auch erneuert.