Dreigingsmodellering voor ISO 27001, NIS2 en DORA

Anya, de CISO van een snelgroeiend fintechbedrijf, werd gevraagd een releaseplan goed te keuren voor een nieuw B2B-platform voor betalingsrisico’s. De raad van bestuur wilde vóór het einde van het kwartaal naar de markt. Sales had bankklanten al voorbereid. Engineering had een cloud-native architectuur geschetst met identiteitsattributen, apparaatsignalen, transactiemetadata, gedragsgerichte risicoscores, een beheerde database en een externe analyticsprovider.

Op papier leek het platform een commerciële doorbraak. Voor Anya zag het eruit als vijf compliancegesprekken die tegelijk op tafel kwamen.

Als financiële technologieaanbieder stond het bedrijf onder druk van DORA. Als aanbieder van clouddiensten en een digitaal platform moest het zijn blootstelling aan NIS2 begrijpen. Omdat het platform persoonsgegevens van EU-betrokkenen verwerkte, was GDPR van toepassing. Zakelijke klanten verwachtten ISO/IEC 27001:2022-certificering. Als de dienst onderdeel zou worden van een verbonden softwareproduct, zouden de verwachtingen uit de Cyber Resilience Act aanvullend productbewijsmateriaal voor secure-by-design vereisen.

Het ontwikkelteam stelde het gebruikelijke beveiligingsplan voor: afhankelijkheden scannen, een kwetsbaarheidsscan uitvoeren, een penetratietest plannen en de kritieke bevindingen vóór livegang verhelpen. Anya wist dat dit niet voldoende was. Deze activiteiten testen wat al is gebouwd. Ze tonen niet aan dat de architectuur secure-by-design is, dat vertrouwensgrenzen zijn begrepen, dat gegevensstromen met persoonsgegevens zijn geminimaliseerd, dat leveranciersaannames zijn beoordeeld of dat scenario’s voor verstoring van dienstverlening vóór de release zijn overwogen.

Daarom vertraagde zij de vergadering met vier vragen:

1. Waar liggen de vertrouwensgrenzen?
2. Welke misbruikscenario’s kunnen leiden tot fraude, gegevensblootstelling of verstoring van dienstverlening?
3. Welke ontwerpbeslissingen verlagen het risico voordat code wordt geschreven?
4. Welk bewijsmateriaal overtuigt beoordelaars voor ISO 27001, NIS2, DORA, CRA en GDPR over zes maanden?

Bij die vierde vraag gaat het bij veel organisaties mis. Dreigingsmodellering wordt vaak gezien als een nuttige engineeringworkshop en verdwijnt daarna in een wikipagina. In 2026 is dat onvoldoende. Voor SaaS-aanbieders, fintechbedrijven, cloudplatformen, MSP’s, MSSP’s, exploitanten van digitale infrastructuur en softwarefabrikanten is dreigingsmodellering een motor voor compliancebewijsmateriaal geworden.

Een volwassen proces voor dreigingsmodellering zet STRIDE-bevindingen, misbruikscenario’s en architectuurbeslissingen om in registraties in het risicoregister, beveiligingseisen, behandelplannen, testcases, taken voor leveranciersassurance, privacy-by-design-bewijsmateriaal en traceerbaarheid naar de Verklaring van Toepasselijkheid.

Waarom bewijsmateriaal voor secure-by-design nu belangrijk is

Moderne regelgeving convergeert rond dezelfde verwachting: organisaties moeten beveiligings- en privacyrisico’s vroegtijdig identificeren, eigenaarschap toewijzen, proportionele beheersmaatregelen implementeren en bewijsmateriaal bewaren.

ISO/IEC 27001:2022 vereist een risicogebaseerd managementsysteem voor informatiebeveiliging. Clausules 6.1.2 en 6.1.3 vereisen risicobeoordeling en risicobehandeling voor informatiebeveiliging. Clausule 8.1 vereist operationele planning en beheersing. Annex A bevat beheersmaatregelen die via de Verklaring van Toepasselijkheid moeten worden geselecteerd op basis van risico, wettelijke eisen en bedrijfsbehoeften.

