SOC-2-Bericht für US-Kunden: Type 1 oder Type 2, Prüfer, Dauer und Kosten

Das Wichtigste in Kürze

• Ein SOC-2-Bericht ist ein Prüfbericht (Attestation), keine Zertifizierung: Eine unabhängige, zugelassene CPA-Prüfungsgesellschaft gibt ein Prüfungsurteil nach den Attestation-Standards des AICPA ab, und Sie geben den Bericht unter NDA an Kunden weiter.
• Ein SOC 2 Type 1 Bericht bewertet das Design Ihrer Kontrollen zu einem Stichtag. Ein Type 2 Bericht prüft zusätzlich, ob sie über einen Beobachtungszeitraum wirksam waren; beim ersten Bericht sind das typischerweise drei Monate, ab dem zweiten Bericht zwölf Monate.
• Ohne Vorarbeit dauert der erste SOC 2 Type 2 Bericht acht bis zehn Monate. Mit einem laufenden ISMS nach ISO 27001 schrumpft die Vorbereitung auf zwei bis drei Wochen und das gesamte Projekt auf etwa fünf bis sechs Monate.
• SOC 2 verlangt keinen Penetrationstest. Penetrationstests werden nur als ein Beispiel in den Points of Focus zum Kriterium CC4.1 genannt, und diese sind Orientierungshilfen, keine Anforderungen.
• Security ist die einzige Pflichtkategorie der Trust Services Criteria. Die meisten Unternehmen beschränken den Scope auf Security und nehmen Availability, Confidentiality oder Privacy erst auf, wenn ein Kundenvertrag es verlangt.

‍

Warum ein europäisches SaaS-Unternehmen plötzlich einen SOC-2-Bericht braucht

Ein europäisches SaaS-Unternehmen gewinnt seinen ersten US-Kunden oder steht kurz davor und erhält einen Sicherheitsfragebogen vom Einkauf oder vom Security-Team des Käufers. Einer der Punkte fragt nach einem aktuellen SOC-2-Bericht. Das Unternehmen betreibt vielleicht schon ein ISMS, manchmal mit einem ISO-27001-Zertifikat. Der Vendor-Risk-Prozess des US-Käufers ist aber auf SOC 2 ausgelegt, und in diesem Prozess ersetzt ISO 27001 den Bericht nicht. Warum US-Käufer sich so stark auf den Bericht stützen und was er einem Unternehmen über den ersten Deal hinaus bringt, beschreiben wir in unserem Überblick über die Vorteile eines SOC-2-Berichts für wachsende Tech-Unternehmen.

In meinen Projekten hat das typische Unternehmen in dieser Lage 5 bis 50 Mitarbeitende, meistens um die 20, läuft auf AWS, Azure oder GCP und hatte vor dem Fragebogen noch nie mit den Trust Services Criteria zu tun. Was es braucht, ist keine Erklärung des Standards. Es muss wissen, welchen Bericht es braucht, wer ihn ausstellen darf, wie lange der Kunde warten muss und was das kostet. Darum geht es in diesem Beitrag.

SOC 2 Type 1 oder Type 2: Was erwartet der US-Kunde?

Die kurze Antwort: Fragen Sie den Käufer. Die meisten US-Kunden wollen einen Type 2 oder akzeptieren einen Type 1 als Überbrückung, damit der Deal weiterläuft, während der Type 2 in Arbeit ist.

Der Unterschied liegt darin, worüber der Prüfer ein Urteil abgibt. In einem SOC 2 Type 1 Bericht beurteilt der Prüfer, ob Ihre Kontrollen zu einem Stichtag angemessen gestaltet und eingerichtet sind. In einem SOC 2 Type 2 Bericht prüft er zusätzlich, ob diese Kontrollen über einen Zeitraum wirksam funktioniert haben, den sogenannten Beobachtungs- oder Prüfungszeitraum. Ein Type 2 Bericht enthält deshalb einen Abschnitt mit jeder Kontrolle, dem durchgeführten Test und dem Ergebnis. Ein Type 1 enthält ihn nicht.

