Fintech-Penetrationstests: Anforderungen gemäß DORA, TLPT oder PCI DSS?

Die Entscheidung, bei der Ihnen dieser Leitfaden hilft

Legen Sie vor der Auswahl von Prüfungsbezeichnungen die juristische Person, die regulierte Tätigkeit und die Umgebung mit Zahlungskartendaten fest. Die Anwendbarkeit von DORA und die TLPT-Auswahl sind unterschiedliche Fragen. Halten Sie die Ziele der Produktsicherheit ausdrücklich fest, auch wenn eine Compliance-Anforderung den Penetrationstest ausgelöst hat.

Die regulierte Tätigkeit ermitteln

Die Bezeichnung Fintech kann ein reguliertes Zahlungsinstitut, einen Softwareanbieter oder mehrere unterschiedliche Unternehmen innerhalb einer Gruppe meinen. Ermitteln Sie, welches Unternehmen den Dienst erbringt und welche Pflichten für dieses gelten. Die Anwendbarkeit von DORA und die Auswahl für ein TLPT sind miteinander verbundene, aber unterschiedliche Fragen.

Den Zahlungskartenumfang separat abbilden

PCI DSS betrifft Zahlungskartendaten und die Systeme innerhalb des festgelegten Geltungsbereichs. Eine Finanzanwendung ist nicht automatisch mit einer Karteninhaberdatenumgebung gleichzusetzen. Stimmen Sie sich mit dem zuständigen Compliance-Team oder Prüfer ab, um die relevanten Grenzen und Nachweiserwartungen zu bestimmen, bevor Sie die Prüfung festlegen.

Produktrisiken sichtbar machen

Mandantenisolierung, Befugnisse von Diensttokens und die Verarbeitung von Transaktionszuständen können auch dann relevant sein, wenn ein bestimmter Regulierungsrahmen nicht gilt. Beschreiben Sie diese Geschäftsziele ausdrücklich. Ein Test, der sich ausschließlich an einer Rahmenwerksbezeichnung orientiert, kann das Produktverhalten auslassen, das für Kunden am wichtigsten ist.

Übertreiben Sie die Aussagekraft des Ergebnisses nicht

Eine technische Bewertung dokumentiert beobachtete Befunde und Einschränkungen. Sie verleiht keine universelle DORA-, PCI- oder DSGVO-Konformität. Richten Sie den Bericht an den angeforderten Nachweisen aus, überlassen Sie regulatorische Schlussfolgerungen dem geeigneten Verfahren und planen Sie Wiederholungstests für die Kontrollen, die das Engineering-Team ändert.

Rechtsträger und Produktarchitektur getrennt betrachten

Ein Fintech-Produkt kann mehrere juristische Personen, regulierte Tätigkeiten und Dienstleister umfassen. Ermitteln Sie, welche Einheit den betreffenden Dienst betreibt und wer für die anwendbaren Pflichten verantwortlich ist. Ordnen Sie anschließend die Systeme zu, die diese Tätigkeit unterstützen. Leiten Sie eine rechtliche Einstufung nicht allein aus der Nutzung von Zahlungs-APIs, einer Bankpartnerschaft oder einer Marketingkategorie ab. Das technische Team kann Architektur- und Datenflussnachweise bereitstellen; die zuständigen Rechts- und Compliance-Funktionen bestimmen die Anwendbarkeit.

Ein Scoping-Vermerk sollte die entscheidungsverantwortliche Person und offene Fragen dokumentieren. So wird verhindert, dass ein Anbietervorschlag stillschweigend zur rechtlichen Auslegung der Organisation wird, nur weil er die passenden regulatorischen Akronyme enthält.

Aussagen zur Prüfungssicherheit am Umfang der Abdeckung ausrichten

Für eine klar abgegrenzte technische Prüfung sollten Sie die Anwendungen, Identitäten, Umgebungen und Methoden angeben, die tatsächlich abgedeckt sind. Erläutern Sie, ob Karteninhaberdatensysteme, unterstützende Dienste oder Grenzen zu Drittanbietern zum vereinbarten Leistungsumfang gehören. Eine erfolgreiche API-Prüfung belegt für sich genommen keine PCI-DSS-Konformität. Ebenso ist ein Bericht mit Verweisen auf DORA kein Nachweis dafür, dass eine vorgeschriebene fortgeschrittene bedrohungsgeleitete Übung durchgeführt wurde. Ordnen Sie jede angeforderte Leistung ihrem vorgesehenen Zweck zu, statt ein pauschales Assurance-Label auszustellen.

Der Leitfaden zu Bank-Penetrationstests im Vergleich zu DORA-TLPT erläutert den Unterschied zwischen routinemäßigen technischen Tests und einer von einer Behörde gesteuerten erweiterten Übung. Informationen zum zugrunde liegenden TLPT-Bereitstellungsmodell finden Sie im Leitfaden zu TIBER-EU und DORA.

Verwenden Sie einen zusammenhängenden Prüfungsumfang mit eindeutigem Zweck

Teams können Architektur-, Zuständigkeits- und Nachweisvorbereitungen häufig über mehrere Assurance-Arbeitsbereiche hinweg wiederverwenden. Dabei dürfen Unterschiede bei Zielen, Methoden oder Abnahmekriterien nicht verwischt werden. Erstellen Sie eine Matrix, die jede Geschäftsentscheidung oder Anforderung mit der relevanten Testaktivität, den Nachweisen und der verantwortlichen Person verknüpft. Kennzeichnen Sie, wo weiterhin eine andere Prüfung oder eine fachliche Begutachtung erforderlich ist. So wird die Beschaffung effizienter, ohne zu behaupten, dass ein und derselbe Test alle Pflichten erfüllt.

Zum Abschluss sollten Sie die getestete Version, Einschränkungen des Umfangs und noch offene Entscheidungen festhalten. Verlagert das Produkt sensible Verarbeitungen zu einem anderen Anbieter oder fügt es eine neue Dienstidentität hinzu, sollten Sie die betreffende Abgrenzung erneut prüfen, statt davon auszugehen, dass ein früherer Bericht die Änderung automatisch abdeckt. Das Ergebnis sollte eine klare, belegbare Aussage dazu sein, was getestet wurde und was die Organisation noch feststellen muss.

Setzen Sie die Leitlinien praktisch um

Verwenden Sie die Vorbereitungs-Checkliste, um Annahmen zu dokumentieren, oder sehen Sie sich den fiktiven Bericht der Fintech AG mit Beispielen für Nachweise und Maßnahmenpläne an. Kontaktieren Sie Atlant Security mit einer nicht sensiblen Beschreibung Ihres Umfangs.