Modeliranje prijetnji za ISO 27001, NIS2 i DORA

Anya, CISO brzorastuće fintech tvrtke, trebala je odobriti plan lansiranja nove B2B platforme za procjenu rizika plaćanja. Upravni odbor želio je izlazak na tržište prije kraja tromjesečja. Prodaja je već pripremila bankarske klijente. Inženjering je skicirao arhitekturu izvornu za oblak s atributima identiteta, signalima uređaja, metapodacima transakcija, bihevioralnim ocjenama rizika, upravljanom bazom podataka i pružateljem analitike treće strane.

Na papiru je platforma izgledala kao komercijalni iskorak. Anyi je izgledala kao pet razgovora o usklađenosti koji dolaze istodobno.

Kao pružatelj financijske tehnologije, društvo je bilo pod pritiskom DORA. Kao pružatelj usluga u oblaku i digitalne platforme, moralo je razumjeti izloženost prema NIS2. Budući da je platforma obrađivala osobne podatke povezane s pojedincima iz EU-a, primjenjivao se GDPR. Korporativni klijenti očekivali su certifikaciju prema ISO/IEC 27001:2022. Ako bi usluga postala dio povezanog softverskog proizvoda, očekivanja Akta o kibernetičkoj otpornosti dodala bi zahtjeve za dokazima sigurnosti ugrađene u dizajn proizvoda.

Razvojni tim predložio je uobičajeni sigurnosni plan: skenirati ovisnosti, provesti skeniranja ranjivosti, rezervirati penetracijsko testiranje i zakrpati kritične nalaze prije puštanja u produkciju. Anya je znala da to nije dovoljno. Te aktivnosti testiraju ono što je već izgrađeno. One ne dokazuju da je arhitektura osmišljena sa sigurnošću ugrađenom u dizajn, da su granice povjerenja shvaćene, da su tokovi osobnih podataka minimizirani, da su pretpostavke o dobavljačima pregledane ili da su scenariji prekida usluge razmotreni prije lansiranja.

Zato je usporila sastanak s četiri pitanja:

1. Gdje su granice povjerenja?
2. Koji scenariji zlouporabe mogu dovesti do prijevare, izloženosti podataka ili prekida usluge?
3. Koje odluke u dizajnu smanjuju rizik prije nego što je kod napisan?
4. Koji će dokazi zadovoljiti pregledavatelje za ISO 27001, NIS2, DORA, CRA i GDPR za šest mjeseci?

Na četvrtom pitanju mnoge organizacije zakažu. Modeliranje prijetnji često se tretira kao korisna inženjerska radionica, a zatim se zakopa na wiki stranici. U 2026. to više nije dovoljno. Za SaaS pružatelje, fintech društva, platforme u oblaku, MSP-ove, MSSP-ove, operatore digitalne infrastrukture i proizvođače softvera modeliranje prijetnji postalo je mehanizam za stvaranje dokaza usklađenosti.

Zreo proces modeliranja prijetnji pretvara STRIDE nalaze, scenarije zlouporabe i arhitekturne odluke u stavke registra rizika, sigurnosne zahtjeve, planove obrade rizika, testne slučajeve, zadatke atestacije sigurnosti dobavljača, dokaze ugrađene zaštite privatnosti i sljedivost prema Izjavi o primjenjivosti.

Zašto su dokazi sigurnosti ugrađene u dizajn sada važni

Suvremeni propisi približavaju se istom očekivanju: organizacije moraju rano identificirati sigurnosne rizike i rizike za privatnost, dodijeliti vlasništvo, implementirati razmjerne kontrole i zadržati dokaze.

ISO/IEC 27001:2022 zahtijeva sustav upravljanja informacijskom sigurnošću temeljen na riziku. Točke 6.1.2 i 6.1.3 zahtijevaju procjenu rizika informacijske sigurnosti i obradu rizika. Točka 8.1 zahtijeva operativno planiranje i kontrolu. Dodatak A sadrži kontrole koje se moraju odabrati kroz Izjavu o primjenjivosti na temelju rizika, pravnih zahtjeva i poslovnih potreba.

