Zoek je naar SOC 2 in pull requests, dan vind je vooral proceschecklists: vereiste reviews, statuscontroles en ondertekende commits. Die instellingen zijn belangrijk. Ze vormen bewijs dat een wijzigingsbeheerproces bestaat. CC8.1 (Common Criteria wijzigingsbeheer) gaat ook over de vraag of de controle daadwerkelijk is toegepast voor een specifieke wijziging: is de wijziging op de manier goedgekeurd die je beleid voorschrijft, of heeft een hotfix, bot of noodprocedure een vereiste stap overgeslagen.
Deze handleiding richt zich op het PR-niveau. Het herhaalt niet de verschillen tussen Type I en Type II (zie /guides/how-to-pass-soc-2-as-a-startup) en behandelt niet de hele CC6-toegangsfamilie (zie /guides/what-soc-2-actually-checks-in-your-repo). Het concentreert zich op wijzigingsbeheer op het moment dat een pull request wordt gemerged.
Branch protection is noodzakelijk, maar niet voldoende
Het vereisen van één goedkeurende review en een groene CI-check is de gebruikelijke basis. Auditors controleren of dit proces tijdens het observatievenster is uitgevoerd. Een repository met branch protection produceert nog steeds uitzonderingen wanneer iemand merge met admin-override, wanneer een deploypad de beveiligde branch omzeilt, of wanneer een automatiseringsaccount merge zonder de menselijke goedkeuring die je beleid vereist.
Het codegerichte bewijs staat niet altijd in de applicatiecode. Het bevindt zich vaak in workflowbestanden, CODEOWNERS, deploy-scripts of een eenregelige wijziging in wie mag goedkeuren. Die landt nog steeds als pull requests.
Praktijkvoorbeeld: noodprocedure die de vereiste goedkeuring overslaat
De on-call wordt opgeroepen. Een engineer opent een pull request die een workflow_dispatch-taak toevoegt met continue-on-error en een pad dat productie deployt vanaf een persoonlijke fork met een langlevend token, gedocumenteerd als "break-glass". Een tweede PR op dezelfde dag wijzigt CODEOWNERS, zodat dat pad niet langer goedkeuring van het platformteam vereist. Beide PR's zien eruit als operationele hygiëne. De applicatiecode hoeft niet eens te veranderen.
Waar CC8.1 om draait, is of wijzigingen aan productie nog steeds door het geautoriseerde wijzigingsproces gaan. Een break-glass-pad dat permanent de vereiste goedkeuringen verzwakt, is een wijziging in de controle, niet alleen een gemak. Tijdens een Type II-venster, als de auditor deploys samplet die dit pad hebben gebruikt zonder de gedocumenteerde goedkeuring, moet je een uitzondering uitleggen. Het opvangen van de workflow- en CODEOWNERS-diffs tijdens de review is goedkoper dan ze zes maanden later uitleggen.
Hoe dit samenhangt met het observatievenster (zonder de audit opnieuw uit te leggen)
Bij Type II test de auditor of controles gedurende een periode hebben gewerkt. Een enkele overgeslagen goedkeuring binnen dat venster kan een gesamplede uitzondering worden, zelfs als de rest van het jaar schoon was. Daarom is wijzigingsbeheershygiëne tijdens het venster geen bureaucratie om de bureaucratie; het is hoe je verrassingen in de verklaring voorkomt waar je maanden aan hebt gewerkt. Details over paraatheid, scope en auditorselectie staan in de SOC 2-proceshandleiding voor startups.
Een pull-request-compliancecheck die CC8.1 citeert bij een verzwakte goedkeuringspoort keurt de noodprocedure niet goed. Het maakt de proceswijziging zichtbaar terwijl de PR nog open is.
Waar heygrc past, en de eerlijkheidsgrens
heygrc is gebouwd om pull requests te lezen tegen de door jou geselecteerde frameworks, inclusief SOC 2 als deze is ingeschakeld, en om criteria zoals CC8.1 te benoemen wanneer een wijziging het wijzigingsbeheer lijkt te verzwakken (goedkeuringspoorten, vereiste controles, deploy-autorisatie). Het voert geen audit uit, verzamelt geen IdP- of HR-bewijs, en geeft geen verklaring af.
Houd je codekwaliteitsreviewer. CC8.1 gaat over de integriteit van het proces bij de wijziging, niet of de hotfix elegant was.