PCI DSS en DORA zijn nu code-reviewproblemen.
Voor fintech- en betalingsteams wier toezichthouders in de repository zijn gekomen: de verwerking van kaartgegevens, operationele veerkracht en leveranciersrisico veranderen één diff tegelijk.
Fintech heeft de zwaarste overlap van verplichtingen die daadwerkelijk in code leven: PCI DSS als je kaartgegevens aanraakt, DORA als je een financiële entiteit in de EU bedient of bent, SOC 2 omdat je klanten dit vragen. Geen van deze verplichtingen vervalt op een schema. Een kaartnummer belandt in een logbestand, een failover-taak wordt uitgeschakeld tijdens een opschoning, een betalingspad verliest stilletjes een controle, en elk van deze wijzigingen is een pull request die iemand alleen op correctheid heeft beoordeeld.
Veerkracht en verplichtingen voor kaartgegevens, benaderd bij de diff
Wat fintech anders maakt, is dat de toezichthouders eisen hebben opgesteld die concreet genoeg zijn om tegen een wijziging te controleren: PCI DSS eist bescherming van opgeslagen rekeninggegevens en authenticatie van toegang; DORA eist bescherming, detectie en herstel. heygrc is ontworpen om elke pull request te lezen tegen de kaders die je hebt geselecteerd en de eis te citeren die een wijziging raakt, zodat de engineer die beslist of hij moet mergen, weet dat hij ook beslist over een controle.
Het scopeert niet je CDE, voert je DORA-testprogramma niet uit of vervangt je QSA. Het vangt het moment dat een beoordeelde wijziging een eis begint te ondermijnen, tijdens de review zelf.
Wijzigingen die als gewone code lezen.
Een paar van de control-relevante wijzigingen die heygrc is gebouwd om voor dit geval te markeren, elk met verwijzing naar de clausule die het raakt.
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
De frameworks die hier het meest relevant zijn.
Gids: Maak compliance een verplichte check
heygrc markeert control-relevante wijzigingen en verwijst naar de clausule, zodat het probleem in de pull request kan worden opgelost. Het certificeert je niet, voert je audit niet uit en vervangt je eigen oordeel niet.