SOC 2 Penetration Testing: Die wichtigsten Anforderungen, die Sie kennen müssen

Es ist verständlich, dass Sie verwirrt sind. Das SOC 2-Framework ist bewusst flexibel gestaltet, was zwar ideal ist, um Kontrollen an Ihre Umgebung anzupassen, aber es erschwert eine klare Antwort. Und wenn es um einen verzögerten Audit, ein eingeschränktes Testat oder einen verlorenen Enterprise-Deal geht, ist "es kommt darauf an" nicht die Art von Leitfaden, die Ihnen hilft, ruhig zu schlafen.

Die Wahrheit ist: Penetration Testing ist technisch gesehen nicht durch SOC 2 vorgeschrieben. Aber im Jahr 2026 ohne einen solchen Test in Ihren Audit zu gehen, ist ein Glücksspiel, das sich die meisten Unternehmen nicht leisten können. Lassen Sie uns genau aufschlüsseln, was das Framework besagt, was Auditoren tatsächlich erwarten und wie Sie einen Penetration Test so gestalten, dass er Ihre Sicherheitslage stärkt und Ihren Prüfer zufriedenstellt.

Eine kurze Einführung in SOC 2

Bevor wir über Penetration Testing sprechen, ist es hilfreich zu verstehen, was SOC 2 eigentlich ist – und was nicht.

SOC 2 wurde vom American Institute of Certified Public Accountants (AICPA) entwickelt. Im Gegensatz zu präskriptiven Compliance-Standards wie PCI DSS, die spezifische technische Kontrollen vorschreiben, die Sie implementieren müssen, ist SOC 2 ergebnisorientiert. Es definiert Kriterien, die Ihre Kontrollen erfüllen müssen, gibt Ihnen aber erhebliche Flexibilität bei der Umsetzung.

Das Framework bewertet Organisationen anhand von fünf Trust Services Criteria (TSC):

Security (auch Common Criteria genannt) ist für jeden SOC 2-Audit obligatorisch. Es umfasst Zugriffskontrollen, Risikobewertungen, Change Management, Incident Response und Schutz vor unbefugtem Zugriff. Die übrigen vier – Availability, Processing Integrity, Confidentiality und Privacy – sind optional und werden basierend auf den von Ihnen angebotenen Dienstleistungen und den Zusagen, die Sie Ihren Kunden geben, ausgewählt.

Es gibt zwei Arten von SOC 2-Berichten. Ein Type I-Audit bewertet das Design Ihrer Kontrollen zu einem bestimmten Zeitpunkt. Ein Type II-Audit untersucht sowohl das Design als auch die operative Effektivität dieser Kontrollen über einen Zeitraum von in der Regel sechs bis zwölf Monaten. Type II ist das, was die meisten Enterprise-Käufer und -Partner benötigen, und hier wird Penetration Testing besonders wichtig.

Ist Penetration Testing also durch SOC 2 vorgeschrieben?

Die kurze Antwort ist nein. Der Begriff "Penetration Testing" kommt in keiner SOC 2-Anforderung als obligatorische Aktivität vor. Die Trust Services Criteria des AICPA bieten zwar Richtlinien, lassen Organisationen aber Flexibilität beim Nachweis, dass ihre Sicherheitskontrollen vorhanden sind und funktionieren.

Aber hier liegt die Nuance.

Die Kriterien, die in dieser Diskussion am wichtigsten sind, fallen unter die Kategorie Monitoring Activities, insbesondere Common Criteria 4.1 (CC4.1). Darin heißt es:

Lesen Sie das sorgfältig durch. Das Framework fordert Sie auf, aktiv zu beweisen, dass Ihre Kontrollen funktionieren. Nicht nur, dass sie in einem Richtliniendokument existieren. Nicht nur, dass jemand eine Checkliste abgezeichnet hat. Es möchte Beweise dafür, dass jemand getestet hat, ob diese Kontrollen dem Druck standhalten.

