Security by design binnen ICT-projectgovernance in 2026

Het project lag op schema, totdat de audit één vraag stelde

De CISO van een snelgroeiend betaaltechnologiebedrijf had goed nieuws voor het bestuur. Het nieuwe platform voor klantonboarding was klaar voor lancering. Het productteam had de mobiele ervaring opgeleverd, engineering had identiteitsverificatie geïntegreerd, de juridische afdeling had de cloud- en API-providers gecontracteerd en de beheerorganisatie had het go-liveplan geoefend.

Toen stelde de interne auditor een eenvoudige vraag:

“Laat zien waar beveiliging en privacy in elke fase van het project zijn meegewogen.”

Het werd stil in de projectruimte.

Er was een penetratietestrapport, maar die test was laat uitgevoerd. Er was een cloudarchitectuurdiagram, maar geen bewijs dat gegevensstromen waren beoordeeld aan de hand van GDPR-beginselen. Er was een vragenlijst voor leveranciers-due diligence, maar die was niet gekoppeld aan het risicoregister. Er was een wijzigingsticket voor de uitrol naar productie, maar de goedkeuring vermeldde niets over impact op kritieke diensten, incidentmelding, weerbaarheidstesten, klantcommunicatie of escalatie bij een inbreuk in verband met persoonsgegevens. Er waren sprintnotities, maar beveiligingsvereisten stonden verspreid over user stories en chatberichten.

Niets was evident nalatig. Alles zag eruit als een druk, modern ICT-project. Maar voor een financiële entiteit die onder DORA valt, een SaaS-aanbieder die mogelijk binnen de reikwijdte van NIS2 valt, en een verwerkingsverantwoordelijke of verwerker onder GDPR, ging het niet langer alleen om de vraag of beveiliging aanwezig was. De vraag was of security by design aantoonbaar was.

Dat is het probleem van 2026. ICT-projecten worden niet meer alleen beoordeeld op opleversnelheid, kostenbeheersing en technische kwaliteit. Ze worden beoordeeld op governancebewijs: risicobeoordelingen, ontwerpbesluiten, leveranciers-due diligence, registraties van veilige ontwikkeling, wijzigingsgoedkeuringen, privacybesluiten, testresultaten en managementtoezicht.

ISO/IEC 27001:2022 biedt organisaties een praktische managementsysteemstructuur om dit probleem op te lossen. De norm helpt CISO’s, compliancemanagers, projectsponsors, DPO’s, architecten, inkoopteams en auditors om belangrijke ICT-projecten om te zetten in verdedigbaar bewijs voor security by design.

Waarom ICT-projectgovernance nu een regelgevingsvraagstuk rond bewijsvoering is

Een cloudmigratie, klantportaal, betaalplatform, CRM-implementatie, wijziging van identiteitsprovider, analysepipeline, API-integratie, SaaS-workflow, low-code toepassing of transitie naar een beheerde dienst kan het risicoprofiel van de organisatie wijzigen. In 2026 vinden deze wijzigingen plaats onder overlappende verplichtingen.

NIS2 is breed van toepassing op essentiële en belangrijke entiteiten in sectoren uit Annex I en Annex II, waaronder digitale infrastructuur, aanbieders van beheerde diensten, aanbieders van beheerde beveiligingsdiensten en digitale aanbieders. NIS2 Article 20 maakt bestuursorganen verantwoordelijk voor het goedkeuren van cyberbeveiligingsrisicobeheersmaatregelen en het toezicht op de uitvoering daarvan. NIS2 Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen voor risicobeheer, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving, veilige ontwikkeling, kwetsbaarhedenafhandeling, beoordeling van doeltreffendheid, cyberhygiëne, cryptografie, toegangscontrole, beheer van bedrijfsmiddelen en beveiligde communicatie.

DORA is van toepassing op financiële entiteiten en richt zich op digitale operationele weerbaarheid. DORA Article 5 legt de verantwoordelijkheid voor ICT-risicobeheer bij het bestuursorgaan. DORA Article 6 vereist een solide, omvattend en goed gedocumenteerd ICT-risicobeheerkader. DORA behandelt ook melding van ICT-gerelateerde incidenten, testen van digitale operationele weerbaarheid, ICT-bedrijfscontinuïteit, respons en herstel, het delen van informatie over cyberdreigingen, ICT-risicobeheer voor derde partijen, contractuele regelingen en toezicht op kritieke ICT-dienstverleners van derde partijen.