NIS2 brengt hetzelfde principe naar cybersecuritygovernance. Article 20 vereist dat leidinggevende organen maatregelen voor cybersecurityrisicobeheer goedkeuren en toezicht houden op de implementatie. Article 21 vereist passende en proportionele technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, beveiliging bij verwerving, ontwikkeling en onderhoud, afhandeling van kwetsbaarheden, cyberhygiëne, encryptie, toegangsbeveiliging, beheer van bedrijfsmiddelen en MFA waar passend.

DORA past vanaf 17 januari 2025 een lens van digitale operationele weerbaarheid toe op de financiële sector. DORA vereist dat gereguleerde financiële entiteiten een solide, volledig en gedocumenteerd ICT-risicobeheerkader onderhouden, ICT-activa en afhankelijkheden identificeren, beschermende en preventieve maatregelen toepassen, afwijkende activiteit detecteren, digitale operationele weerbaarheid testen, ICT-risico’s bij derde partijen beheren en respons- en herstelcapaciteiten voorbereiden. Voor gereguleerde financiële entiteiten is DORA de sectorspecifieke Unierechtshandeling voor overlappende NIS2-verplichtingen.

GDPR voegt verantwoordingsplicht en gegevensbescherming door ontwerp en door standaardinstellingen toe. Elk systeem dat persoonsgegevens verwerkt, moet kunnen aantonen dat de verwerking rechtmatig, behoorlijk, transparant, doelgebonden, geminimaliseerd, opslagbeperkt en veilig is. Een dreigingsmodel dat gegevensstromen met persoonsgegevens, toegangspaden, logboeken, bewaartermijnen, verwijdering en doorgiften aan derden in kaart brengt, is direct relevant voor GDPR Articles 5, 25, 32 en 35.

De Cyber Resilience Act verhoogt de druk voor producten met digitale elementen. Productteams hebben levenscyclusbewijsmateriaal nodig waaruit blijkt dat cybersecurityrisico’s, voorzienbaar misbruik, interfaces, updatemechanismen, authenticatiestromen en aannames voor de afhandeling van kwetsbaarheden vroegtijdig zijn overwogen.

De les is duidelijk: als een architectuurbeoordeling niet herleidbaar is naar risico’s, beheersmaatregelen, eigenaren, mitigaties en tests, is deze in 2026 moeilijk te verdedigen in een audit of toetsing door toezichthouders.

Het Clarysec-model: één dreigingsmodel, meerdere outputs

De aanpak van Clarysec begint met een praktisch principe: een dreigingsmodel is pas compleet wanneer het auditeerbare beslissingen oplevert.

In Zenith Blueprint: een 30-stappenroadmap voor auditors [ZB] geeft de fase Risicobeheer, stap 9, teams een eenvoudig format om technische observaties om te zetten in risicotaal:

“Combineer nu bedrijfsmiddel + dreiging + kwetsbaarheid tot een beknopte beschrijving van een risicoscenario. Beschrijf in essentie het potentiële incident. Dit wordt later een regel in uw risicoregister. Gebruik een eenvoudig format: ‘[Dreiging] misbruikt [kwetsbaarheid] op [bedrijfsmiddel], met [impact] als gevolg.’”

Die zin vormt de brug tussen engineering en compliance.

Een whiteboardnotitie zoals “spoofingrisico partner-API” wordt:

“Een aanvaller misbruikt zwakke authenticatie van de partner-API op de API voor transactierisico’s, met ongeautoriseerde toegang tot beslissingen over betalingsrisico’s en blootstelling van persoonsgegevens als gevolg.”

De bevinding heeft nu een bedrijfsmiddel, dreiging, kwetsbaarheid en impact. Zij kan worden beoordeeld, toegewezen, behandeld, getest en geaccepteerd.

De beleidslaag maakt dit herhaalbaar. Het P24 Beleid inzake veilige ontwikkeling [P24] stelt:

“Alle nieuwe toepassingen en majeure wijzigingen moeten vóór de start van de ontwikkeling een beoordeling van de beveiligingsarchitectuur en dreigingsmodellering ondergaan.”
Uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.

Het beleid vereist ook:

“Ontwerpbeoordelingen moeten gegevensstroomdiagrammen, vertrouwensgrenzen en mitigerende maatregelen voor geïdentificeerde risico’s documenteren.”
Uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.2.

Deze twee clausules zijn krachtige auditankers. Ze tonen aan dat dreigingsmodellering niet optioneel is en dat ontwerpbewijsmateriaal diagrammen, grenzen en mitigatiebeslissingen moet bevatten.

Het P06 Beleid inzake risicobeheer [P06] verbindt dreigingsmodellering met organisatiebreed risicobeheer:

“Alle bedrijfseenheden moeten risico’s proactief identificeren met behulp van gestructureerde technieken afgeleid van ISO/IEC 27005:2024, waaronder dreigingsmodellering, het in kaart brengen van afhankelijkheden van bedrijfsmiddelen en scenariogebaseerde identificatie.”
Uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.

Het stelt ook:

“Geïdentificeerde risico’s moeten worden gedocumenteerd met verwijzing naar de eigenaar van het bedrijfsmiddel, de dreigingsactor, de kwetsbaarheid en de potentiële impact op vertrouwelijkheid, integriteit en beschikbaarheid (CIA).”
Uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.4.

Dit is de bewijsketen die auditors willen zien: beleidsvereiste, ontwerpactiviteit, risicoscenario, selectie van beheersmaatregelen, implementatie, testen en goedkeuring.

STRIDE maakt de dekking systematisch, misbruikscenario’s maken die realistisch

STRIDE blijft een van de nuttigste methoden voor dreigingsmodellering in de ontwerpfase, omdat het teams dwingt zes veelvoorkomende faalwijzen te beoordelen:

• Spoofing
• Manipulatie
• Ontkenning
• Openbaarmaking van informatie
• Denial-of-service
• Privilege-escalatie

Voor Anya’s platform voor betalingsrisico’s gebruikte het team STRIDE voor elke component, gegevensstroom en vertrouwensgrens.

Spoofing riep de vraag op of een partner-API-client zich kon voordoen als een bankklant wanneer wederzijdse authenticatie zwak was. Manipulatie maakte zichtbaar dat apparaatsignalen of transactiebedragen vóór ingestie konden worden aangepast. Ontkenning benadrukte de noodzaak van auditlogboeken voor beheerders en transacties. Openbaarmaking van informatie richtte zich op lekkage via logboeken, analyticsexporten, supporttools en rapportage-API’s. Denial-of-service dwong het team om piekvensters voor transacties en floods met misvormde verzoeken te beoordelen. Privilege-escalatie bracht risico’s aan het licht in supportrollen, sessietokens en beheerfuncties.

Misbruikscenario’s zetten deze categorieën om in realistische verhalen:

• Een fraudeur uploadt gemanipuleerde apparaatsignalen om een risicoscore te beïnvloeden.
• Een gecompromitteerde partnerreferentie overspoelt de API met frauduleuze verzoeken.
• Een ontwikkelaar gebruikt productiegegevens met persoonsgegevens in een testomgeving.
• Een kwaadwillende insider exporteert klantidentificatoren en scorelogica.
• Uitval bij een cloudanalyticsleverancier blokkeert risicobeslissingen tijdens een betalingsvenster.
• Een verkeerde opslagconfiguratie stelt geüploade identiteitsdocumenten bloot.
• Een verwijderingsworkflow verwijdert de applicatieregistratie, maar laat back-ups en leverancierskopieën bestaan.

Elk misbruikscenario werd een registratie van een ontwerprisico met het geraakte bedrijfsmiddel, de dreigingsactor, kwetsbaarheid, impact, bestaande aannames, vereiste mitigatie, eigenaar van het restrisico, testbewijsmateriaal en regelgevende relevantie.

Deze structuur voorkomt vage bevindingen zoals “API-beveiligingsrisico”. Zij levert risicouitspraken op die als bewijsmateriaal kunnen dienen, zoals:

“Een aanvaller gebruikt gestolen partnerreferenties om frauduleuze scoreverzoeken via de API voor transactierisico’s in te dienen, met aantasting van de integriteit van risicobeslissingen, mogelijk financieel verlies voor klanten en ongeautoriseerde verwerking van persoonsgegevens als gevolg.”