Und in den Points of Focus, die CC4.1 begleiten, verweist das AICPA explizit auf Penetration Testing als eine Methode zur Durchführung dieser Bewertungen. Es werden auch unabhängige Zertifizierungen und interne Auditbewertungen erwähnt. Aber Penetration Testing wird direkt genannt, und Auditoren nehmen das zur Kenntnis.

Über CC4.1 hinaus kann Penetration Testing auch mehrere andere Kriterien unterstützen:

CC6.1 konzentriert sich auf logische und physische Zugriffskontrollen. Ein Pentest kann validieren, ob Ihre Zugriffsbeschränkungen tatsächlich unbefugten Zugriff auf Systeme verhindern, die sensible Daten speichern oder verarbeiten.

CC7.1 verlangt von Ihnen, Ihre Systeme auf Anomalien zu überwachen, die auf Sicherheitsereignisse hindeuten könnten. Aktive Tests Ihrer Abwehrmechanismen tragen dazu bei, nachzuweisen, dass Ihre Überwachungs- und Erkennungsfunktionen tatsächlich bösartiges Verhalten erkennen.

A1.2, relevant, wenn Availability im Scope ist, befasst sich mit dem Design und der Wartung von Umweltschutzmaßnahmen, Software und Wiederherstellungsinfrastruktur. Ein Penetration Test, der auf Verfügbarkeit ausgerichtete Szenarien beinhaltet, kann auch hier Beweise liefern.

Keines dieser Kriterien schreibt einen Pentest vor. Aber jedes einzelne ist deutlich einfacher zu erfüllen – und für einen Auditor deutlich überzeugender –, wenn Sie auf reale Testergebnisse verweisen können.

Was Auditoren im Jahr 2026 tatsächlich erwarten

Hier trifft Theorie auf Realität.

Auditoren erwarten im Jahr 2026 überwiegend, Penetration Testing-Nachweise als Teil eines SOC 2-Engagements zu sehen. Dies gilt insbesondere für Type II-Audits, bei denen sie beurteilen müssen, ob Ihre Kontrollen im Laufe der Zeit effektiv funktioniert haben. Ein Penetration Test liefert einen konkreten Beweis dafür, dass jemand versucht hat, Ihre Kontrollen zu umgehen, und dokumentiert hat, was er gefunden hat.

Mehrere erfahrene Auditoren haben die Dynamik wie folgt beschrieben: Sie prüfen nicht nur Richtliniendokumente und Konfigurations-Screenshots. Sie wollen sehen, dass Ihre Organisation proaktiv nach Schwachstellen gesucht hat, indem sie die Arten von Angriffen simuliert hat, die ein echter Angreifer versuchen würde. Ein sauberer Pentest-Bericht mit Scope-Dokumentation, Methodik, Ergebnissen und Nachweisen über die Behebung ist eines der stärksten Beweismittel, die Sie einem Prüfer vorlegen können.

Die praktische Realität ist, dass Ihr Auditor fast sicher danach fragen wird, wenn Sie ohne einen Penetration Test erscheinen. Möglicherweise können Sie CC4.1 auf andere Weise erfüllen – interne Auditbewertungen, Zertifizierungen von Drittanbietern oder kontinuierliche Überwachungsdaten –, aber Sie müssen einen überzeugenden Fall vorlegen. Und für viele Organisationen, insbesondere SaaS-Unternehmen, die Kundendaten verarbeiten, ist ein Pentest der Weg des geringsten Widerstands und das stärkste Signal für den Auditor.

Stellen Sie sich das wie Bauvorschriften für ein Haus vor. Der Inspektor will nicht nur den Bauplan sehen – er will sehen, dass jemand das Fundament auf Herz und Nieren geprüft hat.

Den Scope Ihres Pentests für SOC 2 festlegen

Wenn Sie in einen Penetration Test für Ihren SOC 2-Audit investieren (und das sollten Sie), ist das Wichtigste, den Scope richtig festzulegen. Ein beeindruckend aussehender Pentest, der nicht mit Ihrer SOC 2-Systemgrenze übereinstimmt, ist aus Audit-Sicht nahezu nutzlos.

Ihre Systembeschreibung abgleichen