GDPR voegt de verantwoordingslaag voor persoonsgegevens toe. GDPR Article 25 vereist gegevensbescherming door ontwerp en door standaardinstellingen. Verwerkingsverantwoordelijken moeten kunnen aantonen dat zij beginselen naleven zoals rechtmatigheid, behoorlijkheid, transparantie, doelbinding, gegevensminimalisatie, opslagbeperking, integriteit, vertrouwelijkheid en verantwoordingsplicht. Wanneer verwerking waarschijnlijk een hoog risico oplevert, kan ook een gegevensbeschermingseffectbeoordeling onder GDPR Article 35 vereist zijn.

De rode draad is bewijsvoering. Toezichthouders en auditors vragen niet alleen of een platform versleuteld, gepatcht, gescand of getest was. Zij vragen of de organisatie kan aantonen dat beveiliging, privacy, leveranciersrisico en weerbaarheid vanaf het begin deel uitmaakten van de besluitvorming.

Daarom is ISO/IEC 27001:2022-projectgovernance zo krachtig. Hiermee kan de organisatie NIS2, DORA, GDPR, NIST CSF 2.0, contractuele verplichtingen en assurance richting klanten beheren via één herhaalbaar ISMS-proces, in plaats van via meerdere losstaande checklists.

De ISO 27001-ruggengraat voor projectgovernance

ISO/IEC 27001:2022 wordt vaak ten onrechte gezien als alleen een certificeringstraject. Voor ICT-projecten is de operationele waarde breder. De norm biedt een governance-ruggengraat voor bedrijfsverandering.

Clausules 4.1 tot en met 4.4 vereisen dat organisaties inzicht hebben in interne en externe kwesties, belanghebbenden, wettelijke, regelgevende en contractuele eisen, het ISMS-toepassingsgebied, interfaces en afhankelijkheden. In projecttermen betekent dit dat het projectcharter betrokken diensten, klanten, leveranciers, regelgeving, bedrijfsprocessen, persoonsgegevens, kritieke activiteiten en uitbestede diensten moet identificeren.

Clausules 5.1 tot en met 5.3 vereisen betrokkenheid van het leiderschap, afstemming met beleid, middelen, integratie in bedrijfsprocessen en toegewezen verantwoordelijkheden. Dit is relevant omdat zowel NIS2 als DORA cyberbeveiliging en ICT-risico onder de verantwoordelijkheid van het bestuursorgaan plaatsen. Een project dat een kritisch klantplatform wijzigt, kan niet leunen op een informele beveiligingsopmerking in een chatthread. Het vereist duidelijke verantwoordingsplicht.

Clausules 6.1.1 tot en met 6.1.3 vereisen een herhaalbaar proces voor risicobeoordeling en risicobehandeling, risicocriteria, risico-eigenaren, evaluatie van vertrouwelijkheid, integriteit en beschikbaarheid, risicobehandelingsplannen, de Verklaring van Toepasselijkheid en goedkeuring van restrisico. Hier wordt projectrisico auditbewijs.

Clausules 7.1 tot en met 7.5 vereisen middelen, competentie, bewustzijn, communicatie en beheersing van gedocumenteerde informatie. Zo worden projectregistraties betrouwbaar bewijs in plaats van verspreide artefacten.

Clausule 8.1 vereist operationele planning en beheersing, gedocumenteerde informatie waaruit blijkt dat processen volgens planning zijn uitgevoerd, beheersing van geplande wijzigingen, beoordeling van onbedoelde wijzigingen, mitigatie van nadelige effecten en beheersing van extern geleverde processen, producten of diensten die relevant zijn voor het ISMS. Clausules 8.2 en 8.3 vereisen informatiebeveiligingsrisicobeoordelingen en -behandeling op geplande intervallen of wanneer significante wijzigingen optreden.

Annex A verbindt deze managementcyclus vervolgens met praktische beheersmaatregelen. Voor security by design in ICT-projecten staan drie ISO/IEC 27001:2022 Annex A-beheersmaatregelen centraal:

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap behandelt informatiebeveiliging in projectmanagement als een governancevraagstuk voor alle projecttypen, niet alleen voor softwareontwikkeling:

“Elk project — een migratie van een marketingsysteem, een verhuizing van een gebouw, een herontwerp van een bedrijfsproces, een HR-onboardingplatform of zelfs een fusie of overname — kan impact hebben op de vertrouwelijkheid, integriteit of beschikbaarheid van informatie. Wanneer dat zo is, moet beveiliging aan tafel zitten.”

Dezelfde sectie vat de kernles voor implementatie samen:

“Het doel van deze beheersmaatregel is niet om projecten te belasten met bureaucratie. Het doel is ervoor te zorgen dat beveiliging wordt behandeld als ontwerpinput, niet als testfase.”

Dat onderscheid scheidt compliance-theater van verdedigbare security by design.

Hoe security by design eruitziet binnen een ICT-project

Security by design begint vóór de eerste sprint, inkoopaanvraag, architectuurtekening of migratiedraaiboek. Het stelt een eenvoudige vraag: wat kan dit project aan het risico veranderen?

Een praktisch model voor projectgovernance gebruikt zeven bewijspoorten.

Het gaat niet om bureaucratie. Het gaat erom beveiliging zichtbaar te maken op de plaatsen waar projectbesluiten daadwerkelijk worden genomen.

Het Clarysec Enterprise Informatiebeveiligingsbeleid formuleert dit rechtstreeks:

“Informatiebeveiligingsgovernance moet worden geïntegreerd met enterprise governance, projectmanagement, inkoop en juridisch toezicht om te waarborgen dat informatiebeveiliging niet geïsoleerd is, maar is ingebed in de volledige zakelijke besluitvorming.”

Uit de sectie “Governancevereisten”, beleidsclausule 5.5.

Het maakt projectlevenscycli ook tot een aandachtspunt voor implementatie:

“Projectlevenscycli (bijv. veilige ontwikkeling, dreigingsmodellering)”

Uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.3.1.1.

En het benoemt het auditprincipe dat veel organisaties te laat ontdekken:

“Alle geïmplementeerde beheersmaatregelen moeten auditbaar zijn, ondersteund door gedocumenteerde procedures en bewaard bewijs van de werking.”

Uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.6.1.

Met andere woorden: beveiligingswerk dat niet wordt bestuurd, bewaard en gemapt, komt vaak niet door de audit, zelfs wanneer technische teams redelijke besluiten hebben genomen.

Van dreigingsmodellering naar bewijsvoering: een praktisch fintechvoorbeeld

Neem een project voor de lancering van een nieuw EU-klantonboardingportaal voor een fintech. Het portaal verzamelt identiteitsdocumenten, voert biometrische verificatie uit via een derde partij, bewaart onboardingstatus, integreert met CRM, activeert klantmeldingen en voedt risicoscores.

Een security-by-designaanpak bouwt het bewijs op terwijl het project vordert.

Open eerst een classificatieregistratie voor projectbeveiliging. Stel vast of het project kritieke of belangrijke functies, persoonsgegevens, bijzondere categorieën persoonsgegevens, authenticatie, publieksgerichte beschikbaarheid, uitbestede ICT-diensten, gereguleerde rapportageprocessen of klantcommunicatie raakt. Onder GDPR zijn biometrische gegevens die worden gebruikt voor unieke identificatie een bijzondere categorie persoonsgegevens, tenzij een specifieke uitzondering van toepassing is. Dat verhoogt onmiddellijk het vereiste niveau van juridische analyse en waarborgen.

Maak vervolgens een projectrisicobeoordeling. Het Clarysec SME Beleid inzake risicobeheer maakt risicobeheer onderdeel van planning, niet van een kwartaalspreadsheet:

“1.2 Het waarborgt dat risicobeheer een actief onderdeel is van planning, projectuitvoering, leveranciersselectie en incidentrespons, in lijn met ISO 27001, ISO 31000 en toepasselijke regelgevende vereisten.”

Uit de sectie “Doel”, beleidsclausule 1.2.

Voor enterprise-omgevingen definieert het Clarysec Enterprise Beleid inzake risicobeheer de reikwijdte op strategisch, operationeel, project- en technisch niveau:

“Het bestrijkt informatiebeveiligingsrisico’s op strategisch, operationeel, project- en technisch niveau en is verplicht voor al het personeel, contractanten en dienstverleners die betrokken zijn bij activiteiten van het Managementsysteem voor informatiebeveiliging (ISMS).”

Uit de sectie “Reikwijdte”, beleidsclausule 2.3.

Voer ten derde een dreigingsmodel uit voordat de ontwikkeling begint. Het Enterprise Beleid inzake veilige ontwikkeling is expliciet:

“Alle nieuwe toepassingen en majeure wijzigingen moeten vóór aanvang van de ontwikkeling een beveiligingsarchitectuurbeoordeling en dreigingsmodellering ondergaan.”

Uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.

Voor het onboardingportaal moet het dreigingsmodel blootgestelde interfaces, identiteitsstromen, privilegegrenzen, API-misbruikscenario’s, webhook-spoofing, replay-aanvallen, gecompromitteerde inloggegevens, paden voor gegevenslekkage, afhankelijkheidsrisico, loggingvereisten, back-upaannames, herstelvereisten en faalmodi van aanbieders omvatten.

Werk ten vierde het privacybewijs bij. Het SME Beleid inzake gegevensbescherming en privacy stelt de baseline:

“5.3.1. Privacy by design en privacy by default moeten worden afgedwongen in alle nieuwe systemen en diensten”

Uit de sectie “Governancevereisten”, beleidsclausule 5.3.1.

De projectregistratie moet het doel, de rechtsgrondslag, de rol als verwerkingsverantwoordelijke of verwerker, besluiten over gegevensminimalisatie, bewaartermijnen, toegangsrollen, encryptiekeuzes, overwegingen over impact op betrokkenen, transparantievereisten, verwerkersvoorwaarden en meldpaden voor inbreuken in verband met persoonsgegevens omvatten.

Leg ten vijfde bewijs voor veilige ontwikkeling vast. Het SME Beleid inzake veilige ontwikkeling geeft een beknopte bewijslijst die werkt voor kleine en middelgrote teams:

“5.3 De Algemeen directeur (GM) moet registraties bijhouden van: 5.3.1 Alle actieve softwareontwikkelingsprojecten en de verantwoordelijke ontwikkelaars of leveranciers 5.3.2 Beveiligingschecklists die voor elk project zijn gebruikt 5.3.3 Uitgevoerde code reviews en de personen die deze hebben uitgevoerd 5.3.4 Testresultaten voorafgaand aan uitrol 5.3.5 Componenten van derden en hun bijbehorende licentie- of risicostatus”

Uit de sectie “Governancevereisten”, beleidsclausule 5.3.

Beheers ten zesde de uitrol als een wijziging. Het SME Wijzigingsbeheerbeleid stelt:

“1.1 Dit beleid waarborgt dat alle wijzigingen aan IT-systemen, configuraties, bedrijfsapplicaties of in de cloud gehoste diensten vóór implementatie worden gepland, op risico beoordeeld, getest en goedgekeurd.”

Uit de sectie “Doel”, beleidsclausule 1.1.

Voor het onboardingportaal moet het wijzigingsticket betrokken diensten, risicobeoordeling, testresultaten, rollbackplan, monitoringplan, beveiligingsgoedkeuringen, privacygoedkeuring, gereedheid van leveranciers, updates voor incidentescalatie en triggers voor klantcommunicatie omvatten.

Map tot slot de verplichtingen. Het SME Beleid inzake juridische en regelgevende naleving geeft de operationele regel:

“5.2.2 Wanneer regelgeving op meerdere gebieden van toepassing is (bijv. GDPR is van toepassing op bewaring, beveiliging en privacy), moet dit duidelijk worden gemapt in het Complianceregister en in trainingsmateriaal.”

Uit de sectie “Governancevereisten”, beleidsclausule 5.2.2.

Dat Complianceregister wordt de brug tussen ISO/IEC 27001:2022-beheersmaatregelen, maatregelen onder NIS2 Article 21, DORA-verplichtingen voor ICT-risico, GDPR-verantwoordingsplicht en contractuele toezeggingen aan klanten.

Eén projectbewijspakket mappen naar NIS2, DORA, GDPR en NIST CSF 2.0

De meest efficiënte compliancestrategie is niet om werk te dupliceren. Het is om één sterk bewijspakket aan meerdere verplichtingen te koppelen.

