SOC 2 Nachweissammlung: Was Prüfer tatsächlich suchen
Erfahren Sie genau, welche Nachweise SOC 2 Prüfer anfordern, wie Sie diese effizient sammeln und welche häufigen Fehler zu Audit-Verzögerungen führen. Ein praktischer Leitfaden für SaaS-Engineering- und Compliance-Teams.
GRCTrail Team
Die Nachweissammlung ist der Punkt, an dem SOC 2 Compliance ernst wird. Ihre Richtlinien beschreiben, wozu Sie sich verpflichten. Ihre Kontrollen sind die Mechanismen, die diese Verpflichtungen durchsetzen. Nachweise sind der Beweis, dass diese Kontrollen tatsächlich funktioniert haben — durchgehend, über Ihren gesamten Beobachtungszeitraum.
Für einen SOC 2 Type I Bericht beweisen Nachweise, dass Kontrollen zu einem Zeitpunkt ordnungsgemäß gestaltet sind. Für einen Type II Bericht liegt die Messlatte höher: Nachweise müssen belegen, dass Kontrollen über einen anhaltenden Zeitraum — typischerweise 6 bis 12 Monate — wirksam betrieben wurden. Jeder Monat in diesem Fenster zählt. Eine einzige Lücke in den Nachweisen kann zu einem eingeschränkten Gutachten oder einer Ausnahme in Ihrem Bericht führen, die Enterprise-Kunden genau prüfen werden.
SaaS-Unternehmen, die die Nachweissammlung als Last-Minute-Aktion vor der Audit-Saison behandeln, enden mit unvollständigen Aufzeichnungen, panischen Teams und verspäteten Berichten. Unternehmen, die die Nachweissammlung in ihre täglichen Abläufe integrieren, stellen fest, dass das Audit selbst zu einer unkomplizierten Übung wird.
Arten von SOC 2 Nachweisen
Screenshots. Zeitpunktbezogene Erfassungen von Systemkonfigurationen, Sicherheitseinstellungen und Dashboard-Ansichten. Fügen Sie immer die Browser-URL-Leiste, einen Zeitstempel und ausreichend Kontext ein.
Logs. Systemgenerierte Aufzeichnungen von Ereignissen: Zugriffsprotokolle, Änderungsprotokolle, Audit-Trails, Authentifizierungslogs. Logs sind die stärkste Form von Nachweisen. Stellen Sie sicher, dass die Log-Aufbewahrung Ihren gesamten Beobachtungszeitraum plus einen Puffer abdeckt.
Tickets. Issue-Tracking-Datensätze aus Systemen wie Jira, Linear oder ServiceNow. Tickets sind nur nützlich, wenn sie die richtigen Metadaten enthalten: Zeitstempel, Zugewiesene, Genehmigungsdatensätze, Statusübergänge.
Berichte. Formelle Ausgaben von Sicherheitstools und Prozessen: Schwachstellenscan-Ergebnisse, Penetrationstest-Berichte, Zugriffsüberprüfungszusammenfassungen, Risikobewertungsdokumente.
Dokumente. Unterzeichnete Richtlinien, Schulungsaufzeichnungen, Besprechungsprotokolle, Management-Assertions.
Konfigurationen. Infrastructure-as-Code-Templates, CI/CD-Pipeline-Konfigurationen, Firewall-Regeln, Netzwerk-ACLs. Verweisen Sie Prüfer auf Ihr IaC-Repository mit spezifischen Commit-Hashes.
Bestätigungen. Unterzeichnete Anerkennungen, Management-Assertions und formelle Erklärungen.
Nachweise nach Kontrollbereich
Zugriffskontrollen (CC6)
Zugriffskontrolle ist der nachweisintensivste Bereich eines SOC 2 Audits.
Benutzerzugriffslisten mit Rollen. Aktuelle Zugriffslisten für alle in-scope Systeme bereitstellen.
SaaS-Beispiel: Benutzerlisten aus AWS IAM, Okta, GitHub und Ihrer Produktionsdatenbank exportieren mit Benutzernamen, zugewiesenen Rollen, Gruppenmitgliedschaften und letzten Anmeldedaten.
MFA-Durchsetzungsnachweise. Beweisen, dass Multi-Faktor-Authentifizierung durchgesetzt wird — nicht nur verfügbar.
Vierteljährliche Zugriffsüberprüfungen mit Behebung. Prüfer wollen vier abgeschlossene Zugriffsüberprüfungen während eines 12-monatigen Beobachtungszeitraums sehen.
Onboarding- und Offboarding-Tickets. Tickets, die zeigen, dass die Zugangsbereitstellung Ihrem dokumentierten Verfahren folgt und dass gekündigte Mitarbeiter fristgerecht deprovisioniert werden.
Privilegierte Zugriffsprotokolle. Audit-Logs für privilegierte Konten bereitstellen.
Change Management (CC8)
Pull-Request-Historie mit Code-Reviews. Prüfer werden Pull Requests stichprobenartig prüfen und verifizieren, dass Code-Reviews vor dem Merge stattfanden.
Deployment-Logs. Aufzeichnungen von Produktions-Deployments bereitstellen mit was, wann, von wem und durch welchen Mechanismus deployed wurde.
Change-Genehmigungs-Workflows. Genehmigungsdatensätze für Änderungen bereitstellen, die explizite Genehmigung über das Code-Review hinaus erfordern.
Notfalländerungsdokumentation. Wenn Notfalländerungen während des Beobachtungszeitraums auftraten, die Notfalländerungs-Tickets mit Begründung und nachträglicher Überprüfung bereitstellen.
Systembetrieb (CC7)
Monitoring-Dashboards und Alert-Konfigurationen. Konfigurationsexporte aus Tools wie Datadog, PagerDuty oder CloudWatch bereitstellen.
Incident-Tickets mit Reaktionszeiten. Für jeden Vorfall während des Beobachtungszeitraums das Ticket mit Erkennungszeit, Reaktionseinleitung, Eindämmungsmaßnahmen, Lösung und Post-Mortem-Abschluss bereitstellen.
SaaS-Beispiel: Ein PagerDuty-Incident-Datensatz zeigt: Alert ausgelöst um 02:15 UTC, bestätigt vom Bereitschaftsingenieur um 02:18 UTC, verknüpftes Jira-Incident-Ticket mit dokumentierten Eindämmungsschritten bis 02:45 UTC, Lösung um 03:30 UTC und Post-Mortem-Dokument innerhalb von drei Werktagen abgeschlossen.
Schwachstellenscan-Ergebnisse und Behebungstickets. Scan-Ergebnisse in regelmäßigen Abständen über den Beobachtungszeitraum plus Tickets, die die fristgemäße Behebung zeigen.
Penetrationstest-Berichte. Mindestens ein Penetrationstest während des Beobachtungszeitraums.
Risikobewertung (CC3)
Formelles Risikobewertungsdokument. Eine abgeschlossene Risikobewertung mit Datum innerhalb des Beobachtungszeitraums.
Risikoregister mit Behandlungsplänen. Ein lebendes Dokument mit identifizierten Risiken, aktuellem Status, zugewiesenen Eigentümern und Behandlungsmaßnahmen. Siehe unseren Vendor-Management-Leitfaden für Details zu Lieferanten-Risikobewertungen.
Kommunikation (CC2)
Schulungsabschluss-Aufzeichnungen. Aufzeichnungen, die zeigen, dass alle Mitarbeiter Sicherheitsbewusstseinsschulungen innerhalb der richtlinienmäßigen Frist absolviert haben.
Richtlinienbestätigungsunterschriften. Aufzeichnungen der Mitarbeiterbestätigung von Kernrichtlinien.
Sicherheitsberichte an Board oder Management. Nachweis, dass die Sicherheitslage an die Führungsebene kommuniziert wird.
Aufbau eines Nachweissammlungssystems
Wo möglich automatisieren. Jedes Tool in Ihrem Stack hat eine API. GitHub liefert Pull-Request- und Code-Review-Daten. AWS CloudTrail liefert Zugriffs- und Änderungsprotokolle. Bauen Sie Integrationen oder nutzen Sie eine Compliance-Plattform.
Sammlungsrhythmus festlegen:
- Täglich: Zugriffsprotokolle, Deployment-Logs, Monitoring-Ereignisse
- Wöchentlich: Schwachstellenscan-Ergebnisse, Ticket-Status-Updates
- Monatlich: Schulungsabschluss-Aufzeichnungen, Richtlinienbestätigungs-Updates
- Vierteljährlich: Zugriffsüberprüfungen, Lieferantenüberprüfungen, Risikoregister-Updates
- Jährlich: Penetrationstest-Berichte, vollständige Risikobewertungen, Richtlinienüberprüfungen
Nachweisspeicherung zentralisieren. Alle Nachweise in einem System mit konsistenter Organisation. Verknüpfen Sie Ihr Nachweisprogramm mit Ihren Continuous-Monitoring-Workflows.
Nachweisverantwortliche zuweisen. Jeder Kontrollbereich braucht einen identifizierten Verantwortlichen.
Einheitlich benennen. Beispiel: zugriffsueberprüfung_aws-iam_2026-Q1.pdf.
Häufige Nachweisfehler
Lücken im Beobachtungszeitraum. Prüfer können nicht annehmen, dass eine Kontrolle in Zeiträumen ohne Nachweise funktioniert hat.
Screenshots ohne Zeitstempel oder Kontext. Entwickeln Sie eine Vorlage für Screenshot-Nachweise.
Nachweise, die Ihren Richtlinien widersprechen. Vor der Einreichung verifizieren, dass Nachweise die Compliance mit Ihren eigenen Richtlinien belegen.
Nachweise erst zur Audit-Zeit statt kontinuierlich sammeln.
Nachweise von gekündigten Mitarbeiterkonten nicht aufbewahren.
Übersammeln ohne Organisation. Organisierte, relevante, gut beschriftete Nachweise sind das, was Prüfer brauchen.
Zusammenarbeit mit Ihrem Prüfer
Nachweisanforderungsliste frühzeitig anfordern. Die PBC-Liste so früh wie möglich erhalten. Sehen Sie unseren Audit-Prozess-Leitfaden.
Format und Benennungskonventionen abstimmen.
Gemeinsames Portal oder sichere Ordnerstruktur nutzen.
Zügig auf Rückfragen antworten. Innerhalb von 24-48 Stunden.
Wie GRCTrail hilft
GRCTrail transformiert die Nachweissammlung von einem manuellen Kraftakt in einen automatisierten, kontinuierlichen Prozess.
- Automatisierte Nachweissammlung aus Ihren bestehenden Tools — GitHub, AWS, Okta, Jira und mehr
- Nachweise verknüpft mit spezifischen Kontrollen und Kriterien, sodass jedes gesammelte Artefakt direkt auf die Common-Criteria-Kategorie und Kontrolle abgebildet ist
- Prüferbereite Nachweispakete mit konsistenter Benennung, Metadaten und Kontroll-Mapping
- Lückenerkennung für fehlende Nachweiszeiträume, die Sie alarmiert, wenn erwartete Nachweise nicht gesammelt wurden
- Kontinuierliche Sammlung mit geplanter Automatisierung
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.