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.
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.
Ein anschauliches Beispiel. Ihr Ergebnis hängt von Ihren Quellen, Daten und Anfragen ab.
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.
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.
| Kontrolle | Vorhandener Nachweis | Status | Verantwortliche/r / nächster Schritt |
|---|---|---|---|
| CC1.4 — Hintergrundprüfungen bei Neueinstellungen | Richtlinie zu Hintergrundprüfungen; abgeschlossene Prüfungen für die 9 im Zeitraum eingestellten Personen | Vorhanden | People Ops — abgeschlossen |
| CC6.1 — Logische Zugriffskontrollen | Zugriffskontrollrichtlinie; Konfigurationsexport zur SSO- und MFA-Durchsetzung aus Okta | Vorhanden | Security — abgeschlossen |
| CC6.2 — Provisionierung und Deprovisionierung | Onboarding-Tickets vorhanden; Offboarding-Tickets für 2 der 5 Abgänger noch nicht verknüpft | Teilweise | IT Ops — die 3 fehlenden Offboarding-Tickets anhängen |
| CC6.3 — Quartalsweise Zugriffsprüfungen | Benutzerzugriffsprüfungen Q2 und Q3, im Knowledge Center abgezeichnet | Vorhanden | Security — 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 zusammengetragen | Fehlend | Security — die Alarmkonfiguration und einen bearbeiteten Alarm heranziehen |
| CC7.3 — Incident Response | Incident-Response-Plan; im Zeitraum trat kein Vorfall auf, daher wird stattdessen der Nachweis einer Tabletop-Übung benötigt | Fehlend | Security — 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 exportiert | In Arbeit | Engineering — eine Stichprobe von PR-Freigaben und Deploys exportieren |
| A1.2 — Backups und Wiederherstellung | Backup-Richtlinie; Konfigurationsexport des Backup-Jobs vorhanden; letzter Wiederherstellungstest liegt vor dem Zeitraum | Teilweise | IT 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?
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.
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.
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.
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.
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.
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.
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.
Jede Kontrolle ist als vorhanden, teilweise oder fehlend markiert, sodass Sie die Abdeckungslücke auf einen Blick sehen, statt sie über Laufwerke hinweg zusammenzusuchen.
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 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.
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.
Sortieren Sie die Lücken zu einem Arbeitsplan für die Wochen, bevor sich der Beobachtungszeitraum schließt.
Beginnen Sie mit dem Nachweispaket des Vorjahres und markieren Sie, was übernommen wird, was aufgefrischt werden muss und was neu im Umfang ist.
Führen Sie denselben Index zu einem Stichtag aus, um das Kontrolldesign zu prüfen, bevor Sie sich auf einen Typ-II-Zeitraum festlegen.
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.
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.
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.
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.
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.
Melden Sie sich für die Warteliste an und probieren Sie diesen Workflow bei der Einführung von JoySuite als Erste aus.