Verlangt SOC 2 Penetrationstests und Schwachstellenscans?

Ist ein Penetrationstest für SOC 2 Pflicht?

Ein Penetrationstest ist für SOC 2 keine Pflicht. Die Trust Services Criteria nennen ihn in einem Point of Focus von CC4.1, als Beispiel für gesonderte Bewertungen, mit denen eine Organisation prüfen kann, ob ihre Kontrollen funktionieren. Ob Sie einen Test brauchen und wie oft, ergibt sich aus Ihrer Risikobewertung und aus den Kontrollen, die Sie in Ihrem Bericht beschreiben.

Herausgeber der Kriterien ist das AICPA, der Berufsverband der US-Wirtschaftsprüfer. Gültig sind derzeit die Trust Services Criteria von 2017 mit den 2022 überarbeiteten Points of Focus, ein kostenloses Dokument, das nur mit einem AICPA-Konto zugänglich ist. Die Formulierungen unten stammen deshalb von Prüfungsgesellschaften, die es wiedergeben. Linford & Co, eine Wirtschaftsprüfungsgesellschaft (CPA-Firm), die SOC-2-Audits durchführt, sagt es ohne Umschweife: „the simple answer is no“, die einfache Antwort lautet nein. CC4.1 verlangt von der Organisation laufende oder gesonderte Bewertungen, die sicherstellen, dass die Komponenten der internen Kontrolle vorhanden sind und funktionieren. Sein Point of Focus nennt Penetrationstests neben unabhängigen Zertifizierungen, etwa nach ISO, und internen Audits als Arten von Bewertungen, auf die das Management zurückgreifen kann. Der Beitrag von Linford stammt vom Juni 2021, also aus der Zeit vor der Überarbeitung von 2022.

Die Überarbeitung von 2022 hat daraus keine Regel gemacht. BARR Advisory, eine weitere Prüfungsgesellschaft für SOC 2, zitiert das AICPA zu den überarbeiteten Points of Focus: Sie „do not, in any way, alter the criteria in the 2017 TSC“, ändern die Kriterien von 2017 also in keiner Weise.

Auf dem Papier ist der Test damit freiwillig, und die Entscheidung müssen Sie begründen. Linford rät jedem Unternehmen, das seine Dienste über eine interaktive, öffentlich erreichbare Website anbietet, einen Penetrationstest ernsthaft in Betracht zu ziehen, mit Häufigkeit und Umfang auf Grundlage einer gründlichen Risikobewertung.

In einem Fall ist die Wahl bereits getroffen. Laut der Prüfungsgesellschaft TrustNet ist die Systembeschreibung Ihre eigene Aufstellung von Systemen, Diensten und Kontrollen, die Sie selbst verfassen und der Auditor prüft. Das Urteil des Auditors betrifft dann, ob diese Kontrollen gut ausgestaltet sind (Type I) und ob sie über die Zeit betrieben wurden (Type II). Steht in Ihrer Systembeschreibung oder in Ihrer Richtlinie, dass Sie jährlich einen Penetrationstest durchführen, ist er zu einer Ihrer Kontrollen geworden, und der Auditor wird den Bericht sehen wollen.

Sind Schwachstellenscans für SOC 2 Pflicht?

SOC 2 nennt Schwachstellenscans nicht als Anforderung. CC7.1 verlangt Verfahren zur Erkennung und Überwachung, die Konfigurationsänderungen mit neuen Schwachstellen aufdecken, ebenso wie Ihre Anfälligkeit für neu entdeckte Schwachstellen. Sein Point of Focus „Conducts Vulnerability Scans“ beschreibt Scans, die regelmäßig und nach jeder wesentlichen Änderung laufen, wobei die gefundenen Mängel zeitnah behoben werden.

Linford & Co gibt den Point of Focus wieder: Gescannt wird „on a periodic basis and after any significant change in the environment“, also regelmäßig und nach jeder wesentlichen Änderung der Umgebung, und die Organisation behebt zeitnah, was die Scans finden. Das Urteil ist dasselbe wie beim Penetrationstest, keine Pflicht, allerdings mit einer Warnung: „it may be tough for a user organization to accept a clean SOC 2 report“, wenn darin jeder Verweis auf Scans fehlt. Ein Kunde dürfte sich demnach schwertun, einen SOC-2-Bericht mit uneingeschränktem Prüfungsurteil zu akzeptieren, in dem Scans gar nicht vorkommen.

