Trusselsmodellering for ISO 27001, NIS2 og DORA

Anya, CISO i en hurtigt voksende fintech-virksomhed, blev bedt om at godkende en lanceringsplan for en ny B2B-platform til betalingsrisiko. Bestyrelsen ønskede markedsintroduktion inden kvartalets udgang. Salg havde allerede forberedt bankkunder. Udviklingsteamet havde skitseret en cloud-native arkitektur med identitetsattributter, enhedssignaler, transaktionsmetadata, adfærdsbaserede risikoscorer, en administreret database og en tredjepartsleverandør af analyse.

På papiret lignede platformen et kommercielt gennembrud. For Anya lignede den fem efterlevelsesdialoger, der ramte på én gang.

Som udbyder af finansiel teknologi var virksomheden under pres fra DORA. Som udbyder af cloudtjenester og digitale platforme skulle den forstå sin NIS2-eksponering. Fordi platformen behandlede personoplysninger om personer i EU, fandt GDPR anvendelse. Storkunder forventede ISO/IEC 27001:2022-certificering. Hvis tjenesten blev en del af et forbundet softwareprodukt, ville forventningerne i Cyber Resilience Act til produktdokumentation for sikkerhed gennem design også komme i spil.

Udviklingsteamet foreslog den sædvanlige sikkerhedsplan: scan afhængigheder, gennemfør en sårbarhedsscanning, planlæg en penetrationstest, og udbedr de kritiske fund før idriftsættelse i produktionsmiljøet. Anya vidste, at det ikke var tilstrækkeligt. Disse aktiviteter tester det, der allerede er bygget. De dokumenterer ikke, at arkitekturen er designet sikkert, at tillidsgrænser er forstået, at flows med personoplysninger er minimeret, at leverandørantagelser er gennemgået, eller at scenarier for driftsafbrydelser er vurderet før lancering.

Derfor bremsede hun mødet med fire spørgsmål:

1. Hvor er tillidsgrænserne?
2. Hvilke misbrugsscenarier kan føre til svig, dataeksponering eller driftsafbrydelser?
3. Hvilke designbeslutninger reducerer risikoen, før der skrives kode?
4. Hvilket bevismateriale vil tilfredsstille reviewere af ISO 27001, NIS2, DORA, CRA og GDPR om seks måneder?

Det fjerde spørgsmål er der, hvor mange organisationer fejler. Trusselsmodellering behandles ofte som en nyttig workshop for udviklingsteamet og begraves derefter på en wiki-side. I 2026 er det ikke nok. For SaaS-udbydere, fintech-virksomheder, cloudplatforme, MSP’er, MSSP’er, operatører af digital infrastruktur og softwareproducenter er trusselsmodellering blevet en motor for efterlevelsesbevismateriale.

En moden proces for trusselsmodellering omsætter STRIDE-fund, misbrugsscenarier og arkitekturbeslutninger til poster i risikoregisteret, sikkerhedskrav, behandlingsplaner, testcases, leverandørassurance-opgaver, dokumentation for databeskyttelse gennem design og sporbarhed til anvendelseserklæringen (SoA).

Hvorfor dokumentation for sikkerhed gennem design er vigtig nu

Moderne reguleringer konvergerer omkring den samme forventning: Organisationer skal identificere sikkerheds- og privatlivsrisici tidligt, tildele ejerskab, implementere proportionale kontroller og opbevare bevismateriale.

ISO/IEC 27001:2022 kræver et risikobaseret ledelsessystem for informationssikkerhed. Klausul 6.1.2 og 6.1.3 kræver risikovurdering og risikobehandling vedrørende informationssikkerhed. Klausul 8.1 kræver operationel planlægning og styring. Bilag A indeholder kontroller, der skal udvælges gennem anvendelseserklæringen baseret på risiko, retlige krav og forretningsbehov.

NIS2 bringer samme princip ind i cybersikkerhedsstyring. Article 20 kræver, at ledelsesorganer godkender foranstaltninger til styring af cybersikkerhedsrisici og fører tilsyn med implementeringen. Article 21 kræver passende og proportionale tekniske, driftsmæssige og organisatoriske foranstaltninger, herunder risikoanalyse, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikkerhed ved anskaffelse, udvikling og vedligeholdelse, sårbarhedshåndtering, cyberhygiejne, kryptering, adgangsstyring, politik for aktivstyring og MFA, hvor det er relevant.

