SOC2-Nachweis-Sammler

Verwandeln Sie ein SOC-2-Audit in ein geordnetes Nachweispaket. Joy ordnet Ihre Richtlinien, Tickets, Konfigurationsexporte und Zugriffsprüfungen anhand der Trust Services Criteria zu und zeigt für jede Kontrolle, was bereits vorliegt, was noch fehlt und wer für die Lücke verantwortlich ist.

Für Security- und Compliance-Verantwortliche GRC-Manager Gründer wachsender Unternehmen IT- und Engineering-Verantwortliche
Beispiel-Prompt für den Joy-Assistenten

Wir haben ein [SOC 2 Typ]-Audit vor uns, und unser Beobachtungszeitraum ist [Zeitraum]. Hier ist der Kontext: [Kontext]. Organisieren Sie unsere Nachweise anhand der Trust Services Criteria in einem prüfungssicheren Index, der für jede Kontrolle zeigt, welche Nachweise wir bereits im Knowledge Center haben, was noch fehlt und wer für jede Lücke verantwortlich ist.

So kann es aussehen

Ein anschauliches Beispiel. Ihr Ergebnis hängt von Ihren Quellen, Daten und Anfragen ab.

Wir haben ein SOC 2 Typ II-Audit vor uns, und unser Beobachtungszeitraum ist der 1. April bis 30. September. Hier ist der Kontext: Es ist unser erstes Typ II mit Sterling & Beck, wir decken die Kriterien Sicherheit und Verfügbarkeit ab, die meisten unserer Richtlinien sind aktuell und unsere quartalsweisen Zugriffsprüfungen sind protokolliert, aber unsere Nachweise zum Änderungsmanagement und ein paar Konfigurationsexporte sind noch nicht zusammengestellt, und ich möchte das vollständige Bild, bevor ich Lücken an Verantwortliche übergebe. Organisieren Sie unsere Nachweise anhand der Trust Services Criteria in einem prüfungssicheren Index, der für jede Kontrolle zeigt, welche Nachweise wir bereits im Knowledge Center haben, was noch fehlt und wer für jede Lücke verantwortlich ist.

Ich habe Ihre Nachweise anhand der Trust Services Criteria geordnet, gestützt auf die Richtlinien, Tickets, Konfigurationsexporte und Zugriffsprüfungen, die bereits in Ihrem Knowledge Center liegen. Jede Kontrolle zeigt, was vorhanden ist, gegenüber dem, was noch fehlt, mit einer verantwortlichen Person für jede Lücke, sodass Sie genau wissen, bei wem Sie nachhaken müssen, bevor sich der Zeitraum schließt.

SOC 2 Typ II Nachweisindex: Entwurf

Audit: Erstes SOC 2 Typ II
Prüfer: Sterling & Beck
Kriterien im Umfang: Sicherheit, Verfügbarkeit
Beobachtungszeitraum: 1. April – 30. September 2026

Hier sind Ihre Nachweise nach Kontrolle geordnet. Für jede: was bereits im Knowledge Center liegt, wie es steht und wer für die Schließung der Lücke verantwortlich ist.

KontrolleVorhandener NachweisStatusVerantwortliche/r / nächster Schritt
CC1.4 — Hintergrundprüfungen bei NeueinstellungenRichtlinie zu Hintergrundprüfungen; abgeschlossene Prüfungen für die 9 im Zeitraum eingestellten PersonenVorhandenPeople Ops — abgeschlossen
CC6.1 — Logische ZugriffskontrollenZugriffskontrollrichtlinie; Konfigurationsexport zur SSO- und MFA-Durchsetzung aus OktaVorhandenSecurity — abgeschlossen
CC6.2 — Provisionierung und DeprovisionierungOnboarding-Tickets vorhanden; Offboarding-Tickets für 2 der 5 Abgänger noch nicht verknüpftTeilweiseIT Ops — die 3 fehlenden Offboarding-Tickets anhängen
CC6.3 — Quartalsweise ZugriffsprüfungenBenutzerzugriffsprüfungen Q2 und Q3, im Knowledge Center abgezeichnetVorhandenSecurity — abgeschlossen
CC7.2 — Sicherheitsüberwachung und AlarmierungÜberwachung läuft, aber der Export der Alarmkonfiguration und ein Beispiel für einen bearbeiteten Alarm sind nicht zusammengetragenFehlendSecurity — die Alarmkonfiguration und einen bearbeiteten Alarm heranziehen
CC7.3 — Incident ResponseIncident-Response-Plan; im Zeitraum trat kein Vorfall auf, daher wird stattdessen der Nachweis einer Tabletop-Übung benötigtFehlendSecurity — eine Tabletop-Übung durchführen und dokumentieren
CC8.1 — ÄnderungsmanagementÄnderungsrichtlinie vorhanden; Pull-Request-Freigaben und Deploy-Datensätze existieren im Tooling, sind aber nicht als Nachweis exportiertIn ArbeitEngineering — eine Stichprobe von PR-Freigaben und Deploys exportieren
A1.2 — Backups und WiederherstellungBackup-Richtlinie; Konfigurationsexport des Backup-Jobs vorhanden; letzter Wiederherstellungstest liegt vor dem ZeitraumTeilweiseIT Ops — einen Wiederherstellungstest im Zeitraum durchführen und protokollieren

