Hotmodellering för ISO 27001, NIS2 och DORA

Anya, informationssäkerhetschef på ett snabbväxande fintechbolag, ombads att godkänna lanseringsplanen för en ny B2B-plattform för betalningsrisker. Styrelsen ville nå marknaden före kvartalets slut. Säljteamet hade redan förberett bankkunderna. Utvecklingsteamet hade skissat på en molnbaserad arkitektur med identitetsattribut, enhetssignaler, transaktionsmetadata, beteendebaserade riskpoäng, en hanterad databas och en tredjepartsleverantör för analys.

På papperet såg plattformen ut som ett kommersiellt genombrott. För Anya såg den ut som fem efterlevnadsfrågor som uppstod samtidigt.

Som leverantör av finansiell teknik stod bolaget under tryck från DORA. Som leverantör av molntjänster och digital plattform behövde det förstå sin exponering mot NIS2. Eftersom plattformen behandlade personuppgifter om personer i EU var GDPR tillämplig. Företagskunder förväntade sig ISO/IEC 27001:2022-certifiering. Om tjänsten blev en del av en uppkopplad programvaruprodukt skulle förväntningar enligt Cyber Resilience Act tillföra krav på produktunderlag för säkerhet genom design.

Utvecklingsteamet föreslog den vanliga säkerhetsplanen: skanna beroenden, genomföra en sårbarhetsskanning, boka ett penetrationstest och åtgärda de kritiska iakttagelserna före produktionssättning. Anya visste att det inte räckte. Sådana aktiviteter testar det som redan har byggts. De visar inte att arkitekturen har utformats med säkerhet genom design, att tillitsgränserna har förståtts, att personuppgiftsflöden har minimerats, att antaganden om leverantörer har granskats eller att scenarier för tjänsteavbrott har beaktats före lansering.

Därför bromsade hon mötet med fyra frågor:

1. Var finns tillitsgränserna?
2. Vilka missbruksfall kan leda till bedrägeri, dataexponering eller tjänsteavbrott?
3. Vilka designbeslut minskar risken innan kod skrivs?
4. Vilket underlag kommer att uppfylla förväntningarna från granskare av ISO 27001, NIS2, DORA, CRA och GDPR om sex månader?

Den fjärde frågan är där många organisationer misslyckas. Hotmodellering behandlas ofta som en användbar teknisk workshop och begravs sedan på en wikisida. Under 2026 räcker det inte. För SaaS-leverantörer, fintechbolag, molnplattformar, MSP:er, MSSP:er, operatörer av digital infrastruktur och programvarutillverkare har hotmodellering blivit en motor för efterlevnadsunderlag.

En mogen process för hotmodellering omvandlar STRIDE-iakttagelser, missbruksfall och arkitekturbeslut till poster i riskregister, säkerhetskrav, riskbehandlingsplaner, testfall, uppgifter för leverantörssäkring, underlag för integritetsskydd genom design och spårbarhet till tillämplighetsförklaringen (SoA).

Varför underlag för säkerhet genom design är viktigt nu

Moderna regelverk konvergerar kring samma förväntan: organisationer ska identifiera säkerhets- och integritetsrisker tidigt, tilldela ägarskap, genomföra proportionerliga kontroller och bevara underlag.

ISO/IEC 27001:2022 kräver ett riskbaserat ledningssystem för informationssäkerhet. Avsnitt 6.1.2 och 6.1.3 kräver riskbedömning och riskbehandling avseende informationssäkerhet. Avsnitt 8.1 kräver operativ planering och styrning. Bilaga A innehåller kontroller som ska väljas genom tillämplighetsförklaringen baserat på risk, rättsliga krav och verksamhetens behov.

NIS2 för in samma princip i styrning av cybersäkerhet. Article 20 kräver att ledningsorgan godkänner riskhanteringsåtgärder för cybersäkerhet och övervakar genomförandet. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säkerhet vid anskaffning, utveckling och underhåll, hantering av sårbarheter, cyberhygien, kryptering, åtkomstkontroll, tillgångshantering och MFA där det är lämpligt.