De Zenith Blueprint beveelt in de risicobeheerfase, stap 14, dit type kruisverwijzing aan:

“Voor elke regelgeving kunt u, indien van toepassing, een eenvoudige mappingtabel maken (bijvoorbeeld als bijlage bij een rapport) met de belangrijkste beveiligingsvereisten van de regelgeving en de bijbehorende beheersmaatregelen/beleidslijnen in uw ISMS.”

Het voegt daaraan toe dat dit nuttig is omdat het auditors en beoordelaars laat zien “dat u beveiliging niet in een vacuüm beheert, maar zich bewust bent van de juridische context.”

Clarysec’s Zenith Controls: The Cross-Compliance Guide ondersteunt dezelfde geïntegreerde aanpak door ISO/IEC 27001:2022-beheersmaatregelen te mappen naar andere raamwerken, auditverwachtingen en compliancebehoeften. Voor ICT-projectgovernance positioneert het A.5.8, A.8.25 en A.8.32 als preventieve beheersmaatregelen die vertrouwelijkheid, integriteit en beschikbaarheid beschermen binnen governance, applicatiebeveiliging, ecosysteem, bescherming en systeem- en netwerkbeveiliging.

Deze tabel is geen vervanging voor juridische analyse. Het is een governanceversneller. De tabel zorgt dat de CISO, DPO, projectsponsor, inkoopverantwoordelijke, systeemeigenaar en interne auditor naar hetzelfde bewijs kijken.

NIST CSF 2.0 past ook natuurlijk in dit model. De GOVERN-functie helpt organisaties beleid, rollen, risicobereidheid, toezicht en juridisch of contractueel bewustzijn vast te stellen. De functies IDENTIFY, PROTECT, DETECT, RESPOND en RECOVER helpen teams om bedrijfsmiddelen, leveranciersdiensten, toegangscontrole, gegevensbeveiliging, platformbeveiliging, veilige softwareontwikkeling, monitoring, incidentrespons en herstel in een gedeelde operationele taal te bespreken.

Eén op ISO 27001 afgestemd proces rond Annex A.5.8 kan verdedigbaar bewijs genereren voor al deze verwachtingen.

Veilige ontwikkeling is breder dan code schrijven

Veel ICT-projecten falen omdat de organisatie veilige ontwikkeling behandelt als iets dat alleen ontwikkelaars doen. In 2026 omvat veilige ontwikkeling ook SaaS-configuratie, workflowautomatisering, infrastructure as code, API-integraties, identiteitsregels, cloud landing zones, analysepipelines, robotic process automation en low-code bedrijfsapplicaties.

De Zenith Blueprint, fase Controls in Action, stap 20, behandelt ISO/IEC 27002:2022 control 8.25 Secure Development Life Cycle:

“Deze beheersmaatregel is van toepassing of u nu eigen toepassingen schrijft, platformen zoals ERP- of CRM-systemen configureert, SaaS-workflows aanpast of infrastructure-as-code-omgevingen beheert.”

Het legt ook uit dat beveiligingsvereisten naast functionele vereisten moeten staan, en dat dreigingsmodellering helpt om blootgestelde delen van het systeem, risicovolle gebruikersrollen en gegevensstromen die extra bescherming vereisen te identificeren.

Voor een modern project kan bewijs voor veilige ontwikkeling bestaan uit:

• Beveiligingsvereisten gekoppeld aan bedrijfsvereisten
• Dreigingsmodel of beveiligingsarchitectuurbeoordeling
• Checklist voor veilige programmeerpraktijken of veilige configuratie
• Registraties van code review of peer review
• Componenteninventaris en status van afhankelijkheidsrisico’s
• Besluiten over secretsmanagement
• Ontwerp voor toegangscontrole en het principe van minimale privileges
• Vereisten voor logging en monitoring
• Resultaten van kwetsbaarheidsscans en registraties van herstelmaatregelen
• Beveiligingstesten in de pre-productieomgeving
• Back-up-, herstel- en weerbaarheidstesten waar relevant
• Bewijs voor uitrolgoedkeuring en rollback