Sechs der acht Kontrollen haben vollständige oder teilweise Nachweise; die eigentliche Arbeit sind die vier Lücken. Zwei davon, CC7.2 Überwachung und CC7.3 Incident Response, sind diejenigen, auf die ein Prüfer erfahrungsgemäß drängt, und beide liegen bei Security, also würde ich dort beginnen. Die Change-Management-Exporte (CC8.1) und die Offboarding-Tickets (CC6.2) sind schnell zu schließen, sobald jemand zugewiesen ist. Nichts hier ist erfundener Nachweis — jede Zeile spiegelt wider, was tatsächlich hochgeladen ist, sodass die fehlenden Zeilen wirklich fehlen und nicht bloß nichtindexiert sind.

Soll ich die Lücken-Anforderungsnotiz entwerfen, die Sie an jede verantwortliche Person senden können, oder die vier Lücken zu einem Bereitschafts-Zeitplan für den Rest des Zeitraums sortieren?

In wenigen Schritten von verstreuten Nachweisen zu einem prüfungssicheren Index

Der SOC2-Nachweis-Sammler nimmt die Kriterien, gegen die Sie geprüft werden, sowie jeden Kontext, den Sie geben können, und ordnet Ihre Nachweise in einem Index, der Kontrolle für Kontrolle zugeordnet ist. Joy, die JoySuite-Assistentin, gleicht jedes Trust-Services-Kriterium mit dem ab, was in Ihrem Knowledge Center liegt, markiert die vorhandenen Nachweise gegenüber dem, was noch fehlt, und benennt für jede Lücke eine verantwortliche Person.

  1. Geben Sie Joy den Kontext

    Sagen Sie Joy, welchen SOC-2-Bericht Sie anstreben, den Beobachtungszeitraum und die Kriterien im Umfang. Erwähnen Sie alles, von dem Sie bereits wissen, dass es solide ist oder fehlt. Grob genügt.

  2. Sagen Sie, was organisiert werden soll

    Bitten Sie um einen Nachweisindex, der den Trust Services Criteria zugeordnet ist, mit jeder Kontrolle als vorhanden oder fehlend markiert und einer verantwortlichen Person für jede Lücke. Joy ergänzt die Standardkontrollen und sinnvolle Verantwortliche, wenn Sie nicht alle ausbuchstabieren.

  3. Prüfen Sie den Index

    Erhalten Sie Ihre Nachweise Kontrolle für Kontrolle aufgelistet, mit Status und Verantwortlichen, und die Lücken am Ende zu einem klaren Überblick zusammengefasst. Gleichen Sie ihn mit dem ab, was tatsächlich hochgeladen ist und wie Ihre Kontrollen wirklich laufen.

  4. Nutzen Sie ihn dort, wo Ihr Team arbeitet

    Bitten Sie um eine Anpassung – „Verschiebe den Change-Management-Export zu Engineering“ oder „Füge eine Zeile für Lieferantenprüfungen hinzu“ – und kopieren Sie den Index dann in Ihr GRC-Tool, gemeinsames Laufwerk oder die Nachricht, die Sie an jede verantwortliche Person senden.

  5. Machen Sie es für Ihr Team zu einem Klick

    Speichern Sie diese Anfrage als benutzerdefinierten Befehl auf dem Assistenten, den Ihr Team ohnehin nutzt, damit ihn jede und jeder in einem Schritt ausführen kann.

Machen Sie es sich zu eigen

Den Kriterien zugeordnet

