KI-Penetrationstests haben Wellen geschlagen und rivalisieren die Leistungsfähigkeit menschlicher Hacker auf unerwartete Weise. Häufig suchen Unternehmen jedoch nach Penetrationstests, um ihre Compliance-Zertifizierungen zu erreichen und zu unterstützen. Und der Druck, dies häufiger zu tun, ist real. Laut dem 2026 State of AI in Pentesting-Bericht von Aikido Security, der 400 CISOs und leitende Ingenieure befragte, sind 79 % besorgt über fehlende Schwachstellen, die zwischen geplanten Tests eingeführt werden.
In der Vergangenheit haben Auditoren Ergebnisse von automatisierten Tools abgelehnt. Dies lag jedoch nicht daran, dass ein Mensch alle Tests durchführen musste, sondern daran, dass diese alten Tools keine annähernd korrekten Penetrationstests durchführten. Ein KI-Penetrationstest, der 250 orchestrierte Agents gegen Ihre Anwendung ausführt, entspricht weitgehend der Art und Weise, wie menschliche Pentester ihre Bewertungen durchführen. Das bedeutet, die Anwendung zu erkunden, zu verstehen, wie Funktionen funktionieren, Wege zu finden, sie zu kompromittieren, und zu validieren, dass das Problem tatsächlich ausnutzbar ist, bevor es in den Bericht aufgenommen wird.
Echte KI-Penetrationstests werden heute regelmäßig von Auditoren akzeptiert. In diesem Beitrag werden wir Missverständnisse über KI-Penetrationstests und deren Bezug zur Compliance erörtern und erläutern, wie und wann Sie KI-Penetrationstests einsetzen können, um Ihre Compliance-Anforderungen zu erfüllen.
{{cta}}
Was benötigen Sie wirklich für Compliance-Penetrationstests?
Wenn ein Auditor einen Penetrationstest anfordert, verlangt er eine Dokumentation, dass Ihre Anwendung anhand eines definierten Satzes von Angriffsvektoren und Testmethoden getestet wurde, dass Ergebnisse validiert und aufgezeichnet wurden und dass Sie einen Maßnahmenplan für kritische Punkte haben. Ob ein Mensch zwei Wochen lang vor einem Terminal saß oder KI-Agents einen Tag damit verbracht haben, ist dabei nicht die entscheidende Frage. Es war auch so, dass sich die Infrastruktur in der Vergangenheit mit vierteljährlichen Releases viel langsamer änderte, sodass der Gedanke an wöchentliche Penetrationstests eher absurd war. Das ist heute definitiv nicht mehr der Fall.
Die gängigsten Frameworks, die Penetrationstests vorschreiben oder empfehlen, sind SOC 2, ISO 27001, HIPAA und PCI DSS. Bei den meisten davon ist nicht explizit vorgeschrieben, dass ein Mensch den Test durchgeführt haben muss. Was sie vorschreiben, sind Abdeckung, Methodik und Dokumentation. PCI DSS ist weniger eindeutig – seine Richtlinien definieren Penetrationstests als „im Wesentlichen eine manuelle Aufgabe“ und besagen, dass automatisierte Tools allein die Anforderung nicht erfüllen (was das für KI-Penetrationstests bedeutet, werden wir später betrachten).
Betrachten wir SOC 2. Das Framework schreibt Penetrationstests überhaupt nicht vor. Was es jedoch verlangt, ist der Nachweis, dass Ihre Kontrollen wirksam sind, insbesondere in Bezug auf logischen Zugriff (CC6.1), Änderungsmanagement (CC8.1) und Risikominderung (CC7.1 bis CC7.4). Auditoren haben sich auf Penetrationstests als glaubwürdigste Methode geeinigt, diese Kontrollen nachzuweisen, da sie zeigen, dass jemand tatsächlich versucht hat, sie zu umgehen. Ein Penetrationstestbericht, der die Ergebnisse diesen Kriterien zuordnet, dokumentiert, was getestet wurde, und die Behebung kritischer Punkte aufzeigt, erfüllt die Anforderung. Es stellt sich heraus, dass das Framework nichts darüber aussagt, wer oder was den Test durchgeführt hat.
ISO 27001 folgt einem ähnlichen Muster und empfiehlt Penetrationstests als Teil der kontinuierlichen Risikobewertung.
HIPAA hat Penetrationstests historisch eher als Best Practice denn als feste Anforderung behandelt, aber das ändert sich. Im Dezember 2024 schlug das HHS Aktualisierungen der HIPAA Security Rule vor, die jährliche Penetrationstests für alle betroffenen Einrichtungen und Geschäftspartner obligatorisch machen würden, wobei die Tests von qualifiziertem Personal mit entsprechendem Cybersecurity-Wissen durchgeführt werden müssen. Diese Regelung wird voraussichtlich Mitte 2026 finalisiert. Wenn Sie im Gesundheitswesen tätig sind, erkundigen Sie sich direkt bei Ihrem Compliance-Team nach dem aktuellen Stand.
Alle Frameworks erfordern einen strukturierten Bericht mit einer Management Summary, einem Methodik-Abschnitt, validierten Ergebnissen mit Nachweisen und Reproduktionsschritten, Schweregradbewertungen und Empfehlungen zur Behebung. Der OWASP Web Application Security Testing Guide ist der Maßstab, dem die meisten Tester für die Abdeckung folgen (und es ist eine lange Liste). Selbst ein menschliches Team mit einem Budget von einer Woche kann nicht realistisch alles in der Tiefe bearbeiten. Sie müssen die wichtigsten Dinge triagieren und priorisieren. Häufigkeit und Breite sind Einschränkungen, die unseren Testumfang nicht mehr begrenzen.
Die Annahme, dass Compliance-Penetrationstests menschliche Penetrationstests bedeuten, ist in den meisten Frameworks nicht festgeschrieben. Dies war standardmäßig der Fall, da bis zu LLMs keine Technologie annähernd in der Lage war, diese tatsächlich durchzuführen. Für Teams in stark regulierten Sektoren mit spezifischen Compliance-Anforderungen lohnt es sich, dieses Gespräch direkt mit Ihrem Auditor zu führen. Für die meisten wird der Bericht jedoch keine Bedenken aufwerfen. KI-Penetrationstests decken die Anforderungen ab.
Scrollen Sie zum Ende des Artikels, um mehr darüber zu erfahren, wie AI-Pentesting im Detail mit verschiedenen Frameworks funktioniert.
Worauf Auditoren achten
Kurz gesagt, Auditoren oder Standards suchen in einem Penetrationstest tatsächlich nach Folgendem:
- Eine dokumentierte, wiederholbare Methodik, kein ad-hoc Herumprobieren
- Unabhängigkeit und dass der Tester nicht dasselbe Team ist, das das System erstellt oder betreibt
- Echtes Testen der Effektivität, das über automatisiertes Schwachstellen-Scanning hinausgeht
- Nachweise, wie Befunde, Schweregrad und Beweise
- Behebung und erneutes Testen von Befunden
Wenn Ihr Pentest diese Kriterien erfüllt, ob AI oder Mensch, besteht eine gute Chance, dass Ihr Auditor ihn akzeptiert.
Wo KI-Penetrationstests bereits Compliance-Vorteile bieten
Audit-Trails
Der Audit-Trail eines KI-Penetrationstests ist umfangreich und detailliert, oft besser als viele menschliche Penetrationstestberichte. Jede gesendete Anfrage, jede versuchte Payload, jede von jedem Agent ausgeführte Aktion wird protokolliert. Sie können genau sehen, was getestet wurde, wie der Test durchgeführt wurde und was gefunden wurde. Die meisten menschlichen Penetrationstestberichte liefern Ihnen Ergebnisse und einen Methodik-Abschnitt. Sie liefern Ihnen keine vollständige Nachverfolgung jedes einzelnen Schritts. Wenn Ihr Auditor fragt: „Woher wissen wir, dass X getestet wurde?“, kann der aus einem KI-Penetrationstest generierte Bericht tatsächlich das Protokoll für genau diesen Punkt anzeigen.
Testabdeckung
KI-Penetrationstests decken einen erheblichen Bereich ab. Für diejenigen, die fragen: „Woher wissen wir, dass alles versucht wurde?“, gilt diese Sorge gleichermaßen für menschliche Pentester. Ein manueller Penetrationstestbericht, der null Ergebnisse und keinen Audit-Trail der getesteten Punkte aufweist, wird vollständig auf Vertrauen basiert. Es besteht eine Art Hörigkeit gegenüber dem Ritual des jährlichen Penetrationstests. Man kann ohnehin nicht beweisen, dass ein Mensch alles versucht hat. Mit einem KI-Penetrationstest können Sie eine detaillierte Testabdeckung anhand der Protokolle aufzeigen.
Agents können das gesamte OWASP Top 10 in Stunden durcharbeiten. Sie testen Autorisierungsprüfungen über jeden Endpunkt hinweg, nicht nur eine repräsentative Stichprobe. Sie versuchen jeden Angriffsvektor bei jeder Funktion, nicht nur die, die ein menschlicher Tester vor Ende des Engagements erreichen konnte.
KIs verbessern sich exponentiell in ihrer Fähigkeit, Code zu analysieren und zu verstehen. Sie finden neue, kontextabhängige Schwachstellen, die Menschen jahrelang übersehen haben. Skeptiker gehen davon aus, dass KIs keine Business-Logik-Schwachstellen bewältigen können. Dies ist nicht länger der Fall. In der Praxis lesen Agents den Code, verstehen das beabsichtigte Verhalten und finden kreative Wege, es zu kompromittieren. Der Satz „Wenn man nur einen Hammer hat, sieht jedes Problem wie ein Nagel aus“ trifft hier zu. Selbst wenn ein menschlicher Tester wirklich gut darin ist, XSRF-Schwachstellen zu finden und eine sechsstellige Bug Bounty zu verdienen, ist die Wahrheit, dass KI-Tests einen Sack voller Hämmer für die Aufgabe mitbringen.
Im direkten Vergleich von Aikido Security über vier nicht-triviale Webanwendungen hinweg fanden KI-Agents doppelt so viele fehlerhafte Zugriffskontrolle-Schwachstellen wie erfahrene menschliche Tester. Sie entdeckten auch eine E-Signaturfälschung in einer Zahlungsanwendung, die die manuellen Tester überhaupt nicht bemerkt hatten. Die KIs hatten zugegebenermaßen einen großen Vorteil, da sie Zugriff auf den Quellcode hatten. Eine KI erfasst einen vollständigen Codebestand fast sofort, während menschliche Tester aus logistischen Gründen und aufgrund von NDAs normalerweise ohne diesen arbeiten. Aber White-Box-, Grey-Box- oder Black-Box-Tests werden durch die Parallelität, die agentenbasiertes Penetrationstesting mit sich bringt, definitiv aufgewertet.
Der Benchmark ergab zudem, dass menschliche Tester bei der Untersuchung unzureichender Konfigurationshärtung und der Identifizierung von Compliance-Hygiene-Checks überlegen waren. Seitdem haben sich KI-Penetrationstests kontinuierlich verbessert. Aikidos KI-Penetrationstests beispielsweise erkennen regelmäßig komplexe IDOR-Schwachstellen, die die Authentifizierung als echte Benutzer und das Durchlaufen langer End-to-End-Workflows erfordern.
Integrationen von Drittanbietern, insbesondere komplexe OAuth-Flows und SSO-Implementierungen, sind für Agenten schwieriger konsistent zu navigieren. Aikidos KI-Penetrationstests haben den erforderlichen Aufwand investiert, um diese Probleme zu lösen, aber es ist nicht selbstverständlich, dass alle KI-Penetrationstestprodukte dies leisten können.
Berichte
Das Berichtsformat entspricht direkt den Anforderungen der Compliance-Teams. SOC 2 und ISO 27001 erhalten ein vollständiges PDF mit Nachweisen, detaillierten Empfehlungen zur Behebung und Reproduktionsschritten für erneute Tests nach der Anwendung von Behebungsmaßnahmen. HIPAA-Anforderungen sind abgedeckt.
Die Bearbeitungszeiten für KI-Penetrationstests liegen im Bereich von Stunden (definitiv weniger als ein Tag), was sehr hilfreich ist, wenn Sie einen Zertifizierungszeitplan einhalten müssen oder auf eine Prüfungsanfrage reagieren, die bisher nicht getestete, im Geltungsbereich liegende Assets umfasst.
Was können KI-Penetrationstests nicht für die Compliance leisten?
Während KI-Penetrationstests zunehmend akzeptiert werden, ist die Technologie noch recht neu, und einige Branchen sowie deren Regulierungsbehörden finden noch ihre Position zu diesem Thema.
PCI DSS ist präskriptiver als SOC 2 oder ISO 27001 und schreibt explizit Penetrationstests mindestens jährlich vor, mit spezifischer Abdeckung von Karteninhaberdaten-Umgebungen. Seine offizielle Anleitung für Penetrationstests, zuletzt aktualisiert im Jahr 2017, beschreibt Penetrationstests als „im Wesentlichen eine manuelle Aufgabe“ und besagt, dass die alleinige Ausführung automatisierter Tools die Anforderung nicht erfüllt. Der Geist der Anforderung war schon immer aktive Ausnutzung, validierte Nachweise und die Anwendung von Urteilsvermögen auf die Ergebnisse. Menschliche Penetrationstester können KI-Penetrationstests als Werkzeug nutzen, um einen Großteil der aufwendigen Arbeit auf der Anwendungsseite zu erledigen. Allerdings erfordert PCI DSS auch Netzwerk- und Segmentierungstests neben Anwendungsschicht-Tests, die KI-Penetrationstests ohnehin nicht abdecken.
Für einige Aufsichtsbehörden im Finanzdienstleistungssektor oder Anforderungen des öffentlichen Sektors müssen Unternehmen direkt mit ihrem Auditor klären, um deren Offenheit zu beurteilen, kontinuierliche Überwachung und Tests nicht nur als gleichwertig mit punktuellen Tests, sondern als deutlich überlegenen Nachweis von Sicherheitskontrollen und Programmrobustheit anzusehen.
FedRAMP, das für Cloud-Dienstleister gilt, die an US-Bundesbehörden verkaufen, verlangt, dass Bewertungen von akkreditierten Drittanbieter-Bewertungsorganisationen (3PAOs) durchgeführt werden. Jüngste RFCs für FedRAMP 20x deuten jedoch darauf hin, dass das Programm daran arbeitet, seinen Ansatz zur Überprüfung von SaaS-Lösungen zu modernisieren, um kritische Infrastrukturen sowie Regierungsanwendungen und -dienste zu schützen.
Physische Sicherheitstests und Social Engineering sind vollständig ausgeschlossen (Phishing-Tests sind für FedRAMP erforderlich). Wir sind noch weit davon entfernt, dass KI-Penetrationstester herumgehen, Türklinken drehen, um zu sehen, ob sie verschlossen sind, und Phishing-E-Mails versenden (was wahrscheinlich auch besser ist).
Es ist wahrscheinlicher, dass akkreditierte Firmen KI-Penetrationstests an bestimmten Stellen als Tools einsetzen, anstatt sie vollständig als Ersatz für ihre Aufklärungs- und Penetrationstests zu verwenden. Heute können KI-Penetrationstests in einem Partnermodell eingesetzt werden, bei dem eine akkreditierte Firma die Arbeit und die Testartefakte überprüft und mitunterzeichnet. Dieser Ansatz ist es wert, erkundet zu werden, wenn Sie in einem dieser Märkte tätig sind.
Lehnen Auditoren KI-Penetrationstest-Tools nicht als Scanner ab?
Der häufigste Einwand betrifft nicht einmal KI-Penetrationstests. Das Problem sind automatisierte Scanner, die sich als KI-Penetrationstests ausgeben.
Seit Jahren versuchen weniger gewissenhafte Organisationen, die Ausgabe einfacher Schwachstellenscanner als Penetrationstestbericht auszugeben. Tools wie Nessus oder OpenVAS erstellen lange Listen von gemeldeten Problemen mit Schweregraden, die auf dem Papier glaubwürdig aussehen, aber nichts wurde validiert, ausgenutzt oder kontextualisiert. Sie verwechseln das Konzept einer möglichen Schwachstelle mit einem nachweisbaren Angriffspfad. Auditoren haben genug davon gesehen, um allem gegenüber skeptisch zu sein, was nach einem als Penetrationstest getarnten Scan riecht. Daher müssen Sie sicherstellen, dass Ihr KI-Penetrationstest wirklich ein KI-Penetrationstest ist und nicht ein Scanner oder DAST, der sich mit KI-„Lippenstift“ schmückt.
Ein echter KI-Penetrationstest nutzt Schwachstellen tatsächlich aus und bestätigt sie an einem Live-Ziel, bevor sie in einem Bericht aufgeführt werden. Den Unterschied erkennen Sie an der Sprache und den Details des Berichts. Validierte Ergebnisse enthalten Proof-of-Concept-Nachweise und Reproduktionsschritte, die zeigen, wie der Exploit tatsächlich ausgeführt wurde, während unvalidierte Scanner-Ergebnisse lediglich ein potenzielles Problem mit einer generischen Schweregradbewertung beschreiben und keinen Beweis dafür enthalten, dass etwas tatsächlich versucht wurde. Wenn ein Bericht Hunderte von Ergebnissen enthält und keines davon Exploitation-Nachweise zeigt, haben Sie es wahrscheinlich mit einem Scanner zu tun, unabhängig davon, was auf der Verpackung steht.
Dies knüpft an unsere Ausführungen zu PCI DSS an. Die Formulierung von 2017, die Penetrationstests als „im Wesentlichen eine manuelle Aufgabe“ beschreibt, wurde speziell verfasst, um das Problem von Organisationen anzugehen, die Scanner-Ausgaben als Penetrationstestbericht einreichen. Die Richtlinie zog eine Grenze gegen diese Praxis und antizipierte keine Welt, in der KI-Agenten aktiv Schwachstellen ausnutzen und Ergebnisse validieren, wie es menschliche Tester tun. Während KI-Penetrationstests nicht alle PCI DSS-Anforderungen für Penetrationstests abdecken (wie Netzwerk- und Segmentierungstests), können KI-Penetrationstest-Tools Organisationen dabei helfen, Anwendungstests effizienter durchzuführen, und wir könnten sehen, dass diese Vorschriften ihre Formulierung in Zukunft aktualisieren, um die Nuance zu berücksichtigen. Die Branche neigt dazu, sich schneller zu entwickeln als Compliance-Frameworks.
Kontinuierliche Compliance
Über die Compliance-Checkliste hinaus ist Point-in-Time- oder Snapshot-Penetrationstesting ein fehlerhaftes Modell für alles, was Code regelmäßiger als einmal pro Jahr ausliefert.
Ein jährlicher Penetrationstest zeigt Ihnen, wie Ihre Anwendung an dem Tag oder in der Woche aussah, in der der Test durchgeführt wurde. Doch Ihr Entwicklungsteam hat wahrscheinlich schon am nächsten Tag neue Änderungen eingespielt. Drei Monate später ist der Compliance-Bericht auf dem Papier immer noch gültig, aber Ihre Angriffsfläche hat sich erheblich verändert. Die 85 % der CISOs und Engineering-Leiter in unserer Umfrage, die angeben, dass Ergebnisse zumindest manchmal veraltet sind, liegen mit ihrer Einschätzung nicht falsch. Die Verzögerung ist spürbar und birgt hohe Risiken.
Kontinuierliches Penetrationstesten verwandelt Ihre punktuelle Aussage in eine lebendige Aufzeichnung. Anstatt einem Auditor zu sagen „wir haben im März einen Pentest gegen Produktions-Assets durchgeführt“, können Sie ihm eine Sicherheitstest-Historie zeigen, die direkt neben Ihrer Deployment-Historie liegt. Und das nicht nur in der Produktion, sondern auch in den unteren Umgebungen. Jede Änderung, die Ihre Angriffsfläche beeinflusst, wurde getestet, sodass Probleme erkannt und behoben wurden, bevor sie die Produktion erreichten.
Banken und stark regulierte Branchen sind derzeit gezwungen, Release-Zyklen zu verlangsamen, insbesondere um Features und Funktionalitäten vor der Auslieferung einem Penetrationstest zu unterziehen. Kontinuierliches KI-Penetrationstesten ändert dies, da die Tests im Einklang mit Ihrer Deployment-Kadenz ablaufen und nur das prüfen, was sich geändert hat, sodass Releases nicht auf Sicherheitsüberprüfungen warten müssen.
Sehen Sie, wie ein audit-tauglicher KI-Penetrationstest aussieht
Auditoren prüfen, ob ein Test stattgefunden hat, ob er einer definierten Testmethodik folgte, ob Testergebnisse mit Nachweisen dokumentiert wurden und ob kritische Probleme behoben wurden. Ein KI-Penetrationstestbericht erfüllt all diese Anforderungen. Die Frameworks, die definieren, was als Testbericht und Compliance-Artefakt zählt, legen nicht fest, wer oder was den Test durchgeführt hat.
Wenn Sie auf SOC 2 Compliance, ISO 27001, HITRUST oder eine ähnliche Zertifizierung hinarbeiten und sehen möchten, wie der Bericht aussieht, bevor Sie sich festlegen, können Sie einen Beispielbericht anfordern oder einen Feature-Scan für Ihre Anwendung durchführen. Die meisten Teams stellen fest, dass das KI-Penetrationstest-Format für ihre Auditoren überhaupt keine Überraschung ist.
Bei Aikido haben wir sehr gute Ergebnisse bei unseren Kunden erzielt, die KI-Penetrationstests in Verbindung mit Compliance einsetzen. Obwohl wir versprechen, einen manuellen Penetrationstest durchzuführen, falls Ihr KI-Penetrationstest von einem Auditor abgelehnt wird, ist dies bisher noch nicht vorgekommen. Sprechen Sie uns noch heute an, um schnelles, Compliance-konformes Penetrationstesting freizuschalten.
Anhang: Branchenspezifika
Finanzbranche
PCI DSS
Die Anforderung: PCI DSS ist hier das vorschreibendste Framework. Es erfordert eine dokumentierte Penetrationstest-Methodik, interne und externe Penetrationstests mindestens einmal jährlich und nach wesentlichen Änderungen, erneutes Testen aller behobenen Probleme sowie separate Tests der Kontrollen, die die Umgebung für Kartendaten segmentieren (häufiger für Dienstleister). Der Test muss von einem qualifizierten Tester durchgeführt werden, der organisatorisch unabhängig von den zu testenden Systemen ist.
Kann autonomes Testen diese erfüllen? Nein. Die eigene Penetration Testing Guidance von PCI zieht eine klare Grenze zwischen einem Penetrationstest und einem Schwachstellenscan: Ein Scan ist automatisiert, während ein Penetrationstest ein manueller Prozess der Exploitation ist, der auf den Fähigkeiten eines qualifizierten, unabhängigen Testers beruht. Automatisierte Tools können unterstützen, aber die Guidance betrachtet die manuelle Arbeit als den Test selbst. Ein autonomer Penetrationstest wird nicht als PCI-Pentest akzeptiert.
Die Agenten von Aikido nutzen Business Logic, BOLA und verkettete Schwachstellen aus, daher lohnt es sich, sie als kontinuierliche Sicherheitstests parallel zum erforderlichen Engagement einzusetzen, auch nach wesentlichen Änderungen. Dies ist ein Sicherheitsvorteil und eine Quelle für Nachweise zur Behebung, aber keine PCI-Abnahme. Planen Sie den qualifizierten menschlichen Pentest separat.
Fazit: Erfüllt die Anforderung nicht. Der Penetrationstest muss von einem qualifizierten menschlichen Tester durchgeführt werden. Autonomes Testen wird nicht als PCI-Pentest akzeptiert.
Referenz: PCI DSS v4.0.1 Anforderung 11.4 (11.4.1 bis 11.4.6); PCI SSC Penetration Testing Guidance.
DORA
Die Anforderung: DORA umfasst zwei Teststufen. Die allgemeine Stufe ist ein Programm für digitale operationelle Resilienztests, das jedes Finanzunternehmen etablieren muss, und Penetrationstests sind eine der dabei zu verwendenden Methoden. Die fortgeschrittene Stufe erfordert Threat-Led Penetration Testing (TLPT) mindestens einmal alle drei Jahre für bedeutende Finanzunternehmen, mit strengen Regeln, wer diese durchführen darf.
Kann autonomes Testen diese erfüllen? Ja für das allgemeine Programm, nein für TLPT. Das allgemeine Programm ist methodenflexibel und seine aufgeführten Methoden umfassen Penetrationstests, sodass kontinuierliche autonome Tests dazu passen und über das periodische Minimum hinausgehen. TLPT ist anders. Es basiert auf dem TIBER-EU-Framework der EZB und erfordert externe, qualifizierte Red-Teamer sowie einen externen Threat-Intelligence-Anbieter, wobei bedeutende Kreditinstitute ausschließlich externe Tester einsetzen müssen. Dies ist konzeptionell ein menschliches Red-Team-Engagement.
Fazit: Ja für das allgemeine Testprogramm. Es wird die TLPT-Anforderung nicht erfüllen, die externe menschliche Red-Teamer vorschreibt. Nutzen Sie Aikido, um das allgemeine Programm durchzuführen und zu belegen. Das TLPT ist ein separates Engagement, das von Menschen durchgeführt werden muss.
Referenz: DORA (Verordnung (EU) 2022/2554) Artikel 24 und 25 (Testprogramm), Artikel 26 und 27 (TLPT).
FTC Safeguards Rule
Die Anforderung: Die FTC Safeguards Rule regelt, wie Finanzinstitute Kundeninformationen schützen. Sie erfordert regelmäßige Tests der Wirksamkeit Ihrer Schutzmaßnahmen und bietet zwei Möglichkeiten dazu: kontinuierliche Überwachung oder, in deren Abwesenheit, einen jährlichen Penetrationstest plus Schwachstellenbewertungen mindestens alle sechs Monate. Tests sind auch nach größeren Änderungen im Betrieb erforderlich.
Kann autonomes Testen diese erfüllen? Ja. Kontinuierliche Überwachung ist als direkte Alternative zum jährlichen Penetrationstest vorgesehen, was kontinuierliches autonomes Testen bietet. Für eine Institution, die den periodischen Ansatz bevorzugt, liefert ein autonomes Programm sowohl den jährlichen Test als auch die sechsmonatigen Bewertungen. Die Regel legt keine menschliche oder Akkreditierungsanforderung für den Tester fest.
Fazit: Ja. Kontinuierliche Überwachung ist ein expliziter Ersatz für den jährlichen Pentest.
Referenz: FTC Safeguards Rule, 16 CFR 314.4(d) und 314.4(d)(2).
NYDFS Cybersicherheitsverordnung
Die Anforderung: Die Cybersicherheitsverordnung für Finanzdienstleistungen des Staates New York gilt für Banken, Versicherer und andere in New York lizenzierte Unternehmen und wird über den Staat hinaus als Referenzpunkt für den Finanzsektor herangezogen. Ihr Abschnitt zum Penetration Testing erfordert Tests, die auf Ihrer Risikobewertung basieren und entweder als kontinuierliche Überwachung oder als jährlicher Penetrationstest zusammen mit halbjährlichen Schwachstellenbewertungen strukturiert sind.
Kann autonomes Testen dies erfüllen? Ja. Wie bei der FTC-Regel behandelt die Verordnung die kontinuierliche Überwachung und den jährlichen Penetrationstest als Alternativen. Kontinuierliches autonomes Testen entspricht dem Pfad der kontinuierlichen Überwachung, und für Unternehmen, die den periodischen Weg wählen, liefert es auch den jährlichen Test und die halbjährlichen Bewertungen. Die Verordnung legt keine Anforderungen an die Akkreditierung von Testern fest.
Fazit: Ja. Kontinuierliche Überwachung erfüllt die Anforderung eigenständig.
Referenz: NYDFS Cybersicherheitsverordnung, 23 NYCRR 500.5 (Zweite Änderung, 2023).
Gesundheitswesen
HIPAA
Die Anforderung: Die HIPAA Security Rule nennt Penetration Testing nicht explizit. Ihr Bewertungsstandard erfordert eine periodische technische und nicht-technische Evaluierung Ihrer Schutzmaßnahmen, unter die Pentests typischerweise fallen. Ein vorgeschlagenes Update vom Dezember 2024 würde dies explizit machen und Schwachstellenscans mindestens alle sechs Monate sowie Penetration Testing mindestens einmal jährlich fordern. Mitte 2026 ist dieses Update noch nicht final, aber die Richtung ist klar.
Kann autonomes Testen dies erfüllen? Ja. Weder der aktuelle Bewertungsstandard noch das vorgeschlagene Update schreiben einen menschlichen Tester vor. Ein autonomer Bericht ist heute ein Nachweis einer periodischen technischen Evaluierung und würde morgen die vorgeschlagene jährliche Pentest-Verpflichtung erfüllen, wobei kontinuierliches Testen eine einmal jährliche Kadenz übertrifft.
Fazit: Ja, und bereit für die vorgeschlagene Regelung.
Referenz: HIPAA Security Rule, 45 CFR 164.308(a)(8); 2024 NPRM (RIN 0945-AA22).
HITRUST CSF
Die Anforderung: HITRUST CSF ist ein zertifizierbares Framework, das US-amerikanische Gesundheitsorganisationen und deren Anbieter nutzen, um den Schutz von Protected Health Information (PHI) nachzuweisen. Penetration Testing ist Teil der Anforderungen an die technische Compliance und Sicherheitsbewertung. Für die höhere (r2) Zertifizierung muss der Test innerhalb eines rollierenden 12-Monats-Fensters liegen und als fortlaufendes Programm statt als einmaliges jährliches Ereignis durchgeführt werden, wobei die Ergebnisse verfolgt und erneut getestet werden müssen.
Kann autonomes Testen dies erfüllen? Ja HITRUST verlangt keinen menschlichen oder akkreditierten Tester für den Penetrationstest, und seine Präferenz für ein fortlaufendes Programm gegenüber einem einmal jährlichen Ereignis stimmt mit kontinuierlichem autonomem Testen überein. Ein autonomer Penetration-Testing-Bericht ist ein gültiger Nachweis für den Prüfer.
Fazit: Ja für die Penetration-Testing-Anforderung. Die Validierung durch den externen Prüfer ist ein separater Auditschritt.
Referenz: HITRUST CSF Kontrolle 06.h (Technische Compliance-Prüfung).
FDA-Leitfaden zur Cybersicherheit vor der Markteinführung
Die Anforderung: Der FDA-Leitfaden Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions empfiehlt einen mehrschichtigen Ansatz für Sicherheitstests, erfordert aber in der Praxis einen Penetration-Test-Bericht bei Einreichungen vor der Markteinführung.
Kann autonomes Testen dies erfüllen? Ja. Der Leitfaden ist ergebnisorientiert: Er verlangt Nachweise darüber, dass Tests durchgeführt wurden, von wem, in welchem Umfang, was gefunden wurde und vor allem, was Sie dagegen unternommen haben. Letztendlich geht es darum, sicherzustellen, dass die Sicherheitsrisiken unter Kontrolle sind. Der AI-Pentest-Bericht von Aikido erfüllt diese Erwartungen.
Fazit: Ja, aber Umfang, Methoden und Unabhängigkeit in der Einreichung dokumentieren.
Referenz: FD&C Act Abschnitt 524B; FDA-Leitfaden zur Cybersicherheit vor der Markteinführung (2025).
EU-Medizinprodukte-Verordnung (MDR)
Die Anforderung: Die allgemeinen Sicherheits- und Leistungsanforderungen der MDR erwarten, dass Medizinproduktesoftware nach dem Stand der Technik entwickelt wird, mit Verifizierung und Validierung sowie minimalen IT-Sicherheitsmaßnahmen über den gesamten Produktlebenszyklus hinweg. Der EU-Leitfaden zur Cybersicherheit von Medizinprodukten (MDCG 2019-16) nennt Penetration Testing als Teil dieser Verifizierung und Validierung, neben Sicherheitstestfunktionen, Fuzzing und Schwachstellenscans.
Kann autonomes Testen dies erfüllen? Ja. Die MDR und ihr Leitfaden sind methodenneutral, und ein autonomer Penetrationstest ist ein gültiger Verifizierungs- und Validierungsnachweis. Kontinuierliches Testen passt auch besser zum Lebenszyklus-Schwerpunkt als ein einmaliger Test. Ähnlich wie beim FDA-Leitfaden geht es darum, nachzuweisen, dass die Sicherheitsrisiken unter Kontrolle sind.
Fazit: Ja.
Referenz: EU MDR (Verordnung (EU) 2017/745) Anhang I, GSPR 17.2 und 17.4; Leitfaden MDCG 2019-16.
IEC 81001-5-1
Die Anforderung: Dies ist der Standard für den sicheren Software-Lebenszyklus für Gesundheitssoftware und wird für die MDR harmonisiert. Seine Software-Systemtestaktivitäten umfassen Tests von Sicherheitsanforderungen, Bedrohungsminderungs-Tests, Schwachstellentests und Penetrationstests. Der Standard verlangt, dass Penetrationstests von einer Abteilung oder Organisation durchgeführt werden, die unabhängig von den Entwickelnden ist, und er enthält eine separate Bestimmung zur Verwaltung von Interessenkonflikten zwischen Testern und Entwickelnden.
Kann autonomes Testen dies erfüllen? Ja, und die Unabhängigkeitsanforderung spricht für Sie. Was der Standard verlangt, ist organisatorische Unabhängigkeit von den Entwickelnden, nicht ein menschlicher Tester. Als externer Dritter erfüllt Aikido diese Unabhängigkeitsanforderung, während die autonome Methodik und der Audit-Trail die dokumentierte, wiederholbare Aktivität liefern, die der Standard erwartet.
Urteil: Ja, die Unabhängigkeit Dritter erfüllt den Standard.
Referenz: IEC 81001-5-1:2021 Klausel 5.7.4 (abgebildet auf SVV-4) und 5.7.5.
Automobilindustrie
ISO/SAE 21434
Die Anforderung: Die Cybersicherheit im Automobilbereich basiert auf ISO/SAE 21434, dem Engineering-Standard für Fahrzeug-Cybersicherheit, seiner Risikomethode und der Bedrohungsanalyse und Risikobewertung („TARA“). Der Standard nennt Penetrationstests als eine Methode zur Validierung, dass die Cybersicherheitsziele erreicht wurden.
Kann autonomes Testen dies erfüllen? Ja, für die Bereiche, die es erreichen kann. Der Standard ist ergebnisorientiert. Penetrationstests sind eine Validierungsmethode unter mehreren (z. B. Fuzzing, SAST, DAST, …), und ein autonomer Pentest-Bericht ist ein gültiger Nachweis, wobei kontinuierliches Testen auch den Lebenszyklus-Schwerpunkt berücksichtigt. Ein Vorbehalt: Fahrzeuge basieren auf eingebetteten Komponenten; physische Sicherheitstests auf Hardware-Ebene können nicht durch autonome Methoden durchgeführt werden.
Urteil: Ja für die verbundene und Backend-Angriffsfläche. Der Standard ist methodenflexibel und akzeptiert autonomes Testen als Validierungsnachweis.
Referenz: ISO/SAE 21434:2021 Cybersicherheitsvalidierung (Klausel 11, RQ-11-01).
Regierung & öffentlicher Sektor
ENS
Die Anforderung: Spaniens Esquema Nacional de Seguridad listet Penetrationstests als explizite Sicherheitsmaßnahme auf. Es ist obligatorisch für Systeme hoher Kategorie und empfohlen für Systeme mittlerer Kategorie, und aktuelle Ergebnisse fließen in das periodische Audit des Frameworks ein.
Können autonome Tests dies erfüllen? Ja. ENS schreibt vor, dass getestet wird, nicht wer die Tests durchführt. Ergebnisse autonomer Penetrationstests erfüllen die Maßnahme, und kontinuierliche Tests übertreffen die empfohlenen jährlichen (hoch) und zweijährlichen (mittel) Frequenzen.
Fazit: Ja, autonome Penetrationstests erfüllen die Anforderung.
Referenz: ENS (Real Decreto 311/2022) Anhang II Maßnahme mp.s.3; periodische Prüfung gemäß Artikel 31.
NIST SP 800-53
Die Anforderung: NIST 800-53 enthält eine dedizierte Kontrolle für Penetrationstests. Sie fordert Penetrationstests in einer vom Unternehmen festgelegten Häufigkeit, sieht einen unabhängigen Penetrationstest-Agenten oder ein Team vor und ergänzt Red-Team-Übungen als Erweiterung. Die Kontrolle besagt explizit, dass Penetrationstests über automatisierte Schwachstellenscans hinausgehen und von Agenten und Teams mit nachweisbaren Fähigkeiten durchgeführt werden.
Kann autonomes Testen diese erfüllen? Weitgehend ja, mehr als PCI. Die Kontrolle konzentriert sich auf Unabhängigkeit und das Überschreiten von Scans, beides erfüllt Aikido: Es ist eine unabhängige dritte Partei, die Schwachstellen ausnutzt und validiert, anstatt nur zu scannen. Die Kontrolle verwendet sogar das Wort „Agenten“. Das Resturteil, ob ein autonomer Agent die erforderlichen „Fähigkeiten“ aufweist, liegt bei der bewertenden Behörde. Bestätigen Sie die Akzeptanz daher mit Ihrem Gutachter.
Urteil: Ja, mit Zustimmung des Gutachters. Unabhängigkeit und „über das Scannen hinaus“ sind eindeutig erfüllt.
Referenz: NIST SP 800-53 Rev. 5, Kontrolle CA-8 (mit CA-8(1) und CA-8(2)).
US EO 14028
Die Anforderung: Diese US-Exekutivanordnung führte zum Secure Software Development Framework (SSDF). Das Framework enthält eine Praxis zum Testen von ausführbarem Code, um Schwachstellen zu finden, wo dynamisches Testen, Fuzzing und Penetrationstests angesiedelt sind. Lieferanten von US-Bundesbehörden bestätigen die Einhaltung des Frameworks auf einem CISA-Bestätigungsformular.
Kann autonomes Testen diese erfüllen? Ja. Das Framework ist technologieunabhängig. Ein autonomer Penetrationstest ist eine legitime Methode, um die Praxis des Code-Testings zu erfüllen, und Ihr Bericht ist der Nachweis für die Selbstbestätigung.
Urteil: Ja, manuelle Tests sind nicht erforderlich.
Referenz: EO 14028 Abschnitt 4(e); NIST SSDF (SP 800-218) Praxis PW.8 und PW.8.2; CISA Secure Software Development Attestation Form (OMB M-22-18).
FedRAMP
Die Anforderung: FedRAMP erfordert einen jährlichen Penetrationstest über seine Baselines hinweg, der nach einem obligatorischen Satz von Angriffsvektoren durchgeführt und von einer akkreditierten Drittanbieter-Bewertungsorganisation (einer 3PAO) für Moderate- und High-Systeme durchgeführt wird.
Kann autonomes Testen diese erfüllen? Nein. Der Penetrationstest, der einer FedRAMP-Autorisierung zugrunde liegt, und der jährliche Pentest, der diese aufrechterhält, müssen von einer akkreditierten 3PAO durchgeführt werden. Ein autonomer Test durch eine Nicht-3PAO wird in einem Autorisierungspaket oder einer jährlichen Bewertung nicht akzeptiert. Er kann zwischen diesen Engagements als zusätzliche Sicherheitstests durchgeführt werden, ist aber kein Autorisierungsnachweis.
Urteil: Erfüllt die Anforderung nicht. Die Pentests müssen von einer akkreditierten Drittorganisation durchgeführt werden.
Referenz: FedRAMP Penetration Test Guidance; NIST SP 800-53 Kontrolle CA-8; 3PAO-Akkreditierung durch A2LA.
FISMA
Die Anforderung: FISMA übernimmt seine Testerwartungen von NIST 800-53, angewendet durch das Risk Management Framework von NIST. Umfang und Strenge werden von der Behörde und der Systemkategorisierung festgelegt.
Kann autonomes Testen diese erfüllen? Im Allgemeinen ja, die gleiche Logik wie bei der NIST 800-53 Kontrolle, vorbehaltlich der Bewertungsanforderungen der Behörde. Für Systeme, die auch eine externe Autorisierung mit Regeln für akkreditierte Gutachter (wie FedRAMP) anstreben, sind die Einschränkungen dieses Programms maßgebend.
Urteil: Ja, aber nach Ermessen der Behörde.
Referenz: FISMA über NIST SP 800-53 (CA-8) und NIST SP 800-37 (Risk Management Framework).
Internationale Standards
SOC 2
Die Anforderung: SOC 2 erfordert nicht explizit einen Pentest, aber die Trust Services Criteria des AICPA (der Dachorganisation hinter SOC 2) weisen darauf hin: Das Überwachungskriterium nennt Penetrationstests als akzeptable Bewertungsmethode, und das Kriterium zur Erkennung neuer Schwachstellen wird durch aktive Tests unterstützt. In der Praxis erwarten Auditoren Pentest-Nachweise, insbesondere für einen Typ-II-Bericht, innerhalb des Auditzeitraums, einschließlich Nachweisen für Behebung und erneute Tests.
Kann autonomes Testen diese erfüllen? Ja. Ein unabhängiger Drittanbieter-Test ist ein stärkerer Nachweis als ein interner Test, und die Formulierung „laufende oder separate Bewertungen“ deutet auf kontinuierliche Tests hin.
Urteil: Ja. Kontinuierliche Tests entsprechen direkt „laufenden Bewertungen“.
Referenz: AICPA Trust Services Criteria CC4.1 und CC7.1
ISO/IEC 27001
Die Anforderung: Einige der Annex-A-Kontrollen von ISO 27001 sind die Ansatzpunkte: eine zur Verwaltung technischer Schwachstellen, die „geplante, dokumentierte und wiederholbare Penetrationstests oder Schwachstellenbewertungen durch kompetente und autorisierte Personen“ fordert; eine zu Sicherheitstests in Entwicklung und Abnahme; und eine zum sicheren Entwicklungslebenszyklus.
Kann autonomes Testen diese erfüllen? Ja. Die Formulierung im Standard ist fast eine Beschreibung des autonomen Testens, und die Reproduzierbarkeit ist in die Funktionsweise der Agenten integriert. Auditoren akzeptieren hier automatisierte und kontinuierliche Tests durch Dritte als Nachweis, und der Bericht sowie der Audit-Trail liefern den „dokumentierten“ Teil.
Fazit: Ja. Wiederholbare Tests passen hier natürlich.
Referenz: ISO/IEC 27001:2022 Anhang A; ISO/IEC 27002:2022 Kontrollen 8.8, 8.25 und 8.29.
Europäische Verordnungen
NIS2-Richtlinie
Die Anforderung: NIS2 verlangt von den betroffenen Organisationen, Schwachstellen zu beheben und Richtlinien zur Bewertung der Wirksamkeit ihrer Sicherheitsmaßnahmen zu haben. Die Durchführungsverordnung präzisiert dies mit Anforderungen an das Schwachstellenmanagement und automatisierte oder manuelle Sicherheitstests, Penetrationstests und Schwachstellenscans, die regelmäßig und nach wesentlichen Änderungen durchgeführt werden.
Kann autonomes Testing dies erfüllen? Ja, explizit. Die Durchführungsverordnung von NIS2 ist eines der wenigen Instrumente, das automatisierte Tests und Penetrationstests als akzeptable Methoden benennt. Kontinuierliches autonomes Testing entspricht der Formulierung „regelmäßig und nach wesentlichen Änderungen“, und der Bericht dient als Nachweis sowohl für die Verpflichtungen zum Schwachstellenmanagement als auch zur Wirksamkeitsbewertung.
Fazit: Ja. Automatisierte Tests und Penetrationstests sind ausdrücklich vorgesehen.
Referenz: NIS2-Richtlinie (EU) 2022/2555 Artikel 21 Absatz 2 Buchstaben e und f; Durchführungsverordnung (EU) 2024/2690 Anhangspunkte 6.10 und 7.1.
GDPR
Die Anforderung: Die DSGVO verlangt einen Prozess zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit Ihrer technischen und organisatorischen Sicherheitsmaßnahmen.
Kann autonomes Testing dies erfüllen? Ja. Die DSGVO schreibt keine Methode vor und betont regelmäßige Tests, daher ist kontinuierliches autonomes Testing ein stärkerer Nachweis eines fortlaufenden Prozesses als ein jährliches PDF. Der Bericht belegt sowohl die Tests als auch den Behebungsprozess.
Fazit: Ja, es begünstigt kontinuierliches Testing.
Referenz: DSGVO (Verordnung (EU) 2016/679) Artikel 32 Absatz 1 Buchstabe d.
Cyber Resilience Act
Die Anforderung: Der Cyber Resilience Act verlangt, dass Produkte mit digitalen Elementen ohne bekannte ausnutzbare Schwachstellen auf den Markt gebracht werden und dass im Rahmen des Schwachstellenmanagements über die gesamte Produktlebensdauer hinweg wirksame und regelmäßige Tests und Überprüfungen der Produktsicherheit durchgeführt werden.
Kann autonomes Testing dies erfüllen? Ja. „Wirksame und regelmäßige“ Tests sind das, was kontinuierliches autonomes Penetrationstesting über den gesamten Produktlebenszyklus hinweg liefert, und der Bericht unterstützt sowohl die Testpflicht als auch die Anforderung „keine bekannten ausnutzbaren Schwachstellen“ bei der Veröffentlichung.
Fazit: Ja, „regelmäßige“ Tests begünstigen autonomes Penetrationstesting.
Referenz: Cyber Resilience Act (Verordnung (EU) 2024/2847) Anhang I (Teil I und Teil II Punkt 3); Artikel 13.
FAQ
Funktionieren KI-Penetrationstests für die SOC 2 Compliance?
Ja, in den meisten Fällen. SOC 2 legt nicht fest, wer oder was einen Penetrationstest durchführt, sondern nur, dass Tests stattgefunden haben, Ergebnisse mit Nachweisen dokumentiert und kritische Probleme behoben wurden.
Werden Auditoren einen KI-Penetrationstestbericht akzeptieren?
In den meisten Fällen ja, vorausgesetzt, der Bericht enthält validierte Ergebnisse mit Proof-of-Concept-Nachweisen, einen Methodik-Abschnitt, Schweregradeinstufungen und Empfehlungen zur Behebung. Das Hauptrisiko einer Ablehnung ist die Einreichung von automatisierten Scanner-Ergebnissen, die als Penetrationstest ausgegeben werden, und nicht ein echter KI-Penetrationstest.
Was ist der Unterschied zwischen KI-Penetrationstests und automatisiertem Scanning?
Automatisierte Scanner gleichen Muster mit bekannten Schwachstellensignaturen ab und kennzeichnen potenzielle Probleme, ohne zu bestätigen, ob diese tatsächlich ausnutzbar sind. Ein echter KI-Penetrationstest analysiert die Funktionsweise der Anwendung, versucht, die Ergebnisse an einem Live-Ziel auszunutzen, und zeigt nur Schwachstellen auf, die tatsächlich bestätigt wurden.
Erfordert SOC 2 einen menschlichen Penetrationstester?
Nein. SOC 2 ist ergebnisorientiert, was bedeutet, dass es definiert, was Ihre Kontrollen basierend auf Ihren schriftlichen Sicherheitsrichtlinien demonstrieren müssen, und nicht, wie die Tests durchgeführt werden müssen. Das Framework orientiert sich an Common Criteria-Kontrollen wie CC4.1 und CC7.1, und ein gut dokumentierter KI-Penetrationstestbericht erfüllt diese Anforderungen.
Können KI-Penetrationstests manuelle Penetrationstests für die Compliance ersetzen?
Für die meisten SOC 2-, ISO 27001- und HIPAA-Programme: ja. Bestimmte regulierte Umgebungen, wie britische Industrien, die eine CREST-Zertifizierung erfordern, oder US-Bundesbehörden, die eine FedRAMP-Autorisierung benötigen, haben Akkreditierungsanforderungen, die derzeit eine menschliche Gegenzeichnung der Arbeit erfordern.
Wie oft muss ein Penetrationstest für die Compliance durchgeführt werden?
Die meisten Frameworks erwarten mindestens jährliche Tests sowie erneute Tests nach der Einführung signifikanter Änderungen an Ihrer Anwendung oder Infrastruktur. KI-Penetrationstests können dies für SOC 2 und ISO 27001 abdecken. PCI DSS ist das präskriptivere Framework, das explizit sowohl interne als auch externe Tests jährlich und nach jeder signifikanten Änderung der Karteninhaberdaten-Umgebung vorschreibt. KI-Penetrationstests decken einen Großteil des Anwendungs-Layer-Teils dieser Anforderung ab, müssen aber von einem menschlichen Penetrationstester eingesetzt werden. Netzwerk- und Segmentierungstests erfordern eine separate Abdeckung, typischerweise durch einen menschlichen Penetrationstester.
Welche Frameworks erfordern explizit Penetrationstests?
PCI DSS fordert dies explizit unter Abschnitt 11.4, und FedRAMP verlangt es als Teil der Autorisierung von Cloud-Dienstanbietern. SOC 2, ISO 27001 und HIPAA schreiben es nicht direkt vor, aber Auditoren erwarten es routinemäßig als Nachweis, dass die Sicherheitskontrollen funktionieren.
Was muss ein Penetrationstestbericht für die Compliance enthalten?
Mindestens: eine Zusammenfassung für die Geschäftsleitung, einen Methodik- und Umfangabschnitt, validierte Ergebnisse mit Proof-of-Concept-Nachweisen und Reproduktionsschritten, Schweregradeinstufungen und einen Maßnahmenplan zur Behebung. Speziell für SOC 2 sollten die Ergebnisse den relevanten Trust Services Criteria zugeordnet werden.
Werden KI-Penetrationstests für ISO 27001 akzeptiert?
Ja. ISO 27001 empfiehlt Penetrationstests als Teil der fortlaufenden Risikobewertung, legt aber nicht fest, wie diese durchgeführt werden müssen. Ein Bericht, der dokumentiert, was, wie und welche Ergebnisse gefunden wurden, erfüllt die Nachweisanforderungen des Frameworks.
Was sind die Einschränkungen von KI-Penetrationstests im Hinblick auf die Compliance?
Physische Sicherheitstests und Social Engineering sind für jeden anwendungsfokussierten Penetrationstest, ob KI-gestützt oder nicht, außerhalb des Geltungsbereichs. PCI DSS benötigt mindestens einen menschlichen Penetrationstester für Netzwerk- und Segmentierungstests. Branchen mit spezifischen Akkreditierungsanforderungen, wie CREST in Großbritannien oder 3PAO-Anforderungen unter FedRAMP, benötigen möglicherweise zusätzliche Schritte, bevor ein KI-Penetrationstest ihre Compliance-Verpflichtungen vollständig erfüllt.
