SOC 2 Type II erklärt: was er beweist, wer ihn braucht und was er kostet

Was SOC 2 wirklich ist, und was nicht

SOC 2 ist ein Prüfbericht, den eine lizenzierte Wirtschaftsprüferin oder ein lizenzierter Wirtschaftsprüfer über die Kontrollen eines Dienstleisters erstellt. Die Abkürzung steht für System and Organization Controls, und die "2" bezeichnet jenen Bericht, der sich um Sicherheit und operative Kontrollen dreht und nicht um die Finanzberichterstattung. SOC 2 stammt aus den USA. Definiert, geregelt und gepflegt wird es vom American Institute of Certified Public Accountants (dem AICPA), das System and Organization Controls als "eine Reihe von Dienstleistungen, die CPAs anbieten können" beschreibt und festhält, dass es "die fachlichen Standards für SOC Prüfungen vorgibt".¹

Das Wichtigste zuerst, noch vor jedem Detail: SOC 2 ist kein Zertifikat. Es gibt kein Siegel, kein Bestanden oder Durchgefallen, keine behördliche Lizenz. Ein SOC 2 Bericht ist die unabhängige Meinung einer Prüferin, festgehalten in einem langen Dokument, darüber, ob die Kontrollen einer Organisation passend gestaltet waren und, im Fall von Type II, ob sie über einen Zeitraum tatsächlich so funktioniert haben wie beschrieben.¹² Der Bericht ist ein Dokument mit eingeschränktem Empfängerkreis, gedacht für den Dienstleister, seine Kunden und deren eigene Prüfer, nicht für das offene Netz.¹

Dieser Unterschied ist für die Ehrlichkeit entscheidend, und Ehrlichkeit ist der Kern meiner Arbeit. Ich baue Software auf jenem technischen Niveau, das ein SOC 2 Bericht beschreibt. Ich bereite ein Unternehmen so vor, dass eine Prüfung gelingen kann. Den Bericht ausstellen kann ich nicht, und kein anderer Entwickler kann das. Das darf einzig eine lizenzierte CPA Kanzlei, die du beauftragst und bezahlst. Wer dir erzählt, er werde dir "SOC 2 verschaffen", nimmt es entweder mit der Sprache nicht genau oder verkauft dir etwas, das es nicht gibt.

Wer einen SOC 2 Bericht ausstellt, und warum ich das nicht kann

Eine SOC 2 Prüfung läuft nach den Prüfstandards des AICPA, festgelegt im Statement on Standards for Attestation Engagements No. 18 (SSAE No. 18). Die gemeinsamen Anforderungen stehen in Abschnitt 105 dieser Standards, die Regeln für eine Prüfung mit Prüfungsurteil, und genau das ist ein SOC 2, in Abschnitt 205.² Diese Standards darf nur eine CPA anwenden, und das AICPA hält unmissverständlich fest, dass es bei nicht lizenzierten Prüfern gegen seine Mitglieder vorgeht und Aufsichtsbehörden unterstützt.¹

Die Rollen trennen sich also sauber, und ich halte sie bewusst auseinander:

• Die CPA Kanzlei ist unabhängig. Sie prüft deine Kontrollen und unterzeichnet das Urteil. Sie muss von dir unabhängig sein, und genau deshalb kann sie nicht zugleich jene Kanzlei sein, die deine Systeme gebaut hat.
• Ich bin der Baumeister und der Vorbereiter. Ich entwerfe und schreibe die Software so, dass die Kontrollen existieren, funktionieren und Nachweise hinterlassen. Ich mache die Lückenanalyse, helfe beim Umfang, stelle Protokollierung und Zugriffsmodell auf und bringe dich an den Punkt, an dem eine Prüferin etwas Echtes zu prüfen hat.

Würde ich zusätzlich behaupten, das Ergebnis selbst zu prüfen, wäre die Unabhängigkeit dahin, die einem SOC 2 Bericht seinen Wert gibt. Die beiden Rollen zu trennen ist keine Einschränkung. Sie ist der Grund, warum der Bericht überhaupt etwas bedeutet.

