SOC 2 Compliance für Google Workspace: Was Sie wissen müssen

Wenn Ihr Unternehmen SOC 2 anstrebt – und das tun die meisten B2B-Softwareunternehmen früher oder später, weil Kunden danach fragen – wird Google Workspace im Geltungsbereich liegen. Es verwaltet Identitäten, Dokumente und Zugriffskontrollen, die direkt auf die Kriterien einzahlen, die ein Auditor prüft. Dieser Artikel erklärt, wie sich Workspace in ein SOC-2-Programm einfügt und wie Sie die Workspace-Seite vorbereiten, ohne in letzter Minute in Hektik zu verfallen.

Eine Anmerkung zur Begrifflichkeit vorweg: SOC 2 ist eine *Attestierung*, die von einer unabhängigen Wirtschaftsprüfungsgesellschaft (CPA-Firma) durchgeführt wird – kein Abzeichen, das man sich selbst verleiht. Das Ergebnis ist ein Bericht eines Auditors, keine selbst erklärte Bezeichnung. Was Sie intern tun können, ist, die Kontrollen aufzubauen und nachzuweisen sowie die entsprechenden Belege zu sammeln, damit die Attestierung reibungslos verläuft. Darum geht es in diesem Artikel.

Eine kurze Orientierung zu SOC 2

SOC 2 bewertet die Kontrollen einer Serviceorganisation anhand der Trust Services Criteria (TSC): Security (immer enthalten, oft als Common Criteria bezeichnet) sowie optional Availability, Processing Integrity, Confidentiality und Privacy. Die Security-Kriterien – die CC-Serie – sind der Bereich, in dem Google Workspace am häufigsten relevant wird.

Ein Type-I-Bericht bewertet, ob Kontrollen zu einem bestimmten Zeitpunkt angemessen *konzipiert* sind. Ein Type-II-Bericht bewertet, ob sie über einen Zeitraum (typischerweise 3–12 Monate) *wirksam funktioniert* haben. Type II ist das, was Kunden in der Regel wollen, und das hat eine wichtige Konsequenz: Sie benötigen Kontrollen, die funktionieren, sowie Nachweise dafür, dass sie während des gesamten Zeitraums funktioniert haben – nicht nur am Prüfungstag.

Wo Google Workspace auf die Kriterien einzahlt

Mehrere Common Criteria lassen sich klar auf Workspace-Kontrollen abbilden, mit denen Sie ohnehin bereits arbeiten:

• CC6.1 — Logische Zugriffskontrollen. Wer auf geschützte Informationen zugreifen kann und wie der Zugriff auf autorisierte Nutzer beschränkt wird. In Workspace-Begriffen: Konto-Provisionierung, MFA-Durchsetzung, Freigabekontrollen und der Zugriff jeder Identität, einschließlich externer und Service-Konten.
• CC6.2 — Registrierung und Autorisierung. Neue Nutzer werden registriert und autorisiert, bevor Zugriff gewährt wird; Zugriff wird entfernt, sobald er nicht mehr benötigt wird. Hier geht es um Joiner/Mover/Leaver-Hygiene.
• CC6.3 — Least Privilege und Aufgabentrennung. Zugriff basiert auf Rollen und wird auf das notwendige Minimum beschränkt. Überberechtigter Zugriff und Admin-Wildwuchs sind Feststellungen gegen dieses Kriterium.
• CC6.6 — Schutz vor externen Bedrohungen. Die von außen erreichbare Angriffsfläche: öffentliche Links, externe Freigaben und Zugriff, der Identitäten außerhalb der Organisation gewährt wird.
• CC7.x — Monitoring und Incident Response. Erkennung von Anomalien und Reaktion auf Sicherheitsereignisse. Zu wissen, wann sich Freigaben oder Zugriffe ändern, und in der Lage zu sein, dies zu untersuchen, unterstützt diese Kriterien.