Ihr SOC 2-Bericht enthält eine Systembeschreibung, die die Grenzen Ihres Audits definiert – die Infrastruktur, Anwendungen, Datenflüsse und Services, die im Scope enthalten sind. Ihr Penetration Test muss denselben Bereich abdecken.

Wenn Ihre Systembeschreibung auf eine kundenorientierte API, eine Webanwendung und eine Cloud-gehostete Datenbank verweist, muss der Scope Ihres Pentests alle drei umfassen. Wenn der Pentest nur die Webanwendung abdeckt und die API ignoriert, ist dies eine Scope-Lücke, die Ihr Auditor beanstanden wird.

Bevor Sie einen Testanbieter beauftragen, teilen Sie ihm Ihren Systembeschreibungsentwurf mit. Ein guter Anbieter wird den Pentest-Scope direkt Ihrer SOC 2-Grenze zuordnen und alle Bereiche mit Überschneidungen oder Lücken vermerken.

Alle Angriffsflächen abdecken

Ein gut definierter SOC 2-Pentest umfasst in der Regel mehrere Komponenten:

Externes Netzwerk-Testing untersucht Ihre dem Internet zugewandte Infrastruktur – Webserver, Mailserver, VPN-Endpunkte, APIs und alles andere, was dem öffentlichen Internet ausgesetzt ist. Dies simuliert, was ein externer Angreifer vorfinden würde, wenn er versucht, in Ihr System einzudringen.

Internes Netzwerk-Testing simuliert ein Szenario, in dem ein Angreifer bereits einen Fuß in Ihr Netzwerk gesetzt hat, möglicherweise durch Phishing oder einen kompromittierten Endpunkt. Es bewertet, ob Ihre interne Segmentierung, Zugriffskontrollen und Erkennungsmechanismen die laterale Bewegung in Richtung sensibler Systeme verhindern.

Webanwendungs-Testing konzentriert sich auf die benutzerdefinierten Anwendungen, die Ihr Unternehmen entwickelt und wartet, insbesondere auf solche, die Kundendaten verarbeiten. Tester suchen nach gängigen Schwachstellen wie Injection-Flaws, defekter Authentifizierung, unsicheren API-Endpunkten und Fehlern in der Geschäftslogik, die automatisierte Scanner in der Regel übersehen.

Cloud-Umgebungs-Testing ist unerlässlich, wenn Ihre Infrastruktur auf AWS, Azure oder GCP läuft. Tester bewerten IAM-Konfigurationen, Speicherberechtigungen, Netzwerksicherheitsgruppen und dienstspezifische Fehlkonfigurationen. Das Shared-Responsibility-Modell bedeutet, dass Ihr Cloud-Anbieter die zugrunde liegende Plattform sichert, Sie aber für alles verantwortlich sind, was Sie darauf aufbauen.

Abhängig von Ihrer Umgebung können Sie auch Wireless-Testing, Social Engineering-Bewertungen oder Mobile-Application-Testing einbeziehen. Entscheidend ist, dass jede Komponente in Ihrer Systembeschreibung eine entsprechende Abdeckung in Ihrem Pentest hat.

Das Timing ist wichtig

Für Type II-Audits kann das Timing Ihres Penetration Tests seinen Wert als Beweismittel erhöhen oder mindern. Idealerweise sollte Ihr Pentest innerhalb des Audit-Beobachtungszeitraums oder sehr nahe daran stattfinden. Ein Test, der 14 Monate vor dem Ende des Audit-Zeitraums durchgeführt wurde, sagt dem Auditor sehr wenig über die aktuelle Wirksamkeit Ihrer Kontrollen aus.

Viele Organisationen planen ihren Pentest in der ersten Hälfte des Audit-Zeitraums. Dies gibt ihnen Zeit, den Bericht zu erhalten, alle Ergebnisse zu beheben, Nachtests durchzuführen und die Ergebnisse dennoch in den Beobachtungszeitraum fallen zu lassen. Wenn Sie Ihren ersten SOC 2 Type I durchlaufen, ist das Timing flexibler, da das Audit eine Momentaufnahme ist – es sollte aber dennoch aktuell sein.

