PCI DSS und DORA sind jetzt Code-Review-Probleme.
Für Fintech- und Zahlungsteams, deren Aufsichtsbehörden in das Repository gewechselt sind: Die Verarbeitung von Kartendaten, operationelle Resilienz und Anbieterrisiken ändern sich mit jedem Diff.
Fintech hat die größte Überschneidung von Verpflichtungen, die tatsächlich im Code verankert sind: PCI DSS, wenn Kartendaten verarbeitet werden, DORA, wenn Sie eine Finanzinstitution in der EU bedienen oder sind, SOC 2, weil Ihre Kunden es verlangen. Keine dieser Anforderungen verliert mit der Zeit an Gültigkeit. Eine Kartennummer landet in einem Log, ein Failover-Job wird bei einer Bereinigung deaktiviert, ein Zahlungspfad verliert leise eine Kontrolle – und jedes Mal handelt es sich um einen Pull Request, der nur auf Korrektheit geprüft wurde.
Resilienz und Pflichten zum Schutz von Kartendaten, direkt im Diff benannt
Was Fintech besonders macht, ist, dass die Aufsichtsbehörden Anforderungen formuliert haben, die konkret genug sind, um sie gegen eine Änderung zu prüfen: PCI DSS verlangt den Schutz gespeicherter Kontodaten und die Authentifizierung des Zugriffs; DORA verlangt Schutz, Erkennung und Wiederherstellung. heygrc ist darauf ausgelegt, jeden Pull Request gegen die von Ihnen ausgewählten Frameworks zu prüfen und die Anforderung zu benennen, die eine Änderung betrifft, sodass der Entwickler, der über das Mergen entscheidet, weiß, dass er auch über eine Kontrolle entscheidet.
Es definiert nicht Ihren CDE-Bereich, führt Ihr DORA-Testprogramm durch oder ersetzt Ihren QSA. Es erkennt den Moment, in dem eine geprüfte Änderung beginnt, eine Anforderung zu untergraben – direkt im Review.
Änderungen, die wie normaler Code aussehen.
Einige der kontrollrelevanten Änderungen, die heygrc für diesen Fall markieren soll, jeweils mit Verweis auf die betroffene Klausel.
A card number starts landing in application logs
PCI DSS Req 3An MFA check is removed from admin access to the payments system
PCI DSS Req 8A failover path on a critical payments call is removed
DORA Art. 11
Die Frameworks, die hier am wichtigsten sind.
Anleitung: Compliance als Pflichtprüfung festlegen
heygrc markiert kontrollrelevante Änderungen und zitiert die Klausel, sodass das Problem im Pull Request behandelt werden kann. Es zertifiziert dich nicht, führt dein Audit nicht durch und ersetzt nicht dein eigenes Urteil.