Deze SDLC-beveiligingschecklist koppelt beheersmaatregelen voor softwareontwikkeling clausule voor clausule aan ISO/IEC 27001:2022 Bijlage A — specifiek het cluster A.8.25–A.8.34 en aanverwante beheersmaatregelen — zodat compliance officers, IT-managers en beveiligingsverantwoordelijken de toepasselijke beheersmaatregelen kunnen vastleggen in hun Verklaring van Toepasselijkheid, auditeerbaar bewijs kunnen verzamelen en de implementatiewerkzaamheden met vertrouwen kunnen begroten. Lees verder voor taken per clausule, voorbeelden van bewijs en planningslinks naar Ismscalculator.
Wat u met deze checklist krijgt:
- Clausule-voor-clausule koppeling van SDLC-beheersmaatregelen aan ISO 27001 Bijlage A (A.8.25–A.8.34, A.5.23, A.8.8, A.8.9)
- Concrete checklisttaken met minimale bewijsvereisten en eigenaarschapsrollen
- Rode vlaggen voor audits en snelle interne controles vóór Stage 2
- Inspanningsbanden en een voorbeeldganttplanning voor budgettering
- Links naar Ismscalculator-tools voor op maat gemaakte kosten- en tijdlijnschattingen
Inhoudsopgave
- Wat dekt de SDLC-beveiligingschecklist onder ISO 27001?
- Hoe verzamelt en presenteert u bewijs voor elk checklistitem?
- Wie is waarvoor verantwoordelijk? Governance voor SDLC-beheersmaatregelen binnen het ISMS
- Hoe lang duurt de implementatie van SDLC-beheersmaatregelen en wat kost het?
- Waar vindt u een checklistsjabloon en hoe past u het aan voor uw organisatie?
- Belangrijkste conclusies
- Het onderdeel waar de meeste teams de fout ingaan bij SDLC-beheersmaatregelen
- Ismscalculator zet deze checklist om in een budget en een projectplan
- Nuttige bronnen en verder lezen
Wat dekt de SDLC-beveiligingschecklist onder ISO 27001?
ISO/IEC 27001:2022 heeft Bijlage A gereorganiseerd en applicatiebeveiliging expliciet gemaakt. De herziening van 2022 heeft beheersmaatregelen geconsolideerd en nieuwe ingevoerd die de volledige levenscyclus van softwareontwikkeling beslaan; de overgang naar de baseline van 2022 werd op 31 oktober 2025 voltooid. Tien beheersmaatregelen in het technologische thema (A.8.25 t/m A.8.34) plus A.5.23, A.8.9 en A.8.16 vormen een AppSec-cluster van 13 beheersmaatregelen dat auditors doorgaans doorlopen tijdens Stage 2-audits.
De onderstaande tabel koppelt elke primaire clausule aan checklisttaken, minimaal bewijs en een voorgestelde eigenaar.
| ISO-clausule | Checklisttaak | Minimaal bewijs | Eigenaar |
|---|---|---|---|
| Veilige ontwikkelingslevenscyclus | Regels voor planning, ontwerp, codering, testen, uitrol en onderhoud documenteren en toepassen | Beleid voor veilige ontwikkeling, ondertekend door ISMS-eigenaar; proceduredocument met versiehistorie | ISMS-manager / Product Owner |
| Beveiligingsvereisten voor applicaties | Beveiligingsvereisten definiëren en documenteren vóór aanvang van de ontwikkeling | Vereistenspecificatie met beveiligingsacceptatiecriteria; bedreigingsmodel of risicoregistervermeldingen | Product Owner / Security Engineer |
| Veilige systeemarchitectuur en -engineering | Veilige ontwerpprincipes toepassen (least privilege, defense in depth, fail-safe defaults) | Architectuurreviewing; ontwerpautorisatie met goedkeuring van security engineer | Security Engineer / Dev Lead |
| Veilig coderen | Een veilige coderingsstandaard adopteren en handhaven (bijv. OWASP ASVS, SEI CERT) | Document met veilige coderingsstandaard; SAST-scanresultaten gekoppeld aan commits; code-reviewrecords | Dev Lead |
| Beveiligingstesten in de ontwikkeling | Beveiligingstesten integreren in de ontwikkelingspipeline | SAST/DAST-scanrapporten gekoppeld aan build-ID's; testplan met beveiligingstestcases; geslaagd/gezakt-records | QA Lead / DevOps Lead |
| Uitbestede ontwikkeling | Beveiligingsvereisten toepassen op code van derden en uitbestede code | Beveiligingsclausules in leverancierscontracten; bewijs van code-review of SAST-resultaten van de leverancier | Leverancierseigenaar / ISMS-manager |
| Scheiding van ontwikkel-, test- en productieomgevingen | Omgevingsisolatie afdwingen; gebruik van productiegegevens in testomgevingen verbieden | Omgevingstopologiediagram; toegangscontrolelogboeken; anonimiseringsrecords van testgegevens | DevOps Lead |
| Wijzigingsbeheer | Wijzigingen aan systemen via een formeel proces beheersen | Wijzigingsverzoekrecords met goedkeuringen; pipelinegoedkeuringspoortlogboeken; rollback-procedures | Dev Lead / Wijzigingsbeheerder |
| Testinformatie | Testgegevens beschermen; gebruik van echte persoonsgegevens bij testen vermijden | Testgegevensbeleid; records van anonimisering of synthetische gegevensgeneratie | QA Lead / Functionaris voor gegevensbescherming |
| Bescherming van informatiesystemen tijdens audittests | Toegang tijdens audit- of penetratietesten beperken en registreren | Scopeovereenkomst voor penetratietest; toegangslogboeken tijdens testvenster; bevindingsrapport met remediatie | ISMS-manager / Security Engineer |
| Informatiebeveiliging voor clouddiensten | Beveiligingsvereisten toepassen op in de cloud gehoste ontwikkelomgevingen | Clouddienstverlenerovereenkomst met beveiligingsclausules; matrix voor gedeelde verantwoordelijkheid | ISMS-manager / Leverancierseigenaar |
| Beheer van technische kwetsbaarheden | Een kwetsbaarheidsbeheersproces onderhouden dat SDLC-resultaten omvat | Kwetsbaarhedentriagelogboek met datums en ernstgraad; SBOM-records; remediatietickets met SLA-bewaking | Security Engineer |
| Configuratiebeheer | Veilige configuraties beheren voor ontwikkeltools en -infrastructuur | Configuratiebasisdocumenten; IaC-sjablonen met versiebeheer; drift-detectielogboeken | DevOps Lead |
Het AppSec-beheersmaatrregelencluster vereist een gedocumenteerde procedure, een benoemde eigenaar en een steekproef van bewijs over ten minste één auditperiode (doorgaans 3–12 maanden). Beheersmaatregelen A.8.25, A.8.26, A.8.27 en A.8.28 hebben verschillende doeleinden en moeten expliciet worden behandeld, ook als ze worden geïmplementeerd via één enkel proceduuredocument.
Minimaal bewijs dat auditors doorgaans accepteren:
- Git-gekoppelde SAST-resultaten met bevinding, commit-hash en remediatiedatum
- SBOM-records per release gegenereerd met tijdstempels
- Pipelinegoedkeuringspoortlogboeken waaruit verplichte voltooiing van de beveiligingsfase blijkt
- Omgevingsisolatielogboeken of toegangscontrolerecords
- Kwetsbaarhedentriagetickets met ernstgraad, openingsdatum en sluitingsdatum
Hoe verzamelt en presenteert u bewijs voor elk checklistitem?
Auditors richten zich op traceerbaarheid: een benoemde beheersmaatregel, een bewijsstuk en een datum. Abstracte procesbeschrijvingen zijn onvoldoende. Elk checklistitem moet 3–5 reproduceerbare artefacten opleveren.
Beleid voor veilige ontwikkeling: Het beleidsdocument heeft een naam van een eigenaar, een goedkeuringsdatum, een versienummer en een herzieningsdatum nodig. Sla het op in uw documentbeheersysteem met een versiehistorie. De bestandsnaamconventie SDev-Policy-v1.2-2025-09-01.pdf geeft een auditor datum en versie in één oogopslag.
Omgevingsscheiding: Een topologiediagram alleen is niet voldoende. Combineer het met toegangscontrolelogboeken waaruit blijkt dat er geen ontwikkelaarsaccounts in productie zijn, en een gedateerd record van eventuele uitzonderingen met een ondertekende risicoaanvaarding. CI/CD-pipelines moeten verplichte beveiligingstestfasen, goedkeuringspoorten en onveranderlijke audittrails afdwingen om aan de A.14-subbeheersmaatregelen te voldoen; die pipelinelogboeken fungeren als het onveranderlijke record.
Kwetsbaarhedentriagerecords (A.8.8): Een spreadsheet zonder datums is een rode vlag. Gebruik uw ticketingsysteem (Jira, Linear of gelijkwaardig) zodat elke bevinding een aanmaakaanpassing, ernstgraad, verantwoordelijke en sluitingsdatum heeft. Exporteer een gefilterde weergave over de auditperiode als uw bewijsartefact.
| Artefact | Vereiste metadata | Opslaglocatie | Verificatiemethode auditor |
|---|---|---|---|
| Beleid voor veilige ontwikkeling | Eigenaar, versie, goedkeuringsdatum, herzieningsdatum | Documentbeheersysteem (versiebeheerd) | Versiehistorie controleren; bevoegdheid ondertekenaar bevestigen |
| SAST-scanrapport | Build-ID, commit-hash, toolnaam, scandatum, aantal bevindingen | CI/CD-artefactopslag (onveranderlijk) | Commit-hash kruislings verifiëren in bronbeheer |
| SBOM-bestand | Releaseversie, generatiedatum, toolnaam, componentenlijst | Artefactregister of beveiligde bestandsopslag | Controleren of generatiedatum overeenkomt met releasedatum |
| Kwetsbaarhedentriagelogboek | Bevindingsnummer, ernstgraad, openingsdatum, verantwoordelijke, sluitingsdatum | Issuetracker (Jira, Linear, enz.) | Filteren op auditperiode; SLA-naleving controleren |
| Omgevingstoegangslogboek | Gebruiker, actie, tijdstempel, omgevingsnaam | SIEM of cloudtoegangslogboekdienst | Bevestigen dat er geen omgevingsoverschrijdende toegang zonder goedkeuring is |
Pro Tip: Auditors vragen steeds vaker om git-gekoppeld bewijs in plaats van periodieke rapporten. Configureer uw CI/CD-pipeline om het SAST-rapport als build-artefact toe te voegen met de commit-SHA opgenomen in de bestandsnaam. Die ene stap elimineert de meest voorkomende betwisting van bewijsauthenticiteit.
Wie is waarvoor verantwoordelijk? Governance voor SDLC-beheersmaatregelen binnen het ISMS
Duidelijke verantwoording is wat een functionerend ISMS onderscheidt van een compliance-exercise. Het onderstaande governancemodel wijst rollen toe over de zes functies die auditors verwachten te zien.
| Beheersmaatrregelengebied | ISMS-eigenaar | Beheersmaatregeleneigenaar | Dev Lead | Security Engineer | QA Lead | Leverancierseigenaar |
|---|---|---|---|---|---|---|
| Beleid voor veilige ontwikkeling | A (Goedkeuren) | R (Verantwoordelijk) | C (Geconsulteerd) | C | I (Geïnformeerd) | I |
| Beveiligingsvereisten | I | C | R | C | C | C |
| Veilige architectuur | I | C | C | R | I | I |
| Veilige coderingsstandaard | I | C | R | R | C | C |
| Beveiligingstesten | I | C | C | C | R | I |
| Uitbestede ontwikkeling | A | R | I | C | I | R |
| Omgevingsscheiding | I | C | R | C | I | I |
| Kwetsbaarheidsbeheer | I | R | C | R | C | C |
Vereiste goedkeuringen van leidinggevenden omvatten: initiële beleidsgoedkeuring door de ISMS-eigenaar, ondertekening van de Verklaring van Toepasselijkheid ter bevestiging van de toepasselijkheid en rechtvaardiging van elke beheersmaatregel, en een jaarlijkse directiebeoordeling met steekproeven uit de voorgaande periode. De steekproeffrequentie voor bewijs moet minimaal driemaandelijks zijn voor hoogrisicobeheersmaatregelen (A.8.28, A.8.29, A.8.8) en halfjaarlijks voor beheersmaatregelen met een lager risico.
Hoe lang duurt de implementatie van SDLC-beheersmaatregelen en wat kost het?
De benodigde inspanning varieert naar gelang de volwassenheid. De onderstaande tabel geeft realistische bandbreedtes voor een organisatie die SDLC-beheersmaatregelen implementeert als onderdeel van een breder ISO 27001-project.
| Volwassenheidsband | Fase | Typische doorlooptijd | Resourceprofiel |
|---|---|---|---|
| Minimaal (ad-hocprocessen, geen formeel SDLC-beleid) | Beleidsontwikkeling en VvT-mapping | 3–4 weken | — |
| Minimaal | Toolingopzet (SAST, SBOM, pipelinepoorten) | 4–6 weken | 1 FTE DevOps + — |
| Matig (enige beleidsvorming aanwezig, inconsistent bewijs) | Klachtenremediatie en bewijsverzameling | 4–6 weken | — |
| Matig | Interne audit en pre-auditreview | 2–3 weken | 0,5 FTE ISMS-manager |
| Volledig (volwassen DevSecOps, gedocumenteerde beheersmaatregelen) | Bewijsverpakking en afronden Verklaring van Toepasselijkheid | 2–3 weken | 0,25 FTE ISMS-manager + 0,25 FTE Dev Lead |
Een voorbeeldganttplanning voor de SDLC-werkstroom in een organisatie met matige volwassenheid: weken 1–3 voor het opstellen van beleid en procedures; weken 4–8 voor toolingintegratie en configuratie van pipelinepoorten; weken 9–12 voor bewijsverzameling over een steekproefauditperiode; weken 13–14 voor interne bewijsaudit en klachtenafhandeling; week 15 voor update van de Verklaring van Toepasselijkheid en auditvoorbereiding.
Pro Tip: Voer de Ismscalculator 2-minuten gereedheidscheck uit voordat u zich aan een tijdlijn verbindt. Het brengt uw huidige volwassenheid in kaart over alle vier de ISO/IEC 27001:2022-beheersmaatregelenthema's en geeft aan welke SDLC-beheersmaatregelen de meeste inspanning vergen, zodat u de juiste werkzaamheden als eerste kunt aanpakken.
De volledige gereedheidsassessment zet die inspanningsbanden om in een op maat gemaakte kostenraming en een downloadbare ganttplanning — precies wat u nodig hebt voor een budgetgoedkeuringsgesprek.
Waar vindt u een checklistsjabloon en hoe past u het aan voor uw organisatie?
Een praktisch checklistsjabloon voor deze beheersmaatregelenset moet de volgende kolommen bevatten: ISO-clausule, checklisttaak, type bewijsartefact, bestandsnaamconventie voor artefacten, eigenaarrol, huidige status (Niet gestart / In uitvoering / Voltooid) en een link naar het voorbeeldartefact.
Aanpassingsstappen per organisatietype:
- SaaS- en techbedrijven: Voeg een kolom toe voor de CI/CD-pipelinefase waarin elke beheersmaatregel wordt afgedwongen. De gids ISO 27001 voor SaaS- en techbedrijven bevat SDLC-specifieke sjablonen en implementatienotities die hier direct van toepassing zijn.
- Gereguleerde sectoren (financiën, gezondheidszorg): Kruis elke SDLC-beheersmaatregel aan met de specifieke vereisten van uw sector (SOC 2, HIPAA, PCI DSS). De vergelijking van financiële gegevensbeveiligingsstandaarden koppelt ISO 27001-beheersmaatregelen aan financiële regelgeving.
Pro Tip: Bewaar uw checklist in een versiebeheerd document (Confluence, Notion of een in Git gehost markdownbestand). Elke statuswijziging wordt automatisch een gedateerde audittrail en u kunt een momentopname exporteren voor de auditor zonder een apart bewijspakket te hoeven samenstellen.
Beleidsraamwerken, voorbeeld-SBOM-sjablonen en testplanfragmenten zijn beschikbaar via de ISO 27001 Bijlage A-beheersmaatregelengids van Ismscalculator, die elke beheersmaatregel koppelt aan praktische bewijsitems.
Belangrijkste conclusies
Een auditeerbare SDLC-beveiligingschecklist vereist een benoemde eigenaar, een gedateerd artefact en een traceerbare koppeling tussen elke ISO 27001 Bijlage A-beheersmaatregel en het bijbehorende bewijs vóór aanvang van Stage 2.
| Punt | Details |
|---|---|
| Elke SDLC-beheersmaatregel expliciet in kaart brengen | Vermeld A.8.25–A.8.34, A.5.23, A.8.8 en A.8.9 afzonderlijk in uw Verklaring van Toepasselijkheid met een procedure en bewijs voor elk. |
| Bewijs koppelen aan builds en commits | Voeg SAST-rapporten en SBOM's toe aan build-ID's en commit-hashes zodat auditors de authenticiteit kunnen verifiëren. |
| Benoemde eigenaren toewijzen, geen teams | Elke procedure en elk checklistitem heeft een specifieke roltitel als eigenaar nodig, niet "het ontwikkelteam". |
| Eerst een interne tracetest uitvoeren | Neem een willekeurige build en volg deze door SAST, goedkeuringspoort, SBOM en triagerecords vóór Stage 2. |
| Ismscalculator gebruiken voor inspanningsplanning | De gereedheidscheck en het volledige assessment zetten SDLC-beheersmaatrregelenhiaten om in een gebudgetteerde tijdlijn en ganttexport. |
Het onderdeel waar de meeste teams de fout ingaan bij SDLC-beheersmaatregelen
De meeste organisaties besteden hun eerste twee maanden aan het schrijven van beleid en vrijwel niets aan bewijsinfrastructuur. Dat is de verkeerde volgorde. Een verzorgd beleid voor veilige ontwikkeling zonder pipelinegekoppelde SAST-resultaten of gedateerde SBOM's levert een grote afwijking op bij Stage 2, ongeacht hoe goed het document geschreven is.
De beheersmaatregelen waar teams het vaakst struikelen, zijn niet de complexe. A.8.31 (omgevingsscheiding) en A.8.8 (kwetsbaarheidsbeheer) falen voortdurend bij audits — niet omdat de beheersmaatregelen moeilijk te implementeren zijn, maar omdat het bewijs verspreid of ongedateerd is. Herstel de bewijsketen voordat u de beleidsformulering verfijnt.
Eén praktische prioriteit: automatiseer SBOM-generatie op het moment van release, niet als een handmatige kwartaalstaak. Een gedateerde SBOM per release, opgeslagen bij het releaseartefact, voldoet aan de bewijsvereisten van A.8.8 en geeft u een afhankelijkheidsaudittrail die meerdere beheersmaatregelen tegelijkertijd dekt. Die ene pipelinestap levert winst op voor ten minste vier checklistitems.
Ismscalculator zet deze checklist om in een budget en een projectplan
SDLC-beheersmaatregelen koppelen aan ISO 27001 is één ding. Weten wat het uw organisatie zal kosten en hoe lang het zal duren, is wat een project goedgekeurd krijgt.
Ismscalculator neemt uw bedrijfsomvang, sector en huidige beveiligingsvolwassenheid en produceert een op maat gemaakte kosten- en inspanningsraming voor uw volledige ISO 27001-implementatie, inclusief de SDLC-beheersmaatrregelenwerkstroom. Het platform dekt alle vier de ISO/IEC 27001:2022-beheersmaatregelenthema's, genereert een aanpasbare ganttplanning die u met stakeholders kunt delen en exporteert een pdf-rapport dat is opgebouwd voor gesprekken over budgetgoedkeuring. De 2-minuten gereedheidscheck geeft u kosteloos een directe momentopname van uw volwassenheid. Wanneer u klaar bent voor meer diepgang, zet het volledige ISO 27001 gereedheidsassessment uw checklisthiaten om in een gefaseerd projectplan met referentiemodelvergelijkingen, zodat u precies weet waar u staat ten opzichte van het referentiemodel.
Nuttige bronnen en verder lezen
De onderstaande bronnen ondersteunen specifieke secties van deze checklist. Gebruik ze om clausuleteksten te verifiëren, verwachtingen van auditors te beoordelen en de checklist aan te passen voor uw omgeving.
- ISO 27001 Application Security: Annex A Controls Guide (2022)
- ISO 27001 Application Security: Full Control Mapping
- ISO 27001 Secure SDLC: Key Requirements, Steps, and Templates (2026) | Konfirmity
- ISO 27001 A.14 Deep Dive — System Development and Maintenance in CI/CD - Regulated DevSecOps
- ICT Institute | ISO 27001 technological controls for software development
- Gratis ISO 27001 gereedheidscheck — 2-minuten zelfassessment | ISMS Calculator
- ISO 27001 voor SaaS- en techbedrijven: een praktische gids | ISMS Calculator