DORA tillför ett perspektiv för operativ resiliens i finanssektorn från den 17 januari 2025. DORA kräver att omfattade finansiella entiteter upprätthåller ett välgrundat, heltäckande och dokumenterat ramverk för IKT-riskhantering, identifierar IKT-tillgångar och beroenden, tillämpar skyddande och förebyggande åtgärder, upptäcker avvikande aktivitet, testar digital operativ resiliens, hanterar IKT-tredjepartsrisk och förbereder respons- och återställningsförmåga. För omfattade finansiella entiteter är DORA den sektorsspecifika unionsrättsakten för överlappande NIS2-skyldigheter.

GDPR lägger till ansvarsskyldighet samt dataskydd genom design och som standard. Varje system som behandlar personuppgifter måste kunna visa laglig, korrekt, transparent, ändamålsbegränsad, uppgiftsminimerad, lagringsbegränsad och säker behandling. En hotmodell som kartlägger personuppgiftsflöden, åtkomstvägar, loggar, lagringstider, radering och tredjepartsöverföringar är direkt relevant för GDPR Articles 5, 25, 32 och 35.

Cyber Resilience Act ökar trycket på produkter med digitala delar. Produktteam behöver livscykelunderlag som visar att cybersäkerhetsrisker, förutsebar felanvändning, gränssnitt, uppdateringsmekanismer, autentiseringsflöden och antaganden om sårbarhetshantering har beaktats tidigt.

Lärdomen är tydlig: om en arkitekturgranskning inte kan spåras till risker, kontroller, ägare, riskreducerande åtgärder och tester blir den svår att försvara vid en revision eller regulatorisk granskning under 2026.

Clarysecs modell: en hotmodell, många utdata

Clarysecs metod utgår från en praktisk princip: en hotmodell är inte färdig förrän den producerar beslut som kan granskas.

I Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB] ger riskhanteringsfasen, steg 9, teamen ett enkelt format för att omvandla tekniska observationer till riskspråk:

”Kombinera nu tillgång + hot + sårbarhet till en koncis beskrivning av ett riskscenario. Beskriv i praktiken den möjliga incidenten. Detta blir senare en radpost i ert riskregister. Använd ett enkelt format: ’[Hot] utnyttjar [sårbarhet] på [tillgång], vilket leder till [konsekvens].’”

Den meningen är bryggan mellan utveckling och regelefterlevnad.

En anteckning på whiteboarden, till exempel ”risk för spoofing i partner-API”, blir:

”En angripare utnyttjar svag autentisering i partner-API:t på API:t för transaktionsrisker, vilket leder till obehörig åtkomst till beslut om betalningsrisker och exponering av personuppgifter.”

Nu har iakttagelsen en tillgång, ett hot, en sårbarhet och en konsekvens. Den kan bedömas, tilldelas, behandlas, testas och accepteras.

Policylagret gör detta repeterbart. P24 Secure Development Policy [P24] anger:

”Alla nya applikationer och större ändringar ska genomgå säkerhetsgranskning av arkitektur och hotmodellering innan utveckling påbörjas.”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.

Den kräver också:

”Designgranskningar ska dokumentera dataflödesdiagram, tillitsgränser och riskreducerande åtgärder för identifierade risker.”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.2.

Dessa två klausuler är starka revisionsankare. De visar att hotmodellering inte är valfritt och att designunderlag ska omfatta diagram, gränser och beslut om riskreducerande åtgärder.

P06 Risk Management Policy [P06] kopplar hotmodellering till organisationens riskhantering:

”Alla verksamhetsenheter ska proaktivt identifiera risker med hjälp av strukturerade tekniker baserade på ISO/IEC 27005:2024, inklusive hotmodellering, kartläggning av tillgångsberoenden och scenariobaserad identifiering.”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.

Den anger också:

”Identifierade risker ska dokumenteras med hänvisning till tillgångsägare, hotaktör, sårbarhet och möjlig påverkan på konfidentialitet, riktighet och tillgänglighet (CIA).”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.4.

Detta är den underlagskedja som revisorer vill se: policykrav, designaktivitet, riskscenario, kontrollurval, genomförande, testning och godkännande.

STRIDE gör täckningen systematisk, missbruksfall gör den verklig