Was ich bei US-Kunden sehe:

• Einkaufsabteilungen großer Unternehmen und alle mit einem formalen Third-Party-Risk-Programm verlangen einen Type 2 und schreiben das in den Vertrag.
• Die meisten akzeptieren einen Type 1 als Überbrückung, wenn der Beobachtungszeitraum für den Type 2 bereits begonnen hat und Sie ein verbindliches Datum für den Type 2 Bericht nennen. Manche akzeptieren stattdessen eine unterschriebene Zusage, dass Sie auf ein Type 2 Audit hinarbeiten.

Meine Empfehlung: Bevor Sie irgendetwas entscheiden, fragen Sie den Käufer, welchen Berichtstyp er verlangt und welche Trust Services Criteria er im Scope erwartet. Seine Antwort bestimmt das Projekt. Ein Type 1 ist ein eigener Auftrag mit eigenem Honorar und verschafft Ihnen ein paar Monate. Wenn niemand wartet, sind diese Monate im Type-2-Zeitraum besser investiert.

Ein Punkt zur Begrifflichkeit, weil er in jedem Erstgespräch aufkommt: Es gibt keine "SOC-2-Zertifizierung" und kein Zertifikat. SOC 2 ist ein Attestation-Auftrag nach den Attestation-Standards des AICPA, SSAE No. 18 mit den Abschnitten AT-C 105 und 205, wie das AICPA es beschreibt. Das Ergebnis ist ein Bericht mit dem Prüfungsurteil eines Prüfers, und dieser Bericht ist vertraulich. Sie geben ihn unter NDA an Kunden weiter, meist über ein Trust Center oder auf Anfrage.

Wer darf einen SOC-2-Bericht ausstellen?

Die kurze Antwort: eine zugelassene Prüfungsgesellschaft. Für US-Kunden ist entscheidend, nach welchem Standard diese Gesellschaft ihr Urteil unterschreibt.

Ein Prüfungsurteil nach den Attestation-Standards des AICPA, geprüft gegen die Trust Services Criteria, darf nur eine CPA-Prüfungsgesellschaft unterschreiben, die von einem US State Board of Accountancy zugelassen ist, und die Gesellschaft muss vom geprüften Unternehmen unabhängig sein. Appendix G des SOC-2-Leitfadens des AICPA erlaubt außerdem Prüfern außerhalb der USA, gegen dieselben Kriterien nach dem internationalen Prüfungsstandard ISAE 3000 (Revised) zu prüfen und nach diesem Standard zu berichten. In der Praxis heißt das: Ein deutscher Wirtschaftsprüfer, ein niederländischer RA oder eine britische Chartered-Accountancy-Gesellschaft kann einen Bericht gegen die Trust Services Criteria ausstellen. Im strengen Sinn ist das kein AICPA-SOC-2-Bericht, auch wenn SOC 2 im Titel steht.

Was sonst niemand kann: Eine Beratung, ein Security-Anbieter oder eine ISO-Zertifizierungsstelle darf keines der beiden Urteile unterschreiben, und ein PDF mit "SOC-2-Zertifikat" ohne den Prüfbericht einer Prüfungsgesellschaft dahinter ist in keiner Form ein SOC-2-Bericht.

Für ein europäisches Unternehmen bleiben damit zwei Wege:

1. Eine in den USA zugelassene CPA-Prüfungsgesellschaft, die remote arbeitet. Das ist der Normalfall. Mehrere Gesellschaften haben sich auf SOC 2 für kleine und mittlere SaaS-Unternehmen spezialisiert, wickeln den ganzen Auftrag über Videocalls und Bildschirmfreigabe ab und haben kein Problem mit einem Kunden in München oder Wien.
2. Eine europäische Prüfungsgesellschaft, die nach ISAE 3000 gegen die Trust Services Criteria berichtet. Meist günstiger und näher. Passt gut, wenn der Bericht vor allem für europäische Kunden gedacht ist.