Dreigingsmodellering koppelen aan ISO/IEC 27001:2022 en ISO/IEC 27002:2022

ISO/IEC 27001:2022 vereist dreigingsmodellering niet expliciet onder die naam. De norm vereist consistente, gedocumenteerde risicobeoordeling en risicobehandeling. Dreigingsmodellering is een van de sterkste methoden om dat bewijsmateriaal te genereren in software-, cloud- en productomgevingen.

De sleutel is traceerbaarheid. In ZB adviseert de fase Risicobeheer, stap 13, om beheersmaatregelen te koppelen aan risico’s en clausules, inclusief verwijzingen naar Annex A in behandelplannen, en vast te leggen waar beheersmaatregelen GDPR, NIS2 of DORA ondersteunen.

Zenith Controls: de gids voor cross-compliance [ZC] helpt die traceerbaarheid te structureren door beheersmaatregelen uit ISO/IEC 27002:2022 te koppelen aan gerelateerde beheersmaatregelen, auditverwachtingen en externe raamwerken.

Voor dreigingsmodellering is ISO/IEC 27002:2022 beheersmaatregel 5.8, Informatiebeveiliging in projectmanagement, het anker voor projectgovernance. Deze beheersmaatregel toont aan dat beveiliging is geïntegreerd in projectinitiatie, planning, uitvoering en acceptatie.

Beheersmaatregel 8.25, Veilige ontwikkelingslevenscyclus, is het SDLC-anker. ZC verbindt 8.25 met ondersteunende beheersmaatregelen zoals 8.26 vereisten voor applicatiebeveiliging, 8.27 veilige systeemarchitectuur en engineeringprincipes, 8.28 veilig programmeren, 8.29 beveiligingstesten tijdens ontwikkeling en acceptatie, 8.30 uitbestede ontwikkeling en 8.31 scheiding van ontwikkel-, test- en productieomgevingen.

Deze mapping helpt een ontwerpworkshop om te zetten in bewijsmateriaal voor de Verklaring van Toepasselijkheid. Zij ondersteunt ook ISO/IEC 27001:2022 clausules 4 tot en met 6, omdat vereisten van belanghebbenden, het ISMS-toepassingsgebied, leiderschapscommitments en beslissingen over risicobehandeling zichtbaar zijn.

Een cross-compliancekaart voor NIS2, DORA, CRA, GDPR en NIST CSF

Een goed uitgevoerd dreigingsmodel moet geen vijf losstaande compliancewerkstromen opleveren. Het moet één bewijspakket voor ontwerprisico’s opleveren dat over raamwerken heen kan worden hergebruikt.

NIST CSF 2.0 is bijzonder nuttig voor communicatie met het topmanagement. De GOVERN-functie ondersteunt wettelijke, regelgevende, contractuele en privacyverplichtingen, terwijl de uitkomsten voor de toeleveringsketen helpen om leverancierscriticaliteit, contractuele eisen, due diligence, monitoring en incidentplanning aan hetzelfde bewijsmateriaal uit dreigingsmodellering te koppelen.

GDPR vereist bijzondere aandacht omdat dreigingsmodellering en DPIA-werk elkaar moeten versterken. Het P17 Beleid inzake gegevensbescherming en privacy [P17] stelt:

“Dreigingsmodellering en gegevensbeschermingseffectbeoordelingen (DPIA’s) zijn verplicht voor verwerkingssystemen met een hoog risico.”
Uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.3.4.

Voor kleinere teams stelt het P17S Beleid inzake gegevensbescherming en privacy - mkb [P17S]:

“Privacy by design en privacy by default moeten in alle nieuwe systemen en diensten worden afgedwongen.”
Uit de sectie “Governancevereisten”, beleidsclausule 5.3.1.

Het resultaat is een praktisch operationeel model: gebruik dezelfde gegevensstroomdiagrammen, vertrouwensgrenzen en misbruikscenario’s voor beveiligingsrisico’s, privacyrisico’s, leveranciersbeoordeling en regelgevend bewijsmateriaal.