STRIDE är fortfarande en av de mest användbara metoderna för hotmodellering i designfasen eftersom den tvingar team att beakta sex vanliga felmoder:

• Spoofing (identitetsförfalskning)
• Tampering (manipulation)
• Repudiation (förnekande)
• Information disclosure (informationsröjande)
• Denial of service (tjänsteöverbelastning)
• Elevation of privilege (privilegiehöjning)

För Anyas plattform för betalningsrisker använde teamet STRIDE på varje komponent, dataflöde och tillitsgräns.

Spoofing väckte frågan om huruvida en partner-API-klient kunde utge sig för att vara en bankkund om ömsesidig autentisering var svag. Manipulation synliggjorde risken att enhetssignaler eller transaktionsbelopp kunde ändras före inläsning. Förnekande tydliggjorde behovet av revisionsloggar för administratörer och transaktioner. Informationsröjande fokuserade på läckage via loggar, analysexporter, supportverktyg och rapporterings-API:er. Tjänsteöverbelastning tvingade teamet att beakta transaktionstoppar och flöden av felaktigt formaterade förfrågningar. Privilegiehöjning synliggjorde risker i supportroller, sessionstokens och administrativa funktioner.

Missbruksfall omvandlade dessa kategorier till realistiska scenarier:

• En bedragare laddar upp manipulerade enhetssignaler för att påverka en riskpoäng.
• En komprometterad partnerautentiseringsuppgift överbelastar API:t med bedrägliga förfrågningar.
• En utvecklare använder personuppgifter från produktion i en testmiljö.
• En illvillig insider exporterar kundidentifierare och poängsättningslogik.
• Ett avbrott hos en molnleverantör för analys blockerar riskbeslut under ett betalningsfönster.
• En felkonfiguration i lagring exponerar uppladdade identitetshandlingar.
• Ett arbetsflöde för radering tar bort applikationsposten men lämnar kvar säkerhetskopior och leverantörskopior.

Varje missbruksfall blev en designriskpost med påverkad tillgång, hotaktör, sårbarhet, konsekvens, befintliga antaganden, krav på riskreducering, ägare av kvarstående risk, testunderlag och regulatorisk relevans.

Den strukturen förhindrar vaga iakttagelser som ”API-säkerhetsrisk”. Den ger riskformuleringar med underlagskvalitet, såsom:

”En angripare använder stulna partnerautentiseringsuppgifter för att skicka bedrägliga poängsättningsförfrågningar via API:t för transaktionsrisker, vilket leder till komprometterad riktighet i riskbeslut, möjlig ekonomisk förlust för kunder och obehörig behandling av personuppgifter.”

Mappa hotmodellering till ISO/IEC 27001:2022 och ISO/IEC 27002:2022

ISO/IEC 27001:2022 kräver inte uttryckligen hotmodellering. Den kräver konsekvent och dokumenterad riskbedömning och riskbehandling. Hotmodellering är en av de starkaste metoderna för att ta fram sådant underlag i programvaru-, moln- och produktmiljöer.

Nyckeln är spårbarhet. I ZB rekommenderar riskhanteringsfasen, steg 13, att kontroller mappas till risker och avsnitt, inklusive hänvisningar till Bilaga A i riskbehandlingsplaner, samt att det anges var kontroller stödjer GDPR, NIS2 eller DORA.

Zenith Controls: The Cross-Compliance Guide [ZC] hjälper till att strukturera spårbarheten genom att mappa ISO/IEC 27002:2022-kontroller till relaterade kontroller, revisionsförväntningar och externa ramverk.

För hotmodellering är ISO/IEC 27002:2022 kontroll 5.8, informationssäkerhet i projektledning, ankaret för projektstyrning. Den visar att säkerhet är integrerad i projektinitiering, planering, genomförande och acceptans.

Kontroll 8.25, livscykeln för säker utveckling, är SDLC-ankaret. ZC kopplar 8.25 till stödjande kontroller såsom 8.26 säkerhetskrav för applikationer, 8.27 säker systemarkitektur och tekniska principer, 8.28 säker kodning, 8.29 säkerhetstestning vid utveckling och acceptans, 8.30 outsourcad utveckling och 8.31 separation av utvecklings-, test- och produktionsmiljöer.