DORA anlægger et perspektiv om digital operationel robusthed i den finansielle sektor fra 17. januar 2025. DORA kræver, at omfattede finansielle enheder opretholder en sund, dækkende og dokumenteret styringsramme for IKT-risiko, identificerer IKT-aktiver og afhængigheder, anvender beskyttende og forebyggende foranstaltninger, detekterer anomal aktivitet, tester digital operationel robusthed, styrer IKT-tredjepartsrisiko og forbereder respons- og genopretningskapaciteter. For omfattede finansielle enheder er DORA den sektorspecifikke EU-retsakt for overlappende NIS2-forpligtelser.

GDPR tilføjer ansvarlighed og databeskyttelse gennem design og standardindstillinger. Ethvert system, der behandler personoplysninger, skal kunne dokumentere lovlig, rimelig, gennemsigtig, formålsbegrænset, minimeret, opbevaringsbegrænset og sikker behandling. En trusselsmodel, der kortlægger flows med personoplysninger, adgangsveje, logfiler, opbevaring, sletning og tredjepartsoverførsler, er direkte relevant for GDPR Articles 5, 25, 32 og 35.

Cyber Resilience Act øger presset på produkter med digitale elementer. Produktteams har brug for livscyklusbevismateriale, der viser, at cybersikkerhedsrisici, forudsigeligt misbrug, grænseflader, opdateringsmekanismer, autentifikationsflows og antagelser om sårbarhedshåndtering blev vurderet tidligt.

Læringen er klar: Hvis en gennemgang af sikkerhedsarkitekturen ikke kan spores til risici, kontroller, ejere, afbødende foranstaltninger og test, bliver den vanskelig at forsvare i en revision eller regulatorisk gennemgang i 2026.

Clarysec-modellen: én trusselsmodel, mange output

Clarysecs tilgang begynder med et praktisk princip: En trusselsmodel er ikke færdig, før den producerer revisionsbare beslutninger.

I Zenith Blueprint: En auditors 30-trins køreplan [ZB] giver risikostyringsfasen, trin 9, teams et enkelt format til at omsætte tekniske observationer til risikosprog:

“Kombinér nu aktiv + trussel + sårbarhed i en kort beskrivelse af et risikoscenarie. Beskriv i praksis den potentielle hændelse. Dette bliver senere en linjepost i jeres risikoregister. Brug et enkelt format: ‘[Trussel] udnytter [sårbarhed] på [aktiv], hvilket medfører [konsekvens].’”

Den sætning er broen mellem udvikling og efterlevelse.

En whiteboardnote som “risiko for spoofing af partner-API” bliver til:

“En angriber udnytter svag autentifikation af partner-API på API’et til transaktionsrisiko, hvilket medfører uautoriseret adgang til beslutninger om betalingsrisiko og eksponering af personoplysninger.”

Nu har fundet et aktiv, en trussel, en sårbarhed og en konsekvens. Det kan vurderes, tildeles, behandles, testes og accepteres.

Politiklaget gør dette gentageligt. P24 Politik for sikker udvikling [P24] fastslår:

“Alle nye applikationer og større ændringer skal gennemgå sikker arkitekturgennemgang og trusselsmodellering, før udviklingen begynder.”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.

Den kræver også:

“Designgennemgange skal dokumentere dataflowdiagrammer, tillidsgrænser og afbødende foranstaltninger for identificerede risici.”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.2.

Disse to klausuler er stærke revisionsankre. De viser, at trusselsmodellering ikke er valgfrit, og at designdokumentation skal omfatte diagrammer, grænser og beslutninger om risikoreduktion.

P06 Politik for risikostyring [P06] kobler trusselsmodellering til risikostyring på virksomhedsniveau:

“Alle forretningsenheder skal proaktivt identificere risici ved hjælp af strukturerede teknikker afledt af ISO/IEC 27005:2024, herunder trusselsmodellering, kortlægning af aktivafhængigheder og scenariebaseret identifikation.”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.

Den fastslår også:

“Identificerede risici skal dokumenteres med henvisning til aktivejer, trusselsaktør, sårbarhed og potentiel påvirkning af fortrolighed, integritet og tilgængelighed (CIA).”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.4.

Dette er den beviskæde, auditorer vil se: politikkrav, designaktivitet, risikoscenarie, kontroludvælgelse, implementering, test og godkendelse.