Häufige Fehler, die Audits zum Scheitern bringen

Selbst Organisationen, die in Penetration Testing investieren, können bei der Ausführung ins Stolpern geraten. Hier sind die Fehler, die am häufigsten Probleme bei SOC 2-Bewertungen verursachen.

Sich ausschließlich auf automatisiertes Scannen verlassen

Automatisierte Vulnerability-Scanner sind nützliche Tools, aber sie sind keine Penetration Tests. Scanner identifizieren bekannte Schwachstellen, indem sie Signaturen mit einer Datenbank abgleichen. Sie können keine Fehler in der Geschäftslogik bewerten, keine Szenarien zum Umgehen der Authentifizierung testen, nicht mehrere Low-Risk-Ergebnisse zu High-Impact-Exploits verketten und keine Art von risikokontextualisierter Analyse liefern, die Auditoren erwarten.

Auditoren kennen den Unterschied. Ein Vulnerability-Scan-Bericht, der anstelle eines Penetration Tests eingereicht wird, wird wahrscheinlich Fragen, Verzögerungen oder ein eingeschränktes Testat auslösen. Verwenden Sie Scanning als Ergänzung zu Pentesting – nicht als Ersatz.

Interne Teams ohne Unabhängigkeit einsetzen

Unabhängigkeit ist beim Audit wichtig. Ein Penetration Test, der von Ihrem eigenen Engineering- oder Sicherheitsteam durchgeführt wird – selbst einem technisch versierten –, entbehrt der Unparteilichkeit durch Dritte, die Auditoren erwarten. Der Prüfer muss darauf vertrauen können, dass die Tests gründlich, unvoreingenommen und frei von Interessenkonflikten waren.

Das bedeutet nicht, dass Ihr internes Team nicht teilnehmen kann. Es kann bei der Festlegung des Scopes helfen, Zugangsdaten bereitstellen und für Fragen zur Verfügung stehen. Aber das eigentliche Testen und die Berichterstattung sollten von einem unabhängigen, qualifizierten Dritten durchgeführt werden.

Behebung und Nachtests ignorieren

Das Identifizieren von Schwachstellen ist nur die halbe Miete. Auditoren wollen eine vollständige Geschichte sehen: was gefunden wurde, was behoben wurde und wie Sie die Behebung verifiziert haben.

Wenn Ihr Pentest eine kritische SQL-Injection-Schwachstelle in einer kundenorientierten Anwendung aufdeckt, möchte der Auditor mehr als nur das ursprüngliche Ergebnis sehen. Er möchte ein Behebungsticket sehen, das zeigt, dass Ihr Team es behoben hat, einen Zeitplan, der zeigt, dass es umgehend behoben wurde, und Nachweise für Nachtests, die bestätigen, dass die Schwachstelle nicht mehr vorhanden ist.

Ein Penetration Test mit ungelösten kritischen Ergebnissen ist aus Audit-Sicht schlimmer als gar kein Test, da er bekannte Risiken dokumentiert, die Sie nicht behoben haben.

Scope-Fehlausrichtung

Wir haben dies bereits erwähnt, aber es muss wiederholt werden, da dies einer der häufigsten Gründe dafür ist, dass Organisationen eingeschränkte SOC 2-Testate erhalten. Wenn der Scope Ihres Pentests nicht mit Ihrer Systembeschreibung übereinstimmt, hat der Auditor keine Möglichkeit, die Testergebnisse den Kontrollen zuzuordnen, die er bewertet.

Überprüfen Sie Ihre Systembeschreibung und Ihr Pentest-Scope-Dokument Seite an Seite, bevor Sie mit dem Testen beginnen. Melden Sie alle Abweichungen und beheben Sie sie im Vorfeld.

Den richtigen Testansatz wählen

SOC 2 schreibt keine bestimmte Art von Penetration Test vor, was bedeutet, dass Sie Flexibilität bei der Wahl des Ansatzes haben, der am besten zu Ihrer Umgebung passt.