NIS2 isti princip uvodi u upravljanje kibernetičkom sigurnošću. Article 20 zahtijeva da upravljačka tijela odobre mjere upravljanja rizicima kibernetičke sigurnosti i nadziru njihovu provedbu. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, postupanje s incidentima, kontinuitet poslovanja, sigurnost opskrbnog lanca, sigurnost pri nabavi, razvoju i održavanju, postupanje s ranjivostima, kibernetičku higijenu, šifriranje, kontrolu pristupa, upravljanje imovinom i MFA gdje je primjenjivo.

DORA od 17. siječnja 2025. primjenjuje perspektivu operativne otpornosti financijskog sektora. Za obuhvaćene financijske subjekte zahtijeva održavanje pouzdanog, sveobuhvatnog i dokumentiranog okvira za upravljanje IKT rizicima, identifikaciju IKT imovine i ovisnosti, primjenu zaštitnih i preventivnih mjera, otkrivanje anomalnih aktivnosti, testiranje digitalne operativne otpornosti, upravljanje IKT rizikom trećih strana te pripremu sposobnosti odgovora i oporavka. Za obuhvaćene financijske subjekte DORA je sektorski pravni akt Unije za preklapajuće obveze prema NIS2.

GDPR dodaje odgovornost te zaštitu podataka u fazi projektiranja i prema zadanim postavkama. Svaki sustav koji obrađuje osobne podatke mora moći dokazati zakonitu, poštenu, transparentnu, svrhom ograničenu, minimiziranu, rokom pohrane ograničenu i sigurnu obradu. Model prijetnji koji mapira tokove osobnih podataka, putove pristupa, dnevničke zapise, zadržavanje, brisanje i prijenose trećim stranama izravno je relevantan za GDPR Articles 5, 25, 32 i 35.

Akt o kibernetičkoj otpornosti pojačava pritisak na proizvode s digitalnim elementima. Timovi za proizvode trebaju dokaze kroz životni ciklus koji pokazuju da su kibernetički rizici, predvidiva zlouporaba, sučelja, mehanizmi ažuriranja, tokovi autentifikacije i pretpostavke o postupanju s ranjivostima razmotreni rano.

Pouka je jasna: ako se pregled arhitekture ne može povezati s rizicima, kontrolama, vlasnicima, mjerama ublažavanja i testovima, teško će ga biti opravdati u reviziji ili regulatornom pregledu u 2026.

Clarysec model: jedan model prijetnji, više izlaznih rezultata

Clarysecov pristup počinje praktičnim načelom: model prijetnji nije dovršen dok ne proizvede odluke koje se mogu revizijski provjeriti.

U Zenith Blueprint: revizorov plan u 30 koraka [ZB], faza Upravljanje rizicima, korak 9, daje timovima jednostavan format za pretvaranje tehničkih opažanja u jezik rizika:

„Sada spojite imovinu + prijetnju + ranjivost u sažet opis scenarija rizika. U osnovi, opišite mogući incident. To će kasnije biti stavka u vašem registru rizika. Upotrijebite jednostavan format: ‘[Prijetnja] iskorištava [ranjivost] na [imovina], što dovodi do [utjecaj].’”

Ta rečenica povezuje inženjering i usklađenost.

Bilješka na ploči poput „rizik lažnog predstavljanja partnerskog API-ja” postaje:

„Napadač iskorištava slabu autentifikaciju partnerskog API-ja na API-ju za rizik transakcija, što dovodi do neovlaštenog pristupa odlukama o riziku plaćanja i izloženosti osobnih podataka.”

Sada nalaz ima imovinu, prijetnju, ranjivost i utjecaj. Može se procijeniti, dodijeliti, obraditi, testirati i prihvatiti.

Sloj politike čini to ponovljivim. P24 Politika sigurnog razvoja [P24] navodi:

„Sve nove aplikacije i značajne promjene moraju proći pregled sigurne arhitekture i modeliranje prijetnji prije početka razvoja.”
Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.1.1.