Denna mappning hjälper till att omvandla en designworkshop till underlag för tillämplighetsförklaringen. Den stödjer också ISO/IEC 27001:2022 avsnitt 4 till 6 eftersom krav från intressenter, ISMS-omfattning, ledningens åtaganden och beslut om riskbehandling blir synliga.

En karta för samlad efterlevnad av NIS2, DORA, CRA, GDPR och NIST CSF

En väl genomförd hotmodell bör inte skapa fem frikopplade efterlevnadsspår. Den bör skapa ett samlat underlagspaket för designrisker som kan återanvändas mellan ramverk.

NIST CSF 2.0 är särskilt användbart för kommunikation med ledningen. Funktionen GOVERN stödjer rättsliga, regulatoriska, avtalsmässiga och integritetsrelaterade skyldigheter, medan dess utfall för leveranskedjan hjälper till att koppla leverantörskritikalitet, avtalskrav, leverantörsgranskning, övervakning och incidentplanering till samma underlag från hotmodellen.

GDPR kräver särskild uppmärksamhet eftersom hotmodellering och DPIA-arbete bör förstärka varandra. P17 Data Protection and Privacy Policy [P17] anger:

”Hotmodellering och konsekvensbedömningar avseende dataskydd (DPIA) är obligatoriska för system med högriskbehandling.”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.3.4.

För mindre team anger P17S Data Protection and Privacy Policy - SME [P17S]:

”Integritetsskydd genom design och som standard ska tillämpas i alla nya system och tjänster.”
Från avsnittet ”Styrningskrav”, policyklausul 5.3.1.

Resultatet är en praktisk operativ modell: använd samma dataflödesdiagram, tillitsgränser och missbruksfall för säkerhetsrisk, integritetsrisk, leverantörsgranskning och regulatoriskt underlag.

En 90-minuters sprint för designrisker i högriskfunktioner

Hotmodellering behöver inte börja som ett tungt program. För ett nytt betalnings-API, ett onboardingflöde, en AI-baserad funktion, en identitetstjänst, en molnmigrering eller en extern integration kan en 90-minuters sprint för designrisker ge värdefullt underlag.

1. Öppna en säkerhetskontrollpunkt i projektet

Använd P24 klausul 6.1.1 som utlösare. Skapa en underlagsmapp för varje ny applikation eller större ändring med:

• Arkitekturdiagram
• Dataflödesdiagram
• Karta över tillitsgränser
• Tillgångslista
• Anteckningar om personuppgifter
• Lista över leverantörs- och IKT-beroenden
• Inledande säkerhetskrav
• Arbetsblad för hotmodell
• Poster i riskregister
• Spårbarhet mellan riskreducerande åtgärder och tester
• Godkännandepost

För mindre organisationer stödjer P24S Secure Development Policy - SME [P24S] samma disciplin genom att koppla processer för säker utveckling till åtkomstkontroll för utvecklare, testning, hotmodellering och dokumentation. Den kräver också centraliserat bevarande av checklistor, granskningsgodkännanden, testrapporter och komponentförteckningar för revisionsändamål. Klausul 11.3.1 hänvisar till SA-3 till SA-15 för att definiera processer för säker utveckling, inklusive hotmodellering.

2. Rita det minsta användbara dataflödet

Börja inte med ett polerat diagram. Börja med flödena som skapar risk:

• Användaren laddar upp identitetshandlingar eller transaktionsdata.
• Webbapplikationen skickar förfrågningar till API:t.
• API:t skriver till hanterad lagring eller en databas.
• Leverantören tar emot verifierings- eller analysdata.
• Den interna analytikerportalen visar resultat.
• Kundsystemet hämtar status eller beslut.
• Loggar, övervakningsverktyg och säkerhetskopior tar emot kopior.

Markera varje tillitsgräns: internet till applikation, applikation till API, intern tjänst till leverantör, produktionssystem till analys, administratör till privilegierad funktion och produktion till icke-produktionsmiljö.

3. Kör STRIDE och missbruksfall tillsammans