Black-Box-Testing simuliert einen externen Angreifer ohne Vorkenntnisse Ihrer Systeme. Der Tester beginnt bei Null, führt eine Aufklärung durch und versucht, in Ihre Abwehrmechanismen einzudringen, genau wie ein echter Bedrohungsakteur. Dies bietet eine realistische Sicht auf Ihre externe Sicherheitslage, kann aber zeitaufwendig sein.

Grey-Box-Testing gibt Testern begrenzte Informationen – vielleicht ein Benutzerkonto, eine API-Dokumentation oder Netzwerkdiagramme –, um einen besser informierten Angreifer oder einen böswilligen Insider zu simulieren. Dieser Ansatz ist oft der Sweet Spot für SOC 2-Engagements, da er sowohl externe als auch interne Angriffsszenarien effizient abdeckt, ohne übermäßig viel Zeit für die Discovery aufzuwenden.

White-Box-Testing bietet vollständigen Zugriff auf Quellcode, Architektur-Dokumentation und Administratoranmeldeinformationen. Dies ermöglicht die tiefste Analyse, wird aber häufiger mit Secure-Code-Reviews als mit traditionellem Pentesting in Verbindung gebracht.

Für die meisten SaaS-Unternehmen, die SOC 2 anstreben, bietet ein Grey-Box-Ansatz, der externe Infrastruktur, interne Systeme, Webanwendungen, APIs und Cloud-Konfigurationen umfasst, die stärksten Beweise zu einem vernünftigen Preis. Ihr Testanbieter kann Ihnen helfen, das richtige Gleichgewicht basierend auf Ihrer spezifischen Umgebung und den Trust Services Criteria zu finden, die Sie in Ihren Audit-Scope aufgenommen haben.

Was sollte im Pentest-Bericht enthalten sein?

Ihr Penetration Test-Bericht ist das primäre Artefakt, das Ihr Auditor überprüfen wird. Er muss eine klare, glaubwürdige Geschichte erzählen. Obwohl es kein vorgeschriebenes Format gibt, sollte ein Bericht, der Ihren SOC 2-Audit unterstützt, die folgenden Elemente enthalten.

Eine Executive Summary gibt Stakeholdern einen allgemeinen Überblick über das Engagement, die wichtigsten Ergebnisse und die allgemeine Risikolage. Dies ist oft das, was Ihr Auditor zuerst liest.

Ein Scope- und Methodikabschnitt beschreibt die im Test enthaltenen Systeme, den Testansatz (Black Box, Grey Box oder White Box), die verwendeten Tools und Techniken sowie alle Einschränkungen oder Ausschlüsse. Methodiktransparenz ist eine grundlegende Qualitätsschwelle, die Auditoren erwarten.

Detaillierte Ergebnisse sollten jede entdeckte Schwachstelle mit genügend Kontext beschreiben, damit jemand das Risiko verstehen kann. Dazu gehören eine Schweregradeinstufung, eine Beschreibung, wie die Schwachstelle ausgenutzt werden könnte, Beweise wie Screenshots oder Proof-of-Concept-Demonstrationen und die potenziellen Auswirkungen auf das Geschäft.

Behebungsempfehlungen bieten umsetzbare, priorisierte Schritte zur Behebung jedes Ergebnisses. Die besten Berichte sagen nicht nur "beheben Sie dies" – sie erklären, wie es behoben werden kann und welches erwartete Ergebnis erzielt werden soll.

Schließlich bestätigen Nachtestergebnisse, dass identifizierte Schwachstellen behoben und verifiziert wurden. Dies schließt den Kreis und gibt Ihrem Auditor das Vertrauen, dass die Ergebnisse ernst genommen wurden.

Wie oft sollten Sie testen?

SOC 2 legt keine Häufigkeit für Penetration Testing fest, aber jährliche Tests haben sich als akzeptierter Standard etabliert. Sie sollten mindestens einmal pro Jahr einen Penetration Test durchführen, wobei die Ergebnisse in Ihren Audit-Beobachtungszeitraum fallen.