Het doel is niet om elk project door hetzelfde zware proces te dwingen. Het doel is proportionaliteit. Een kleine interne workflowwijziging vereist niet hetzelfde bewijs als een migratie van een kernbetaalplatform. Maar elk project moet worden geclassificeerd, op risico beoordeeld en bestuurd volgens de impact.

Wijzigingsbeheer beschermt het project tegen zichzelf

Het meest risicovolle moment in veel projecten is niet ontwerp of coderen. Het is de uitrol.

Een team kan dreigingsmodellering, code review, leveranciersbeoordeling en privacybeoordeling uitvoeren, en toch door een gehaaste productiewijziging een verstoring of inbreuk veroorzaken. Een debugvlag blijft ingeschakeld. Een firewallregel is ruimer dan goedgekeurd. Een migratiescript kopieert persoonsgegevens naar een niet-productieomgeving. Een webhook-endpoint van een derde partij wordt zonder authenticatie uitgerold. Een loggingwijziging legt nummers van identiteitsdocumenten vast. Een back-uptaak faalt stilzwijgend na de cutover.

De Zenith Blueprint, fase Controls in Action, stap 21, beschrijft ISO/IEC 27002:2022 control 8.32 Change Management in duidelijke termen:

“Verandering is onvermijdelijk, maar in cyberbeveiliging is ongecontroleerde verandering gevaarlijk.”

Het vervolgt:

“In de kern is effectief wijzigingsbeheer een herhaalbare workflow. Het begint met een duidelijk voorstel dat beschrijft wat er verandert, waarom, wanneer en wat de mogelijke risico’s zijn.”

Een sterke ICT-wijzigingsregistratie moet antwoord geven op:

• Welk systeem, welke dienst, gegevensstroom, leverancier of configuratie verandert?
• Welke risico’s zijn geïdentificeerd en wie is eigenaar daarvan?
• Raakt de wijziging persoonsgegevens, kritieke diensten, authenticatie, logging, back-ups of incidentrespons?
• Welke beveiligings-, privacy-, weerbaarheids- en leverancierscontroles zijn uitgevoerd?
• Welke tests zijn vóór uitrol afgerond?
• Welke monitoring bevestigt verwacht gedrag?
• Welk rollback- of herstelplan bestaat er?
• Wie heeft het restrisico goedgekeurd?
• Welk bewijs wordt bewaard?

Voor DORA ondersteunt dit gedocumenteerd ICT-risicobeheer, weerbaarheid, continuïteit, incidentclassificatie en geleerde lessen. Voor NIS2 ondersteunt het risicobeheersmaatregelen, veilige ontwikkeling, incidentpreventie en continuïteit. Voor GDPR helpt het aantonen dat wijzigingen die persoonsgegevens raken zijn beoordeeld aan de hand van de beginselen doel, minimalisatie, bewaring, toegang en beveiliging.

Leveranciers- en cloudbesluiten moeten onderdeel zijn van het projectontwerp

In moderne ICT-projecten is de ontwerpbeslissing met het hoogste risico vaak “kopen” in plaats van “bouwen”. Cloudservices, API-providers, platforms voor identiteitsverificatie, betalingsverwerkers, analyseleveranciers, aanbieders van beheerde diensten en aanbieders van beheerde beveiligingsdiensten worden onderdeel van het risicoppervlak.

NIS2 omvat expliciet beveiliging van de toeleveringsketen, kwetsbaarheden bij directe leveranciers en dienstverleners, cyberbeveiligingspraktijken van leveranciers, procedures voor veilige ontwikkeling en resultaten van gecoördineerde risicobeoordelingen van de toeleveringsketen. DORA gaat verder voor financiële entiteiten. Het vereist ICT-risicobeheer voor derde partijen als onderdeel van het ICT-risicobeheerkader, blijvende verantwoordelijkheid wanneer ICT-diensten worden uitbesteed, informatieregisters, precontractuele beoordelingen, analyse van concentratierisico, contractuele beheersmaatregelen, audit- en inspectierechten, beëindigingstriggers en geteste exitstrategieën voor kritieke of belangrijke functies.

Voor het onboardingportaal kan de aanbieder van biometrische verificatie niet worden goedgekeurd alleen omdat inkoop de prijs aantrekkelijk vindt en de API-documentatie goed is. Het project heeft bewijs nodig van beveiligings-due diligence, verwerkingsrol, gegevenslocatie, subverwerkers, beschikbaarheidsverplichtingen, ondersteuning bij incidenten, auditrechten, beëindigingsondersteuning, haalbaarheid van exit en monitoringverplichtingen.