Wie viel macht der Unterschied aus? Für die meisten Käufer gar nichts. Der Security-Analyst oder Einkäufer sieht einen SOC 2 Type 2 Bericht mit Systembeschreibung, Prüfungsurteil, Kontrolltabellen und Testergebnissen und prüft nicht, ob im Urteil AT-C 205 oder ISAE 3000 steht. Die Ausnahme sind große US-Konzerne und regulierte Branchen wie Banken und Gesundheitswesen, deren Vendor-Risk-Richtlinie "issued by a licensed CPA firm" verlangt. Dort kann ein reiner ISAE-Bericht an einem Absatz scheitern, den niemand liest. Meine Regel: Klären Sie das mit dem potenziellen Kunden, bevor Sie einen SOC-2-Bericht beauftragen.

Was ich Kunden rate, vor der Unterschrift unter den Auftrag zu prüfen:

• Nach welchem Standard unterschreibt die Gesellschaft das Urteil: nach den Attestation-Standards des AICPA, nach ISAE 3000 oder nach beiden? Lassen Sie sich einen Musterbericht geben und lesen Sie die Seite mit dem Prüfungsurteil, nicht nur das Deckblatt.
• Hat die Gesellschaft schon SOC-2-Berichte für Unternehmen Ihrer Größe und mit Ihrem Tech-Stack ausgestellt? Ein Prüfer, der Banken gewohnt ist, verlangt von einem SaaS-Unternehmen mit 20 Mitarbeitenden Nachweise, die es nicht gibt.
• Wer macht die Feldarbeit? Manche Gesellschaften verkaufen unter einer CPA-Marke und vergeben die Tests an Subunternehmer. Sie sollten wissen, mit wem Sie zwölf Monate lang sprechen.
• Arbeitet die Gesellschaft mit Ihrem Compliance-Tool? Prüfer, die Nachweise direkt aus Ihrer Plattform lesen können, sparen Ihnen Wochen an Exporten.

Eines kann der Prüfer ebenfalls nicht: Ihre Kontrollen aufbauen. Wegen der Unabhängigkeitsregeln darf dieselbe Gesellschaft Ihre Kontrollen nicht gestalten und danach testieren. Vorbereitung und Audit sind zwei getrennte Aufträge, oft mit zwei verschiedenen Partnern.

Welche Trust Services Criteria brauchen wir?

Security, und in den meisten Fällen nur Security, sofern der Kunde nichts anderes vorgibt.

Die Trust Services Criteria haben fünf Kategorien: Security, Availability, Processing Integrity, Confidentiality und Privacy. Security ist in jedem SOC-2-Bericht Pflicht. Ihre Kriterien heißen Common Criteria, CC1 bis CC9; die anderen vier Kategorien kommen nur hinzu, wenn Sie sie in den Scope aufnehmen. Aufträge, die 2027 beginnen, nutzen in der Regel noch die Kriterien von 2017 mit den 2022 überarbeiteten Points of Focus. Was jede Kategorie verlangt und was der AICPA-Entwurf neuer Kriterien ab dem 31. Dezember 2027 ändern würde, erklären wir in unserem Leitfaden zu den SOC 2 Trust Services Criteria.

In meinen SOC-2-Projekten beschränkt fast jedes Unternehmen den Scope auf Security, und das empfehle ich als Standard. Die Gründe:

• US-Kunden fragen nach "einem SOC-2-Bericht". Kategorien nennen sie selten. Wenn doch, ist es Security.
• Jede zusätzliche Kategorie bringt Kriterien, Kontrollen und Nachweise mit und verlängert das Audit. Availability zum Beispiel bringt Kapazitätsmanagement, Backup-Tests und Wiederherstellungsziele mit, die Sie dann über den gesamten Beobachtungszeitraum nachweisen müssen.
• Sie können Kategorien im nächsten Berichtszyklus ergänzen, sobald ein Kunde sie verlangt. Ein nicht erfülltes Kriterium können Sie aus einem bereits ausgestellten Bericht nicht mehr entfernen.