Sie müssen sich die Nummerierung nicht merken. Der Punkt ist: Die alltägliche Workspace-Arbeit – MFA durchsetzen, Freigaben kontrollieren, veraltete Zugriffe entfernen, Drittanbieter-Apps steuern – *ist* genau der Kontrollnachweis, den ein Auditor sehen möchte.

Was Auditoren tatsächlich verlangen

Auditoren wollen keine Zusicherungen; sie wollen Nachweise. Für die Workspace-bezogenen Kontrollen sind Anfragen wie diese zu erwarten:

• Nachweis, dass MFA durchgesetzt wird (die Richtlinie und ihre Anwendung, nicht nur „wir haben es aktiviert").
• Die Liste der Administratoren und eine Begründung für jede privilegierte Rolle.
• Nachweise über Zugriffsüberprüfungen – dass Sie regelmäßig prüfen, wer auf sensible Daten zugreifen kann, und auf Basis der Ergebnisse handeln.
• Aufzeichnungen über die Deprovisionierung, wenn Mitarbeiter das Unternehmen verlassen.
• Die Freigabekonfiguration und wie externe Freigaben kontrolliert werden.
• Eine Aufzeichnung darüber, wie Sicherheitsfeststellungen bis zur Behebung nachverfolgt werden.

Das wiederkehrende Thema ist ein dokumentierter, wiederholbarer Prozess mit einem Audit-Trail. Eine Kontrolle, die zwar existiert, aber keine Spuren hinterlässt, lässt sich schwer attestieren. Eine Kontrolle, die kontinuierlich läuft und protokolliert, was sie gefunden hat, ist leicht nachzuweisen.

Wie Sie die Workspace-Seite vorbereiten

1. Eine Konfigurationsbaseline festlegen. Dokumentieren Sie den beabsichtigten Zustand Ihrer Admin-Einstellungen – Freigaben, 2-Schritt-Verifizierung, Marketplace-Beschränkungen, E-Mail-Authentifizierung – und gleichen Sie die Realität regelmäßig damit ab. Abweichungen (Drift) sind der Feind eines sauberen Audits.
2. Zugriffsüberprüfungen durchführen, die Sie nachweisen können. Überprüfen Sie regelmäßig, wer auf sensible Daten zugreifen kann, einschließlich externer und nicht-menschlicher Identitäten, und bewahren Sie die Ergebnisse auf. „Wir haben Zugriffe vierteljährlich überprüft, hier sind die Aufzeichnungen" ist genau das, was CC6.3 verlangt.
3. Freigaben straffen und dokumentieren. Zahlen Sie auf CC6.1 und CC6.6 ein, indem Sie öffentliche und externe Freigaben kontrollieren und den aktuellen Zustand nachweisen können.
4. Feststellungen bis zur Behebung nachverfolgen. Wenn Sie eine Gefährdung entdecken, dokumentieren Sie diese, beheben Sie sie und bewahren Sie die Spur auf. Dies unterstützt die Kriterien für Monitoring und Behebung.
5. Ein Audit-Log führen. Eine zeitgestempelte Aufzeichnung sicherheitsrelevanter Aktionen macht die Fragen „Wer hat was wann getan" trivial zu beantworten.

Vieles davon überschneidet sich mit guter Google-Workspace-Sicherheit im Allgemeinen – und das ist der springende Punkt. SOC 2 ist kein separates, angeflanschtes Projekt; es ist Ihre Sicherheitspraxis, nur nachvollziehbar gemacht und mit Nachweisen versehen.

Kontinuierliche Nachweise schlagen den Audit-Stress

Der klassische Fehlerfall besteht darin, Compliance als Ereignis zu behandeln: ein hektischer Monat mit Screenshots und Tabellenkalkulationen vor dem Audit, jährlich wiederholt. Das ist stressig, fehleranfällig und liefert Nachweise für einen bestimmten Zeitpunkt, die ein Type-II-Auditor zu Recht hinterfragen wird.

Die Alternative ist kontinuierlich: den Sicherheitsstatus das ganze Jahr über kontrollieren, die Nachweise als Nebenprodukt erzeugen und mit der bereits zusammengestellten Spur zum Audit erscheinen. Ein Posture-Tool, das Feststellungen auf SOC-2-Kriterien abbildet und auditorentaugliche Nachweise erstellt, macht aus der Hektik einen einfachen Export.

Häufige Stolperfallen im Workspace-Teil eines Audits

Einige Fehler tauchen immer wieder auf und sollten vermieden werden:

• „Konfiguriert" mit „durchgesetzt" verwechseln. Eine 2-Schritt-Verifizierungsrichtlinie zu aktivieren ist nicht dasselbe, wie sicherzustellen, dass sie für jedes Konto gilt. Auditoren prüfen Letzteres. Überprüfen Sie, ob die Durchsetzung unternehmensweit greift – siehe unseren Leitfaden zur Durchsetzung von MFA in Google Workspace.
• Zugriffsüberprüfungen als bloßes Häkchen behandeln. „Wir überprüfen Zugriffe" ohne Aufzeichnungen, Umfang oder Nachverfolgung ist kein Nachweis. Bewahren Sie die Ergebnisse auf und zeigen Sie, dass Feststellungen bearbeitet wurden.
• Nicht-menschliche Identitäten vergessen. Service-Konten und KI-Agenten besitzen ebenfalls Zugriff, und ein Auditor, der Least Privilege (CC6.3) prüft, wird „wir haben nur Personen überprüft" nicht akzeptieren. Steuern Sie diese – siehe Erkennung riskanter KI-Agenten.
• Konfigurationsabweichungen zwischen Audits zulassen. Eine Baseline, die im Januar sauber war und bis Juni abgedriftet ist, führt zu einer Type-II-Feststellung. Kontinuierliche Überprüfung, nicht eine jährliche Momentaufnahme, sorgt dafür, dass der Standard gehalten wird.

Compliance ist ein Nebenprodukt guter Sicherheit

Die nützlichste Umdeutung für die Workspace-Seite von SOC 2 lautet: Sie bauen Kontrollen nicht *für das Audit* auf – Sie betreiben ein solides Sicherheitsprogramm und lassen das Audit dieses beobachten. Alles, was ein Auditor unter den Zugriffskontroll-Kriterien sehen möchte, ist etwas, das Sie ohnehin wollen würden: durchgesetzte Identität, kontrollierte Freigaben, gesteuerten Drittanbieterzugriff und eine gepflegte Konfigurationsbaseline. Das Audit verlangt lediglich, dies nachvollziehbar zu machen und zu belegen.

Teams, die dies verinnerlichen, hören auf, sich vor dem Jahreszyklus zu fürchten. Die Kontrollen laufen das ganze Jahr über, die Nachweise sammeln sich als Nebenprodukt an, und das Audit wird zu einer Überprüfung bereits geleisteter Arbeit statt zu einem eigenständigen Projekt. Das ist in der Praxis auch der Unterschied zwischen Hektik und Vorbereitetsein.

8200.dev bildet Ihren Google-Workspace-Sicherheitsstatus auf die Kontrollfamilien von SOC 2, ISO 27001 und GDPR ab und erstellt Nachweispakete, die Sie einem Auditor übergeben können – ehrlich, beschränkt auf das, was wir tatsächlich beobachten, niemals eine unbegründete Compliance-Behauptung. Erfahren Sie mehr über wie es funktioniert oder unsere eigenen Sicherheitspraktiken.

Bereiten Sie sich auf ein Audit vor? Starten Sie Ihr kostenloses Sicherheitsaudit und sehen Sie, wie Ihr Google-Workspace-Sicherheitsstatus auf die von Auditoren geprüften Zugriffskontroll-Kriterien abgebildet wird.