In een volwassen bewijsmodel maken leveranciers- en cloudbesluiten deel uit van het projectbewijspakket, niet van een losstaand leveranciersdossier. Wanneer de auditor vraagt waarom een derde partij is geaccepteerd, moet het antwoord de zakelijke behoefte, risicobeoordeling, contractuele waarborgen, beoordeling van gegevensbescherming, weerbaarheidsimpact en doorlopende monitoring omvatten.

Hoe auditors bewijs voor security by design beoordelen

Verschillende auditors benaderen hetzelfde ICT-project vanuit verschillende invalshoeken. Een certificeringsauditor, interne auditor, DORA-beoordelaar, bevoegde NIS2-autoriteit, privacyauditor, NIST-georiënteerde beoordelaar of COBIT-achtige auditor kan om vergelijkbaar bewijs vragen, maar dit anders interpreteren.

Auditors willen geen fraai projectslide deck. Zij willen traceerbaarheid. Zij willen zien dat vereisten tot risico’s hebben geleid, risico’s tot beheersmaatregelen, beheersmaatregelen tot implementatiebewijs en implementatie tot beoordeling.

Daarom is Zenith Controls nuttig bij auditvoorbereiding. Het helpt teams uit te leggen waarom Annex A.5.8, A.8.25 en A.8.32 preventieve beheersmaatregelen zijn die vertrouwelijkheid, integriteit en beschikbaarheid beschermen voordat voorspelbare fouten de productieomgeving bereiken.

Het minimale Clarysec-projectbewijspakket

Een sterk bewijspakket voor security by design hoeft niet enorm te zijn. Het moet consistent, proportioneel en gemapt zijn.

Voor een ICT-project met gemiddeld risico adviseert Clarysec doorgaans het volgende minimumpakket:

1. Classificatieregistratie voor projectbeveiliging
2. Notitie over toepasselijkheid van regelgeving met NIS2, DORA waar relevant, GDPR en contractuele verplichtingen
3. Gegevensstroom- en assetimpactkaart
4. Projectrisicobeoordeling en risicobehandelingsplan
5. Dreigingsmodel of beveiligingsarchitectuurbeoordeling
6. Beoordeling van leverancier en clouddienst waar van toepassing
7. Checklist voor veilige ontwikkeling of configuratiechecklist
8. Beveiligingstestresultaten en bewijs voor herstelmaatregelen
9. Wijzigingsgoedkeuring met rollback- en monitoringplan
10. Registratie voor privacy by design, inclusief rechtsgrondslag en bewaring wanneer persoonsgegevens betrokken zijn
11. Updates voor incidentrespons en monitoring
12. Post-implementatie-evaluatie en geleerde lessen
13. Mapping in het Complianceregister naar beheersmaatregelen en verplichtingen

De Zenith Blueprint geeft de roadmaplogica. Stap 22 brengt informatiebeveiliging in alle projectfasen. Stap 20 verankert veilige ontwikkeling in planning, ontwerp, code, testen en uitrol. Stap 21 maakt wijzigingsbeheer gestructureerd, traceerbaar en beoordeelbaar. Stap 14 beveelt kruisverwijzingen aan naar GDPR, NIS2, DORA en andere verplichtingen, zodat compliance-eisen niet tussen wal en schip vallen.

De beleidslijnen geven de operationele regels. Informatiebeveiligingsbeleid integreert beveiliging met projectmanagement, inkoop en juridisch toezicht. Beleid inzake risicobeheer maakt projectrisico’s onderdeel van ISMS-activiteiten. Beleid inzake veilige ontwikkeling vereist dreigingsmodellering. Wijzigingsbeheerbeleid vereist geplande, op risico beoordeelde, geteste en goedgekeurde wijzigingen. Beleid inzake gegevensbescherming en privacy vereist privacy by design en privacy by default. Beleid inzake juridische en regelgevende naleving vereist dat regelgeving die meerdere gebieden raakt wordt gemapt in het Complianceregister.

Samen maken deze hulpmiddelen van security by design geen ambitie, maar een auditbaar operationeel model.

