SOC 2 in 90 Tagen: Wie ein Healthcare-SaaS sein erstes Audit bestand

Repräsentatives Projekt. Kundendetails anonymisiert und Einzelheiten unter NDA verändert.

Die E-Mail, mit der alles begann, kam nicht von einem Sicherheitsteam. Ein Gründer hatte sie weitergeleitet, drei Zeilen lang, mit dem Betreff “wir könnten den Deal verlieren”. Ein Healthcare-SaaS-Unternehmen mit rund 40 Mitarbeitern hatte einen Enterprise-Vertrag in der Rechtsabteilung liegen, und die Lieferantenrisiko-Abteilung des Käufers hatte mit einer einzigen Bedingung geantwortet: einen SOC 2-Bericht vor dem Go-live vorlegen. Das Unternehmen hatte keinen. Es blieben 90 Tage, bis sich das Verlängerungsfenster schloss.

So beginnt SOC 2-Readiness in der Praxis meistens. Nicht damit, dass ein Sicherheitsteam beschließt, reifer zu werden, sondern damit, dass ein Kunde einen Vertrag zurückhält, bis man beweist, dass man Sicherheit ernst nimmt. Neunzig Tage sind wirklich knapp, aber für einen Type II mit kurzem Beobachtungszeitraum machbar, wenn man schnell handelt und aufhört, das Audit als Papierkram-Übung zu behandeln. Die Falle ist der Scope. Teams verbrennen regelmäßig den ersten Monat mit Diskussionen darüber, was einzubeziehen ist, statt Nachweise zu sammeln.

Hier ist, was wir getan haben, was die Gap-Analyse zutage förderte und welche Handvoll Änderungen ihnen zum Bestehen verhalf.

Die wichtigsten Erkenntnisse

• Bei SOC 2-Readiness geht es darum, nachzuweisen, dass Kontrollen über die Zeit funktionieren, nicht darum, in der Woche vor dem Auditor Richtlinien zu schreiben. Starten Sie die Nachweisuhr am ersten Tag.
• Für einen Type II mit kurzem Zeitfenster ist der schnellste Weg ein enger Scope: das Produktivsystem, das Kundendaten berührt, und sonst nichts.
• Die Lücken, an denen erste Audits scheitern, sind banal. Keine Zugriffsüberprüfungen, kein Offboarding-Nachweis, Logging, das läuft, aber niemand liest es. Keine exotischen Angriffe.
• Verdrahten Sie die Nachweissammlung mit Identität, Cloud-Konfiguration und Ticketing, damit Kontrollen ihren eigenen Nachweis erzeugen, statt sich auf Screenshots zu verlassen.
• Eine Readiness-Bewertung vor dem Audit verwandelt “wir hoffen, das besteht” in eine bekannte Liste von Lücken mit Verantwortlichen und Terminen.

Was SOC 2 von einem Unternehmen tatsächlich verlangt

SOC 2 ist ein Prüfbericht, den eine lizenzierte CPA-Firma anhand der AICPA Trust Services Criteria erstellt. Jeder SOC 2 deckt Security ab, bekannt als Common Criteria, und optional ergänzt man Availability, Confidentiality, Processing Integrity oder Privacy. Ein Type I-Bericht besagt, dass Ihre Kontrollen zu einem bestimmten Stichtag korrekt gestaltet waren. Ein Type II besagt, dass sie über einen Zeitraum tatsächlich funktioniert haben, üblicherweise drei bis zwölf Monate. Enterprise-Käufer wollen fast immer Type II, weil eine reine Design-Momentaufnahme nichts darüber aussagt, wie man sich im Tagesgeschäft verhält.

Bei einem Healthcare-SaaS ist Confidentiality meist im Scope, und darüber liegt eine zweite Realität: Wer geschützte Gesundheitsdaten verarbeitet, unterliegt weiterhin HIPAA. SOC 2 ist kein Ersatz für HIPAA. In diesem Projekt überschnitten sich beide so stark, dass wir jede Kontrolle einmal abbildeten und beide Anforderungen überall dort erfüllten, wo sie sich deckten, was dem Team die doppelte Arbeit ersparte.