Die Zusammenfassung der Überarbeitung von 2022 bei BARR Advisory führt CC7.1 nicht unter den Änderungen: Für den Systembetrieb nennt sie den Umgang mit vertraulichen Informationen in CC7.3. Das Kriterium zum Change Management, CC8.1, hat dagegen Points of Focus zur „identification, testing, and implementation of software patches“ hinzubekommen, also zum Erkennen, Testen und Einspielen von Software-Patches. Das Upgrade einer verwundbaren Abhängigkeit ist ein Patch, die Behebungsseite der Scans fällt damit ebenfalls unter das Change Management.

Der Point of Focus nennt kein Werkzeug, keine Häufigkeit und keinen Umfang. Sie legen fest, was „die Umgebung“ umfasst (Ihren Code, seine Abhängigkeiten, Container, die Cloud-Konfiguration, Hosts), Sie schreiben es in Ihre Richtlinie, und der Auditor misst Sie an dem, was Sie geschrieben haben.

Was unterscheidet einen Schwachstellenscan von einem Penetrationstest?

Ein Schwachstellenscan läuft automatisiert: Ein Werkzeug gleicht Ihren Code, Ihre Abhängigkeiten oder Hosts mit bekannten Schwachstellen ab und listet auf, was es findet. Einen Penetrationstest führen Menschen durch, die mit Werkzeugen und eigenem Urteil Schwachstellen ausnutzen und zeigen, wie weit ein Angreifer käme. Für SOC 2 stützen Scans das Kriterium CC7.1, ein Penetrationstest stützt CC4.1.

Linford & Co zieht die Grenze genauso. Eine Schwachstellenanalyse „is an automated activity“ (eine automatisierte Tätigkeit), die mit einem Werkzeug läuft, während ein Penetrationstest von einer oder mehreren Personen durchgeführt wird, die Schwachstellen und Konfigurationsfehler mit automatisierten Werkzeugen und eigenen Techniken ausnutzen. Für ein Team, das Software baut, umfasst „Scan“ mehrere Arten von Werkzeugen: statische Codeanalyse (SAST), Analyse der Abhängigkeiten (SCA), Secret Scanning sowie Prüfungen von Infrastrukturdateien und Container-Images.

Wie oft muss man für SOC 2 scannen?

Für SOC 2 scannen Sie so oft, wie Ihre Richtlinie es vorsieht, und nach jeder wesentlichen Änderung. Ein festes Intervall gibt es nicht: Der Point of Focus „Conducts Vulnerability Scans“ von CC7.1 verlangt Scans in regelmäßigen Abständen und nach jeder wesentlichen Änderung der Umgebung. Ein Scan auf jedem Pull Request deckt die Änderungen ab, ein geplanter Scan den Rest.

CC7.1 hat zwei Hälften, und jede braucht ihren eigenen Auslöser. Die erste sind Konfigurationsänderungen, die Schwachstellen einführen: Die erkennen Sie, indem Sie die Änderung selbst scannen, in der CI, vor dem Merge. Die zweite ist die Anfälligkeit für neu entdeckte Schwachstellen: Die erkennen Sie, indem Sie auch Code scannen, den Sie nicht mehr angefasst haben, und zwar nach Zeitplan, denn neue Sicherheitsmeldungen (Advisories) treffen laufend alte Abhängigkeiten. In unserem Scan vom 3. November stammten vier der neun kritischen Befunde in den Abhängigkeiten aus Advisories, die zwischen Juli und September 2026 veröffentlicht wurden. Ein Scan im Juni, auf genau demselben Code, hätte sie nicht melden können.

Schreiben Sie beide Auslöser in Ihre Richtlinie, dazu eine Frist pro Schweregrad, bis zu der behoben sein muss, was die Scans finden. Der Auditor kann jeden beliebigen Befund aus dem Zeitraum herausgreifen und mit Ihren Fristen vergleichen, wählen Sie daher Fristen, die Sie auch einhalten können.

Welche Nachweise verlangt ein SOC-2-Auditor?