Die fünf Trust Services Criteria

Ein SOC 2 Bericht wird gegen die Trust Services Criteria geschrieben, eine Reihe von Kontrollkriterien, die das Assurance Services Executive Committee des AICPA aufgestellt hat. Die aktuelle Fassung sind die 2017 Trust Services Criteria mit überarbeiteten Points of Focus aus 2022, kodifiziert als TSP Abschnitt 100, und sie umfasst fünf Kategorien: Security, Availability, Processing Integrity, Confidentiality und Privacy.³

Du musst nicht über alle fünf berichten. Security ist die einzige, die immer dabei ist, weshalb sie als Common Criteria bezeichnet wird. Die anderen vier wählst du nach den Versprechen, die du deinen Kunden gibst, und nach der Art dessen, was du betreibst.³

Kategorie	Worum es geht	Wann du sie dazunimmst
Security (Common Criteria)	Schutz von Systemen und Daten vor unbefugtem Zugriff, in jedem SOC 2 Bericht verpflichtend.	Immer.
Availability	Ob das System wie zugesagt verfügbar ist, also die Verfügbarkeitsversprechen.	Wenn du eine Verfügbarkeit oder ein Service Level zusagst.
Processing Integrity	Ob die Verarbeitung vollständig, gültig, korrekt, rechtzeitig und autorisiert ist.	Wenn du Transaktionen oder Berechnungen für Kunden erledigst, etwa Zahlungen oder Abrechnung.
Confidentiality	Ob als vertraulich eingestufte Informationen wie zugesagt geschützt werden.	Wenn du Geschäftsdaten der Kunden unter Vertraulichkeit hältst.
Privacy	Ob personenbezogene Daten gemäß deiner Erklärung erhoben, genutzt, aufbewahrt und gelöscht werden.	Wenn du personenbezogene Daten verarbeitest und Datenschutzversprechen dazu gibst.

Die meisten Softwareunternehmen starten mit Security allein oder mit Security plus Availability und Confidentiality. Privacy dazuzunehmen ist ein größeres Vorhaben, und es ersetzt deine gesetzlichen Datenschutzpflichten nicht, dazu weiter unten mehr.

Type I und Type II, und warum Käufer Type II wollen

Jeden SOC 2 gibt es in einer von zwei Formen, und der Unterschied ist das, worauf ein Käufer am meisten achtet.

Ein Type I Bericht beschreibt, ob deine Kontrollen zu einem bestimmten Zeitpunkt passend gestaltet waren. Er ist eine Momentaufnahme. Er sagt, dass an dem Tag, an dem die Prüferin hingesehen hat, die richtigen Kontrollen vorhanden waren.²⁴

Ein Type II Bericht geht deutlich weiter. Er prüft, ob diese Kontrollen über einen Zeitraum tatsächlich wirksam funktioniert haben, das Beobachtungsfenster, das in der Regel drei bis zwölf Monate läuft.⁴ Die Prüferin bestätigt nicht nur, dass eine Kontrolle existiert. Sie zieht Nachweise aus dem ganzen Fenster und bestätigt, dass die Kontrolle weiter funktioniert hat: dass Zugänge wirklich entzogen wurden, wenn Leute gingen, dass Änderungen wirklich jedes Mal durch ein Review liefen, dass Backups Monat für Monat wirklich erstellt und getestet wurden.

Deshalb verlangen ernsthafte Käufer Type II. Eine Momentaufnahme lässt sich für einen Tag herrichten. Ein Bericht über sechs oder zwölf Monate Betrieb ist ein Nachweis für eine Disziplin, die du tatsächlich lebst. Type I hat als Zwischenschritt seinen Platz, um zu zeigen, dass die Gestaltung stimmt, während du die Betriebshistorie für Type II sammelst. Hat ein Großkunde aber Type II verlangt, wird ihn Type I nicht zufriedenstellen, und ihn so zu präsentieren, als täte er es, beschädigt das Vertrauen.