Veelvoorkomende faalpatronen in ICT-projecten

De fouten zijn meestal voorspelbaar.

De eerste is late betrokkenheid van beveiliging. Beveiligingsbeoordelingen vinden plaats nadat de architectuur vastligt, contracten zijn ondertekend en opleverdatums publiek zijn. Op dat moment wordt beveiliging een blokkade in plaats van ontwerpinput.

De tweede is versnipperd bewijs. Het project heeft testresultaten in de ene tool, leveranciersbeoordeling in een andere, privacyopmerkingen in e-mail, risicoacceptatie in een vergaderopname en wijzigingsgoedkeuring in een ticket. Geen enkele rode draad bewijst governance.

De derde is blinde vlekken bij leveranciers. Het project steunt op een clouddienst of API-provider, maar niemand controleert subverwerkers, gegevenslocatie, auditrechten, ondersteuning bij incidenten, exitplannen of concentratierisico.

De vierde is privacydrift. Een systeem dat voor één doel is gebouwd, gaat analyses, AI-experimenten, marketingexports of operationele monitoring ondersteunen zonder de rechtsgrondslag, transparantie, minimalisatie of bewaring opnieuw te beoordelen.

De vijfde is onbeoordeelde wijziging. Een productie-uitrol wordt goedgekeurd op functionaliteit, maar niet beoordeeld op toegang, logging, encryptie, back-up, weerbaarheid, persoonsgegevens of rapportage-impact.

De zesde is zwak managementtoezicht. Projectrisico’s met hoge impact worden op een te laag niveau geaccepteerd, zonder bewijs dat de verantwoordelijke risico-eigenaar de regelgevende gevolgen begreep.

Deze problemen worden niet opgelost door nog een scanner aan te schaffen. Ze worden opgelost door securitygovernance te integreren in de manier waarop projecten worden voorgesteld, ontworpen, ingekocht, gebouwd, getest, gewijzigd en beoordeeld.

De CISO-boodschap voor 2026

Security by design in ICT-projecten is nu een kwestie voor bestuur, audit en toezichthouders. NIS2 maakt cyberbeveiligingsrisicobeheer een verantwoordelijkheid van het bestuursorgaan. DORA maakt ICT-risico, weerbaarheidstesten, incidentbeheer en toezicht op derden tot een gestructureerde verplichting voor de financiële sector. GDPR vereist verantwoordingsplicht voor de verwerking van persoonsgegevens en passende beveiliging. ISO/IEC 27001:2022 biedt de managementsysteemstructuur om deze verplichtingen operationeel te maken.

Voor CISO’s ligt de kans in het stoppen met vechten tegen projectteams aan het einde van de oplevering. Breng beveiliging in initiatie, vereisten, ontwerp, leveranciersselectie, bouw, test, wijzigingsgoedkeuring en post-implementatie-evaluatie.

Voor compliancemanagers ligt de kans in het vervangen van versnipperd bewijs door één gemapt projectbewijspakket.

Voor auditors ligt de kans in het toetsen van de projectlevenscyclus, niet alleen het eindsysteem.

Voor bedrijfseigenaren ligt de kans in snellere en veiligere oplevering. Security by design vermindert herwerk, voorkomt complianceverrassingen, verbetert leveranciersbesluiten en geeft het leiderschap een verdedigbaar risicoverhaal.

Als uw ICT-projecten sneller bewegen dan uw bewijsmodel, begin dan met één pilotproject. Gebruik Clarysec’s Zenith Blueprint om projectbeveiligingspoorten te definiëren, pas Clarysec-beleid toe voor risicobeheer, veilige ontwikkeling, wijzigingsbeheer en privacy, en gebruik Zenith Controls om ISO/IEC 27001:2022-projectgovernance te mappen naar NIS2, DORA, GDPR en NIST CSF 2.0.

Clarysec kan u helpen een herbruikbaar projectbewijspakket voor security by design op te bouwen, dit af te stemmen op uw ISMS en het gereed te maken voor interne audit, certificeringsaudit, DORA-gereedheid, NIS2-governance en GDPR-verantwoordingsplicht.

Begin met uw volgende belangrijke ICT-project. Als het systemen, leveranciers, gegevens, toegang, weerbaarheid of klantvertrouwen verandert, verdient het security by design vanaf dag één.