Wann es sinnvoll ist, eine Kategorie von Anfang an aufzunehmen:

• Availability, wenn Ihre Verträge Uptime-SLAs enthalten und Kunden dagegen prüfen.
• Confidentiality, wenn Sie Kundendaten unter strengen vertraglichen Vertraulichkeitsklauseln verarbeiten, wie es in Fintech und Legal Tech üblich ist.
• Privacy, selten verlangt. Wenn Ihr Unternehmen aber DSGVO-Prozesse etabliert hat, ist diese Kategorie relativ leicht zu erreichen; im Wesentlichen ordnen Sie Ihre DSGVO-Praxis den Kriterien zu.

Was müssen wir selbst schreiben?

Ein SOC-2-Bericht hat vier Teile: das Prüfungsurteil, die Erklärung der Geschäftsleitung (Management Assertion), die Beschreibung Ihres Systems und (beim Type 2) die Tests und Ergebnisse des Prüfers. Die Systembeschreibung schreiben Sie als Geschäftsleitung selbst, und sie muss die Description Criteria des AICPA (DC Section 200) erfüllen. Sie erklärt, was der Service ist, auf welche Infrastruktur, Software, Personen, Verfahren und Daten er sich stützt, welche Kontrollen Sie betreiben, welche Teile des Service von Subservice-Organisationen erbracht werden und was Ihre Kunden auf ihrer Seite tun müssen.

Zwei Entscheidungen in der Systembeschreibung wirken sich auf das gesamte Audit aus:

• Subservice-Organisationen: Carve-out oder Inclusive. Ihr Cloud-Anbieter ist eine Subservice-Organisation. Bei der Carve-out-Methode nehmen Sie die Kontrollen des Anbieters aus Ihrem Bericht heraus, benennen sie und erklären, dass Sie sich auf sie stützen. Bei der Inclusive-Methode werden die Kontrollen des Anbieters in Ihrem Bericht mitgeprüft; das setzt die Mitwirkung des Anbieters voraus und ist bei einem Hyperscaler nicht realistisch. In meinen Projekten nutze ich jedes Mal die Carve-out-Methode und bitte die Kunden, die konkreten Kontrollen aufzulisten, auf die sie sich beim Anbieter verlassen (physische Sicherheit, Hardware-Entsorgung, Hypervisor-Patching), damit der Prüfer sieht, dass das eine bewusste Entscheidung war.
• Complementary User Entity Controls (CUECs). Das sind die Kontrollen, die Ihre Kunden betreiben müssen, damit Ihre Kontrollen funktionieren, etwa die Verwaltung ihrer eigenen Benutzerkonten in Ihrer Anwendung. Wenn Sie diese klar auflisten, sind Sie geschützt, falls ein Kunde Ihnen ein Zugriffsproblem auf seiner Seite anlastet.

Meine Empfehlung ist, die Beschreibung in den letzten Wochen der Vorbereitung zu schreiben, nicht am Anfang. Dann sind die Richtlinien geschrieben, sodass sich der Großteil der Beschreibung direkt daraus ableiten lässt. Außerdem haben Sie dann einen klaren Überblick über Ihre Dienstleister und Systeme, was die Entscheidungen zu Carve-outs und CUECs deutlich erleichtert.

Wie lange dauert ein SOC-2-Bericht?

Ohne Vorarbeit bis zum ersten Type 2 Bericht in der Hand sind acht bis zehn Monate realistisch: drei bis vier Monate Vorbereitung, ein Beobachtungszeitraum von drei Monaten und das Audit selbst. Mit einem nach ISO 27001 zertifizierten ISMS im laufenden Betrieb dauert die Vorbereitung zwei bis drei Wochen Lückenschluss, und das ganze Projekt passt in etwa fünf bis sechs Monate.

Das Projekt hat drei Phasen, und nur eine davon lässt sich verkürzen.

Was ich über den Zeitplan gelernt habe:

