Irgendwann kommt die Mail vom Enterprise-Kunden: „Bitte schickt uns euren SOC-Report.“ Und dann beginnt das Rätselraten. SOC 1, SOC 2 oder SOC 3? Type 1 oder Type 2? Wer sich zum ersten Mal damit beschäftigt, steht vor einem Buchstabensalat, der schnell teuer wird, wenn man das falsche Audit beauftragt. Dabei folgt das Ganze einer simplen Logik: Es geht immer nur darum, wer was über eure Kontrollen wissen will.
Zuerst eine Begriffsfalle, die in der Praxis ständig für Verwirrung sorgt. Das Kürzel steht für zwei völlig verschiedene Dinge.
Eine Einheit aus Menschen, Prozessen und Technik, die eure IT überwacht. Dort gibt es die Level L1 bis L4 und Betriebsmodelle wie In-House, Managed oder Hybrid.
Ein Prüfbericht eines unabhängigen Auditors über eure Kontrollen. Hier gibt es SOC 1, SOC 2 und SOC 3 sowie Type 1 und Type 2. Darum geht es in diesem Beitrag.
Wenn ein Kunde „euren SOC-Report“ anfordert, meint er praktisch immer die zweite Bedeutung. Ein Security Operations Center produziert keinen SOC-Report, kann darin aber ein sehr überzeugender Beleg sein.
Ihr sucht das andere SOC? Aufbau, Betriebsmodelle und die Level L1 bis L4 haben wir hier erklärt: Was ist ein SOC? Und welche Varianten davon gibt es?
Ein SOC-Report ist kein Zertifikat, sondern ein Prüfbericht eines unabhängigen Auditors über die internen Kontrollen eines Dienstleisters. Er beantwortet die Frage, ob ein Unternehmen die Kontrollen, die es zu haben behauptet, tatsächlich implementiert hat und ob sie funktionieren.
Adressat ist dabei nicht eine Behörde, sondern eure Kunden und deren Prüfer. Sie tragen weiterhin Verantwortung für ihre Daten und Bilanzen, auch wenn sie Prozesse an euch ausgelagert haben. Der Report ist ihr Nachweis, dass diese Auslagerung sauber war. Genau deshalb existieren drei Varianten, die sich in Zielgruppe und Detailtiefe unterscheiden.
SOC 1 betrachtet ausschließlich die Kontrollen, die sich auf die Finanzberichterstattung eures Kunden auswirken. Der klassische Fall: Ihr wickelt Zahlungs- oder Abrechnungsprozesse ab. Wenn eure Systeme falsch rechnen, landen falsche Zahlen in der Bilanz des Kunden, und dessen Wirtschaftsprüfer will wissen, ob er euren Prozessen trauen kann.
Ein Payment-Dienstleister, der Abrechnungen für einen Klinikbetreiber verarbeitet, braucht typischerweise SOC 1. Ein Zeiterfassungs-Anbieter, dessen Daten in die Lohnbuchhaltung fließen, ebenfalls. Wer ein reines Kollaborationstool betreibt, hat mit der Bilanz seiner Kunden nichts zu tun und braucht kein SOC 1.
Häufiger Fehler: SOC 1 wird beauftragt, weil es „die 1″ ist und damit vermeintlich der Einstieg. Die Nummern sind aber keine Stufen, sondern unterschiedliche Themen. Wer keine Finanzdaten berührt, verbrennt mit SOC 1 nur Budget.
SOC 2 ist der Report, nach dem Enterprise-Kunden in den allermeisten Fällen fragen. Er bewertet eure Kontrollen anhand der Trust Services Criteria (TSC). Davon gibt es fünf, aber nur Security ist verpflichtend.
Schutz des Systems vor unbefugtem Zugriff. Das einzige verpflichtende Kriterium, oft als Common Criteria bezeichnet.
Verfügbarkeit gemäß zugesagter Service Levels. Relevant bei harten SLA-Zusagen im Vertrag.
Schutz vertraulich klassifizierter Informationen, etwa Geschäftsgeheimnisse oder Vertragsdaten eurer Kunden.
Vollständigkeit, Richtigkeit und Rechtzeitigkeit der Verarbeitung. Relevant überall dort, wo Daten transformiert oder berechnet werden.
Umgang mit personenbezogenen Daten. Privacy im TSC-Sinne ist nicht deckungsgleich mit der DSGVO und ersetzt sie nicht.
Die vier optionalen Kriterien wählt ihr nach Bedarf, und genau hier liegt die eigentliche Entscheidung. Jedes zusätzliche Kriterium erhöht Aufwand, Kosten und Auditdauer. Ein Scope, der ohne Not alle fünf TSC umfasst, ist kein Qualitätsbeweis, sondern meist ein Zeichen fehlender Vorbereitung.
Praxisempfehlung: Startet mit Security und ergänzt genau die Kriterien, nach denen eure Kunden in Verträgen oder Security-Fragebögen tatsächlich fragen. Der Scope lässt sich in Folgeaudits erweitern.
SOC 3 basiert auf derselben Prüfung wie SOC 2, liefert aber deutlich weniger Details. Der Unterschied liegt im Publikum. Ein SOC 2 Report enthält konkrete Kontrollbeschreibungen und Prüfergebnisse und geht nur unter NDA an Kunden. SOC 3 ist die verkürzte, frei verteilbare Fassung für die Website.
Große Cloud-Anbieter machen das genau so: Das SOC 3 Siegel liegt öffentlich auf der Trust-Seite, den vollständigen SOC 2 Report bekommen Enterprise-Kunden auf Anfrage. SOC 3 ist damit weniger ein Prüfinstrument als ein Vertrauenssignal nach außen.
Kurzformel: SOC 1 für die Wirtschaftsprüfer eurer Kunden. SOC 2 für deren Security-Teams und Einkauf. SOC 3 für alle anderen, die nur sehen wollen, dass ihr geprüft seid.
Unabhängig davon, ob SOC 1 oder SOC 2, gibt es jeden Report in zwei Ausführungen. Diese Unterscheidung wird häufig übersehen, entscheidet aber über die Aussagekraft.
Der Auditor prüft zu einem Stichtag, ob die Kontrollen so beschrieben und gestaltet sind wie behauptet. Bestätigt wird das Design, nicht die gelebte Praxis.
Der Auditor prüft über einen Zeitraum von typischerweise drei bis zwölf Monaten, ob die Kontrollen durchgehend wirksam waren. Bestätigt wird Design und operative Wirksamkeit.
Ernsthafte Kunden wollen Type 2 sehen. Ein Type 1 sagt lediglich, dass ihr an einem einzigen Tag aufgeräumt hattet. Als Einstieg ist er trotzdem sinnvoll, weil er schneller zu erreichen ist und die Zeit überbrückt, bis euer Type 2 Beobachtungszeitraum abgelaufen ist.
Hier schließt sich der Kreis zum anderen SOC: Ein Type 2 Report verlangt lückenlose Nachweise über Monate. Wer ein Security Operations Center betreibt oder als Managed Service einkauft, hat diese Monitoring- und Incident-Nachweise ohnehin und kann sie direkt als Evidenz einspeisen.
Die Entscheidung lässt sich auf drei Fragen herunterbrechen:
Ein Missverständnis, das teuer wird: SOC 2 ersetzt weder ISO 27001 noch die DSGVO. Es ist ein US-geprägtes Prüfformat, das in europäischen Ausschreibungen zunehmend auftaucht, die europäischen Anforderungen aber nicht abdeckt. Wer beides braucht, sollte die Kontrollen von Anfang an gemeinsam denken, statt zwei getrennte Projekte zu fahren.
SOC-Audits selbst werden von Wirtschaftsprüfern durchgeführt, das ist nicht unser Geschäft. Was wir machen: die Kontrollen, die ein solcher Report am Ende bewertet, überhaupt erst belastbar aufbauen und technisch nachweisen.
Ob ISMS, BSI-Grundschutz oder CISO as a Service: Wir bringen eure Sicherheitsorganisation auf ein Niveau, das jedem Audit standhält, unabhängig vom Prüfformat.
Penetration Tests, Schwachstellenmanagement und Attack Surface Analysen liefern genau die technischen Nachweise, die im Audit als Evidenz gefragt sind.
Unsicher, was ihr wirklich braucht? In einem kostenlosen Erstgespräch klären wir, welche Nachweise eure Kunden tatsächlich verlangen und was dafür bei euch fehlt. Jetzt Kontakt aufnehmen.
SOC 1, SOC 2 und SOC 3 sind keine aufeinander aufbauenden Stufen, sondern drei Antworten auf drei verschiedene Fragen. SOC 1 adressiert die Finanzberichterstattung, SOC 2 die Sicherheitskontrollen gegenüber Geschäftskunden, SOC 3 die Außendarstellung.
Die zweite Weichenstellung ist Type 1 gegen Type 2. Nur Type 2 belegt, dass eure Kontrollen über die Zeit wirksam bleiben. Type 1 ist ein Zwischenschritt, kein Ziel.
Der Report selbst kommt vom Auditor. Die Substanz dahinter müsst ihr liefern, und genau dabei unterstützen wir euch. Sprecht uns an.