“Deploy nooit op vrijdag.” Iedereen die weleens software in productie heeft gezet, heeft dat weleens gehoord, of op een vrijdagavond spijt gekregen na een deploy. En bijna iedereen die zich met ISO 27001 software ontwikkeling bezighoudt, kent het bijbehorende gevoel: certificering betekent tragere releases, meer procedures en meer approvals. Wat die traagheid vooral veroorzaakt is het opstapelen zelf. Hoe meer features en hotfixes je op elkaar laat wachten, hoe langer het valideren duurt, in elke vorm. Of je dat nu formeel via change management doet of gewoon in een scrum-validatiesessie, een grote batch kost onvermijdelijk meer tijd om te doorgronden dan een kleine. En zo wordt het proces de bottleneck, terwijl de fix zelf allang klaar is.
Er zijn twee redenen waarom er weerstand bestaat om met en aan beleid te werken. De vrijdagregel bestaat omdat we ons release-proces niet genoeg vertrouwen. En het idee dat compliance je afremt bestaat omdat we de controls behandelen als handmatige poortjes die na het ontwikkelen worden dichtgezet. Beide komen voort uit hetzelfde tekort: te weinig vertrouwen in het proces zelf. Bouw je dat vertrouwen op en veranker je de controls in datzelfde proces, dan verdwijnt de reden om releases uit te stellen. Je kunt op vrijdagmiddag een release taggen, waarna de pipeline alle controles automatisch doorloopt en de bewijslast voor de auditor vanzelf ontstaat.
In deze blog laat ik zien hoe je ISO 27001 software ontwikkeling zo inricht dat je proces én snel is én aantoonbaar voldoet aan de controls uit Annex A van ISO 27001:2022. Niet als checklist achteraf, maar ingebakken in de manier waarop je werkt.
Wat Annex A eigenlijk vraagt (en wat niet)
Het misverstand bij ISO 27001 software ontwikkeling zit hem in de aanname dat de norm je een methode voorschrijft. Dat doet hij niet. ISO 27001 schrijft geen trunk-based development voor, geen Scrum, geen wekelijkse releasedag. Wat de norm vraagt zijn aantoonbare garanties: dat beveiliging vanaf het ontwerp is meegenomen, dat je omgevingen gescheiden zijn, dat wijzigingen gecontroleerd en beoordeeld worden, dat je code getest wordt en dat je kwetsbaarheden beheerst.
De relevante controls zitten in het technologische deel (A.8), met A.8.25 tot en met A.8.34 als het hart van de secure development lifecycle. De overkoepelende drie zijn A.8.25 (Secure development life cycle), A.8.26 (Application security requirements) en A.8.27 (Secure system architecture and engineering principles). Daaronder hangen de concrete controls die je pipeline invult.
Omdat de norm uitkomstgericht is, bepaal je bij ISO 27001 software ontwikkeling zelf hoe je die garanties levert. Een goed ingerichte, geautomatiseerde pipeline levert het bewijs dat een auditor zoekt bovendien als bijproduct van het werk dat je toch al doet.
Zo richt je ISO 27001 software ontwikkeling in, control voor control
Hieronder de opzet voor ISO 27001 software ontwikkeling zoals ik hem inricht. Als branchingmodel gebruik ik trunk-based development.* De kern is dat wijzigingen klein, frequent en beoordeeld naar één gedeelde hoofdlijn gaan, in plaats van in langlopende branches te blijven hangen die je later pijnlijk moet samenvoegen.
Vier-ogen als harde poort. Geen enkele wijziging bereikt de hoofdbranch zonder review door een tweede persoon. Belangrijk daarbij is dat branch protection dit afdwingt, zodat het niet afhangt van discipline of goede wil: een merge zonder goedkeuring is technisch onmogelijk. Hiermee dek je A.5.3 (Segregation of duties) en A.8.32 (Change management) in één beweging af, en dwing je functiescheiding af zonder dat iemand een formulier hoeft te tekenen.
Merge en tag als gescheiden acties. Bij mij geldt: een merge naar main deployt automatisch naar staging, en pas een expliciete tag deployt naar productie. Die tag is de bewuste, gecontroleerde productiehandeling — en degene die tagt is niet noodzakelijk degene die de code schreef. Dat is geen toeval: de norm-guidance bij A.8.31 (Separation of development, test and production environments) beschrijft letterlijk dat idealiter de persoon die de code schrijft niet dezelfde is die de knop naar productie indrukt. Diezelfde control kent ook de “één richting”-regel: code stroomt van dev naar staging naar productie, nooit een hotfix rechtstreeks op productie. Precies wat “tag = deploy” garandeert. Je kunt het taggen bijvoorbeeld beleggen bij een release manager: een rol die een teamlid vervult en die zorgt voor snelle, bewuste tagging naar productie. Zo blijft de functiescheiding intact zonder dat het tempo eronder lijdt.
Een lokale dev-omgeving die losstaat van productie. Ontwikkelaars werken lokaal, zonder toegang tot productiedata. Ook dat valt onder A.8.31 — de scheiding voorkomt dat live-gegevens in een onbeschermde omgeving belanden, een van de klassiekste manieren waarop bedrijven onbedoeld data lekken.
Statische én dynamische analyse in de pipeline. SAST (static application security testing) draait op de broncode vóór de merge en vangt kwetsbare patronen af voordat ze überhaupt in de hoofdbranch komen. DAST (dynamic application security testing) draait vervolgens in de CI-pipeline tegen een afgeschermde, disposable instantie van de applicatie die speciaal voor de test wordt opgestart. De scanner benadert die instantie van buitenaf, zoals een aanvaller dat zou doen, waarna de omgeving weer wordt afgebroken. Beide zijn blokkerende poorten: een negatieve uitslag houdt de wijziging tegen. Samen dekken ze A.8.29 (Security testing in development and acceptance), en de SAST-laag versterkt A.8.28 (Secure coding). Wie ISO 27001 kent weet dat auditors bij A.8.29 juist naar dit soort bewijs zoeken — SAST, DAST, dependency-scans — dus je hebt het meteen op orde.
Dependency-scanning met een policy. Elke pull request scant de dependencies (software composition analysis) tegen bekende kwetsbaarheden. Een dependency met een openstaande high-severity kwetsbaarheid haalt de poort niet. Dit koppelt A.8.28 aan A.8.8 (Management of technical vulnerabilities): de norm vraagt expliciet om bewustzijn van onderliggende kwetsbaarheden bij het gebruik van third-party libraries, en dit automatiseert dat bewustzijn.
Automatische updates via Renovate. Bugfix- en minor-versies worden automatisch als pull request aangeboden en — mits groen door alle tests — samengevoegd. Zo blijf je continu bij zonder dat iemand er handmatig achteraan hoeft. Kleine, frequente updates zijn veiliger dan de grote, uitgestelde dependency-migratie die niemand durft aan te raken. Dit ondersteunt A.8.8 en A.8.25.
De 24-uursregel voor tags. Dit is de subtielste, en misschien wel belangrijkste. Bij projecten die leunen op veel externe dependencies — en dat is vrijwel elk project met open source als basis — is een net gepubliceerde package-versie je grootste supply-chain-risico. Een gecompromitteerde of kwaadaardige release wordt doorgaans binnen enkele uren opgemerkt en teruggetrokken. Door een tag minimaal 24 uur te laten “rijpen” voordat je hem in een productie-deploy trekt, profiteer je ervan dat de bredere community deze releases in de tussentijd signaleert: de meeste malafide versies zijn dan al ontdekt en verwijderd voordat ze jouw pipeline raken. Het is daarmee geen bureaucratische drempel maar een goedkope, concrete mitigatie van een reëel risico onder A.8.8.
Testen als piramide. De basis is een brede laag unit tests met hoge dekking, richtlijn 85% of meer. Daarboven een laag integratietests die de samenwerking tussen componenten bewaakt. En daarbovenop end-to-end tests die per feature minimaal het happy path afdekken. Deze piramide valt onder A.8.29, maar haar belangrijkste functie is het vertrouwen dat ze oplevert: met deze dekking betekent een groene build dat de release ook daadwerkelijk veilig is om uit te rollen. Geen enkele testsuite dekt vooraf alle paden af; soms mis je er een. Daarom hanteer ik bij elke gevonden regressie de vaste regel dat er meteen een test bijkomt die dat specifieke pad voor volgende releases bewaakt. Zo groeit de dekking organisch mee met de fouten die je in de praktijk tegenkomt, en kan dezelfde regressie geen tweede keer ongemerkt terugkomen.
Git-history en CI-logs als audittrail. Alle voorgaande stappen laten sporen na. Elke wijziging in dit proces is terug te vinden: wie schreef het, wie reviewde het, wanneer, welke tests slaagden, welke scans liepen, wie tagde de release. Dat spoor is je bewijs onder A.8.15 (Logging) — en je genereert het volledig automatisch. Waar veel organisaties bij een audit hun bewijs bij elkaar moeten schrapen uit tickets, mails en gedeelde mappen, rolt het bij jou zo uit git en je CI-systeem.
De mapping in één oogopslag
| Onderdeel van de inrichting | Annex A control |
|---|---|
| Vier-ogen (verplichte review, branch protection) | A.5.3 Segregation of duties / Functiescheiding · A.8.32 Change management / Wijzigingsbeheer |
| Merge = staging, tag = productie, lokale dev | A.8.31 Separation of development, test and production environments / Scheiding van ontwikkel, testen en productieomgevingen |
| SAST + DAST als blokkerende poorten | A.8.28 Secure coding / Veilig coderen · A.8.29 Security testing in development and acceptance / Testen van de beveiliging tijdens ontwikkeling en acceptatie |
| Dependency-scanning + policy | A.8.28 Secure coding / Veilig coderen · A.8.8 Management of technical vulnerabilities / Beheer van techische kwetsbaarheden |
| Tags minimaal 24 uur oud | A.8.8 Management of technical vulnerabilities / Beheer van techische kwetsbaarheden |
| Renovate bugfix/minor | A.8.8 Management of technical vulnerabilities / Beheer van techische kwetsbaarheden · A.8.25 Secure development life cycle / Beveiliging tijdens de ontwikkelcyclus |
| Testpiramide (unit 85%+, integratie, e2e) | A.8.29 Security testing in development and acceptance / Testen van de beveiliging tijdens ontwikkeling en acceptatie |
| Git-history + CI-logs | A.8.15 Logging |
| Het geheel | A.8.25 · A.8.26 · A.8.27 |
Eén nuance is belangrijk: dit is één verdedigbare invulling van ISO 27001 software ontwikkeling, niet de enige. De norm schrijft geen tooling en geen branchingmodel voor. Werk je met een externe ontwikkelpartner, dan komt A.8.30 (Outsourced development) erbij; doe je alles in huis, dan speelt die control niet. Vink dus alleen af wat daadwerkelijk van toepassing is, dat maakt je sterker bij een auditor, niet zwakker.
ISO 27001 software ontwikkeling zonder bottleneck
In deze opzet vormen de controls geen handmatige poort meer die vóór het kritieke pad staat; ze zijn onderdeel van dat kritieke pad geworden en draaien automatisch mee. Beleid is daarmee geen stap waar je op wacht, maar iets dat bij elke commit meebeweegt.
Muhammed Akbulut
Cyber Security Expert
Stel dat het vrijdagmiddag is. Je zet een tag op een release die 24 uur eerder al is gemerged en op staging is bewezen. De pipeline doorloopt de unit-, integratie- en e2e-tests, SAST, DAST en de dependency-scan, en zet de release bij een groene uitslag live. Vraagt de auditor later om bewijs dat je secure development lifecycle werkt, dan volstaat een verwijzing naar je git-history en CI-logs; het bewijs is er al, zonder dat je een apart draaiboek hoeft te reconstrueren.
Dat is de kern van mijn punt: bij ISO 27001 software ontwikkeling vragen beleid en snelheid niet om een keuze, maar komen ze voort uit dezelfde investering. Een SDLC die goed is ingericht wordt door ISO 27001 niet vertraagd maar versterkt, en de compliance volgt uit het proces dat je toch al hanteert.
* De uitwerking van trunk-based development staat op trunkbaseddevelopment.com van Paul Hammant.
Meer weten?
Klaar om cyber security en compliance eenvoudig en toegankelijk te maken?