• Der Beobachtungszeitraum ist der Fixkostenblock. Die AICPA-Standards schreiben für einen Type 2 keine Mindestdauer vor. Sechs bis zwölf Monate sind am Markt üblich, und für einen ersten Bericht akzeptieren Prüfer einen kürzeren Zeitraum. Drei Monate setzen wir beim ersten Bericht an: Das ist die akzeptierte Ausnahme für Erstberichte und bringt den Bericht schnell zum Kunden. Der zweite Bericht sollte zwölf oder sechs Monate abdecken, ohne Lücke zwischen den beiden Zeiträumen.
• Bei der Vorbereitung zahlt sich ISO 27001 aus. Richtlinien, Risikobewertung, Asset-Inventar und Zugriffsreviews existieren bereits. Die Vorbereitung besteht also vor allem darin, die vorhandenen Kontrollen den Common Criteria zuzuordnen und die Lücken zu schließen, die der ISO-Scope nicht abgedeckt hat. Diese liegen typischerweise bei den COSO-geprägten Kriterien in CC1 und CC2 (Aufsicht durch die Leitung, Organisationsstruktur, interne Kommunikation) und bei CC9 (Dienstleisterrisiken, Business Continuity, Versicherungen). Auf einer Compliance-Plattform, auf der Umsetzungsaufgaben frameworkübergreifend geteilt werden, hat ein Unternehmen mit abgeschlossener ISO 27001 den Großteil des SOC-2-Fortschritts bereits erreicht, ohne etwas SOC-Spezifisches zu tun. Übrig bleiben zwei bis drei Wochen Lückenschluss, kein zweites Umsetzungsprojekt. Wie wir alle drei Frameworks einem Kontrollsatz zuordnen, zeigen wir in unserem Vergleich von ISO 27001, DSGVO und SOC 2.
• Prüfen Sie intern, bevor der Zeitraum beginnt, nicht währenddessen. Das ist optional und keine Audit-Anforderung, aber ich führe vor Beginn des Beobachtungszeitraums ein eintägiges internes Audit durch: Ist die Kontrolle eingerichtet, gibt es den Nachweis, den sie erzeugen soll, und lässt er sich aus dem System exportieren, das ihn erzeugt? Alles, was dabei auffällt, wird behoben, bevor es zu einer Ausnahme im Bericht werden kann. Dasselbe Problem vier Monate nach Beginn des Zeitraums zu finden, bedeutet entweder eine dokumentierte Ausnahme oder einen Neustart des Zeitraums.
• Die Nachweisanforderungen des Prüfers sind das Terminrisiko. Die Liste für die Type-2-Feldarbeit ist auch bei einem SaaS-Unternehmen mit 20 Mitarbeitenden lang. Wurden die Nachweise während des Beobachtungszeitraums laufend gesammelt, ist sie in einer Woche abgearbeitet. Müssen sie rekonstruiert werden, dauert es einen Monat.

Was kostet ein SOC-2-Audit?

Zwei Budgets: das Honorar des Prüfers und Ihre eigene Zeit. Die Honorare unterscheiden sich stark zwischen den Gesellschaften; vergleichen Sie deshalb Angebote für denselben Scope statt Listenpreise. Ein Type 1 allein ist günstiger als ein Type 2. Was das Honorar bewegt, sind die Zahl der Kategorien im Scope, die Zahl der Kontrollen und Subservice-Organisationen, die Länge des Beobachtungszeitraums und die Qualität der Nachweise, die Sie übergeben.

Die Kostentreiber, die ich am häufigsten sehe:

• Scope Creep bei den Kategorien. Availability oder Confidentiality aufzunehmen, weil es "besser aussieht", ist die teuerste vermeidbare Entscheidung im Projekt. Siehe oben.
• Neustart des Beobachtungszeitraums. Das teuerste Ergebnis überhaupt. Es passiert, wenn eine Kontrolle mitten im Zeitraum als fehlend oder defekt auffällt und sich nicht als isolierte Ausnahme dokumentieren lässt.

Ist ein Penetrationstest notwendig?