Een ontwerprisicosprint van 90 minuten voor functies met een hoog risico

Dreigingsmodellering hoeft niet als zwaar programma te beginnen. Voor een nieuwe betalings-API, onboardingworkflow, AI-ondersteunde functie, identiteitsdienst, cloudmigratie of externe integratie kan een ontwerprisicosprint van 90 minuten waardevol bewijsmateriaal opleveren.

1. Open een beveiligingscontrolepunt voor het project

Gebruik P24 clausule 6.1.1 als trigger. Maak voor elke nieuwe toepassing of majeure wijziging een bewijsmap met:

• Architectuurdiagram
• Gegevensstroomdiagram
• Kaart van vertrouwensgrenzen
• Lijst met bedrijfsmiddelen
• Notities over persoonsgegevens
• Lijst met leveranciers- en ICT-afhankelijkheden
• Initiële beveiligingseisen
• Werkblad voor dreigingsmodellering
• Registraties in het risicoregister
• Traceerbaarheid van mitigatie en tests
• Goedkeuringsregistratie

Voor kleinere organisaties ondersteunt P24S Beleid inzake veilige ontwikkeling - mkb [P24S] dezelfde discipline door veilige ontwikkelingsprocessen te koppelen aan toegangsbeveiliging voor ontwikkelaars, testen, dreigingsmodellering en documentatie. Het beleid vereist ook centrale bewaring van checklists, beoordelingsgoedkeuringen, testrapporten en componentinventarissen voor auditdoeleinden. Clausule 11.3.1 verwijst naar SA-3 tot en met SA-15 om veilige ontwikkelingsprocessen te definiëren, waaronder dreigingsmodellering.

2. Teken de minimaal noodzakelijke gegevensstroom

Begin niet met een uitgewerkt diagram. Begin met de stromen die risico veroorzaken:

• Gebruiker uploadt identiteitsdocumenten of transactiegegevens.
• Webapplicatie stuurt verzoeken naar de API.
• API schrijft naar beheerde opslag of een database.
• Leverancier ontvangt verificatie- of analyticsgegevens.
• Intern analistenportaal toont resultaten.
• Klantsysteem haalt status of beslissingen op.
• Logboeken, monitoringtools en back-ups ontvangen kopieën.

Markeer elke vertrouwensgrens: internet naar applicatie, applicatie naar API, interne dienst naar leverancier, productiesysteem naar analytics, beheerder naar geprivilegieerde functie en productie naar niet-productieomgeving.

3. Voer STRIDE en misbruikscenario’s samen uit

Stel voor elke grens de STRIDE-vragen en schrijf misbruikscenario’s in duidelijke bedrijfstaal. Het doel is niet om elke denkbare aanval op te sommen. Het doel is om plausibele, wezenlijke scenario’s te identificeren die vertrouwelijkheid, integriteit, beschikbaarheid, privacy, weerbaarheid of veiligheid raken.

4. Zet bevindingen om in risicoscenario’s

Gebruik de formule uit ZB stap 9:

“[Dreiging] misbruikt [kwetsbaarheid] op [bedrijfsmiddel], met [impact] als gevolg.”

Bijvoorbeeld:

“Een aanvaller misbruikt zwakke toegangsbeveiliging op objectopslag in de repository voor identiteitsdocumenten, met ongeautoriseerde openbaarmaking van persoonsgegevens en blootstelling aan meldplichten richting toezichthouders als gevolg.”

Voeg daarna eigenaar, waarschijnlijkheid, impact, inherent risico, behandeloptie, doelbeheersmaatregel, restrisico en bewijsmateriaal toe.

5. Leid vereisten en tests af

Een dreigingsmodel is niet klaar wanneer risico’s zijn opgesomd. Het is klaar wanneer mitigerende maatregelen zijn geïmplementeerd, getest of formeel geaccepteerd.

Het Wijzigingsbeheerbeleid - mkb geeft een praktische trigger:

“Als een wijziging betrekking heeft op gevoelige gegevens, toegangsrechten tot systemen of externe integraties, is een beoordeling van de beveiligingsimpact vereist. De aangewezen beveiligings- of compliancecontactpersoon moet beoordelen of de wijziging aanvullende risico’s introduceert en aanvullende waarborgen aanbevelen.”
Uit de sectie “Risicobehandeling en uitzonderingen”, beleidsclausule 7.5.1.

