Erster SOC 2-Bericht: Scope festlegen, ohne sich zu übernehmen

Ein SOC 2-Bericht deckt ein System ab: den Dienst, den Kunden beziehen, und alles, was dahintersteht. Zieht man diese Grenze zu weit, verbringt man Monate damit, Kontrollen zu belegen, nach denen niemand gefragt hat. Zieht man sie zu eng, beantwortet der Bericht nicht die Frage des Kunden. Die teuersten Fehler beim ersten SOC 2-Bericht passieren in der Scoping-Woche.

Entscheidung 1: welches System

Gehen Sie davon aus, was Kunden kaufen und wovon sie abhängen. Bei den meisten Softwareunternehmen ist das die Produktionsplattform: die Anwendung, ihre Infrastruktur und Datenspeicher, die Personen, die sie entwickeln und betreiben, sowie die Prozesse, die sie befolgen. Meist nicht im Scope: interne Unternehmens-IT, die nie mit Kundendaten in Berührung kommt, andere Produktlinien und Vertriebssysteme.

Halten Sie die Grenze früh schriftlich fest, denn sie wird zur Systembeschreibung im Bericht, und jede Kontrolle muss über alles innerhalb dieser Grenze hinweg wirken, an jedem Tag des Beobachtungszeitraums.

Entscheidung 2: welche Kriterien

Security, die gemeinsamen Kriterien CC1 bis CC9, ist verpflichtend. Weitere ergänzen Sie nur, wenn Kunden sie benötigen:

• Availability, wenn Kunden auf Verfügbarkeitszusagen angewiesen sind.
• Confidentiality, wenn Sie Kundendaten verarbeiten, die als vertraulich eingestuft sind (bei den meisten B2B-Diensten).
• Processing Integrity, wenn Kunden sich darauf verlassen, dass Sie ihre Daten korrekt verarbeiten: Zahlungen, Lohnabrechnung, Abrechnung.
• Privacy, wenn Sie personenbezogene Daten für eigene Zwecke verarbeiten und Kunden dies verlangen. Die meisten ihrer Kriterien haben kein Gegenstück in Security-Frameworks, wie unsere Analyse von SOC 2 und ISO 27001 zeigt.

Entscheidung 3: Subservice-Organisationen

Ihr Cloud-Anbieter, Zahlungsdienstleister oder Anbieter verwalteter Datenbanken betreibt Kontrollen, auf die Sie sich verlassen. Sie wählen zwischen:

• Carve-out (am häufigsten): Deren Kontrollen werden ausgeschlossen; Sie beschreiben, wofür Sie sich auf sie verlassen, und zeigen, dass Sie deren eigene SOC 2-Berichte prüfen.
• Inklusiv: Deren Kontrollen werden im Rahmen Ihres Berichts getestet. Dafür ist ihre Mitwirkung nötig, und bei großen Anbietern ist das selten.

Entscheidung 4: ergänzende Kontrollen der Nutzerunternehmen

Listen Sie die Kontrollen auf, die Ihre Kunden betreiben müssen, damit Ihre funktionieren: die Verwaltung ihrer eigenen Benutzerkonten, den Schutz ihrer API-Schlüssel, die Konfiguration ihres SSO. Halten Sie die Liste realistisch und knapp, denn Kunden lesen sie, und deren Sicherheitsteams werden eine unvernünftige Liste hinterfragen.

Entscheidung 5: Typ I oder Typ II und der Zeitraum

Ein Typ I ist schneller; ein Typ II ist das, was die meisten Kunden wollen. Für einen ersten Typ II ist ein Zeitraum von drei bis sechs Monaten üblich. Beginnen Sie erst, wenn die Kontrollen seit einigen Wochen laufen, damit der frühe Teil des Zeitraums nicht voller Abweichungen ist.

Eine Scoping-Checkliste

Klären Sie vor dem Kickoff mit Ihrer CPA-Firma folgende Fragen:

• Auf welches Produkt oder welchen Dienst bezieht sich der Bericht, und wofür benötigen Kunden ihn?
• Welche Umgebungen sind im Scope (nur Produktion oder auch Staging)?
• Welche Cloud-Konten, Regionen und Datenspeicher?
• Welche Teams und Rollen betreiben das System?
• Von welchen Subservice-Organisationen hängt das System ab, und liegen Ihnen deren Berichte vor?
• Welche Kategorien der Trust Services Criteria und warum?
• Welche ergänzenden Kontrollen der Nutzerunternehmen müssen Kunden betreiben?
• Typ I zuerst oder direkt Typ II? Welcher Zeitraum?
• Welche bestehenden Frameworks oder Audits liefern Nachweise, die Sie wiederverwenden können?

Schriftliche Antworten bilden den ersten Entwurf Ihrer Systembeschreibung und sparen Wochen des Hin und Her. Wenn Sie bereits ISO 27001 besitzen, beantwortet die ISO 27001 → SOC 2-Lückenanalyse die letzte Frage.

Scoping-Fehler, die am meisten kosten

• Unternehmens-IT „zur Sicherheit“ einbeziehen: Das verdoppelt die Zahl der Systeme, die belegt werden müssen.
• Privacy oder Processing Integrity hinzufügen, weil sie gut klingen: Jedes Kriterium bringt zusätzliche Kontrollen und Nachweise für den gesamten Zeitraum.
• Eine Systembeschreibung, die nicht der Realität entspricht: Prüfer testen, was Sie geschrieben haben.
• Den Zeitraum starten, bevor Kontrollen laufen: Abweichungen im ersten Monat bleiben im Bericht.

Unser SOC 2-Leitfaden behandelt den gesamten Prozess; die SOC 2-Framework-Seite listet jedes Kriterium mit seinen Zuordnungen auf; und wenn Sie bereits ein anderes Framework besitzen, zeigt die Lückenanalyse, wie weit Sie damit kommen.

Fragen

Was ist der Mindestumfang für einen SOC 2-Bericht?

Die Kategorie Security (die gemeinsamen Kriterien, CC1 bis CC9) für ein definiertes System. Availability, Confidentiality, Processing Integrity und Privacy sind optional.

Was ist ein Carve-out bei SOC 2?

Ausschluss der Kontrollen einer Subservice-Organisation (zum Beispiel der Rechenzentrumskontrollen Ihres Cloud-Anbieters) aus Ihrem Bericht, wobei beschrieben wird, worauf Sie sich dabei verlassen und wie Sie sie überwachen.