Nein. SOC 2 verlangt keinen Penetrationstest. Keines der Trust Services Criteria fordert einen; Penetrationstests werden nur als ein Beispiel in den Points of Focus zu CC4.1 genannt, und Points of Focus sind Orientierungshilfen, keine Anforderungen. CC4 und CC7 verlangen, dass Sie Ihre Kontrollen überwachen und Schwachstellen erkennen. Ein Pentest ist ein Weg, das zu zeigen, aber nicht der einzige. Prüfer fragen regelmäßig, ob Sie einen haben, und US-Kunden fragen im selben Fragebogen, der den SOC-2-Bericht verlangt, nach der Management-Zusammenfassung. Behandeln Sie ihn als eigene Entscheidung mit eigenem Budget: Wenn Kunden danach fragen oder Sie eine starke Antwort auf die Schwachstellenkriterien wollen, führen Sie ihn vor Ende des Beobachtungszeitraums durch und bewahren die Nachweise zur Behebung auf. Wenn niemand danach fragt, steht er nicht zwischen Ihnen und dem Bericht.

Was Sie Ihren Kunden vor einem SOC-2-Audit fragen sollten

Wenn eine Kundenanfrage der Auslöser für Ihren SOC-2-Bericht ist, stellen Sie diesem Kunden zuerst diese vier Fragen:

1. Welchen Berichtstyp brauchen Sie, und bis wann? Type 1, Type 2 oder jetzt ein Type 1 mit einem fest zugesagten Type 2 später. Das Datum zeigt Ihnen, ob sich ein Type 1 als Überbrückung lohnt.
2. Welche Trust Services Criteria erwarten Sie im Scope? Meist lautet die Antwort "ein SOC-2-Bericht" und sonst nichts, also Security. Nennt der Kunde Availability oder Confidentiality, gehört die Kategorie von Anfang an in den Scope und nicht erst in den zweiten Zyklus.
3. Verlangt Ihre Vendor-Risk-Richtlinie, dass das Urteil von einer zugelassenen CPA-Prüfungsgesellschaft unterschrieben wird? Diese eine Frage entscheidet zwischen einem lokalen ISAE-3000-Bericht und einer in den USA zugelassenen CPA-Gesellschaft. Sie jetzt zu stellen ist günstiger, als es nach Ausstellung des Berichts vom Einkauf zu erfahren.
4. Was steht sonst noch im Fragebogen? Eine Pentest-Zusammenfassung, ein Business-Continuity-Plan oder eine bestimmte Richtlinie stehen oft direkt neben der SOC-2-Anfrage. Wenn Sie das früh wissen, liefert der Beobachtungszeitraum auch die Nachweise für diese Punkte.

Wie Kertos Sie beim SOC-2-Bericht unterstützt

Kertos führt ISO 27001, DSGVO und SOC 2 über einen gemeinsamen Kontrollsatz. Umsetzungsaufgaben werden frameworkübergreifend geteilt. Ein Unternehmen, das ISO 27001 mit Kertos abgeschlossen hat, hat den Großteil der SOC-2-Arbeit also schon erledigt, und die Vorbereitung schrumpft auf die oben beschriebenen zwei bis drei Wochen Lückenschluss statt auf ein zweites Projekt. Die Plattform sammelt Nachweise laufend aus Ihren Systemen; genau das macht aus der Type-2-Anforderungsliste des Prüfers eine Woche Arbeit statt eines Monats.

Die zertifizierten Experten von Kertos begleiten Sie durch die Vorbereitung auf Type 1 und Type 2: beim Festlegen der Kategorien, bei der Systembeschreibung mit Carve-outs und CUECs und bei der internen Prüfung vor Beginn des Beobachtungszeitraums. Kaia, die KI-Assistentin von Kertos, beantwortet Fragen zu Ihren Kontrollen und erstellt Entwürfe auf Basis Ihrer eigenen Informationen. Den Bericht selbst stellt weiterhin eine unabhängige Prüfungsgesellschaft Ihrer Wahl aus, denn wer Ihnen beim Aufbau der Kontrollen hilft, darf sie nicht testieren.