Wer SOC 2 braucht, und wer Geld ausgibt, das er sich sparen könnte

SOC 2 rechnet sich in einer bestimmten Lage: Du bist ein Cloud oder SaaS Unternehmen und verkaufst, oder willst verkaufen, an größere Firmen oder an US Kunden, die im Einkauf danach fragen. In dieser Welt ist ein SOC 2 Type II Bericht oft überhaupt erst die Eintrittskarte, um durch die Sicherheitsprüfung zu kommen. Ohne ihn bleibt der Abschluss im Risikoteam des Käufers hängen.

Mindestens so wichtig ist zu wissen, wann du ihn nicht brauchst. Ein Shop, der eigene Waren an Verbraucher verkauft, braucht kein SOC 2. Ein kleines Unternehmen ohne Großkunden und ohne US Käufer braucht kein SOC 2. Wenn in deiner Vertriebspipeline niemand danach fragt, gibst du echtes Geld aus, um eine Frage zu beantworten, die niemand stellt. Das sage ich dir lieber klar, als dir eine Prüfung zu verkaufen, die du nicht nutzen kannst.

Dazu kommt die geografische Seite. SOC 2 ist die nordamerikanische Erwartung. In Europa ist das international anerkannte Zertifikat für Informationssicherheit meist ISO/IEC 27001, der internationale Standard für ein Informationssicherheits Managementsystem, gegen den eine Organisation von einer akkreditierten Zertifizierungsstelle zertifiziert wird.⁵ Anders als ein SOC 2 Bericht ist ISO 27001 eine Zertifizierung mit einem Zertifikat und einem festen Dreijahreszyklus. Sind deine Kunden europäisch, ist vielleicht ISO 27001 das, was sie wirklich erwarten, oder du wirst nach beidem gefragt. Wie das zusammenpasst, beschreibe ich in meinem Überblick über die Qualitätsstufen für geschäftskritische Software, und ein ausführlicher Beitrag zu ISO 27001 folgt.

Was ein SOC 2 Bericht wert ist

Ein SOC 2 Type II Bericht leistet drei konkrete Dinge. Er macht Abschlüsse mit Großkunden und US Kunden möglich, die sonst im Einkauf stecken blieben. Er verkürzt die Sicherheitsfragebögen, die du sonst Zelle für Zelle ausfüllen würdest, weil vieles davon der Bericht selbst beantwortet. Und er ist ein echter, unabhängig geprüfter Nachweis operativer Disziplin, der auch intern etwas wert ist.

Genauso wichtig ist zu sagen, was er nicht ist. Ein SOC 2 Bericht ist keine Sicherheitsgarantie. Er sagt, dass deine Kontrollen passend gestaltet waren und über den beobachteten Zeitraum gegen die von dir gewählten Kriterien so funktioniert haben wie beschrieben. Er verspricht nicht, dass du nie angegriffen wirst. Und er ist kein Nachweis für die Einhaltung von Gesetzen. Die Datenschutz Grundverordnung etwa ist ein eigenes Rechtsregime mit eigenen Pflichten, darunter die Meldung von Verletzungen nach Artikel 33, und ein SOC 2 Bericht erledigt diese nicht.⁶ Ein guter Bericht ist ein starker Beleg dafür, dass du Sicherheit ernst nimmst. Er ist kein Ersatz für das Gesetz und kein Schutzschild gegen jeden Vorfall.

Wie die Prüfung abläuft, Schritt für Schritt

Der Weg zu einem Type II Bericht läuft in einer ziemlich festen Reihenfolge, und der größte Teil meiner Arbeit passiert, bevor die Prüferin überhaupt beginnt.

