Hoe doe ik dit zonder een controle te breken?

Log de beveiligingsrelevante gebeurtenissen (wie heeft wat gedaan en wanneer), voeg altijd de actor toe, schrijf ze ergens duurzaam op en laat een latere opschoning ze niet verwijderen. SOC 2 (CC7.2) en ISO 27001 (A.8.15) verwachten dit allebei en controleren het door steekproeven te nemen van de gebeurtenissen die je daadwerkelijk hebt geregistreerd.

Plaats de sleutel nooit in de broncode. Lees deze uit de omgevingsvariabelen of een beheerde geheimenopslag tijdens runtime, houd deze buiten de repository en de logs, en roteer elk geheim dat ooit is gecommit. ISO 27001 A.8.24 (en gewoon voorzichtigheid) verwacht dat sleutels worden beheerd, niet hardgecodeerd.

Zorg dat het verwijderpad elke locatie bereikt waar de gegevens van de persoon staan: de primaire database, caches, zoekindexen, analytics, back-ups (met hun eigen gedocumenteerde levenscyclus) en elke derde partij waaraan je de gegevens hebt doorgegeven. Wanneer het recht op vergetelheid (GDPR Art. 17) van toepassing is, is een vergeten kopie de reden waarom het mislukt, dus het verwijderpad moet ze allemaal bereiken.

Pin de versie, verifieer wat je downloadt (met een lockfile en integriteitscontrole), vermijd het uitvoeren van externe installatiescripts en geef de voorkeur aan je eigen gecontroleerde registry of mirror. NIS 2 (Art. 21(2)(d)) beschouwt je afhankelijkheden als onderdeel van supply-chain security, en de controles hierop staan in je manifest en build.

Schakel versleuteling in rust in voor elke opslag die elektronische beschermde gezondheidsinformatie (ePHI) bevat (de database, buckets, volumes, back-ups), of documenteer waarom een equivalente beveiligingsmaatregel is geïmplementeerd. De versleutelingsspecificatie van HIPAA (164.312(a)(2)(iv)) is afweegbaar: implementeer deze waar redelijkerwijs mogelijk, of registreer een equivalent, in plaats van deze over te slaan.

Geef alleen de toegang die elke rol of service nodig heeft, weiger standaard en vermijd wildcards. SOC 2 (CC6.1) controleert logische toegang, en minimale rechten is wat een auditor steekproefsgewijs controleert: kan elke identiteit alleen doen wat zijn taak vereist, en niets meer.

Log minimale referenties en codes, niet de volledige inhoud. Registreer een verzoek-id of order-id, masker persoonsgerelateerde velden voordat iets wordt opgeslagen, en log nooit het volledige verzoek of gebruikersobject. Minder data en minder identificerende data loggen is waar GDPR-dataminimalisatie (Art. 5(1)(c)) om draait. Behandel een identifier die naar een persoon verwijst ook als persoonsgegevens en beperk het tot wat je daadwerkelijk nodig hebt voor onderzoek.

Valideer het doel voordat je het ophaalt: vereis https, los de host op en wijs private, interne en link-local adressen (inclusief cloudmetadata-eindpunten) af. Gebruik bij voorkeur een allowlist als de bestemmingen bekend zijn en volg geen redirects blindelings. Server-side request forgery is een inputvalidatieprobleem (NIST 800-53 SI-10), en de controle bevindt zich in de code die het verzoek doet.

Een export is een nieuwe kopie van persoonsgegevens, dus behandel deze ook als zodanig: geef deze een vervaldatum zodat deze niet langer bestaat dan het doel vereist, exporteer alleen de velden en rijen die voor het doel nodig zijn en laat een terugkerende export geen permanente, onbeheerde tweede opslag worden. Dat is waar GDPR bewaarbeperking (Art. 5(1)(e)) om draait.

Gebruik de tokenisatie van je betaalverwerker, zodat de ruwe kaartgegevens direct naar hen gaan en niet via je servers. Sla het token dat ze teruggeven op, samen met de laatste vier cijfers voor weergave, en bewaar nooit het volledige kaartnummer of de verificatiecode. Zo voldoe je aan PCI DSS Vereiste 3 en verklein je de omvang van de PCI-scope die op jou van toepassing is.