Također zahtijeva:

„Pregledi dizajna moraju dokumentirati dijagrame toka podataka, granice povjerenja i mjere ublažavanja za identificirane rizike.”
Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.1.2.

Te dvije točke snažna su revizijska uporišta. Pokazuju da modeliranje prijetnji nije opcionalno i da dokazi o dizajnu moraju uključivati dijagrame, granice i odluke o ublažavanju.

P06 Politika upravljanja rizicima [P06] povezuje modeliranje prijetnji s upravljanjem rizicima organizacije:

„Sve poslovne jedinice moraju proaktivno identificirati rizike primjenom strukturiranih tehnika izvedenih iz ISO/IEC 27005:2024, uključujući modeliranje prijetnji, mapiranje ovisnosti imovine i identifikaciju temeljenu na scenarijima.”
Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.1.1.

Također navodi:

„Identificirani rizici moraju se dokumentirati uz upućivanje na vlasnika imovine, aktera prijetnje, ranjivost i mogući utjecaj na povjerljivost, cjelovitost i dostupnost (CIA).”
Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.1.4.

To je lanac dokaza koji revizori žele vidjeti: zahtjev politike, aktivnost dizajna, scenarij rizika, odabir kontrola, implementacija, testiranje i odobrenje.

STRIDE čini obuhvat sustavnim, scenariji zlouporabe čine ga stvarnim

STRIDE ostaje jedna od najkorisnijih metoda za modeliranje prijetnji u fazi dizajna jer prisiljava timove da razmotre šest uobičajenih načina neuspjeha:

• Lažno predstavljanje
• Neovlaštena izmjena
• Poricanje radnje
• Otkrivanje informacija
• Uskraćivanje usluge
• Eskalacija privilegija

Za Anyinu platformu za rizik plaćanja tim je primijenio STRIDE na svaku komponentu, tok podataka i granicu povjerenja.

Lažno predstavljanje otvorilo je pitanje može li klijent partnerskog API-ja oponašati bankarskog klijenta ako je uzajamna autentifikacija slaba. Neovlaštena izmjena razotkrila je rizik manipulacije signalima uređaja ili iznosima transakcija prije unosa. Poricanje radnje istaknulo je potrebu za administratorskim i transakcijskim revizijskim dnevničkim zapisima. Otkrivanje informacija usmjerilo se na curenje kroz dnevničke zapise, izvoze analitike, alate podrške i izvještajna API sučelja. Uskraćivanje usluge prisililo je tim da razmotri vršne transakcijske prozore i poplave neispravnih zahtjeva. Eskalacija privilegija razotkrila je rizike u ulogama podrške, tokenima sesije i administrativnim funkcijama.

Scenariji zlouporabe pretvorili su te kategorije u stvarne priče:

• Prevarant učitava manipulirane signale uređaja kako bi utjecao na ocjenu rizika.
• Kompromitirana partnerska vjerodajnica preplavljuje API prijevarnim zahtjevima.
• Razvojni inženjer koristi produkcijske osobne podatke u testnom okruženju.
• Zlonamjerni interni korisnik izvozi identifikatore klijenata i logiku bodovanja.
• Prekid rada dobavljača analitike u oblaku blokira odluke o riziku tijekom prozora plaćanja.
• Pogrešna konfiguracija pohrane izlaže učitane identifikacijske dokumente.
• Radni tok brisanja uklanja zapis aplikacije, ali ostavlja sigurnosne kopije i kopije kod dobavljača.

Svaki scenarij zlouporabe postao je zapis o riziku u dizajnu s pogođenom imovinom, akterom prijetnje, ranjivošću, utjecajem, postojećim pretpostavkama, potrebnom mjerom ublažavanja, vlasnikom preostalog rizika, dokazima testiranja i regulatornom relevantnošću.

Takva struktura sprječava neodređene nalaze poput „rizik sigurnosti API-ja”. Ona proizvodi izjave o riziku dokazne razine, primjerice:

„Napadač koristi ukradene partnerske vjerodajnice za podnošenje prijevarnih zahtjeva za bodovanje putem API-ja za rizik transakcija, što dovodi do narušavanja cjelovitosti odluka o riziku, mogućeg financijskog gubitka za klijente i neovlaštene obrade osobnih podataka.”

Mapiranje modeliranja prijetnji na ISO/IEC 27001:2022 i ISO/IEC 27002:2022

ISO/IEC 27001:2022 ne zahtijeva modeliranje prijetnji pod tim nazivom. Zahtijeva dosljednu, dokumentiranu procjenu rizika i obradu rizika. Modeliranje prijetnji jedna je od najsnažnijih metoda za stvaranje tih dokaza u softverskim okruženjima, okruženjima u oblaku i proizvodnim okruženjima.

Ključ je sljedivost. U ZB, faza Upravljanje rizicima, korak 13, preporučuje mapiranje kontrola na rizike i točke, uključujući reference na Dodatak A u planovima obrade rizika i bilježenje gdje kontrole podupiru GDPR, NIS2 ili DORA.

Zenith Controls: vodič za međusobnu usklađenost [ZC] pomaže strukturirati tu sljedivost mapiranjem kontrola ISO/IEC 27002:2022 na povezane kontrole, revizijska očekivanja i vanjske okvire.

Za modeliranje prijetnji, kontrola ISO/IEC 27002:2022 5.8, informacijska sigurnost u upravljanju projektima, uporište je za upravljanje projektom. Pokazuje da je sigurnost integrirana u pokretanje, planiranje, provedbu i prihvat projekta.

Kontrola 8.25, sigurni životni ciklus razvoja, uporište je za SDLC. ZC povezuje 8.25 s potpornim kontrolama kao što su 8.26 zahtjevi sigurnosti aplikacija, 8.27 sigurna arhitektura sustava i inženjerska načela, 8.28 sigurno kodiranje, 8.29 sigurnosno testiranje u razvoju i prihvatu, 8.30 razvoj povjeren vanjskim izvođačima i 8.31 odvajanje razvojnih, testnih i produkcijskih okruženja.

Ovo mapiranje pomaže pretvoriti radionicu dizajna u dokaze za Izjavu o primjenjivosti. Također podupire točke 4 do 6 ISO/IEC 27001:2022 jer su zahtjevi zainteresiranih strana, opseg ISMS-a, obveze vodstva i odluke o obradi rizika vidljivi.

Mapa međusobne usklađenosti za NIS2, DORA, CRA, GDPR i NIST CSF

Dobro proveden model prijetnji ne bi trebao proizvesti pet odvojenih tijekova rada za usklađenost. Trebao bi proizvesti jedan paket dokaza o rizicima u dizajnu koji se može ponovno koristiti u više okvira.

NIST CSF 2.0 posebno je koristan za komunikaciju s izvršnim rukovodstvom. Njegova funkcija GOVERN podupire pravne, regulatorne, ugovorne i privatnosne obveze, dok ishodi za opskrbni lanac pomažu povezati kritičnost dobavljača, ugovorne zahtjeve, dubinsku analizu dobavljača, praćenje i planiranje incidenata s istim dokazima modela prijetnji.

GDPR zahtijeva posebnu pozornost jer bi se modeliranje prijetnji i DPIA trebali međusobno pojačavati. P17 Politika zaštite podataka i privatnosti [P17] navodi:

„Modeliranje prijetnji i procjene učinka na zaštitu podataka (DPIA) obvezni su za sustave obrade visokog rizika.”
Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.3.4.

Za manje timove, P17S Politika zaštite podataka i privatnosti - SME [P17S] navodi:

„Zaštita privatnosti u fazi projektiranja i prema zadanim postavkama mora se primjenjivati u svim novim sustavima i uslugama”
Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.3.1.

Rezultat je praktičan operativni model: iste dijagrame toka podataka, granice povjerenja i scenarije zlouporabe koristite za sigurnosni rizik, rizik za privatnost, pregled dobavljača i regulatorne dokaze.