För varje gräns, ställ STRIDE-frågorna och skriv missbruksfall på tydligt verksamhetsspråk. Målet är inte att lista varje tänkbart angrepp. Målet är att identifiera sannolika och väsentliga scenarier som påverkar konfidentialitet, riktighet, tillgänglighet, integritet, resiliens eller säkerhet.

4. Omvandla iakttagelser till riskscenarier

Använd formeln från ZB steg 9:

”[Hot] utnyttjar [sårbarhet] på [tillgång], vilket leder till [konsekvens].”

Exempel:

”En angripare utnyttjar svaga åtkomstkontroller för objektlagring i lagringsplatsen för identitetshandlingar, vilket leder till obehörigt röjande av personuppgifter och exponering för regulatorisk anmälan.”

Lägg sedan till ägare, sannolikhet, konsekvens, inneboende risk, behandlingsalternativ, målbild för kontroll, kvarstående risk och underlag.

5. Härled krav och tester

En hotmodell är inte färdig när riskerna är listade. Den är färdig när riskreducerande åtgärder har genomförts, testats eller formellt accepterats.

Change Management Policy - SME ger en praktisk utlösare:

”Om en ändring omfattar känsliga data, systemåtkomsträttigheter eller externa integrationer krävs en granskning av säkerhetspåverkan. Den utsedda säkerhets- eller regelefterlevnadskontakten ska bedöma om ändringen inför ytterligare risker och rekommendera ytterligare skyddsåtgärder.”
Från avsnittet ”Riskbehandling och undantag”, policyklausul 7.5.1.

Känsliga data, åtkomsträttigheter och externa integrationer är exakt de ändringar som kräver granskning av designrisker.

Vad olika revisorer kommer att fråga

En ISO/IEC 27001:2022-revisor kommer att fråga om hotmodellering ingår i en definierad riskbedömningsprocess, om kriterierna är konsekventa, om riskägare har godkänt kvarstående risker, om riskbehandlingsplaner kopplas till SoA och om underlag bevaras. Revisorn kommer att leta efter repeterbarhet, versionshistorik, synlighet i ledningens genomgång och täckning i internrevision.

För Bilaga A kommer revisorn att koppla ert underlag till 5.8, 8.25, 8.26, 8.27 och 8.29. ZB steg 21, Controls in Action, lyfter säker systemarkitektur och tekniska principer genom att fråga vilka principer som styr säker arkitektur. Revisorer kan fråga om hotmodellering genomförs under design med metoder som STRIDE eller attackträd, och om arkitekturbeslut granskas före implementering.

En NIS2-granskare kommer att fokusera på styrning och proportionalitet. Granskaren kan fråga om ledningen har godkänt metoden för riskhantering av cybersäkerhet, om säker anskaffning, utveckling och underhåll omfattas, om leverantörers sårbarheter beaktas, om incidentscenarier kopplas till rapporteringsarbetsflöden och om kontinuitetsscenarier analyseras. NIS2 Article 23 stegvisa rapportering för betydande incidenter, inklusive tidig varning inom 24 timmar, anmälan inom 72 timmar och en slutrapport inom en månad, gör tydliga scenarier särskilt värdefulla.

En DORA-granskare kommer att fokusera på styrning av IKT-risk, kritiska funktioner, IKT-tillgångar, externa beroenden, resiliensprovning och IKT-tredjepartstjänster. Om systemet stödjer en kritisk eller viktig funktion förväntas starkare underlag som kopplar hotscenarier till tillgångsförteckningar, beroendekartor, testplaner, tredjepartsavtal och återställningsåtgärder.

En integritetsgranskare kommer att granska dataflöden och fråga om behandlingen av personuppgifter är nödvändig, laglig, minimerad och skyddad. Granskaren kommer att fråga om särskilda kategorier av personuppgifter förekommer, om pseudonymisering eller kryptering används, om lagringstider är motiverade och om en DPIA krävs. Hotmodellering och DPIA är olika aktiviteter, men de bör dela diagram, scenarier och riskreducerande åtgärder.