Der Auditor verlangt Aufzeichnungen: dass die Scans zu den Zeitpunkten liefen, die Ihre Richtlinie vorsah, was sie abdeckten, was sie fanden und was mit jedem Befund geschah, ob er vor Ablauf der Frist behoben oder als Ausnahme mit Begründung und genehmigender Person akzeptiert wurde. In einem Type-II-Bericht deckt das Urteil einen ganzen Zeitraum ab, die Aufzeichnungen müssen es auch.

Ein SOC-2-Bericht ist eine Prüfung, die ein zugelassener, unabhängiger Wirtschaftsprüfer (CPA) nach den Attestation Standards des AICPA durchführt, so formuliert es die Pressemitteilung des AICPA selbst. Bei einem Type II betrifft das Urteil des Prüfers, wie Ihre Kontrollen über einen Zeitraum funktioniert haben. Für das Schwachstellenmanagement läuft das auf eine kurze Liste von Fragen hinaus:

Liefern Open-Source-Scanner Nachweise für SOC 2?

Open-Source-Scanner liefern die Erkennungshälfte des SOC-2-Nachweises. Am 3. November 2026 haben wir Trivy, Gitleaks und Opengrep auf OWASP Juice Shop laufen lassen und in 56 Sekunden 383 Rohbefunde in vier JSON-Dateien erhalten. Keine der Dateien nennt den gescannten Commit, einen Verantwortlichen, eine Frist oder einen Status, und genau diese Aufzeichnung zieht der Auditor als Stichprobe.

Wir haben OWASP Juice Shop in der Version 20.3.0 verwendet, veröffentlicht am 11. Oktober 2026. Das README nennt die Anwendung „probably the most modern and sophisticated insecure web application“, wahrscheinlich die modernste und ausgefeilteste unsichere Webanwendung. Die Zahlen unten sagen deshalb nichts über eine normale Codebasis aus: Sie zeigen die Form dessen, was die Werkzeuge Ihnen in die Hand geben. Juice Shop wird ohne Lockfile ausgeliefert, deshalb haben wir für den Scan der Abhängigkeiten am selben Tag eines aus einer Kopie seiner package.json aufgelöst, mit abgeschalteten Install-Skripten von npm. Danach haben wir vier Befehle ausgeführt:

trivy fs --scanners vuln --format json --output trivy-sca.json sca/
trivy fs --scanners misconfig,secret --format json --output trivy-repo.json juice-shop/
gitleaks dir juice-shop --report-format json --report-path gitleaks.json
opengrep scan --config opengrep-rules/javascript --config opengrep-rules/typescript \
  --config opengrep-rules/terraform --json --output opengrep.json juice-shop/

Ergebnisse von vier Open-Source-Scans von OWASP Juice Shop 20.3.0, durchgeführt am 3. November 2026. Gescannt haben wir das Tag v20.3.0 auf Commit f189f52, mit den Community-Regeln von Opengrep auf Commit f1d2b56, den Standardeinstellungen von Trivy und ohne jedes Tuning. Die vier Läufe dauerten zusammen 56 Sekunden, das Update der Datenbank von Trivy eingeschlossen:

Jedes Werkzeug hat gefunden, wofür es gebaut wurde. Zwischen diesen Dateien und einem SOC-2-Nachweis stehen trotzdem vier Dinge:

1. Duplikate. Die fünf Secrets, die Trivy gefunden hat, sind unter den 69 von Gitleaks, in derselben Datei und derselben Zeile. Von den 54 Terraform-Befunden von Opengrep liegen 17 auf derselben Zeile wie ein Befund von Trivy und 34 höchstens drei Zeilen davon entfernt. Ohne Zusammenführung werden aus einem Problem zwei Tickets mit zwei Fristen.
2. Drei Skalen für den Schweregrad. Trivy stuft von critical bis low ein, Opengrep von error bis info, Gitleaks überhaupt nicht. Eine Richtlinie, nach der „kritische Befunde innerhalb von N Tagen behoben“ sein müssen, braucht eine einzige Skala, und jemand muss die beiden anderen darauf abbilden.
3. Abdeckung. Opengrep hat 1.306 Dateien gescannt und 32 Einträge zu Parse-Fehlern und nur teilweise geparsten Dateien protokolliert, in einem eigenen Abschnitt für Fehler, den Sie nur sehen, wenn Sie die Datei tatsächlich lesen. Ein Auditor, der fragt, ob der Scan den Code abgedeckt hat, braucht diese Zeile.
4. Die Aufzeichnung selbst. Die Dateien von Trivy tragen einen Zeitstempel ihrer Erstellung und den gescannten Pfad. Die von Opengrep tragen gar keinen Zeitstempel. Im Verzeichnismodus lässt Gitleaks seine Felder für Commit und Datum leer. Keine Datei hat einen Verantwortlichen, eine Frist oder einen Status.