STRIDE gør dækningen systematisk, misbrugsscenarier gør den realistisk

STRIDE er fortsat en af de mest anvendelige metoder til trusselsmodellering i designfasen, fordi den tvinger teams til at vurdere seks almindelige fejlkategorier:

• Spoofing
• Manipulation
• Ikke-benægtelse
• Videregivelse af information
• Denial of service
• Rettighedseskalering

For Anyas platform til betalingsrisiko anvendte teamet STRIDE på tværs af hver komponent, hvert dataflow og hver tillidsgrænse.

Spoofing rejste spørgsmålet om, hvorvidt en partner-API-klient kunne udgive sig for en bankkunde, hvis gensidig autentifikation var svag. Manipulation afdækkede risikoen for, at enhedssignaler eller transaktionsbeløb kunne ændres før indlæsning. Ikke-benægtelse fremhævede behovet for administrator- og transaktionsrevisionslogs. Videregivelse af information fokuserede på lækage gennem logfiler, analyseeksporter, supportværktøjer og rapporterings-API’er. Denial of service tvang teamet til at vurdere spidsbelastningsvinduer for transaktioner og floods med fejlformede forespørgsler. Rettighedseskalering afdækkede risici i supportroller, sessionstokens og administrative funktioner.

Misbrugsscenarier omsatte disse kategorier til realistiske scenarier:

• En svindler uploader manipulerede enhedssignaler for at påvirke en risikoscore.
• En kompromitteret partnerlegitimationsoplysning oversvømmer API’et med svigagtige forespørgsler.
• En udvikler bruger produktionsdata med personoplysninger i et testmiljø.
• En ondsindet insider eksporterer kundeidentifikatorer og scoringslogik.
• Et nedbrud hos en cloudbaseret analyseleverandør blokerer risikobeslutninger under et betalingsvindue.
• En fejlkonfiguration af lagring eksponerer uploadede identitetsdokumenter.
• En slettearbejdsgang fjerner applikationsposten, men efterlader sikkerhedskopier og leverandørkopier.

Hvert misbrugsscenarie blev til en post om designrisiko med det berørte aktiv, trusselsaktør, sårbarhed, konsekvens, eksisterende antagelser, krævet afbødning, ejer af restrisiko, testbevismateriale og regulatorisk relevans.

Denne struktur forhindrer vage fund som “API-sikkerhedsrisiko”. Den producerer risikoudsagn med beviskvalitet såsom:

“En angriber bruger stjålne partnerlegitimationsoplysninger til at indsende svigagtige scoringsforespørgsler gennem API’et til transaktionsrisiko, hvilket medfører kompromittering af integriteten i risikobeslutninger, muligt finansielt tab for kunder og uautoriseret behandling af personoplysninger.”

Kortlægning af trusselsmodellering til ISO/IEC 27001:2022 og ISO/IEC 27002:2022

ISO/IEC 27001:2022 kræver ikke trusselsmodellering ved navn. Den kræver konsistent, dokumenteret risikovurdering og risikobehandling. Trusselsmodellering er en af de stærkeste metoder til at generere dette bevismateriale i software-, cloud- og produktmiljøer.

Nøglen er sporbarhed. I ZB anbefaler risikostyringsfasen, trin 13, at kontroller kortlægges til risici og klausuler, herunder henvisninger til Bilag A i behandlingsplaner, og at det noteres, hvor kontroller understøtter GDPR, NIS2 eller DORA.

Zenith Controls: Vejledningen til tværgående efterlevelse [ZC] hjælper med at strukturere denne sporbarhed ved at kortlægge ISO/IEC 27002:2022-kontroller til relaterede kontroller, revisionsforventninger og eksterne rammeværker.

For trusselsmodellering er ISO/IEC 27002:2022-kontrol 5.8, informationssikkerhed i projektstyring, ankeret for projektstyring. Den viser, at sikkerhed er integreret i projektinitiering, planlægning, udførelse og accept.

Kontrol 8.25, sikker udviklingslivscyklus, er SDLC-ankeret. ZC kobler 8.25 til understøttende kontroller såsom 8.26 krav til applikationssikkerhed, 8.27 sikker systemarkitektur og tekniske principper, 8.28 sikker kodning, 8.29 sikkerhedstestning i udvikling og accept, 8.30 outsourcet udvikling og 8.31 adskillelse af udviklings-, test- og produktionsmiljøer.