En granskare med fokus på NIST CSF eller COBIT 2019 kommer att leta efter styrning, processägarskap, prestation, ansvarsskyldighet och ständig förbättring. Granskaren bryr sig kanske mindre om själva STRIDE-arbetsbladet och mer om huruvida processen är tillförlitlig, mätt, godkänd och förbättrad.

Vanliga brister i underlag från hotmodellering

De vanligaste bristerna är inte tekniska. De är brister i underlag.

Team genomför hotmodellering för sent, efter att systemet redan har byggts. Då blir workshopen en förberedelse inför penetrationstest i stället för en designkontroll.

Iakttagelser omvandlas inte till riskspråk. ”Lägg till auth” eller ”loggningsproblem” kan hjälpa utvecklare, men revisorer behöver tillgång, hot, sårbarhet, konsekvens, ägare, behandling och kvarstående risk.

Integritet och säkerhet separeras. Ett team dokumenterar spoofing- och injektionsrisker medan ett annat dokumenterar lagringstider och rättslig grund. GDPR:s ansvarsskyldighet fungerar bättre när dataflöden, missbruksfall och DPIA-utlösare kopplas samman.

Leverantörsantaganden förblir odokumenterade. NIS2, DORA och NIST CSF höjer alla förväntningarna på IKT-risker i leveranskedjan. Om en riskreducerande åtgärd beror på en leverantörs kryptering, loggning, radering, resiliens eller incidenthantering ska underlaget samlas in.

Tester mappas inte tillbaka till hot. En rapport från penetrationstestning kan vara användbar, men den kanske inte visar att de specifika designriskerna har reducerats. Varje större hotsiakttagelse bör ha valideringsunderlag.

Acceptans av kvarstående risk är informell. ”Vi accepterar detta för MVP” räcker inte. ISO/IEC 27001:2022 förväntar sig att kvarstående risk accepteras av lämpliga riskägare som dokumenterad information.

Ditt underlagspaket för hotmodellering 2026

För varje större system eller väsentlig ändring bör ni behålla ett standardiserat underlagspaket som kan stödja ISO 27001, NIS2, DORA, CRA, GDPR och kundförsäkran.

Risk Management Policy - SME fångar den operativa modellen väl:

”Den säkerställer att riskhantering är en aktiv del av planering, projektgenomförande, leverantörsval och incidenthantering, i linje med ISO 27001, ISO 31000 och tillämpliga regulatoriska krav.”
Från avsnittet ”Syfte”, policyklausul 1.2.

Det är rätt målbild. Hotmodellering ska påverka planering, utveckling, leverantörsval, incidenthantering och beredskap för revision.

Gör hotmodellering revisionsklar före nästa release

De organisationer som bäst kommer att hantera efterlevnadstrycket under 2026 är inte de som har flest diagram. Det är de som kan visa en enkel kedja:

Designrisk identifierades. Risken bedömdes. Kontroller valdes. Riskreducerande åtgärder genomfördes. Tester validerade åtgärderna. Kvarstående risk godkändes. Underlag mappas till de ramverk som är relevanta.

Börja med en högriskändring: en betalningsintegration, ett nytt API, ett AI-baserat arbetsflöde, en identitetsfunktion, en molnmigrering, en kundvänd produktrelease eller en leverantörsansluten tjänst. Genomför en 90-minuters sprint för designrisker. Använd ZB för att omvandla iakttagelser till riskscenarier, riskbehandlingsplaner och SoA-spårbarhet. Använd ZC för att mappa ISO/IEC 27002:2022-kontroller såsom 5.8, 8.25, 8.26, 8.27 och 8.29 till stödjande kontroller, leverantörsrisk, integritet, testning och revisionsunderlag. Samordna P24, P06, P17, P24S och er ändringshanteringsrutin så att hotmodellering blir obligatorisk, repeterbar och granskningsbar.

Om du vill att Clarysec hjälper till, börja med en granskning av underlaget från hotmodellering. Vi bedömer ett verkligt projekt, identifierar gap mot förväntningar enligt ISO/IEC 27001:2022, NIS2, DORA, CRA och GDPR och ger dig en praktisk åtgärdsplan som era utvecklare, revisorer och styrelse kan förstå.