1. Bereitschaftsanalyse. Du machst, meist mit einem Vorbereiter wie mir, eine Lückenanalyse gegen die gewählten Kriterien. Jede Kontrolle wird als vorhanden, teilweise oder fehlend markiert, und die fehlenden werden zur Arbeitsliste. Hier passiert die eigentliche Technik.
2. Behebung. Du baust und reparierst: das Zugriffsmodell, den Änderungsprozess, die Protokollierung, die Backups, die Lieferantenprüfungen, die schriftlichen Richtlinien. Nichts danach kann eine Kontrolle retten, die es nicht gibt.
3. Umfang und Prüferwahl. Du entscheidest, welche Trust Services Kategorien dabei sind, wählst dein Beobachtungsfenster und beauftragst eine lizenzierte CPA Kanzlei. Du zahlst die Kanzlei direkt und getrennt von den Kosten des Baus.
4. Das Beobachtungsfenster. Für Type II läuft nun die Uhr, in der Regel drei bis zwölf Monate, in denen deine Kontrollen schlicht weiter funktionieren müssen, während sich Nachweise sammeln.⁴
5. Nachweissammlung und Feldarbeit. Die Prüferin fordert Stichproben aus dem ganzen Fenster an und prüft sie, oft aus der Ferne, gegen jede Kontrolle.
6. Der Bericht und sein Urteil. Die Prüferin hält Beschreibung, Kontrollen, Tests und Ergebnisse fest und unterzeichnet ein Urteil. Ein uneingeschränktes (sauberes) Urteil heißt, die Kontrollen waren passend gestaltet und haben wirksam funktioniert. Ein eingeschränktes Urteil nennt bestimmte Ausnahmen. Ein negatives Urteil heißt, auf die Kontrollen ist kein Verlass. Eine Nichtabgabe heißt, die Prüferin konnte gar kein Urteil bilden.²⁴

Das Urteil ist das, was Käufer zuerst lesen. Ein uneingeschränktes Type II ist das Ziel, auf das du hinarbeitest, und es wird in den Schritten eins und zwei verdient, lange bevor die Prüferin kommt.

Was du zuerst bauen musst, und wo ich hineinpasse

Ein SOC 2 Bericht beschreibt Kontrollen, aber Kontrollen sind kein Papierkram. Sie sind Technik, die du vorzeigen kannst. Für eine SaaS Plattform auf Ruby on Rails oder einen Solidus Shop ist das größtenteils ordentlich umgesetzte, gute Praxis, nachprüfbar gemacht.

Zugriffskontrolle und das Prinzip der geringsten Rechte kommen zuerst: Mehrfaktor Authentifizierung auf dem Adminbereich, den Produktionsservern, der Deployment Pipeline und der Cloud Konsole, dazu rollenbasierte Rechte, damit jeder nur erreicht, was seine Aufgabe braucht, und ein sauberer Ablauf, um Zugänge am Tag des Austritts zu entziehen. Änderungsmanagement heißt, dass jede Änderung an der Produktion durch ein Review läuft und eine Spur hinterlässt, und genau hier leisten ein Release Register und Sicherheitstests bei jedem Release echte Arbeit. Über das Nachweisen von Compliance mit Release Registern und Sicherheitstests pro Release habe ich eigens geschrieben, und genau diese Methode zieht eine Type II Prüferin als Stichprobe heran.

Protokollierung und Überwachung müssen zentral sein, mit Alarmen, die ein echter Mensch bekommt, denn eine Prüferin fragt, wer wann was gesehen hat. Verschlüsselung heißt Transportsicherheit auf jeder Verbindung und verschlüsselte Daten im Ruhezustand und in Backups. Lieferantenmanagement heißt eine dokumentierte Prüfung der Dienste, auf die sich dein Service stützt, ihrer Sicherheitslage und ihrer Vorfallsbedingungen, was an die Prüfung von Lieferanten vor dem Schaden anschließt, die ich im Datenschutzkontext beschreibe. Vorfallsreaktion heißt ein schriftlicher Ablauf, nicht guter Wille. Backup und Wiederherstellung heißt ein getesteter Restore, mit der Dauer und dem möglichen Datenverlust schriftlich festgehalten, nicht bloß ein Backup, das nie zurückgelesen wurde.