Denne kortlægning hjælper med at omsætte en designworkshop til bevismateriale for anvendelseserklæringen. Den understøtter også ISO/IEC 27001:2022-klausul 4 til 6, fordi krav fra interessenter, ISMS-omfang, ledelsesforpligtelser og beslutninger om risikobehandling alle er synlige.

Et tværgående efterlevelseskort for NIS2, DORA, CRA, GDPR og NIST CSF

En veldrevet trusselsmodel bør ikke skabe fem adskilte efterlevelsesspor. Den bør producere én bevispakke for designrisici, som kan genbruges på tværs af rammeværker.

NIST CSF 2.0 er særligt nyttig til ledelseskommunikation. GOVERN-funktionen understøtter retlige, regulatoriske, kontraktlige og privatlivsrelaterede forpligtelser, mens resultaterne for forsyningskæden hjælper med at koble leverandørkritikalitet, kontraktlige krav, due diligence, overvågning og hændelsesplanlægning til det samme bevismateriale fra trusselsmodellen.

GDPR kræver særlig opmærksomhed, fordi trusselsmodellering og DPIA-arbejde bør understøtte hinanden. P17 Databeskyttelses- og privatlivspolitik [P17] fastslår:

“Trusselsmodellering og konsekvensanalyser vedrørende databeskyttelse (DPIA’er) er obligatoriske for højrisikosystemer til behandling.”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.3.4.

For mindre teams fastslår P17S Databeskyttelses- og privatlivspolitik - SMV [P17S]:

“Databeskyttelse gennem design og standardindstillinger skal håndhæves i alle nye systemer og tjenester”
Fra afsnittet “Styringskrav”, politikklausul 5.3.1.

Resultatet er en praktisk driftsmodel: Brug de samme dataflowdiagrammer, tillidsgrænser og misbrugsscenarier til sikkerhedsrisiko, privatlivsrisiko, leverandørgennemgang og regulatorisk bevismateriale.

Et 90-minutters designrisiko-sprint for højrisikofunktioner

Trusselsmodellering behøver ikke begynde som et tungt program. For et nyt betalings-API, onboarding-workflow, AI-understøttet funktion, identitetstjeneste, cloudmigrering eller ekstern integration kan et 90-minutters designrisiko-sprint producere værdifuldt bevismateriale.

1. Åbn en projektsikkerhedskontrol

Brug P24 klausul 6.1.1 som udløser. For hver ny applikation eller større ændring skal der oprettes en mappe med bevismateriale med:

• Arkitekturdiagram
• Dataflowdiagram
• Kort over tillidsgrænser
• Aktivliste
• Noter om personoplysninger
• Liste over leverandør- og IKT-afhængigheder
• Indledende sikkerhedskrav
• Arbejdsark til trusselsmodel
• Poster i risikoregisteret
• Sporbarhed for afbødning og test
• Godkendelsesregistrering

For mindre organisationer understøtter P24S Politik for sikker udvikling - SMV [P24S] den samme disciplin ved at koble sikre udviklingsprocesser til adgangsstyring for udviklere, test, trusselsmodellering og dokumentation. Den kræver også centraliseret opbevaring af tjeklister, gennemgangsgodkendelser, testrapporter og komponentfortegnelser til revisionsformål. Klausul 11.3.1 henviser til SA-3 til SA-15 for at definere sikre udviklingsprocesser, herunder trusselsmodellering.

2. Tegn det minimalt tilstrækkelige dataflow

Begynd ikke med et poleret diagram. Begynd med de flows, der skaber risiko:

• Brugeren uploader identitetsdokumenter eller transaktionsdata.
• Webapplikationen sender forespørgsler til API’et.
• API’et skriver til administreret lagring eller en database.
• Leverandøren modtager verifikations- eller analysedata.
• En intern analytikerportal viser resultater.
• Kundesystemet henter status eller beslutninger.
• Logfiler, overvågningsværktøjer og backups modtager kopier.

Markér hver tillidsgrænse: internet til applikation, applikation til API, intern tjeneste til leverandør, produktionssystem til analyse, administrator til privilegeret funktion og produktion til ikke-produktionsmiljø.

3. Kør STRIDE og misbrugsscenarier sammen

