Geen bugs. Wijzigingen die in een audit zichtbaar zouden zijn. Negen categorieën, gekoppeld aan ISO 27001:2022 en SOC 2. De lijst is de granulariteit van de review, niet de 93 regels van Bijlage A.
Een compliance-relevante wijziging is een diff die in een audit van belang zou zijn: het verplaatst wie toegang heeft tot wat, wat wordt gelogd, hoe lang een trail wordt bewaard, hoe een secret wordt opgeslagen, of of een controle nog steeds bewijs heeft. Meestal is het geen bug. Tests kunnen groen blijven. De code kan korter zijn. De verplichting is zwakker na de merge dan ervoor.
heygrc voert geen vaste regelset uit. Het leest de pull request tegen de frameworks die je hebt geselecteerd (ISO 27001:2022 Bijlage A, SOC 2 TSC, GDPR, NIS 2 en de rest van de catalogus) plus de bedrijfscontext die je hebt meegegeven. De onderstaande categorieën zijn de vormen waar de review naar zoekt. Ze omvatten niet elke controle in Bijlage A, en ze zijn geen garantie dat elke regel in elke repository wordt geactiveerd.
Wijzigingscategorieën en de clausules die ze meestal citeren
| Wijzigingscategorieën en de clausules die ze meestal citeren | ISO 27001:2022 | SOC 2 |
|---|---|---|
| Toegangscontrole en autorisatie | A.5.15 tot A.5.18, A.8.2 tot A.8.5 | CC6 |
| Authenticatie | A.8.5 | CC6 |
| Logging, monitoring en hoe lang trails worden bewaard | A.8.15, A.8.16 | CC7 |
| Gegevensverwerking: nieuwe PII-velden, exports, maskering, verwijdering | A.8.10 tot A.8.12 | CC6 |
| Encryptie in transit en at rest, sleutelbeheer | A.8.24 | CC6 |
| Secrets en referenties in code of config | A.8.24 | CC6 |
| Leveranciers en derde partijen: SDK's, subprocessors, uitgaande datastromen | A.5.19 tot A.5.23 | CC9 |
| Bewaar- en verwijderingsregels | A.8.10, A.5.33 | CC6 |
| Auditbewijs: goedkeuringen, CI-gates, migraties | A.8.32, A.5.33 | CC8 |
De negen categorieën
Toegangscontrole en autorisatie: rollen, machtigingen, rij-niveau-beveiliging, admin-paden. Een uitgebreide IAM-rol of een nieuwe onverifieerde route valt onder deze categorie. ISO 27001:2022 A.5.15 tot A.5.18 en A.8.2 tot A.8.5. SOC 2 CC6.
Authenticatie: MFA, sessies, referentiebeheer. Een bevoorrechte route die eerst een tweede factor vereiste en nu alleen een sessie, valt onder deze categorie. A.8.5. SOC 2 CC6.
Logging, monitoring en audit trails, inclusief hoe lang ze worden bewaard. Beschouw dit als illustratief: het verkorten van de bewaring van auditlogs van 365 dagen naar 30 is A.8.15 en SOC 2 CC7.2. Monitoring staat ernaast bij A.8.16.
Gegevensverwerking: een nieuw PII-veld, een export, verwijderde maskering, een verwijderingspad dat een opslag mist. A.8.10 tot A.8.12. SOC 2 CC6 wanneer de wijziging betrekking heeft op wie toegang heeft tot de gegevens.
Encryptie in transit en at rest, en sleutelbeheer. A.8.24. SOC 2 CC6.
Secrets en referenties in code of config. Een sleutel die in de broncode is geplakt, is een blootgesteld secret. A.8.24. SOC 2 CC6.
Leveranciers en derde partijen: een nieuwe SDK, een subprocessor, een uitgaande datastroom die gisteren nog niet bestond. A.5.19 tot A.5.23. SOC 2 CC9 wanneer de wijziging een leveranciersrelatie in code uitdrukt.
Bewaar- en verwijderingsregels. Een nieuwe tabel met geïdentificeerde gebeurtenissen zonder purge-taak. A.8.10 en A.5.33. SOC 2 CC6.
Auditbewijs: goedkeuringen, CI-gates, migraties die een vereiste controle verwijderen. A.8.32 en A.5.33. SOC 2 CC8. Een CODEOWNERS-bewerking die een domeineigenaar verwijdert, valt onder deze categorie.
Hoe dit zich verhoudt tot de ISO-in-repo handleiding
De meeste van deze categorieën vallen onder thema A.8 van Bijlage A, de technologische controles. Dat is hetzelfde segment als de ISO 27001-in-repo handleiding: logging, authenticatie, toegangbeperking, cryptografie, wijzigingsbeheer. Enkele categorieën verwijzen ook naar A.5 wanneer de wijziging betrekking heeft op hoe je toegang verleent, een leverancier toevoegt of records bewaart. De lijst van 93 controles in Bijlage A is nog steeds de verkeerde granulariteit. Je implementeert de 93 items niet als een codechecklist. De Statement of Applicability is waar die beslissingen leven.
GDPR, NIS 2, HIPAA, CCPA en de rest van de catalogus hergebruiken dezelfde wijzigingscategorieën en verwijzen naar hun eigen clausules. De ISO- en SOC 2-kolommen in de tabel zijn de gebruikelijke bestemmingen. Ze zijn niet de enige bestemmingen.
Ernst en een wijziging die een controle verbetert
Ernst is het compliance-risico van het mergen van de pull request in de huidige staat. Een bevinding noemt de controle, zodat het team bewust kan beslissen. Een pull request die MFA herstelt, de bewaring verlengt of een hardcoded sleutel verwijdert, is geen bevinding. Die wijziging krijgt een opmerking in de samenvatting.
heygrc plaatst standaard een neutrale GitHub-check. Het certificeert je niet, schrijft de Statement of Applicability niet en vervangt geen auditor. Het is actief als GitHub App. Gebruik het als reviewer van de wijziging.