Hier ist der Punkt, den viele übersehen. SOC 2 liefert Ihnen keine Liste umzusetzender Kontrollen. Es gibt keine Master-Checkliste von der AICPA. Sie definieren Ihre eigenen Kontrollen anhand der Kriterien, und der Auditor prüft, ob diese Kontrollen existieren und funktionieren. Genau diese Freiheit ist der Grund, warum Teams ohne Anleitung ins Stocken geraten.

Der 90-Tage-Plan, den wir umgesetzt haben

Wir teilten das Zeitfenster in drei Phasen und starteten die Nachweisuhr sofort, statt zu warten, bis das Richtlinienwerk perfekt war.

Tag 1 bis 20: Scope, Gap-Analyse und die Nachweisuhr

Zuerst legten wir den Scope fest, und das war ein Kampf. Der Instinkt des Kunden war, alles einzubeziehen: die Marketing-Website, ein internes Analytics-Tool, drei separate AWS-Accounts. Wir reduzierten es auf das eine Produktiv-Konto, das die Anwendung hostet und Kundendaten verarbeitet. Scope Creep ist der teuerste Fehler in einem ersten Audit. Jedes System, das Sie hineinziehen, vervielfacht die Nachweise, die Sie erbringen müssen, und die Kontrollen, die Sie über den gesamten Beobachtungszeitraum am Laufen halten müssen.

Dann die Readiness-Bewertung. Wir gingen jede Common-Criteria-Kontrolle durch und markierten sie als vorhanden, teilweise oder fehlend. Das Ergebnis war ein schlichtes Gap-Register mit einem Verantwortlichen und einem Fälligkeitsdatum pro Zeile, kein 60-seitiger Bericht, den nach dem Kickoff niemand öffnet.

Tag 20 bis 55: Behebung

Hier passiert die eigentliche Arbeit. Wir richteten die fehlenden Kontrollen ein, verdrahteten die Nachweissammlung mit den Tools, die das Team ohnehin nutzte, und brachten das Beobachtungsfenster in Gang, damit der Auditor echte Betriebshistorie zum Stichprobenziehen hätte statt einer Woche hastig vorgetäuschter Aktivität.

Tag 55 bis 90: betreiben, sammeln und das Audit

Die Kontrollen liefen, während sich die Nachweise von selbst ansammelten. Wir führten einen internen Probelauf anhand der erwarteten Anfrageliste des Auditors durch, besserten die zwei Punkte nach, die noch dünn waren, und übergaben der CPA-Firma ein sauberes Nachweispaket.

Was wir in der Gap-Analyse fanden

Keine der ernsten Lücken war spektakulär. Das ist das Muster bei fast jedem erstmaligen SOC 2-Readiness-Projekt, das wir durchführen. Was Audits scheitern lässt, ist operative Hygiene, nicht Zero-Days.

Keine Zugriffsüberprüfungen. Niemand hatte sich je hingesetzt und gefragt, wer auf die Produktion zugreifen konnte und ob er das noch brauchte. Zwei ehemalige Auftragnehmer hatten noch aktive IAM-Benutzer, einer davon fast ein Jahr nach Vertragsende. CC6.1 und CC6.2 kümmern sich beide darum, und Zugriff ist eines der ersten Dinge, die ein Auditor als Stichprobe zieht.

Offboarding lief informell. Wenn jemand ging, kam der Laptop zurück, aber der Zugriff wurde entzogen, “wann immer sich jemand daran erinnerte”. Kein Ticket, kein Zeitstempel, kein Nachweis. Ein Auditor akzeptiert kein “wir machen das immer”. Er greift sich einen Abgänger aus der HR-Liste und verlangt den Deprovisionierungsnachweis mit Datum.

Logging war aktiv, aber unbeobachtet. CloudTrail war aktiviert, worauf Teams gerne verweisen. Die Logs landeten in einem S3-Bucket, den kein Mensch und kein Alarm je berührte. Erkennung, die man nie ansieht, ist keine Kontrolle. Es ist Speicher mit einer monatlichen Rechnung.

Kein formales Change-Management. Die Engineers mergten und deployten über peer-reviewte Pull Requests in GitHub, was eigentlich eine solide Praxis war. Aber nichts Schriftliches verband diese Praxis mit einer Kontrolle, und so existierte sie aus Sicht des Auditors nicht.