Sprint od 90 minuta za rizike u dizajnu značajki visokog rizika

Modeliranje prijetnji ne mora početi kao opsežan program. Za novi API za plaćanja, radni tok uvođenja korisnika, značajku potpomognutu umjetnom inteligencijom, uslugu identiteta, migraciju u oblak ili vanjsku integraciju, sprint od 90 minuta za rizike u dizajnu može proizvesti vrijedne dokaze.

1. Otvorite projektnu sigurnosnu kontrolnu točku

Upotrijebite točku 6.1.1 iz P24 kao okidač. Za svaku novu aplikaciju ili značajnu promjenu izradite mapu dokaza s:

• Dijagramom arhitekture
• Dijagramom toka podataka
• Mapom granica povjerenja
• Popisom imovine
• Napomenama o osobnim podacima
• Popisom dobavljača i IKT ovisnosti
• Početnim sigurnosnim zahtjevima
• Radnim listom modela prijetnji
• Stavkama registra rizika
• Sljedivošću mjera ublažavanja i testova
• Zapisom odobrenja

Za manje organizacije, P24S Politika sigurnog razvoja - SME [P24S] podupire istu disciplinu povezivanjem procesa sigurnog razvoja s kontrolom pristupa razvojnih inženjera, testiranjem, modeliranjem prijetnji i dokumentacijom. Također zahtijeva centralizirano zadržavanje kontrolnih popisa, odobrenja pregleda, izvješća o testiranju i popisa komponenti za potrebe revizije. Točka 11.3.1 upućuje na SA-3 do SA-15 radi definiranja procesa sigurnog razvoja, uključujući modeliranje prijetnji.

2. Nacrtajte minimalno održiv tok podataka

Ne počinjite s dotjeranim dijagramom. Počnite s tokovima koji stvaraju rizik:

• Korisnik učitava identifikacijske dokumente ili transakcijske podatke.
• Web aplikacija šalje zahtjeve API-ju.
• API zapisuje u upravljanu pohranu ili bazu podataka.
• Dobavljač prima podatke za provjeru ili analitiku.
• Interni portal analitičara prikazuje rezultate.
• Sustav klijenta dohvaća status ili odluke.
• Dnevnički zapisi, alati za praćenje i sigurnosne kopije primaju kopije.

Označite svaku granicu povjerenja: internet prema aplikaciji, aplikacija prema API-ju, interna usluga prema dobavljaču, produkcijski sustav prema analitici, administrator prema privilegiranoj funkciji i produkcijsko prema neprodukcijskom okruženju.

3. Provedite STRIDE i scenarije zlouporabe zajedno

Za svaku granicu postavite STRIDE pitanja i napišite scenarije zlouporabe jasnim poslovnim jezikom. Cilj nije navesti svaki zamislivi napad. Cilj je identificirati vjerojatne, značajne scenarije koji utječu na povjerljivost, cjelovitost, dostupnost, privatnost, otpornost ili sigurnost ljudi i procesa.

4. Pretvorite nalaze u scenarije rizika

Upotrijebite formulu iz koraka 9 u ZB:

„[Prijetnja] iskorištava [ranjivost] na [imovina], što dovodi do [utjecaj].”

Na primjer:

„Napadač iskorištava slabe kontrole pristupa objektnoj pohrani na repozitoriju identifikacijskih dokumenata, što dovodi do neovlaštenog otkrivanja osobnih podataka i izloženosti obvezi regulatornog obavješćivanja.”

Zatim dodajte vlasnika, vjerojatnost, utjecaj, inherentni rizik, mogućnost obrade rizika, ciljanu kontrolu, preostali rizik i dokaze.

5. Izvedite zahtjeve i testove

Model prijetnji nije dovršen kada su rizici navedeni. Dovršen je kada su mjere ublažavanja implementirane, testirane ili formalno prihvaćene.

Politika upravljanja promjenama - SME daje praktičan okidač:

„Ako promjena uključuje osjetljive podatke, prava pristupa sustavu ili vanjske integracije, potreban je pregled utjecaja na sigurnost. Imenovani kontakt za sigurnost ili usklađenost mora procijeniti uvodi li promjena dodatne rizike i preporučiti dodatne zaštitne mjere.”
Iz odjeljka „Obrada rizika i iznimke”, točka politike 7.5.1.

Osjetljivi podaci, prava pristupa i vanjske integracije upravo su promjene koje zahtijevaju pregled rizika u dizajnu.

Što će različiti revizori pitati

Revizor za ISO/IEC 27001:2022 pitat će je li modeliranje prijetnji dio definiranog procesa procjene rizika, jesu li kriteriji dosljedni, jesu li vlasnici rizika odobrili preostale rizike, povezuju li se planovi obrade rizika sa SoA i zadržavaju li se dokazi. Tražit će ponovljivost, povijest verzija, vidljivost u upravinim preispitivanjima sustava upravljanja informacijskom sigurnošću i obuhvat interne revizije.

Za Dodatak A povezat će vaše dokaze s 5.8, 8.25, 8.26, 8.27 i 8.29. Korak 21 u ZB, Kontrole u praksi, ističe sigurnu arhitekturu sustava i inženjerska načela pitanjem koja načela usmjeravaju sigurnu arhitekturu. Revizori mogu pitati provodi li se modeliranje prijetnji tijekom dizajna metodama kao što su STRIDE ili stabla napada te pregledavaju li se arhitekturne odluke prije implementacije.

Pregledavatelj za NIS2 usredotočit će se na upravljanje i razmjernost. Može pitati je li upravljačko tijelo odobrilo pristup upravljanju rizicima kibernetičke sigurnosti, jesu li obuhvaćeni sigurna nabava, razvoj i održavanje, razmatraju li se ranjivosti dobavljača, povezuju li se scenariji incidenata s radnim tokovima izvješćivanja i analiziraju li se scenariji kontinuiteta poslovanja. NIS2 Article 23 o stupnjevitom izvješćivanju o značajnim incidentima, uključujući rano upozorenje u roku od 24 sata, obavijest u roku od 72 sata i završno izvješće u roku od jednog mjeseca, čini jasnoću scenarija posebno vrijednom.

Ispitivač za DORA usredotočit će se na upravljanje IKT rizicima, kritične funkcije, IKT imovinu, vanjske ovisnosti, testiranje otpornosti i IKT usluge trećih strana. Ako sustav podupire kritičnu ili važnu funkciju, očekivat će snažnije dokaze koji povezuju scenarije prijetnji s popisima imovine, mapama ovisnosti, planovima testiranja, ugovorima s trećim stranama i mjerama oporavka.

Pregledavatelj privatnosti pregledat će tokove podataka i pitati je li obrada osobnih podataka nužna, zakonita, minimizirana i zaštićena. Pitat će uključuju li se posebne kategorije podataka, koristi li se pseudonimizacija ili šifriranje, je li zadržavanje opravdano i je li potrebna DPIA. Modeliranje prijetnji i DPIA različite su aktivnosti, ali trebale bi dijeliti dijagrame, scenarije i mjere ublažavanja.

Pregledavatelj usmjeren na NIST CSF ili COBIT 2019 tražit će upravljanje, vlasništvo nad procesima, učinkovitost, odgovornost i kontinuirano poboljšanje. Možda će ga manje zanimati sam STRIDE radni list, a više to je li proces pouzdan, mjeren, odobren i poboljšavan.

Uobičajeni propusti u dokazima modeliranja prijetnji

Najčešći propusti nisu tehnički. To su propusti u dokazima.

Timovi provode modeliranje prijetnji prekasno, nakon što je sustav već izgrađen. U tom trenutku radionica postaje priprema za penetracijsko testiranje umjesto kontrola dizajna.

Nalazi se ne pretvaraju u jezik rizika. „Dodati autentifikaciju” ili „problem sa zapisivanjem događaja” mogu pomoći inženjerima, ali revizorima trebaju imovina, prijetnja, ranjivost, utjecaj, vlasnik, obrada rizika i preostali rizik.