Wenn ein US-Kunde gerade einen SOC-2-Bericht von Ihnen verlangt hat, buchen Sie eine Demo. Wir zeigen Ihnen, wie viel der Arbeit Ihr bestehendes Setup bereits abdeckt.

Häufig gestellte Fragen

Bekommen wir einen SOC-2-Bericht in drei Monaten, weil der Kunde wartet?

Einen Type 1 ja, wenn die Kontrollen bereits eingerichtet sind oder Sie mit einem laufenden ISMS nach ISO 27001 starten; dann dauert der Lückenschluss zwei bis drei Wochen. Einen Type 2 in drei Monaten gibt es ohne Vorarbeit nicht, weil allein der Beobachtungszeitraum nach Abschluss der Vorbereitung so lange dauert. Was in der Regel funktioniert: jetzt ein Type 1 und ein fest zugesagtes Datum für den Type 2 im Vertrag.

Unser Prüfer sitzt in den USA. Läuft das Audit remote?

Ja. In meinen Projekten läuft der gesamte Auftrag vom Kick-off bis zum finalen Bericht über Videocalls, Bildschirmfreigabe und das Nachweisportal. Bei einem Cloud-nativen Unternehmen gibt es keinen Vor-Ort-Termin. Planen Sie die Zeitverschiebung in den Wochen der Feldarbeit ein.

Läuft ein SOC-2-Bericht ab?

Der Bericht trägt kein Ablaufdatum, aber US-Kunden behandeln einen Type 2 Bericht etwa zwölf Monate nach Ende seines Beobachtungszeitraums als aktuell. Üblich ist ein Bericht pro Jahr mit aufeinanderfolgenden Zeiträumen ohne Lücke. Verzögert sich Ihr nächster Bericht, überbrückt ein Bridge Letter (auch Gap Letter genannt), den Ihre Geschäftsleitung unterschreibt, die Zeit zwischen dem Ende des letzten Zeitraums und dem nächsten Bericht.

Ist ein SOC-2-Bericht mit Ausnahmen ein Problem?

Nicht unbedingt. Ausnahmen stehen im Abschnitt mit den Tests und Ergebnissen, zusammen mit der Stellungnahme der Geschäftsleitung. Ein uneingeschränktes Urteil mit ein paar erklärten Ausnahmen ist normal, und Kunden sind es gewohnt, so etwas zu lesen. Ein eingeschränktes Urteil, in dem der Prüfer feststellt, dass die Kontrollen in einem ganzen Bereich nicht wirksam waren, sollten Sie vermeiden, und genau dafür ist die interne Prüfung vor dem Beobachtungszeitraum da.

Müssen wir den vollständigen Bericht jedem Kunden geben, der danach fragt?

Nein. Der Bericht ist vertraulich und wird unter NDA weitergegeben. Die meisten Unternehmen veröffentlichen eine kurze Zusammenfassung oder einen SOC-3-Bericht und schicken den vollständigen SOC-2-Bericht nur an Kunden und Interessenten, die ein NDA unterschreiben. In der Praxis wird der Bericht während des Einkaufsprozesses des Käufers angefragt und geteilt, als Teil des Security-Reviews vor Vertragsabschluss.

Ist ein ISAE-3000-Bericht dasselbe wie ein SOC-2-Bericht?

Nicht ganz. Eine europäische Prüfungsgesellschaft kann Ihre Kontrollen nach ISAE 3000 (Revised) gegen die Trust Services Criteria prüfen, und die meisten Käufer lesen das Ergebnis wie jeden SOC-2-Bericht: Systembeschreibung, Prüfungsurteil, Kontrollen und Testergebnisse. Im strengen Sinn ist es aber kein AICPA-SOC-2-Bericht. Ein Käufer, dessen Vendor-Risk-Richtlinie eine zugelassene CPA-Gesellschaft verlangt, kann ihn deshalb ablehnen. Fragen Sie nach, bevor Sie die Prüfungsgesellschaft auswählen.