Über den jährlichen Rhythmus hinaus sollten Sie auch nach wesentlichen Änderungen an Ihrer Umgebung Tests in Betracht ziehen. Eine größere Infrastrukturmigration, eine neue kundenorientierte Anwendung, ein Cloud-Anbieterwechsel oder eine grundlegende Änderung Ihrer Architektur bringen alle neue Risiken mit sich, die Ihr vorheriger Pentest nicht bewertet hat.

Organisationen mit sich schnell entwickelnden Entwicklungszyklen – denken Sie an tägliche Deployments, Microservices-Architekturen und Continuous-Delivery-Pipelines – setzen zunehmend auf kontinuierliche oder semi-kontinuierliche Testmodelle. Anstatt eines einzelnen jährlichen Engagements führen sie kontinuierlich automatisierte Sicherheitsscans durch und legen periodische manuelle Pentests darüber. Dieser Ansatz unterstützt nicht nur SOC 2, sondern gibt Entwicklungsteams auch schnelleres Feedback zu den Sicherheitsauswirkungen ihrer Änderungen.

Über die Compliance hinaus: Pentest als Sicherheitsinvestition

Es ist leicht, Penetration Testing als eine Checkbox-Aktivität zu betrachten – etwas, das Sie tun, weil der Auditor es erwartet. Aber der wahre Wert geht weit über den Audit-Bericht hinaus.

Ein gut durchgeführter Pentest gibt Ihnen ein realistisches Bild davon, wie ein Angreifer an Ihre Systeme herangehen würde. Er deckt blinde Flecken auf, die interne Teams – die dem Code und der Infrastruktur zu nahe stehen, um sie objektiv zu sehen – zwangsläufig übersehen. Er liefert umsetzbare Informationen, die Ihre Sicherheitslage direkt verbessern und die Wahrscheinlichkeit und die Auswirkungen einer echten Verletzung verringern.

Für SaaS-Unternehmen, bei denen ein einzelner Sicherheitsvorfall das Kundenvertrauen zerstören und den Umsatz gefährden kann, ist das nicht nur eine Compliance-Übung. Es ist eine wichtige Geschäftsinvestition.

Die Organisationen, die den größten Nutzen aus Penetration Testing ziehen, sind diejenigen, die es als eine fortlaufende Praxis und nicht als ein einmaliges Ereignis behandeln. Sie bauen Beziehungen zu ihren Testanbietern auf, integrieren Ergebnisse in ihre Entwicklungs- und Betriebsabläufe und nutzen die Ergebnisse, um die kontinuierliche Verbesserung ihres Sicherheitsprogramms voranzutreiben.

Erste Schritte

Wenn Sie sich auf einen SOC 2-Audit vorbereiten und noch keinen Penetration Testing-Anbieter beauftragt haben, finden Sie hier einen praktischen Ausgangspunkt:

Legen Sie zunächst Ihre Systembeschreibung und Ihren Audit-Scope fest. Sie müssen die Grenzen kennen, bevor Sie einen Pentest dagegen abgrenzen können.

Zweitens: Identifizieren Sie einen qualifizierten, unabhängigen Testanbieter mit Erfahrung in SOC 2-Engagements. Er sollte in der Lage sein, Sie durch die Scope-Abstimmung, die Methodikauswahl und die Berichtsformatierung zu führen, die die Erwartungen des Auditors erfüllen.

Drittens: Planen Sie das Engagement innerhalb Ihres Audit-Beobachtungszeitraums ein und lassen Sie genügend Zeit für Behebung und Nachtests.

Viertens: Erstellen Sie einen Behebungs-Workflow, bevor der Test beginnt. Wissen Sie, wer für die Ergebnisse verantwortlich sein wird, wie Ihre erwarteten Reaktionszeiten für verschiedene Schweregrade sind und wie Sie den Fortschritt verfolgen werden.

Fünftens: Überprüfen Sie den Abschlussbericht mit Ihrem Auditor, bevor die Feldarbeit der Bewertung beginnt, oder stellen Sie zumindest sicher, dass er verfügbar ist, wenn er ihn benötigt.