Lieferantenmanagement war eine Tabelle, zuletzt 2023 angefasst. Ein Healthcare-SaaS stützt sich auf Unterauftragsverarbeiter, und die Kriterien erwarten, dass Sie diese erfassen und ihre Sicherheitslage im Blick behalten.

Sehen Sie, wie viele davon Dokumentations- und Nachweisprobleme sind und nicht “das machen wir überhaupt nicht”. Ein großer Teil von SOC 2-Readiness besteht darin, gute, aber unsichtbare Praktiken für jemanden lesbar zu machen, der nicht im Raum war.

Wie wir die Lücken schlossen, ohne das Engineering auszubremsen

Die Regel, die wir mit dem Kunden festlegten, war unmissverständlich: Nachweise automatisieren, damit eine Kontrolle ihren eigenen Beleg erzeugt, und nur dort auf einen manuellen Prozess zurückfallen, wo Automatisierung den Aufwand nicht wert ist.

Für Identität und Zugriff stellten wir alle hinter SSO, erzwangen MFA und richteten eine wiederkehrende vierteljährliche Zugriffsüberprüfung ein, deren Ergebnis als datiertes Artefakt gespeichert wird statt in einem Slack-Thread, der ins Vergessen scrollt. Für die Deprovisionierung koppelten wir das Offboarding an eine Ticketvorlage, sodass jeder Abgang nun einen zeitgestempelten Nachweis der Zugriffsentfernung erzeugt. Diese eine Änderung machte aus einer nicht belegbaren Kontrolle eine prüfbare.

Für Logging und Monitoring kauften wir keine große Plattform. Wir leiteten CloudTrail- und Anwendungslogs an ein Ziel mit Alarmierung für die Ereignisse, die zählen: Nutzung des Root-Accounts, Änderungen an IAM-Richtlinien und fehlgeschlagene Konsolen-Logins oberhalb eines Schwellwerts. Dann dokumentierten wir, wer Alarme prüft und wie oft. So las es sich in ihrer Kontrollmatrix:

Control ID : CC7.2
Statement  : Security events are logged and monitored; anomalies alert the on-call.
Evidence   : CloudTrail -> log sink; alert rules (root use, IAM change, failed logins);
             on-call rotation; sample alert + triage ticket from the observation window.
Frequency  : Continuous; reviewed weekly.
Owner      : Head of Engineering

Beim Change-Management änderten wir nichts an der Arbeitsweise der Engineers. Wir schrieben die Richtlinie so, dass sie zur bereits bestehenden Realität passte: Pull Request, verpflichtendes Review, CI-Checks, geschützter Main-Branch. Dann nutzten wir die vorhandene GitHub-Historie als Nachweis. Das Dokument an die Praxis anzupassen ist weit schneller und weit ehrlicher, als in der Woche vor dem Auditor einen neuen Prozess aufzupfropfen.

Die Richtlinien kamen zuletzt. Wir verfassten die Richtlinien für Sicherheit, Zugriffskontrolle, Incident Response, Change-Management und Lieferantenmanagement so, dass sie bereits laufende Kontrollen beschrieben. Richtlinien, die der Praxis vorauseilen, beschreiben eine Fantasie, und Auditoren sind sehr gut darin, die Lücke zwischen einer glänzenden Richtlinie und dem zu erkennen, was die Logs tatsächlich sagen.

Das Ergebnis

Sie bestanden. Die CPA-Firma stellte einen SOC 2 Type II-Bericht ohne Ausnahmen im Common-Criteria-Scope aus, was für ein erstes Audit ein starkes Ergebnis ist. Als repräsentatives Ergebnis für ein Unternehmen dieser Größe eingeordnet: Die Readiness-Bewertung förderte rund ein Dutzend relevanter Lücken zutage, die meisten wurden innerhalb der Behebungsphase geschlossen, und der Enterprise-Deal, der das Ganze angestoßen hatte, erreichte das Go-live.

Der nachhaltigere Gewinn war leiser. Die Nachweissammlung wurde zu einem Hintergrundprozess. Zugriffsüberprüfungen, Offboarding-Nachweise und die Triage von Alarmen erzeugen nun ihre eigenen Artefakte, sodass der nächste Auditzeitraum überwiegend Wartung ist statt eines weiteren 90-Tage-Kraftakts. Das ist die eigentliche Grenze zwischen dem Jagen nach einem Bericht und dem Betrieb eines Sicherheitsprogramms.

