Elke praktijk die ertoe doet in engineering krijgt uiteindelijk een naam. Dit is compliance-review voor pull requests: elke wijziging controleren tegen de compliance-kaders die je bedrijf moet naleven, en de specifieke controle benoemen die het raakt, bij de diff, voordat het wordt gemerged. heygrc is onze inzending in die categorie, maar de categorie is groter dan welk product dan ook, en verdient zijn eigen argument.
Categorieën splitsen, en code review splitst nu
Praktijken convergeren niet naar één tool die alles doet; ze divergeren naar specialisten. Code review is al eens gesplitst: correctheidsreview (werkt deze wijziging) en beveiligingsreview (is deze wijziging veilig) zijn verschillende vragen, beantwoord door verschillende reviewers met verschillende kennis, op dezelfde pull request. Niemand verwacht dat een linter een injectie vindt, en niemand verwacht dat een beveiligingsscanner een off-by-one opmerkt.
Compliance is de derde splitsing. Of een wijziging een controle raakt waar je op wordt geaudit, is geen correctheidsvraag en geen beveiligingsvraag: een wijziging kan correct zijn, veilig zijn, en toch een toegangspad verbreden waar SOC 2 CC6.1 om geeft, of een log inkorten die ISO 27001:2022 A.8.15 verwacht dat bestaat. Andere vraag, andere kennis, dezelfde diff. Als een vraag vaak genoeg op eigen voorwaarden wordt gesteld, wordt het een categorie.
Waarom de categorie nu bestaat en niet vijf jaar geleden
Twee curves kruisten elkaar. De eerste: AI-ondersteuning verhoogt de hoeveelheid code die teams produceren, en de menselijke review-aandacht per wijziging is niet mee geschaald. Teams die met agents werken, mergen meer wijzigingen, sneller, met minder menselijke lezing per regel dan waar de praktijk oorspronkelijk op was gebaseerd.
De tweede: het compliance-oppervlak van dezelfde codebases groeit. Meer bedrijven streven SOC 2 en ISO 27001 eerder na; de GDPR is aangevuld met DORA, NIS 2 en de EU AI Act; en de verplichtingen leven steeds vaker in code, in bewaartermijnen, toegangspaden, logs en modelgedrag. Meer wijzigingen, minder menselijke lezing, meer verplichtingen per wijziging: de compliance-lezing heeft automatisering bij de diff nodig als het consistent moet gebeuren.
Wat de categorie is, en wat het niet is
Een compliance-reviewer voor pull requests leest de wijziging tegen de kaders die je bedrijf heeft geselecteerd en baseert elke bevinding op de specifieke controle die het raakt, op een niveau waar je het kunt verifiëren of betwisten. Het draait waar code review al plaatsvindt, en het informeert in plaats van blokkeert: bevindingen zijn review-opmerkingen en een statuscontrole, geen geblokkeerde merge.
Het is geen GRC-platform (het voert je compliance-programma niet uit of verzamelt je bewijs niet), het is geen audit (het is de voorspellende indicator voor dezelfde verplichtingen die de audit meet), en het is geen certificering (een review is een lezing, geen badge). Die tools houden hun taken. Deze categorie bestaat voor de ene taak die geen van hen doet: de compliance-vraag, gesteld bij elke diff, terwijl de wijziging nog goedkoop te herstellen is.