Als een beslissing over een persoon volledig door een algoritme wordt genomen en deze een juridisch of vergelijkbaar significant effect op hen heeft (bijvoorbeeld het weigeren van een terugbetaling, lening of account), beperkt GDPR Art. 22 dit: in de regel heeft de persoon het recht om niet onderworpen te worden aan een volledig geautomatiseerde beslissing van die aard. Waar een dergelijke beslissing toch is toegestaan (bijvoorbeeld omdat deze noodzakelijk is voor een contract of gebaseerd is op de uitdrukkelijke toestemming van de persoon), vereist Art. 22(3) waarborgen, waaronder een manier om menselijke tussenkomst te verkrijgen, een mening te uiten en de uitkomst aan te vechten. In beide gevallen: laat de geautomatiseerde tak niet het laatste woord zijn. Leid deze beslissingen door naar een pad waar een persoon deze kan beoordelen.

Het beperken van wie toegang heeft tot gevoelige functies is waar SOC 2 CC6.1 (logische toegangcontroles) om draait, en voor bevoorrechte acties is een geldige sessie meestal niet voldoende op zich. Vraag een tweede factor aan op het moment van de bevoorrechte actie, weiger standaard als deze ontbreekt en registreer de controle, zodat het bereiken van een admin-pad meer vereist dan een gestolen of achtergebleven sessie.

Drie soorten geautomatiseerde reviewers lezen tegenwoordig een pull request: code reviewers die op zoek zijn naar fouten, beveiligingsreviewers die op zoek zijn naar kwetsbaarheden en compliance reviewers die de wijziging afzetten tegen de frameworks waaraan je bedrijf moet voldoen. heygrc is een compliance reviewer voor pull requests: het beoordeelt elke PR tegen de door jou geselecteerde frameworks en verwijst naar de specifieke controle die een wijziging raakt, bijvoorbeeld ISO 27001 A.8.15 of SOC 2 CC6.1. Voor zover wij weten, is het de eerste compliance reviewer voor pull requests (juli 2026).

De meeste GRC- en compliance-automatiseringsplatforms integreren met GitHub op account- en repositoryniveau: ze lezen instellingen zoals branchbeveiliging en vereiste reviews als bewijs dat je change-management control functioneert. Die integratie leest configuratie, niet code. Het beoordelen van de pull request zelf, het lezen van de gewijzigde regels en het benoemen van de control die ze in gevaar brengen, is een andere taak. heygrc doet die taak: een GitHub App die elke pull request beoordeelt op basis van je geselecteerde frameworks en de bevinding als een check op de PR plaatst.

Een audit is een achterlopende indicator: deze steekproeft wat maanden geleden is uitgerold, wanneer de schending al in productie is en duur om op te lossen. Code review is de voorlopende indicator, het laatste moment waarop een schending met één klik niet hoeft te bestaan. Om compliance hier op te sporen: weet welke van je controls daadwerkelijk in code leven, maak de compliance-vraag onderdeel van het beoordelen van elke diff, baseer elke melding op de specifieke clausule en bewaar het spoor, zodat de review zelf auditbewijs wordt.

Beoordeel door AI gegenereerde code aan dezelfde norm als door mensen geschreven code: de auditor vraagt niet wie een wijziging heeft geschreven, maar of de controle heeft gewerkt. Wat verandert met agents is het volume en de foutpatronen. Een agent optimaliseert voor de zichtbare taak, dus controlecodes die als wrijving worden gezien (een logregel, een toestemmingscontrole, een bewaartermijn) lopen risico in hun diffs, en agents openen meer pull requests dan een menselijke compliance-review kan bijhouden. Automatiseer de eerste check; houd mensen in voor de oordeelsvellingen.

Ja. heygrc is een GitHub-app die elke pull request beoordeelt op ISO 27001:2022 en de specifieke Annex A-maatregel noemt die een wijziging raakt, bijvoorbeeld A.8.15 voor een onderdrukt auditlog of A.8.24 voor verzwakte cryptografie. Je installeert de app op je repositories, selecteert ISO 27001 en eventuele andere toepasselijke frameworks, en het plakt bevindingen als reviewopmerkingen plus een statuscontrole die een merge niet blokkeert, tenzij je dat vereist. Voor zover wij weten, is het de eerste compliance-reviewer voor pull requests (juli 2026).

Alleen als je dat wilt. Een compliance-check op een pull request moet standaard een neutrale status hebben: deze plaatst bevindingen en een checkstatus, en de beslissing om te mergen blijft bij de ontwikkelaar. Teams die harde gating willen, kunnen de check verplicht maken in branch protection, waardoor hetzelfde signaal een blokkade wordt op precies de branches die zij kiezen. heygrc levert de neutrale standaard en ondersteunt de opzet met verplichte checks.