Die Open-Source-Scanner selbst schlagen sich gut. Unsere Tests von Open-Source-SAST-Tools, die wir auf GitHub geprüft haben, und von sechs Open-Source-Secret-Scannern auf einem präparierten Repository zeigen, dass Sie Code und Secrets abdecken können, ohne für einen Scanner zu bezahlen. Die Menge der Befunde ist die andere Hälfte der Arbeit, und unser Beitrag darüber, was SAST-Befunde zu Rauschen macht, erklärt, warum 149 Codebefunde eine Warteschlange für die Triage sind und keine 149 Schwachstellen.

Um aus den Dateien Nachweise zu machen, brauchen Sie eine Warteschlange pro Repository, in der die Befunde aller Werkzeuge zusammengeführt werden, jeder Befund einen Verantwortlichen und eine Frist gemäß Ihrer Richtlinie bekommt und seine Historie erhalten bleibt: eröffnet, behoben, als Ausnahme akzeptiert. Teams bauen sie mit einem Open-Source-Werkzeug für Schwachstellenmanagement wie DefectDojo, mit Tickets oder mit einer Plattform. CybeDefend Open Source übernimmt diesen Teil: Es lässt die Scanner laufen, die Sie auswählen, jedes Werkzeug, das SARIF schreibt, und führt ihre Befunde in einer deduplizierten Warteschlange zusammen, kostenlos und auf Ihren Servern. Es erscheint bald, und die Warteliste ist offen.

Was ändert sich, wenn KI-Agenten den Code schreiben?

Die SOC-2-Kriterien bleiben gleich, wenn KI-Agenten den Code schreiben, doch wesentliche Änderungen werden häufiger, deshalb muss der Scan nach CC7.1 bei jeder Änderung laufen und nicht nur nach Zeitplan. Die vom AICPA vorgeschlagenen Kriterien für 2027 ergänzen Points of Focus zu KI, verbindlich würden sie erst für Prüfungsaufträge, die am oder nach dem 31. Dezember 2027 beginnen.

Der Anteil des Codes, den Agenten schreiben, kann groß sein. Am 3. November 2026 trugen 482 der 509 Commits, die in den vorangegangenen 90 Tagen in den Main-Branch unseres eigenen Website-Repositorys gemergt wurden, einen Co-Author-Trailer von Claude Code. Bei diesem Anteil verschieben sich für SOC 2 drei Dinge:

• Der Scan übernimmt das Lesen Zeile für Zeile. Ein Merge-Gate, das jeden Pull Request scannt, ist die Prüfung, die bei jeder Änderung läuft, und das verlangen CC7.1 und CC8.1. Unser Artikel über die Sicherheitsprüfungen für den Pull Request eines KI-Agenten geht dieses Gate Schritt für Schritt durch.
• Abhängigkeiten kommen mit den Features. Ein Agent, der ein Paket hinzufügt, fügt einen Eintrag hinzu, den der geplante Scan überwachen muss, und jedes Upgrade, das er vornimmt, ist ein Patch im Sinne von CC8.1.
• Grüne Tests beweisen weniger. Ein Agent schreibt ein Feature und die Tests dazu oft in derselben Sitzung. Seine Tests prüfen, was er bauen wollte: Eine Regel, die ihm im Code entgangen ist, kann auch in den Tests fehlen, und die CI bleibt grün. Ein Scanner, der aus der CI heraus läuft, ist eine Prüfung, die nicht der Agent geschrieben hat.