Gevoelige gegevens, toegangsrechten en externe integraties zijn precies de wijzigingen die een beoordeling van ontwerprisico’s vereisen.

Wat verschillende auditors zullen vragen

Een ISO/IEC 27001:2022-auditor zal vragen of dreigingsmodellering onderdeel is van een gedefinieerd risicobeoordelingsproces, of criteria consistent worden toegepast, of risico-eigenaren restrisico’s hebben goedgekeurd, of behandelplannen aan de SoA zijn gekoppeld en of bewijsmateriaal wordt bewaard. De auditor zal letten op herhaalbaarheid, versiehistorie, zichtbaarheid in directiebeoordelingen en dekking door interne audits.

Voor Annex A zal de auditor uw bewijsmateriaal koppelen aan 5.8, 8.25, 8.26, 8.27 en 8.29. ZB stap 21, Beheersmaatregelen in de praktijk, benadrukt veilige systeemarchitectuur en engineeringprincipes door te vragen welke principes de veilige architectuur sturen. Auditors kunnen vragen of dreigingsmodellering tijdens het ontwerp wordt uitgevoerd met methoden zoals STRIDE of aanvalsbomen, en of architectuurbeslissingen vóór implementatie worden beoordeeld.

Een NIS2-beoordelaar zal zich richten op governance en proportionaliteit. De beoordelaar kan vragen of het management de aanpak voor cybersecurityrisicobeheer heeft goedgekeurd, of veilige verwerving, ontwikkeling en onderhoud zijn afgedekt, of leverancierskwetsbaarheden zijn meegenomen, of incidentscenario’s aan meldingsworkflows zijn gekoppeld en of continuïteitsscenario’s zijn geanalyseerd. NIS2 Article 23 gefaseerde rapportage voor significante incidenten, waaronder een vroegtijdige waarschuwing binnen 24 uur, melding binnen 72 uur en een eindrapport binnen één maand, maakt duidelijke scenario’s bijzonder waardevol.

Een DORA-examinator zal zich richten op ICT-risicogovernance, kritieke functies, ICT-activa, externe afhankelijkheden, weerbaarheidstesten en ICT-diensten van derden. Als het systeem een kritieke of belangrijke functie ondersteunt, wordt sterker bewijsmateriaal verwacht dat dreigingsscenario’s koppelt aan inventarissen van bedrijfsmiddelen, afhankelijkheidskaarten, testplannen, contracten met derden en herstelmaatregelen.

Een privacybeoordelaar zal gegevensstromen inspecteren en vragen of verwerking van persoonsgegevens noodzakelijk, rechtmatig, geminimaliseerd en beschermd is. De beoordelaar zal vragen of bijzondere categorieën persoonsgegevens zijn betrokken, of pseudonimisering of encryptie wordt gebruikt, of bewaartermijnen zijn gerechtvaardigd en of een DPIA vereist is. Dreigingsmodellering en DPIA’s zijn verschillende activiteiten, maar ze moeten diagrammen, scenario’s en mitigerende maatregelen delen.

Een beoordelaar die op NIST CSF of COBIT 2019 is georiënteerd, zal kijken naar governance, proceseigenaarschap, prestaties, verantwoordingsplicht en voortdurende verbetering. Het STRIDE-werkblad zelf is mogelijk minder belangrijk dan de vraag of het proces betrouwbaar, meetbaar, goedgekeurd en verbeterd is.

Veelvoorkomende tekortkomingen in bewijsmateriaal voor dreigingsmodellering

De meest voorkomende tekortkomingen zijn niet technisch van aard. Het zijn tekortkomingen in bewijsmateriaal.

Teams voeren dreigingsmodellering te laat uit, nadat het systeem al is gebouwd. Op dat moment wordt de workshop een briefing vóór een penetratietest in plaats van een ontwerpbeheersmaatregel.