Privatnost i sigurnost odvajaju se. Jedan tim dokumentira rizik lažnog predstavljanja i ubacivanja, dok drugi dokumentira zadržavanje i pravnu osnovu. Odgovornost prema GDPR bolje funkcionira kada su tokovi podataka, scenariji zlouporabe i okidači za DPIA povezani.

Pretpostavke o dobavljačima ostaju nedokumentirane. NIS2, DORA i NIST CSF podižu očekivanja za rizike IKT opskrbnog lanca. Ako mjera ublažavanja ovisi o dobavljačevu šifriranju, zapisivanju događaja, brisanju, otpornosti ili odgovoru na incidente, prikupite dokaze.

Testovi se ne mapiraju natrag na prijetnje. Izvješće o penetracijskom testiranju može biti korisno, ali ne mora dokazati da su konkretni rizici dizajna ublaženi. Svaki značajan nalaz prijetnje trebao bi imati dokaze o provjeri.

Prihvaćanje preostalog rizika neformalno je. „Prihvaćamo ovo za MVP” nije dovoljno. ISO/IEC 27001:2022 očekuje prihvaćanje preostalog rizika od odgovarajućih vlasnika rizika kao dokumentirane informacije.

Vaš paket dokaza modeliranja prijetnji za 2026.

Za svaki značajan sustav ili značajnu promjenu zadržite standardni paket dokaza koji može poduprijeti ISO 27001, NIS2, DORA, CRA, GDPR i zahtjeve klijenata za atestacijom.

Politika upravljanja rizicima - SME dobro sažima operativni model:

„Osigurava da je upravljanje rizicima aktivna sastavnica planiranja, provedbe projekta, odabira dobavljača i odgovora na incidente, u skladu s ISO 27001, ISO 31000 i primjenjivim regulatornim zahtjevima.”
Iz odjeljka „Svrha”, točka politike 1.2.

To je ispravan cilj. Modeliranje prijetnji treba utjecati na planiranje, inženjering, odabir dobavljača, odgovor na incidente i spremnost za reviziju.

Učinite modeliranje prijetnji spremnim za reviziju prije sljedećeg izdanja

Organizacije koje će najbolje podnijeti pritisak usklađenosti u 2026. nisu one s najviše dijagrama. To su one koje mogu dokazati jednostavan lanac:

Rizik dizajna je identificiran. Rizik je procijenjen. Kontrole su odabrane. Mjere ublažavanja su implementirane. Testovi su potvrdili mjere ublažavanja. Preostali rizik je odobren. Dokazi se mapiraju na relevantne okvire.

Počnite s jednom promjenom visokog rizika: integracijom plaćanja, novim API-jem, radnim tokom potpomognutim umjetnom inteligencijom, značajkom identiteta, migracijom u oblak, izdanjem proizvoda dostupnog klijentima ili uslugom povezanom s dobavljačem. Provedite sprint od 90 minuta za rizike u dizajnu. Upotrijebite ZB za pretvaranje nalaza u scenarije rizika, planove obrade rizika i sljedivost SoA. Upotrijebite ZC za mapiranje kontrola ISO/IEC 27002:2022 kao što su 5.8, 8.25, 8.26, 8.27 i 8.29 na potporne kontrole, rizik dobavljača, privatnost, testiranje i revizijske dokaze. Uskladite P24, P06, P17, P24S i svoj postupak upravljanja promjenama kako bi modeliranje prijetnji postalo obvezno, ponovljivo i podložno pregledu.

Ako želite da Clarysec pomogne, počnite s pregledom dokaza modeliranja prijetnji. Procijenit ćemo jedan stvarni projekt, identificirati praznine u odnosu na očekivanja ISO/IEC 27001:2022, NIS2, DORA, CRA i GDPR te vam dati praktičan plan otklanjanja nedostataka koji mogu razumjeti vaši inženjeri, revizori i upravni odbor.