Die Kriterien selbst sind in Bewegung. Am 28. Oktober 2026 hat das AICPA einen Entwurf (Exposure Draft) neuer SOC-2-Trust-Services-Criteria zur Kommentierung veröffentlicht. Die Pressemitteilung nennt neue Points of Focus zu „AI governance, model monitoring, prompt manipulation, data poisoning“, also zu KI-Governance, Modellüberwachung, Prompt-Manipulation und Data Poisoning, außerdem zur Transparenz KI-generierter Ausgaben, zum Management von Trainingsdaten und zu automatisierten Entscheidungen. Kommentare sind bis zum 15. Januar 2027 möglich. Werden die neuen Kriterien angenommen, gelten sie für Prüfungsaufträge, die am oder nach dem 31. Dezember 2027 beginnen, eine frühere Anwendung ist erlaubt. Ob diese Points of Focus auch Coding-Agenten erfassen, sagt die Mitteilung nicht, und der Entwurf selbst ist nur mit einem AICPA-Konto zugänglich, deshalb haben wir ihn nicht gelesen. Bis die neuen Kriterien endgültig und in Kraft sind, gilt für Ihr Audit die Fassung von 2017 mit den Points of Focus von 2022.

Was sollte vor dem SOC-2-Audit bereitliegen?

Vor dem SOC-2-Audit sollten bereitliegen: eine schriftliche Richtlinie zum Schwachstellenmanagement, Scans nach Zeitplan und bei jeder Änderung, eine Aufzeichnung pro Befund mit Verantwortlichem, Frist und Ergebnis, genehmigte Ausnahmen und der Bericht eines Penetrationstests, falls Ihre Risikobewertung einen vorsieht. All das muss den gesamten Auditzeitraum abdecken.

1. Die Richtlinie sagt, was, wann und wie schnell. Der Umfang der Scans, der Zeitplan, die Auslöser, eine Frist pro Schweregrad und wer eine Ausnahme genehmigen darf.
2. Jede Änderung wird gescannt. Code, Abhängigkeiten, Secrets und Infrastrukturdateien bei jedem Pull Request, egal ob ein Mensch oder ein Agent ihn geöffnet hat, hinter einem Gate, das einen kritischen Befund ablehnt.
3. Der Zeitplan fängt neue Advisories ab. Ein nächtlicher oder wöchentlicher Scan des Main-Branch und der Images, die Sie betreiben, für die Schwachstellen, die erst nach dem Schreiben des Codes veröffentlicht wurden.
4. Ein Befund, eine Aufzeichnung. Über alle Werkzeuge zusammengeführt, auf einer einzigen Skala für den Schweregrad, mit Verantwortlichem, Frist, Status und Historie.
5. Ausnahmen sind schriftlich festgehalten. Der Geltungsbereich, die Begründung, die genehmigende Person und das Ablaufdatum.
6. Der Penetrationstest ist geplant. Ein Umfang, abgeleitet aus Ihrer Risikobewertung, der Bericht aufbewahrt, die schwerwiegenden Befunde behoben und erneut geprüft.
7. Der Bericht deckt den Zeitraum ab. Ein Dokument, erzeugt aus den Aufzeichnungen, und keine Tabelle, die in der Woche vor dem Besuch des Auditors zusammengestellt wird.

Scan bei jeder ÄnderungEine Aufzeichnung pro BefundVerantwortlicher und FristBehoben oder Ausnahme genehmigtIm Bericht des Zeitraums

Die Punkte 2, 5 und 7 übernimmt die AppSec-Plattform von CybeDefend. Sie scannt in jedem Repository den Code auf Schwachstellen (SAST), dazu Abhängigkeiten (SCA), Secrets, Infrastructure as Code, Container und CI/CD-Pipelines. Eine als Code geschriebene Sicherheitsrichtlinie blockiert den Merge bei einem kritischen Befund und lässt geringeres Risiko mit einer Warnung durch. Eine Ausnahme ist auf einen Pfad begrenzt, datiert, begründet und namentlich genehmigt, und jede hinterlässt eine Zeile im Audit-Log. Sicherheitsberichte ordnen die Befunde den OWASP Top 10 und den CWE Top 25 zu, nach Organisation, Team oder Projekt, exportiert als PDF für den Auditor oder als JSON für ein GRC-Tool. Dieselbe Übung machen wir gerade selbst durch: Das SOC-2-Type-II-Audit von CybeDefend läuft. Wenn Sie Ihres mit einem Team vorbereiten, das mit Agenten entwickelt, gehen wir es gern gemeinsam mit Ihnen durch.