Diese Technik baue ich von Anfang an, damit die Vorbereitung auf eine Prüfung eine Frage des Nachweissammelns ist und kein Umbau des Systems. Jede Plattform, die ich liefere, bekommt außerdem einen Penetrationstest mit dem Kali Linux Werkzeugkasten, bevor sie ins Netz geht, mit Werkzeugen wie Nmap, Burp Suite und OWASP ZAP, und die Befunde werden nach Schwere und Behebung dokumentiert. Genau das ist die Art Nachweis, die eine Bereitschaftsanalyse sehen will.

Was es wirklich kostet, und wie lange es dauert

Kosten und Zeiträume schwanken stark mit deiner Größe und damit, wie reif deine Kontrollen schon sind, also sieh das Folgende als Planungsspannen, nicht als Angebot. Die Zahlen unten stammen von aktuellen Praktikern aus der Branche und stehen in US Dollar, weil die Prüfung selbst eine amerikanische Leistung ist, die du in Dollar bezahlst.

Zu den Kosten: Eine verbreitete Compliance Plattform setzt das Prüferhonorar für eine Type II Prüfung bei rund 12.000 bis 20.000 US Dollar für ein kleines bis mittleres Unternehmen an und bei 30.000 bis über 100.000 US Dollar für eine große Organisation, wobei ein Type II in der Regel 30 % bis 50 % mehr kostet als ein Type I. Die Vorbereitung kommt dazu: eine Lückenanalyse im Bereich von 5.000 bis 25.000 US Dollar, dazu die Umsetzung von Kontrollen, die auf 30.000 US Dollar oder mehr steigen kann. Alles zusammen, samt Werkzeugen und der Zeit deines eigenen Teams, wird ein Erstjahr auf rund 25.000 US Dollar für ein kleines Startup bis über 200.000 US Dollar für ein großes Unternehmen beziffert.⁷

Zum Zeitrahmen: Das AICPA setzt kein formales Mindestbeobachtungsfenster, aber drei Monate sind die praktische Untergrenze, sechs Monate eine häufige Wahl für ein erstes Type II und zwölf Monate üblich, sobald ein Programm reift. Vorbereitung und Behebung vor dem Fenster brauchen meist einen bis drei Monate, die Feldarbeit ein paar Wochen und der Bericht selbst noch ein paar. Ein realistischer Gesamtweg für ein erstes Type II liegt bei sechs bis zwölf Monaten.⁸

Die Trennung, an die du denken solltest, ist die, auf die ich immer wieder zurückkomme. Die Bereitschaft und die Technik sind Arbeit, die ich mit dir machen kann. Das Prüferhonorar ist eine eigene Kosten, die du der CPA Kanzlei direkt zahlst. Ich stelle das Prüferhonorar nie als Teil meines eigenen Preises dar, weil es nicht meines ist, und die beiden zu vermengen ist genau das, was Vertrauen zerstört.

SOC 2, ISO 27001, ein Penetrationstest und die DSGVO, das Richtige wählen

Diese vier werden ständig verwechselt, und das Falsche zu kaufen ist ein häufiger und teurer Fehler. Sie beantworten verschiedene Fragen.

Instrument	Was es ist	Was es beantwortet	Wer es dir gibt
SOC 2 Type II	Ein Prüfbericht nach AICPA Standards	Haben meine gewählten Kontrollen über einen Zeitraum wirksam funktioniert, für einen bestimmten Kunden zum Lesen	Eine lizenzierte CPA Kanzlei, die du beauftragst
ISO/IEC 27001	Eine internationale Managementsystem Zertifizierung	Betreibe ich ein anerkanntes Informationssicherheits Managementsystem, zertifiziert im Dreijahreszyklus	Eine akkreditierte Zertifizierungsstelle
Penetrationstest	Eine technische Sicherheitsprüfung	Kann ein Tester jetzt in dieses System einbrechen	Ein Sicherheitstester, etwa ich als Teil eines Baus
DSGVO	Ein Rechtsregime	Erfülle ich die gesetzlichen Pflichten für personenbezogene Daten	Niemand stellt sie aus, das Gesetz gilt einfach

