"Wie bestehen wir SOC 2?" ist die Frage, die die meisten Startups zum ersten Mal stellen, und die ehrliche Antwort beginnt damit, die Prämisse zu korrigieren. SOC 2 ist keine Prüfung mit einer Bestehensnote und es gibt kein Zertifikat. Eine unabhängige Wirtschaftsprüfungsgesellschaft prüft Ihre Kontrollen anhand der AICPA Trust Services Criteria und gibt eine Stellungnahme ab, einen schriftlichen Bericht, in dem festgestellt wird, ob die Kontrollen angemessen gestaltet wurden und – für den Berichts-Typ, den fast jeder Käufer tatsächlich möchte – ob sie während eines Beobachtungszeitraums wirksam angewendet wurden. "Bestehen" bedeutet, dass die Stellungnahme des Prüfers ohne Einschränkungen ausfällt: keine Ausnahmen, die schwerwiegend genug sind, um sie zu qualifizieren. Alles, was folgt, ist der Prozess, der ein Startup zu dieser uneingeschränkten Stellungnahme führt, und dabei geht es hauptsächlich um Scope und Disziplin, nicht um eine Checkliste von Codeänderungen.
Type I versus Type II und warum Type II der entscheidende ist
Ein Type-I-Bericht prüft, ob Ihre Kontrollen zu einem bestimmten Stichtag angemessen gestaltet sind. Er beantwortet die Frage: "Wenn diese Kontrollen wie beschrieben angewendet würden, würden sie die Kriterien erfüllen?", sagt aber nichts darüber aus, ob sie in der Praxis tatsächlich funktioniert haben. Ein Type-II-Bericht prüft dieselben Kontrollen auf ihre operative Wirksamkeit während eines Beobachtungszeitraums, in der Regel drei Monate für einen ersten Bericht und sechs bis zwölf Monate für eine Verlängerung. Er beantwortet die Frage, die für die Sicherheitsprüfung eines Käufers tatsächlich relevant ist: Haben Zugriffskontrolle, Change Management und Monitoring über einen echten Zeitraum standgehalten, und nicht nur auf dem Papier gut ausgesehen.
Die meisten Startups benötigen irgendwann Type II, da dies von der Einkaufsabteilung von Unternehmen und Sicherheitsfragebögen für Lieferanten zunehmend explizit verlangt wird. Type I hat dennoch eine Rolle: Es ist schneller zu erstellen (keine Wartezeit für den Beobachtungszeitraum) und einige Startups nutzen es als erstes Artefakt, um Fortschritte bei einem frühen Unternehmensdeal zu zeigen, während der Type-II-Beobachtungszeitraum parallel läuft. Keiner der Berichte ist eine Zertifizierung und keiner hat eine numerische Bewertung; das Ergebnis ist ein Bericht, der Ihre (durch das Management) Beschreibung des Systems und der Kontrollen, Ihre Erklärung, die Prüfungen und Ergebnisse des Prüfers für Type II sowie die Stellungnahme des Prüfers enthält.
Scope vor dem Aufbau einer einzigen Kontrolle: Nur Security ist verpflichtend
SOC 2 ist in fünf Trust Services Categories unterteilt: Security, Availability, Confidentiality, Processing Integrity und Privacy. Security, die Common Criteria (die CC-nummerierten Kriterien, CC1 bis CC9), ist die einzige verpflichtende Kategorie; jeder SOC-2-Bericht enthält sie. Die anderen vier sind optional, und ein Startup, das standardmäßig alle fünf in den Scope aufnimmt, baut und dokumentiert in der Regel Kontrollen, die niemand verlangt hat.
Definieren Sie den Scope basierend auf dem, was die Sicherheitsprüfungen Ihrer Käufer tatsächlich verlangen, und nicht anhand einer Vorlage. Ein B2B-SaaS-Unternehmen umfasst typischerweise Security sowie Availability (Sie verpflichten sich zu einer bestimmten Verfügbarkeit) und Confidentiality (Sie verarbeiten Kundengeschäftsdaten unter einer NDA-ähnlichen Pflicht). Processing Integrity ist vor allem relevant, wenn die Kernfunktion Ihres Systems darin besteht, Transaktionen zu verarbeiten, bei denen die Vollständigkeit und Genauigkeit dieser Verarbeitung das Versprechen des Produkts ist, z. B. bei Zahlungen oder Abrechnungen, und nicht nur "wir haben eine Datenbank". Privacy ist die AICPA-Kategorie für Verpflichtungen zur Verarbeitung persönlicher Daten in Ihrer eigenen Datenschutzerklärung, etwas anderes als die DSGVO oder andere gesetzliche Datenschutzbestimmungen; die meisten Startups erfüllen die Erwartungen der Käufer an die Verarbeitung persönlicher Daten, ohne diese Kategorie hinzuzufügen. Fragen Sie Ihre ersten wenigen Unternehmensinteressenten, was deren Sicherheits-Team für Lieferanten verlangt, bevor Sie sich auf einen Scope festlegen; es ist weitaus günstiger, eine Kategorie später hinzuzufügen, als eine zu dokumentieren, die niemand benötigt.
Der realistische Zeitplan
Zuerst kommt die Vorbereitung: eine Lückenanalyse anhand der von Ihnen festgelegten Kriterien, das Erstellen der von den Kriterien geforderten Richtlinien (Zugriffskontrolle, Change Management, Incident Response usw.) und das Schließen von Kontrolllücken in Ihren tatsächlichen Systemen (Erzwingen von MFA, Aktivieren der Audit-Protokollierung, Formalisierung eines Genehmigungsschritts für Änderungen). Für ein kleines Startup, das eine Compliance-Automatisierungsplattform zur Nachverfolgung von Beweisen und Kontrollen nutzt, dauert die Vorbereitung in der Regel vier bis acht Wochen; länger, wenn eine Kontrolle aufgebaut werden muss, anstatt nur dokumentiert zu werden, z. B. die Einrichtung einer zentralen Protokollierung, die zuvor nicht existierte.
Bei einem Type-II-Bericht folgt als Nächstes der Beobachtungszeitraum, und dessen Dauer kann ein Anbieter nicht verkürzen: Die Kontrollen müssen über einen vereinbarten Zeitraum hinweg angewendet werden, bevor der Prüfer sie testen kann. Ein Beobachtungszeitraum von drei Monaten sind also drei Kalendermonate, nicht eine nachträglich zusammengestellte Sammlung von Beweisen. Es gibt keine universelle gesetzliche Mindestdauer; der Zeitraum wird mit Ihrer Wirtschaftsprüfungsgesellschaft vereinbart und richtet sich danach, was die beabsichtigten Nutzer des Berichts erwarten. Erste Berichte decken in der Regel drei bis sechs Monate ab, Verlängerungen oft sechs bis zwölf Monate. Während des Beobachtungszeitraums müssen die Kontrollen im Scope konsistent angewendet werden: Eine Lücke kann zu einer stichprobenartig erfassten Ausnahme werden, abhängig von der Prüfung des Prüfers, deren Art, Häufigkeit und Bedeutung, aber nicht automatisch.
Die Prüfungsarbeiten folgen auf den Beobachtungszeitraum: Der Prüfer überprüft Beweise, prüft stichprobenartig Transaktionen und Änderungen, führt Interviews mit den Verantwortlichen für die Kontrollen durch und erstellt vorläufige Feststellungen, in der Regel innerhalb von zwei bis vier Wochen, bevor er den endgültigen Bericht ausstellt. Insgesamt dauert es für ein Startup realistisch fünf bis neun Monate vom Start bis zum Erhalt des Type-II-Berichts als typischer Richtwert, nicht als AICPA-Anforderung. Behandeln Sie ein Versprechen wie "SOC 2 in einem Monat" mit Vorsicht: In der Regel bezieht es sich auf die Vorbereitungsarbeiten, einen Type-I-Bericht oder einen ungewöhnlich kurzen Berichtszeitraum, den ein bestimmter Prüfer akzeptiert hat, nicht auf einen herkömmlichen mehrmonatigen Type-II-Bericht.
Was einen Beobachtungszeitraum tatsächlich gefährdet
Der Beobachtungszeitraum ist der Punkt, an dem die meisten Startups zum ersten Mal eine unangenehme Überraschung erleben, denn er ist lang genug, dass normale Entwicklungsarbeiten still und leise eine Kontrolle rückgängig machen können, die in der Vorbereitungsphase gerade erst eingerichtet wurde. Eine einzeilige Pull-Request, die eine IAM-Richtlinie aus Bequemlichkeit auf ein Wildcard erweitert, eine Bereinigung, die die Audit-Protokollzeile für eine privilegierte Aktion entfernt, ein Hotfix, der unter Zeitdruck den üblichen Genehmigungsschritt für Änderungen überspringt: Keine dieser Handlungen sieht während ihrer Ausführung wie Compliance-Arbeit aus, und jede davon ist genau die Art von Sache, die zu einer stichprobenartig erfassten Ausnahme werden kann, wenn sie innerhalb des Beobachtungszeitraums landet und die Prüfung des Prüfers sie erfasst. Die detaillierten Kontrollen, die tatsächlich in einem Diff auftauchen, meist die CC6-Familie für logischen Zugriff sowie CC7.2 (Überwachung) und CC8.1 (Change Management), sind im SOC-2-Framework-Deep-Dive und im Begleitleitfaden zu finden, was SOC 2 in Ihrem Repository prüft.
Hier setzt eine Compliance-Prüfung auf Pull-Request-Ebene während des Beobachtungszeitraums an: Sie liest jede Änderung im Hinblick auf die von Ihnen festgelegten Kriterien und benennt diejenige, die sie betrifft, z. B. CC6.1 bei der erweiterten IAM-Richtlinie, als Review-Kommentar zum Zeitpunkt, an dem die Änderung vorgeschlagen wird. Wird sie dort erkannt, kann das Team sie bewerten und beheben, bevor sie jemals bereitgestellt wird, in der Regel weitaus günstiger als im Nachhinein. Wird sie übersehen, handelt es sich um eine Änderung, die der Prüfer stichprobenartig als Ausnahme erfassen könnte, die Sie erklären müssten, was die Stellungnahme erschweren könnte, für die Sie Monate gearbeitet haben.
Was dies nicht ersetzt
Eine Pull-Request-Prüfung ist eine Ebene eines viel größeren Prozesses, und es ist wichtig, präzise zu sein, was den Rest angeht, denn keiner davon ist Aufgabe von heygrc. Die Auswahl Ihres Prüfers, die Festlegung Ihrer Trust Categories, das Erstellen Ihrer Richtlinien, das Durchführen der Vorbereitungs-Lückenanalyse, das Sammeln von Beweisen über Ihren gesamten Stack hinweg (Identitätsanbieter, Cloud-Konfiguration, HR-Onboarding und Offboarding, Lieferantenmanagement) für den gesamten Beobachtungszeitraum und das Ausstellen der Stellungnahme: All das ist das Compliance-Programm, das in der Regel über eine dafür entwickelte Plattform (der Leitfaden zu Compliance-Automatisierungstools bildet diese Ebene ab) sowie Ihren Prüfer abgewickelt wird. heygrc ist darauf ausgelegt, Pull Requests anhand der von Ihnen ausgewählten Kriterien zu prüfen und die Kontrolle zu benennen, die eine Änderung betrifft. Es führt keine Prüfung durch, ersetzt keinen Prüfer und führt nicht selbst zu einer uneingeschränkten Stellungnahme; es ist darauf ausgelegt, dem Team zu helfen, kontrollrelevante Pull-Request-Änderungen frühzeitig im Programm zu erkennen, bevor sie zu der Art von Ausnahme werden können, die das Erreichen der Stellungnahme erschwert.