Die Nachweise werden anhand der Trust Services Criteria so geordnet, wie ein Prüfer sie verlangt, sodass der Index Kontrolle für Kontrolle mit der Anforderung übereinstimmt.

Vorhanden vs. Fehlend

Jede Kontrolle ist als vorhanden, teilweise oder fehlend markiert, sodass Sie die Abdeckungslücke auf einen Blick sehen, statt sie über Laufwerke hinweg zusammenzusuchen.

Verantwortliche für Lücken benannt

Jede Lücke benennt, wer für ihre Schließung verantwortlich ist, sodass nichts unbeansprucht liegen bleibt, während Beobachtungszeitraum und Feldarbeit näher rücken.

Die echten Lücken sichtbar gemacht

Die Kontrollen ohne Nachweis werden hervorgehoben, mit einer Einschätzung, auf welche ein Prüfer erfahrungsgemäß drängt, sodass Sie wissen, was zuerst zu schließen ist.

Lücken-Anforderungsnotiz

Verwandeln Sie die offenen Lücken in eine kurze Notiz, die Sie an jede verantwortliche Person senden können, mit dem benötigten Nachweis und bis wann.

Bereitschafts-Zeitplan

Sortieren Sie die Lücken zu einem Arbeitsplan für die Wochen, bevor sich der Beobachtungszeitraum schließt.

Vom Vorjahr fortschreiben

Beginnen Sie mit dem Nachweispaket des Vorjahres und markieren Sie, was übernommen wird, was aufgefrischt werden muss und was neu im Umfang ist.

Typ-I-Bereitschafts-Momentaufnahme

Führen Sie denselben Index zu einem Stichtag aus, um das Kontrolldesign zu prüfen, bevor Sie sich auf einen Typ-II-Zeitraum festlegen.

Häufig gestellte Fragen

Was macht ein SOC2-Nachweis-Sammler?

Er ordnet Ihre Nachweise anhand der Trust Services Criteria in einem prüfungssicheren Index. Sie geben Joy den Kontext, und sie ordnet jede Kontrolle den Richtlinien, Tickets, Konfigurationsexporten und Zugriffsprüfungen in Ihrem Knowledge Center zu, markiert das Vorhandene gegenüber dem Fehlenden, benennt eine verantwortliche Person für jede Lücke und liest die zuerst zu schließenden Lücken heraus.

Zieht Joy Nachweise automatisch aus meinen Live-Systemen?

Nein. Joy ordnet und indexiert die Nachweise, die Sie in Ihr Knowledge Center hochgeladen haben, und kann aus einem verbundenen System nur dort lesen, wo ein Connector es tatsächlich unterstützt. Sie erfindet keine Nachweise und behauptet nicht, automatisch aus Tools zu ziehen, mit denen sie nicht verbunden ist. Eine Kontrolle erscheint nur dann als abgedeckt, wenn der Nachweis wirklich vorliegt.

Welche Trust Services Criteria deckt er ab?

Diejenigen, gegen die Sie geprüft werden. Das Kriterienpaket Sicherheit (Common Criteria) ist immer im Umfang, und Sie können Verfügbarkeit, Vertraulichkeit, Verarbeitungsintegrität oder Datenschutz ergänzen. Sagen Sie Joy die Kriterien im Umfang, und sie ordnet Ihre Nachweise den relevanten Kontrollen zu, von logischem Zugriff über Änderungsmanagement bis Incident Response.

Kann er das Nachweispaket des Vorjahres nutzen?

Wenn Ihr Knowledge Center die Nachweise des Vorberichts enthält, nutzt Joy sie, um zu erkennen, was übernommen wird und was bereits vorhanden ist, gegenüber dem, was für den neuen Zeitraum aufgefrischt werden muss, sodass Sie den Index nicht aus einer leeren Kriterienliste neu aufbauen.

Wie weise ich die Lücken meinem Team zu?

Joy benennt für jede Lücke eine vorgeschlagene verantwortliche Person, und Sie können jede davon im selben Gespräch neu zuweisen – „Verschiebe den Change-Management-Export zu Engineering“. Kopieren Sie den Index dann in Ihr GRC-Tool oder die Nachricht, die Sie an jede verantwortliche Person senden. Joy entwirft und ordnet; sie versendet nicht.

Bereit, genau zu wissen, wo Ihre SOC-2-Nachweise stehen?

Melden Sie sich für die Warteliste an und probieren Sie diesen Workflow bei der Einführung von JoySuite als Erste aus.