For hver grænse skal STRIDE-spørgsmålene stilles, og misbrugsscenarier skal skrives i almindeligt forretningssprog. Målet er ikke at liste alle tænkelige angreb. Målet er at identificere sandsynlige, væsentlige scenarier, der påvirker fortrolighed, integritet, tilgængelighed, databeskyttelse, robusthed eller sikkerhed.

4. Omsæt fund til risikoscenarier

Brug formlen fra ZB trin 9:

“[Trussel] udnytter [sårbarhed] på [aktiv], hvilket medfører [konsekvens].”

For eksempel:

“En angriber udnytter svage adgangskontroller for objektlagring på repositoriet med identitetsdokumenter, hvilket medfører uautoriseret videregivelse af personoplysninger og risiko for regulatorisk underretning.”

Tilføj derefter ejer, sandsynlighed, konsekvens, iboende risiko, behandlingsmulighed, målkontrol, restrisiko og bevismateriale.

5. Udled krav og test

En trusselsmodel er ikke færdig, når risici er oplistet. Den er færdig, når afbødende foranstaltninger er implementeret, testet eller formelt accepteret.

Politik for ændringsstyring - SMV giver en praktisk udløser:

“Hvis en ændring omfatter følsomme data, systemadgangsrettigheder eller eksterne integrationer, kræves en gennemgang af sikkerhedsmæssig påvirkning. Den udpegede sikkerheds- eller efterlevelseskontakt skal vurdere, om ændringen introducerer yderligere risici, og anbefale yderligere sikkerhedsforanstaltninger.”
Fra afsnittet “Risikobehandling og undtagelser”, politikklausul 7.5.1.

Følsomme data, adgangsrettigheder og eksterne integrationer er netop de ændringer, der kræver gennemgang af designrisici.

Hvad forskellige auditorer vil spørge om

En ISO/IEC 27001:2022-auditor vil spørge, om trusselsmodellering er en del af en defineret risikovurderingsproces, om kriterierne er konsistente, om risikoejere har godkendt restrisici, om behandlingsplaner kobler til SoA, og om bevismateriale opbevares. Auditoren vil se efter gentagelighed, versionshistorik, synlighed i ledelsens gennemgang og dækning i intern audit.

For Bilag A vil auditoren koble jeres bevismateriale til 5.8, 8.25, 8.26, 8.27 og 8.29. ZB trin 21, kontroller i praksis, fremhæver sikker systemarkitektur og tekniske principper ved at spørge, hvilke principper der styrer sikker arkitektur. Auditorer kan spørge, om trusselsmodellering gennemføres under design ved hjælp af metoder såsom STRIDE eller attack trees, og om arkitekturbeslutninger gennemgås før implementering.

En NIS2-reviewer vil fokusere på styring og proportionalitet. Vedkommende kan spørge, om ledelsen har godkendt tilgangen til styring af cybersikkerhedsrisici, om sikker anskaffelse, udvikling og vedligeholdelse er dækket, om leverandørsårbarheder vurderes, om hændelsesscenarier kobler til rapporteringsarbejdsgange, og om scenarier for forretningskontinuitet analyseres. NIS2 Article 23 om trinvis rapportering af væsentlige hændelser, herunder tidlig advarsel inden for 24 timer, underretning inden for 72 timer og endelig rapport inden for én måned, gør scenarieklarhed særligt værdifuld.

En DORA-eksaminator vil fokusere på IKT-risikostyring, kritiske funktioner, IKT-aktiver, eksterne afhængigheder, robusthedstest og IKT-tredjepartstjenester. Hvis systemet understøtter en kritisk eller vigtig funktion, forventes stærkere bevismateriale, der kobler trusselsscenarier til aktivfortegnelser, afhængighedskort, testplaner, tredjepartskontrakter og genopretningsforanstaltninger.

En reviewer af databeskyttelse vil inspicere dataflows og spørge, om behandling af personoplysninger er nødvendig, lovlig, minimeret og beskyttet. Vedkommende vil spørge, om særlige kategorier af data indgår, om pseudonymisering eller kryptering anvendes, om opbevaring er begrundet, og om en DPIA er påkrævet. Trusselsmodellering og DPIA er forskellige aktiviteter, men de bør dele diagrammer, scenarier og afbødende foranstaltninger.

