SOC 2 Richtlinien und Verfahren: Was Sie dokumentieren müssen
Ein vollständiger Leitfaden zu den für die SOC 2 Compliance erforderlichen Richtlinien und Verfahren. Behandelt die wesentlichen Dokumente, was Prüfer erwarten und wie Sie Richtlinien schreiben, die tatsächlich funktionieren.
GRCTrail Team
Richtlinien sind das Fundament jedes SOC 2 Audits. Sie dokumentieren, wozu sich Ihre Organisation verpflichtet, und Prüfer testen, ob Sie es tatsächlich tun. Hier gibt es keine Abkürzung — ohne gut geschriebene, durchsetzbare Richtlinien wird Ihr SOC 2 Bericht entweder scheitern oder so eingeschränkt sein, dass er bei Kunden an Wert verliert.
SaaS-Unternehmen unterschätzen häufig den Richtlinienaufwand. Sie nehmen an, SOC 2 sei primär eine technische Übung — MFA konfigurieren, Daten verschlüsseln, Monitoring einrichten. Diese Kontrollen sind wichtig, aber sie existieren, um Ihre Richtlinien umzusetzen. Der erste Schritt eines Prüfers ist, Ihre Richtlinien zu lesen. Sein zweiter Schritt ist zu prüfen, ob Ihre Abläufe dem entsprechen, was die Richtlinien besagen. Wenn es eine Diskrepanz gibt, haben Sie eine Feststellung.
Dieser Leitfaden behandelt jede Richtlinie und jedes Verfahren, das ein SaaS-Unternehmen für SOC 2 benötigt, was jedes davon audit-bereit macht und die Fehler, die während der Audit-Saison am meisten Probleme verursachen.
Richtlinien vs. Verfahren vs. Standards
Bevor wir in die Liste eintauchen, verstehen Sie die Hierarchie. Diese drei Dokumenttypen dienen unterschiedlichen Zwecken, und Ihr Prüfer erwartet klare Unterscheidungen.
Richtlinien definieren was Ihre Organisation tun wird und warum. Sie legen Verpflichtungen fest, weisen Verantwortlichkeiten zu und setzen Erwartungen. Eine Richtlinie wird von der Geschäftsführung genehmigt und gilt breit in der gesamten Organisation. Beispiel: „Jeder Benutzerzugang folgt dem Prinzip der geringsten Berechtigung.”
Standards definieren die spezifischen Benchmarks, die Ihre Organisation erfüllen muss. Sie übersetzen Richtlinienverpflichtungen in messbare Schwellenwerte. Beispiel: „Passwörter müssen mindestens 14 Zeichen lang sein und alle 90 Tage rotiert werden.”
Verfahren definieren wie etwas getan wird, Schritt für Schritt. Sie sind operative Anweisungen, denen Mitarbeiter folgen, um Richtlinien umzusetzen und Standards zu erfüllen. Beispiel: „Um ein neues Benutzerkonto bereitzustellen, reichen Sie eine Anfrage in Jira über die Vorlage für Zugriffsanfragen ein, holen die Genehmigung des Vorgesetzten ein und konfigurieren das Konto in Okta mit der im Ticket angegebenen Rolle.”
Ein gut strukturiertes Compliance-Programm schichtet alle drei: Richtlinien geben die Richtung vor, Standards setzen die Messlatte und Verfahren sagen den Mitarbeitern genau, was zu tun ist. Wenn Prüfer diese Struktur sehen, signalisiert das Reife.
Kern-Pflichtrichtlinien
Jeder SOC 2 Bericht — unabhängig davon, welche Trust-Service-Kriterien Sie einbeziehen — erfordert eine Reihe grundlegender Richtlinien. Hier sind die zehn Richtlinien, die SaaS-Unternehmen dokumentiert und durchgesetzt haben sollten.
1. Informationssicherheitsrichtlinie
Dies ist Ihr übergreifendes Sicherheitsdokument. Es legt den Umfang Ihres Sicherheitsprogramms fest, definiert Rollen und Verantwortlichkeiten und artikuliert die Verpflichtung Ihrer Organisation zum Schutz von Informationswerten.
Was sie abdeckt: Ziele des Sicherheitsprogramms, Scope, Executive-Sponsoring, Rollen (CISO, Sicherheitsteam, Engineering-Leads) und die Beziehung zwischen dieser Richtlinie und allen untergeordneten Richtlinien.
SaaS-Beispiel: Ihre Richtlinie besagt, dass alle auf AWS gehosteten Produktionssysteme, alle Mitarbeiter-Endgeräte und alle Drittanbieter-Integrationen, die Kundendaten verarbeiten, in den Scope des Sicherheitsprogramms fallen. Interne Tools, die keine Kundendaten berühren, sind explizit ausgeschlossen.
2. Zugriffskontrollrichtlinie
Zugriffskontrolle ist einer der am stärksten getesteten Bereiche in jedem SOC 2 Audit. Diese Richtlinie definiert, wie Ihre Organisation den Benutzerzugriff über seinen gesamten Lebenszyklus verwaltet.
Was sie abdeckt: Benutzerbereitstellung und -deprovisionierung, rollenbasierte Zugriffskontrolle (RBAC), Least Privilege, Multi-Faktor-Authentifizierung (MFA), Privileged Access Management, Servicekonto-Governance und periodische Zugriffsüberprüfungen.
SaaS-Beispiel: Ihre Richtlinie erfordert MFA für jeden Produktionssystemzugriff, vierteljährliche Zugriffsüberprüfungen mit dokumentierter Behebung und Deprovisionierung innerhalb von 24 Stunden nach Mitarbeiterkündigung.
3. Change-Management-Richtlinie
Change Management regelt, wie Änderungen an Ihren Systemen — Code, Infrastruktur, Konfigurationen — vorgeschlagen, überprüft, genehmigt und bereitgestellt werden.
Was sie abdeckt: Code-Review-Anforderungen, Deployment-Prozesse, Testanforderungen, Genehmigungs-Workflows, Notfalländerungsverfahren, Rollback-Verfahren und Änderungsdokumentation.
SaaS-Beispiel: Ihre Richtlinie erfordert, dass alle Produktionsänderungen einen Pull Request mit mindestens einem Peer-Review durchlaufen, CI/CD-Pipeline-Tests bestehen und über Ihr automatisiertes Deployment-System bereitgestellt werden. Notfall-Hotfixes dürfen den Standard-Review umgehen, erfordern aber ein Post-Deployment-Review innerhalb von 48 Stunden und eine dokumentierte Begründung.
4. Incident-Response-Richtlinie
Ihre Incident-Response-Richtlinie definiert, wie Ihre Organisation Sicherheitsvorfälle erkennt, darauf reagiert und sich davon erholt. Für einen vertieften Leitfaden zum Aufbau einer effektiven Incident-Response-Fähigkeit siehe unseren Incident-Response-Leitfaden.
Was sie abdeckt: Vorfallklassifizierung und Schweregradebenen, Erkennungsmechanismen, Eskalationsverfahren, Eindämmungs- und Beseitigungsschritte, Wiederherstellungsverfahren, Kommunikationsprotokolle (intern und extern), Post-Incident-Review-Prozess und Beweissicherung.
SaaS-Beispiel: Ihre Richtlinie definiert vier Schweregradebenen (P1-P4), erfordert einen P1-Incident-War-Room innerhalb von 15 Minuten nach Erkennung, schreibt Kundenbenachrichtigung innerhalb von 72 Stunden bei Datenschutzverletzungen vor und erfordert ein schriftliches Post-Mortem für alle P1- und P2-Incidents innerhalb von fünf Werktagen.
5. Risikobewertungsrichtlinie
Risikobewertung ist grundlegend für SOC 2 — die Common Criteria erfordern ausdrücklich einen formalen, wiederholbaren Prozess zur Identifizierung und Bewertung von Risiken. Für einen vollständigen Durchlauf des Risikobewertungsprozesses siehe unseren Risikobewertungs-Leitfaden.
Was sie abdeckt: Risikobewertungsmethodik (qualitativ, quantitativ oder hybrid), Bewertungshäufigkeit (mindestens jährlich), Risikoidentifikationsansatz, Wahrscheinlichkeits- und Auswirkungsbewertungskriterien, Risikoakzeptanzschwellen, Risikobehandlungsoptionen und verantwortliche Rollen für die Risikoeigentümerschaft.
6. Vendor-Management-Richtlinie
Ihr SOC 2 Bericht ist nur so stark wie Ihr Lieferanten-Ökosystem. Diese Richtlinie regelt, wie Sie Dritte bewerten, onboarden, überwachen und offboarden. Für das vollständige Vendor-Management-Framework siehe unseren Vendor-Management-Leitfaden.
Was sie abdeckt: Lieferantenklassifizierung nach Risikostufe, Due-Diligence-Anforderungen (SOC 2 Berichtsprüfung, Sicherheitsfragebögen), vertragliche Sicherheitsanforderungen, laufende Überwachungsrhythmen, Unterauftragsverarbeiter-Management und Lieferanten-Offboarding-Verfahren.
7. Datenklassifizierungsrichtlinie
Datenklassifizierung definiert, wie Ihre Organisation Informationen nach Sensibilität kategorisiert und die Handhabungsanforderungen für jede Kategorie festlegt.
Was sie abdeckt: Klassifizierungsstufen (z. B. Öffentlich, Intern, Vertraulich, Eingeschränkt), Kriterien für die Zuweisung von Klassifizierungen, Handhabungsanforderungen pro Stufe, Datenkennzeichnungserwartungen und wer befugt ist, Daten zu klassifizieren.
8. Acceptable-Use-Richtlinie
Die Acceptable-Use-Richtlinie definiert die Verantwortlichkeiten der Mitarbeiter bei der Nutzung von Unternehmenssystemen, Netzwerken und Daten.
Was sie abdeckt: Erlaubte und verbotene Nutzung von Unternehmenssystemen, Richtlinien für persönliche Geräte, Internet- und E-Mail-Nutzung, Social-Media-Richtlinien, Datenhandhabungsverantwortlichkeiten, Softwareinstallationsregeln und Konsequenzen bei Verstößen.
9. Business-Continuity- und Disaster-Recovery-Richtlinie
Wenn Sie das Verfügbarkeitskriterium in Ihren SOC 2 Scope einbeziehen — und die meisten SaaS-Unternehmen tun das —, benötigen Sie eine dokumentierte BC/DR-Richtlinie.
Was sie abdeckt: Recovery Time Objective (RTO) und Recovery Point Objective (RPO) für kritische Systeme, Backup-Verfahren und -Verifizierung, Failover-Mechanismen, DR-Testhäufigkeit und -methodik, Kommunikationspläne bei Ausfällen und Rollen während eines Katastrophenereignisses.
SaaS-Beispiel: Ihre Richtlinie setzt ein RTO von 4 Stunden und RPO von 1 Stunde für Ihre Produktionsanwendung. Backups laufen stündlich in eine separate AWS-Region. DR-Failover wird vierteljährlich getestet mit dokumentierten Ergebnissen, und der letzte erfolgreiche Test stellte den vollen Service in 2,5 Stunden wieder her.
10. Personalsicherheitsrichtlinie
Menschen sind eine kritische Kontrollschicht. Diese Richtlinie deckt die Sicherheitsaspekte des Mitarbeiter-Lebenszyklus vom Einstellungsverfahren bis nach der Kündigung ab.
Was sie abdeckt: Anforderungen an Hintergrundprüfungen, Sicherheitsschulungen beim Onboarding (und jährlich danach), Vertraulichkeits- und Geheimhaltungsvereinbarungen, rollenbasierte Sicherheitsverantwortlichkeiten, Offboarding-Verfahren (Zugriffswiderruf, Rückgabe von Vermögenswerten, Exit-Interviews) und Disziplinarverfahren bei Sicherheitsverstößen.
Was eine Richtlinie audit-bereit macht
Versionskontrolle und Genehmigungsdaten. Jede Richtlinie muss zeigen, wann sie erstellt, zuletzt überprüft, genehmigt wurde und von wem.
Klare Eigentümerschaft. Jede Richtlinie braucht einen benannten Verantwortlichen. „Das Sicherheitsteam” ist nicht spezifisch genug.
Spezifische, messbare Anforderungen. „Zugriff sollte regelmäßig überprüft werden” reicht nicht. „Zugriffsüberprüfungen werden vierteljährlich durchgeführt, mit Behebung innerhalb von 14 Werktagen” besteht.
Regelmäßiger Überprüfungsrhythmus. Richtlinien müssen mindestens jährlich überprüft werden.
Mitarbeiterbestätigung. Mitarbeiter sollten Kernrichtlinien formell bestätigen. Verfolgen Sie Bestätigungen mit Datum.
Übereinstimmung mit der tatsächlichen Praxis. Das wichtigste Kriterium. Wenn Ihre Richtlinie etwas sagt, müssen Sie es tun.
Häufige Richtlinienfehler
Vorlagen kopieren ohne Anpassung. Generische Vorlagen verwenden Formulierungen wie „die Organisation unterhält physische Zugriffskontrollen zu Serverräumen.” Wenn Sie ein Cloud-natives SaaS-Unternehmen auf AWS sind, haben Sie keine Serverräume.
Ambitionierte Richtlinien schreiben. Ihre Richtlinie sagt, Zugriffsüberprüfungen finden monatlich statt. Ihre Nachweise zeigen, dass sie vierteljährlich stattfinden — manchmal. Das erzeugt einen Kontrollfehler.
Fehlende Review- und Genehmigungs-Metadaten. Eine Richtlinie ohne Genehmigungsdatum, Versionsnummer oder benannten Genehmiger ist unvollständig.
Übermäßig komplexe Richtlinien, die niemand liest. Halten Sie Richtlinien fokussiert und lesbar. Verschieben Sie detaillierte Anweisungen in Verfahren.
Keine Aktualisierung nach organisatorischen Änderungen. Sie sind von AWS zu GCP migriert, haben einen neuen CISO befördert oder Ihr Engineering-Team umstrukturiert. Wenn Ihre Richtlinien noch die alte Umgebung referenzieren, werden Prüfer die Inkonsistenz bemerken.
Verfahren: Die operativen Details
Verfahren sind dort, wo Richtlinien operativ werden.
Wichtige Verfahren für SaaS-Unternehmen
Verfahren zur Zugriffsüberprüfung. Schritt-für-Schritt-Anweisungen für vierteljährliche Zugriffsüberprüfungen.
Verfahren zur Change-Bereitstellung. Der detaillierte Workflow, um Code von einem Entwickler-Branch in die Produktion zu bringen.
Verfahren zum Schwachstellenmanagement. Wie Schwachstellen identifiziert, triagiert, zugewiesen, innerhalb des SLA behoben und als gelöst verifiziert werden.
Backup- und Wiederherstellungsverfahren. Detaillierte Schritte für die Konfiguration von Backups, Verifizierung, Durchführung einer Wiederherstellung und Dokumentation der Ergebnisse.
Incident-Response-Verfahren. Das schrittweise Playbook für jede Schweregradebene eines Vorfalls.
Jedes Verfahren sollte explizit auf die übergeordnete Richtlinie verweisen, die es umsetzt.
Nachweise der Richtlinien-Compliance
Prüfer nehmen Ihnen nichts auf Wort ab. Sie testen, ob Ihre Abläufe Ihren Richtlinien entsprechen. Für einen umfassenden Leitfaden zur Nachweissammlung siehe unseren Nachweissammlungs-Leitfaden.
Wie GRCTrail hilft
GRCTrail bietet SaaS-Teams einen strukturierten Ansatz zum Aufbau und zur Pflege des Richtlinien-Frameworks, das SOC 2 erfordert.
- Richtlinienvorlagen, die an SOC 2 Common Criteria ausgerichtet sind und jeden erforderlichen Richtlinienbereich abdecken, speziell für SaaS-Unternehmen geschrieben
- Versionskontrolliertes Richtlinienmanagement mit integrierten Genehmigungs-Workflows, Review-Tracking und Änderungsverlauf
- Mitarbeiterbestätigungs-Tracking, das aufzeichnet, wann jedes Teammitglied Richtlinien überprüft und akzeptiert hat
- Erinnerungen an Richtlinienüberprüfungen, die vor Ihrer jährlichen Review-Frist ausgelöst werden
- Verknüpfte Nachweissammlung, die Richtlinien mit den Kontrollen verbindet, die sie umsetzen, und den Nachweisen, die Compliance beweisen
Verwandte Leitfäden
Verwandte Artikel
Der SOC 2 Audit-Prozess: Zeitplan, Schritte und was Sie erwartet
Eine schrittweise Anleitung zum SOC 2 Audit-Prozess, von der Auswahl eines Prüfers bis zum Erhalt Ihres Berichts. Behandelt Zeitpläne, Vorbereitung und was Prüfer bewerten.
SOC 2 Common Criteria (CC) Kontrollen erklärt
Eine detaillierte Aufschlüsselung aller neun SOC 2 Common-Criteria-Kategorien (CC1-CC9), was jede erfordert und wie SaaS-Unternehmen Kontrollen für jede implementieren sollten.
SOC 2 Compliance-Checkliste für SaaS-Unternehmen
Eine umfassende SOC 2 Compliance-Checkliste, die jeden Schritt von der Scoping-Phase bis zum Audit-Abschluss abdeckt. Erstellt für SaaS-Teams, die sich auf ihren ersten oder nächsten SOC 2 Bericht vorbereiten.