Häufige Fragen

Braucht man für SOC 2 Type II einen Pentest?

Nein. Berichte nach Type I und Type II beruhen auf denselben Kriterien, und keines davon verlangt einen Penetrationstest. Ein Type II prüft, ob Ihre Kontrollen über einen Zeitraum funktioniert haben. Sieht Ihre Richtlinie einen jährlichen Penetrationstest vor, prüft der Auditor, ob er innerhalb des Zeitraums stattgefunden hat und ob seine Befunde bearbeitet wurden.

Wie oft muss ein Pentest für SOC 2 stattfinden?

Die Kriterien legen kein Intervall fest. Das tun Ihre Risikobewertung und Ihre Richtlinie, und der Auditor prüft, ob Sie sich an das gehalten haben, was Sie geschrieben haben. Eine große Änderung daran, was Ihr System nach außen zeigt, etwa eine neue öffentliche API oder ein neues Produkt, ist ein guter Grund, vor dem nächsten geplanten Termin erneut zu testen.

Reicht ein Schwachstellenscan für SOC 2 aus?

Für CC7.1 erwarten Auditoren ein Scanprogramm, mit Aufzeichnungen darüber, wie jeder Befund bearbeitet wurde. Ein Scan ersetzt aber nicht die Bewertung Ihrer Kontrollen nach CC4.1, und die kann ein Penetrationstest, ein internes Audit oder eine unabhängige Zertifizierung sein.

Muss man für SOC 2 SAST oder Code-Scans einsetzen?

Kein Kriterium nennt SAST. Der Point of Focus von CC7.1 umfasst Schwachstellen und Fehlkonfigurationen in Ihrer Umgebung, und CC8.1 verlangt, dass Änderungen an Software getestet und freigegeben werden, bevor sie umgesetzt werden. Wenn Sie Software entwickeln, ist ein Scan des Codes und seiner Abhängigkeiten bei jeder Änderung der einfachste Weg, beides zu zeigen.

Taugen Open-Source-Scanner für ein SOC-2-Audit?

Ja. Die Kriterien nennen kein Werkzeug, und der Auditor prüft, ob die Scans so gelaufen sind, wie Ihre Richtlinie es vorgibt, und ob die Befunde bearbeitet wurden. Open-Source-Scanner funktionieren, wenn Sie die Aufzeichnung drumherum führen: wann jeder Scan lief, den gescannten Commit, über alle Werkzeuge zusammengeführte Befunde, Verantwortliche, Fristen und Ergebnisse.

Was bedeutet CC7.1 bei SOC 2?

CC7.1 gehört zu den Common Criteria, den allgemeinen Kriterien von SOC 2, und betrifft Erkennung und Überwachung. Es verlangt von einer Organisation Verfahren, die Konfigurationsänderungen mit neuen Schwachstellen erkennen, ebenso wie ihre Anfälligkeit für neu entdeckte Schwachstellen. Einer seiner Points of Focus ist die Durchführung von Schwachstellenscans, regelmäßig und nach wesentlichen Änderungen.

Was regelt CC4.1 bei SOC 2?

CC4.1 ist das allgemeine Kriterium zu den Überwachungsaktivitäten. Es verlangt von einer Organisation laufende oder gesonderte Bewertungen, die bestätigen, dass die Komponenten der internen Kontrolle vorhanden sind und funktionieren. Sein Point of Focus nennt Penetrationstests, unabhängige Zertifizierungen wie nach ISO und interne Audits als Beispiele für solche Bewertungen.

Was ändern die geplanten SOC-2-Kriterien für 2027?

Das AICPA hat am 28. Oktober 2026 einen Entwurf veröffentlicht, der Teile der Kriterien umstrukturiert und Points of Focus zu KI ergänzt, darunter KI-Governance, Prompt-Manipulation, Data Poisoning und die Transparenz KI-generierter Ausgaben. Die Kommentierungsfrist endet am 15. Januar 2027. Werden die Kriterien angenommen, sind sie für Prüfungsaufträge verbindlich, die am oder nach dem 31. Dezember 2027 beginnen, eine frühere Anwendung ist erlaubt.