Bevindingen worden niet omgezet in risicotaal. “Auth toevoegen” of “loggingprobleem” kan engineers helpen, maar auditors hebben bedrijfsmiddel, dreiging, kwetsbaarheid, impact, eigenaar, behandeling en restrisico nodig.

Privacy en beveiliging worden gescheiden. Het ene team documenteert spoofing- en injectierisico’s, terwijl een ander team bewaartermijnen en rechtsgrondslag documenteert. GDPR-verantwoordingsplicht werkt beter wanneer gegevensstromen, misbruikscenario’s en DPIA-triggers met elkaar zijn verbonden.

Leveranciersaannames blijven ongedocumenteerd. NIS2, DORA en NIST CSF verhogen allemaal de verwachtingen voor ICT-risico’s in de toeleveringsketen. Als een mitigatie afhankelijk is van encryptie, logging, verwijdering, weerbaarheid of incidentrespons van een leverancier, verzamel dan het bewijsmateriaal.

Tests worden niet teruggekoppeld naar dreigingen. Een penetratietestrapport kan nuttig zijn, maar toont mogelijk niet aan dat de specifieke ontwerprisico’s zijn gemitigeerd. Elke belangrijke dreigingsbevinding moet validatiebewijsmateriaal hebben.

Acceptatie van restrisico is informeel. “We accepteren dit voor MVP” is niet genoeg. ISO/IEC 27001:2022 verwacht acceptatie van restrisico door passende risico-eigenaren als gedocumenteerde informatie.

Uw bewijspakket voor dreigingsmodellering in 2026

Bewaar voor elk belangrijk systeem of elke significante wijziging een standaard bewijspakket dat ISO 27001, NIS2, DORA, CRA, GDPR en klantassurance kan ondersteunen.

Het Beleid inzake risicobeheer - mkb vat het operationele model goed samen:

“Het waarborgt dat risicobeheer een actief onderdeel is van planning, projectuitvoering, leveranciersselectie en incidentrespons, in overeenstemming met ISO 27001, ISO 31000 en toepasselijke regelgevende vereisten.”
Uit de sectie “Doel”, beleidsclausule 1.2.

Dat is het juiste doel. Dreigingsmodellering moet invloed hebben op planning, engineering, leveranciersselectie, incidentrespons en het vermogen om bij audits naleving aan te tonen.

Maak dreigingsmodellering auditgereed vóór uw volgende release

De organisaties die de compliancedruk van 2026 het best aankunnen, zijn niet de organisaties met de meeste diagrammen. Het zijn de organisaties die een eenvoudige keten kunnen aantonen:

Ontwerprisico is geïdentificeerd. Risico is beoordeeld. Beheersmaatregelen zijn geselecteerd. Mitigerende maatregelen zijn geïmplementeerd. Tests hebben de mitigerende maatregelen gevalideerd. Restrisico is goedgekeurd. Bewijsmateriaal is gekoppeld aan de relevante raamwerken.

Begin met één wijziging met een hoog risico: een betalingsintegratie, nieuwe API, AI-ondersteunde workflow, identiteitsfunctie, cloudmigratie, klantgerichte productrelease of dienst die met een leverancier is verbonden. Voer een ontwerprisicosprint van 90 minuten uit. Gebruik ZB om bevindingen om te zetten in risicoscenario’s, behandelplannen en SoA-traceerbaarheid. Gebruik ZC om ISO/IEC 27002:2022-beheersmaatregelen zoals 5.8, 8.25, 8.26, 8.27 en 8.29 te koppelen aan ondersteunende beheersmaatregelen, leveranciersrisico, privacy, testen en auditbewijsmateriaal. Stem P24, P06, P17, P24S en uw wijzigingsbeheerprocedure op elkaar af, zodat dreigingsmodellering verplicht, herhaalbaar en beoordeelbaar wordt.

Als u wilt dat Clarysec helpt, begin dan met een beoordeling van bewijsmateriaal voor dreigingsmodellering. Wij beoordelen één echt project, identificeren hiaten ten opzichte van de verwachtingen van ISO/IEC 27001:2022, NIS2, DORA, CRA en GDPR en geven u een praktische remediatieroadmap die uw engineers, auditors en raad van bestuur allemaal kunnen begrijpen.