Wie CyberXplore hilft

Wir führen SOC 2-Readiness genauso durch wie dieses Projekt. Scope eng fassen, ehrlich bewerten, die Lücken schließen, die Auditoren wirklich prüfen, und Nachweise einbauen, damit sich Ihre Kontrollen selbst belegen. Wir bilden Kontrollen auf die Trust Services Criteria ab, führen den Probelauf vor dem Audit anhand der Anfrageliste durch und arbeiten Seite an Seite mit Ihrer CPA-Firma, damit Sie auf dem Weg zum Bericht nichts überrascht. Wenn ein Käufer auf einen Bericht wartet oder Sie eine Frist haben, die Sie sich nicht ausgesucht haben, fordern Sie ein Angebot an und wir sagen Ihnen ehrlich, ob Ihr Zeitfenster realistisch ist und was es braucht, um es einzuhalten.

FAQ

Kann man SOC 2 wirklich in 90 Tagen erreichen?

Sie können SOC 2-Readiness erreichen und einen Type II mit kurzem Beobachtungszeitraum in etwa 90 Tagen abschließen, wenn der Scope eng ist und Sie sofort mit dem Sammeln von Nachweisen beginnen. Der begrenzende Faktor ist der Beobachtungszeitraum, denn Type II verlangt, dass Kontrollen über die Zeit funktionieren, und das lässt sich nicht auf null zusammendrücken. Manche CPA-Firmen beobachten nicht unter drei Monaten, deshalb ist ein gängiger Ausweg zuerst ein Type I, um einen dringenden Käufer zufriedenzustellen, gefolgt von einem Type II-Zeitraum.

Was ist der Unterschied zwischen SOC 2 Type I und Type II?

Type I bescheinigt, dass Ihre Kontrollen zu einem einzelnen Stichtag angemessen gestaltet sind. Type II bescheinigt, dass diese Kontrollen über einen Zeitraum tatsächlich wirksam funktioniert haben, typischerweise drei bis zwölf Monate. Enterprise-Käufer verlangen in der Regel Type II, weil es das Verhalten über die Zeit belegt und nicht nur die Absicht an einem Tag.

Deckt SOC 2 HIPAA für einen Healthcare-SaaS ab?

Nein. SOC 2 und HIPAA sind getrennt. SOC 2 ist eine Prüfung anhand der AICPA Trust Services Criteria, während HIPAA eine US-Regulierung ist, die geschützte Gesundheitsdaten abdeckt. Sie überschneiden sich bei vielen Sicherheitskontrollen, sodass Sie die Arbeit so abbilden können, dass beide erfüllt werden, aber ein SOC 2-Bericht macht Sie nicht allein dadurch HIPAA-konform.

Welche Trust Services Criteria sollten wir einbeziehen?

Jeder SOC 2 muss Security enthalten, die Common Criteria. Sie ergänzen Availability, Confidentiality, Processing Integrity oder Privacy je nachdem, was Sie Kunden zusagen. Die meisten SaaS-Unternehmen starten mit Security plus Availability und Confidentiality und ergänzen Privacy nur dann, wenn sie konkrete Datenschutzzusagen machen.

Woran scheitern Unternehmen bei ihrem ersten Audit?

Fast nie an exotischen Sicherheitsfehlern. Es sind fehlende Nachweise: keine Zugriffsüberprüfungen, keine datierten Offboarding-Nachweise, Logging, das niemand überwacht, und Richtlinien, die einen Prozess beschreiben, den das Team gar nicht befolgt. Eine Readiness-Bewertung, bevor der Auditor kommt, ist der günstigste Weg, diese Lücken zu finden, solange Sie noch Zeit haben, sie zu beheben.

Wie viel davon lässt sich automatisieren?

Einen großen Teil. Nachweise zu Identität und Zugriff, Prüfungen der Cloud-Konfiguration, Änderungshistorie und Log-Monitoring können allesamt planmäßig ihre eigenen Artefakte erzeugen. Die Automatisierung der Nachweissammlung ist es, die SOC 2 von einer wiederkehrenden Feuerwehrübung in eine Wartungsaufgabe verwandelt, und es ist die einzelne Änderung, die sich über künftige Auditzeiträume am meisten auszahlt.