En reviewer med fokus på NIST CSF eller COBIT 2019 vil se efter styring, procesejerskab, performance, ansvarlighed og løbende forbedring. Vedkommende interesserer sig muligvis mindre for selve STRIDE-arbejdsarket og mere for, om processen er pålidelig, målt, godkendt og forbedret.

Almindelige fejl i bevismateriale fra trusselsmodellering

De mest almindelige fejl er ikke tekniske. De er fejl i bevismaterialet.

Teams udfører trusselsmodellering for sent, efter at systemet allerede er bygget. På det tidspunkt bliver workshoppen en briefing før penetrationstest i stedet for en designkontrol.

Fund omsættes ikke til risikosprog. “Tilføj auth” eller “logningsproblem” kan hjælpe udviklere, men auditorer har brug for aktiv, trussel, sårbarhed, konsekvens, ejer, behandling og restrisiko.

Databeskyttelse og sikkerhed adskilles. Ét team dokumenterer risiko for spoofing og injektion, mens et andet dokumenterer opbevaring og behandlingsgrundlag. GDPR-ansvarlighed fungerer bedre, når dataflows, misbrugsscenarier og DPIA-udløsere er forbundet.

Leverandørantagelser forbliver udokumenterede. NIS2, DORA og NIST CSF øger alle forventningerne til IKT-risiko i forsyningskæden. Hvis en afbødende foranstaltning afhænger af en leverandørs kryptering, logning, sletning, robusthed eller hændelseshåndtering, skal bevismaterialet indsamles.

Test kortlægges ikke tilbage til trusler. En rapport fra penetrationstest kan være nyttig, men den dokumenterer ikke nødvendigvis, at de specifikke designrisici blev afbødet. Hvert væsentligt trusselsfund bør have valideringsbevismateriale.

Accept af restrisiko er uformel. “Vi accepterer dette for MVP” er ikke nok. ISO/IEC 27001:2022 forventer accept af restrisiko fra relevante risikoejere som dokumenteret information.

Din bevispakke for trusselsmodellering i 2026

For hvert større system eller hver væsentlig ændring bør der opbevares en standardiseret bevispakke, som kan understøtte ISO 27001, NIS2, DORA, CRA, GDPR og kundeassurance.

Politik for risikostyring - SMV indfanger driftsmodellen godt:

“Den sikrer, at risikostyring er en aktiv del af planlægning, projektgennemførelse, leverandørvalg og håndtering af sikkerhedshændelser i overensstemmelse med ISO 27001, ISO 31000 og gældende regulatoriske krav.”
Fra afsnittet “Formål”, politikklausul 1.2.

Det er det rigtige mål. Trusselsmodellering bør påvirke planlægning, udvikling, leverandørvalg, hændelseshåndtering og revisionsberedskab.

Gør trusselsmodellering revisionsklar før næste release

De organisationer, der bedst håndterer efterlevelsespres i 2026, er ikke dem med flest diagrammer. Det er dem, der kan dokumentere en enkel kæde:

Designrisiko blev identificeret. Risiko blev vurderet. Kontroller blev udvalgt. Afbødende foranstaltninger blev implementeret. Test validerede de afbødende foranstaltninger. Restrisiko blev godkendt. Bevismateriale kortlægges til de rammeværker, der er relevante.

Begynd med én højrisikoændring: en betalingsintegration, et nyt API, et AI-understøttet workflow, en identitetsfunktion, en cloudmigrering, en kundevendt produktrelease eller en leverandørtilknyttet tjeneste. Gennemfør et 90-minutters designrisiko-sprint. Brug ZB til at omsætte fund til risikoscenarier, behandlingsplaner og SoA-sporbarhed. Brug ZC til at kortlægge ISO/IEC 27002:2022-kontroller såsom 5.8, 8.25, 8.26, 8.27 og 8.29 til understøttende kontroller, leverandørrisiko, databeskyttelse, test og revisionsbevismateriale. Tilpas P24, P06, P17, P24S og jeres ændringsstyringsprocedure, så trusselsmodellering bliver påkrævet, gentagelig og gennemgåelig.

Hvis du ønsker hjælp fra Clarysec, kan du starte med en gennemgang af bevismateriale fra trusselsmodellering. Vi vurderer ét reelt projekt, identificerer huller i forhold til forventningerne i ISO/IEC 27001:2022, NIS2, DORA, CRA og GDPR og giver jer en praktisk afhjælpningskøreplan, som jeres udviklere, auditorer og bestyrelse alle kan forstå.