Ein Penetrationstest ist eine technische Prüfung zu einem Zeitpunkt, keine Zertifizierung, und er ist Teil dessen, was ich bei jedem Bau liefere. SOC 2 und ISO 27001 sind die beiden Wege über Prüfbericht und Zertifizierung, gewählt meist nach Geografie und danach, was deine Käufer verlangen. Die DSGVO ist Gesetz, das gilt, ob du eines der anderen hast oder nicht.⁵⁶ Der ehrliche Rat ist einfach: Mach das, wonach deine tatsächlichen Kunden tatsächlich fragen, und nicht mehr, bis der nächste Kunde nach dem Nächsten fragt.

Ein durchgerechnetes Beispiel, ein Linzer SaaS Unternehmen wird nach SOC 2 Type II gefragt

Donauplan ist ein erfundenes Unternehmen in Linz mit 30 Mitarbeitenden und einem Umsatz von rund 4 Millionen €. Es verkauft eine Planungsplattform, die im Browser genutzt wird, unter donauplan.example, und es hat gerade die Einkaufsphase seines bisher größten Abschlusses erreicht: ein Vertrag mit einem großen US Händler, der den Umsatz etwa verdoppeln würde. Das Sicherheitsteam des Händlers verlangt einen SOC 2 Type II Bericht, bevor es unterschreibt. Donauplan hat so etwas noch nie gemacht.

Der erste Reflex des Gründers ist die Frage, ob ein Type I reicht, weil er schneller und weniger teuer ist. Er reicht nicht. Der Händler hat Type II verlangt, also würde ein Type I als Ausweichen gelesen. Donauplan entscheidet sich für das Type II.

Ich mache die Bereitschaftsanalyse gegen Security, Availability und Confidentiality, die drei Kategorien, die zu dem passen, was Donauplan seinen Kunden verspricht. Privacy bleibt vorerst außerhalb des Umfangs, weil Donauplans Datenschutzpflichten eigens behandelt werden und Privacy die Prüfung verbreitern würde, ohne dass ein Käufer danach fragt. Die Lückenanalyse zeigt das übliche Bild. Mehrfaktor Authentifizierung läuft auf der Cloud Konsole der Entwickler, aber nicht auf dem Adminpanel des Supportteams. Änderungen an der Produktion laufen meist durch ein Review, aber nicht jedes Mal, und es gibt kein Register, das es belegt. Backups laufen nächtlich, aber niemand hat heuer eines zurückgespielt. Einen schriftlichen Vorfallsablauf gibt es gar nicht.

Die Behebung dauert etwa zwei Monate. Mehrfaktor Authentifizierung kommt auf jeden Adminweg. Jede Produktionsänderung läuft nun durch ein Review und landet in einem Release Register, mit Sicherheitstest bei jedem Release. Die zentrale Protokollierung bekommt Alarme, die eine benannte Person erhält. Ein Restore Test auf Staging dauert 41 Minuten, und diese Zahl geht mit dem Zeitpunkt des nächtlichen Backups in den Fortführungsplan. Ein Vorfallsablauf wird geschrieben und geprobt.

Donauplan beauftragt dann eine lizenzierte CPA Kanzlei, wählt ein Beobachtungsfenster von sechs Monaten und zahlt die Kanzlei direkt. Sechs Monate lang funktionieren die Kontrollen schlicht weiter, während sich Nachweise sammeln. Die Prüferin zieht Stichproben aus dem Fenster, prüft aus der Ferne und stellt einen uneingeschränkten Type II Bericht aus. Der ganze Weg, von der ersten Lückenanalyse bis zum unterzeichneten Bericht, dauert etwa acht Monate, im Rahmen der oben genannten sechs bis zwölf Monate.⁸ Donauplan reicht den Bericht dem Sicherheitsteam des Händlers, die Einkaufssperre fällt, und der Vertrag wird unterschrieben. Der Bericht verkürzt danach die nächsten drei Sicherheitsfragebögen von Großkunden, weil das meiste darin schon beantwortet ist.

Was Donauplan gekauft hat, war kein Siegel. Es war eine geprüfte operative Disziplin, unabhängig bestätigt, die zufällig genau das war, was ein bestimmter Käufer verlangt hat.

Die ehrliche Position

SOC 2 Type II lohnt sich, wenn ein echter Käufer danach fragt, und ist hinausgeworfenes Geld, wenn niemand fragt. Lohnt es sich, teilt sich die Arbeit sauber. Ich baue das regelkonforme System und bereite dich auf die Prüfung vor: das Zugriffsmodell, das Änderungsmanagement und das Release Register, die Protokollierung, die Verschlüsselung, die Lieferantenprüfungen, den Vorfallsablauf und die getestete Wiederherstellung, alles so gebaut, dass es die Nachweise hinterlässt, die eine Prüferin als Stichprobe zieht. Dann beauftragst du eine unabhängige, lizenzierte CPA Kanzlei, es zu prüfen und den Bericht auszustellen, und du zahlst diese Kanzlei direkt. Ich stelle ihn nie aus, zertifiziere nichts und falte das Prüferhonorar nie in meines. Diese Trennung ist keine Schwäche des Angebots. Sie ist das, was den Bericht, und mein Wort darüber, vertrauenswürdig macht.

Bist du nach SOC 2 Type II gefragt worden und unsicher, ob du es wirklich brauchst, welche Kriterien du in den Umfang nimmst oder ob deine jetzigen Systeme eine Bereitschaftsanalyse überstehen würden? Buch den kostenlosen Workshop, und ich kläre es mit dir. Die ersten zwei Wochen Arbeit gehen auf meine Rechnung.

Footnotes

1. AICPA & CIMA, System and Organization Controls: SOC Suite of Services, aicpa-cima.com, abgerufen am 13. November 2026, https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services ↩ ↩² ↩³ ↩⁴

2. Journal of Accountancy, Clarified attestation standards issued (SSAE No. 18, AT-C sections 105 common concepts and 205 examination engagements), AICPA Publikation, 2016, https://www.journalofaccountancy.com/news/2016/apr/clarified-attestation-standards-issued-201614113/ ↩ ↩² ↩³ ↩⁴

3. AICPA & CIMA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus 2022), TSP section 100, veröffentlicht am 30. September 2023, https://www.aicpa-cima.com/resources/article/2017-trust-services-criteria-with-revised-points-of-focus-2022 ↩ ↩²

4. Linford & Company LLP (lizenzierte CPA Kanzlei), What is SOC 2? Compliance, certification and reports, guidance from an auditor, linfordco.com, abgerufen am 13. November 2026, https://linfordco.com/blog/what-is-soc-2/ ↩ ↩² ↩³ ↩⁴

5. International Organization for Standardization, ISO/IEC 27001 information security management systems, iso.org, abgerufen am 13. November 2026, https://www.iso.org/standard/27001 ↩ ↩²

6. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 33, EUR-Lex, https://eur-lex.europa.eu/eli/reg/2016/679/oj ↩ ↩²

7. Drata, SOC 2 audit cost, drata.com, abgerufen am 13. November 2026, https://drata.com/blog/soc-2-audit-cost ↩

8. Scrut Automation, SOC 2 compliance timeline: how long does it really take, scrut.io, abgerufen am 13. November 2026, https://www.scrut.io/hub/soc-2/soc-2-compliance-timeline ↩ ↩²