Modelovanie hrozieb pre ISO 27001, NIS2 a DORA

Anya, CISO rýchlo rastúcej fintech spoločnosti, mala schváliť plán spustenia novej B2B platformy na hodnotenie platobného rizika. Predstavenstvo chcelo vstúpiť na trh pred koncom štvrťroka. Obchodný tím už mal pripravených bankových zákazníkov. Vývoj načrtol natívnu cloudovú architektúru s atribútmi identity, signálmi zo zariadení, metadátami transakcií, behaviorálnymi rizikovými skóre, spravovanou databázou a analytickým poskytovateľom tretej strany.

Na papieri platforma vyzerala ako obchodný prelom. Pre Anyu to bolo päť rozhovorov o súlade naraz.

Ako poskytovateľ finančných technológií spoločnosť čelila tlaku DORA. Ako poskytovateľ cloudovej služby a digitálnej platformy potrebovala pochopiť svoju expozíciu voči požiadavkám NIS2. Keďže platforma spracúvala osobné údaje dotknutých osôb v EÚ, uplatňovalo sa GDPR. Podnikoví zákazníci očakávali certifikáciu ISO/IEC 27001:2022. Ak by sa služba stala súčasťou prepojeného softvérového produktu, požiadavky aktu o kybernetickej odolnosti (CRA) by doplnili potrebu produktových dôkazov bezpečnosti už od návrhu.

Vývojový tím navrhol obvyklý bezpečnostný plán: skontrolovať závislosti, vykonať skenovanie zraniteľností, objednať penetračný test a opraviť kritické zistenia pred nasadením do produkčného prostredia. Anya vedela, že to nestačí. Tieto aktivity testujú to, čo už bolo vytvorené. Nepreukazujú, že architektúra bola bezpečná už od návrhu, že boli pochopené hranice dôvery, že toky osobných údajov boli minimalizované, že predpoklady týkajúce sa dodávateľov boli preskúmané ani že scenáre prerušenia služieb boli posúdené pred spustením.

Preto stretnutie spomalila štyrmi otázkami:

1. Kde sú hranice dôvery?
2. Ktoré scenáre zneužitia môžu viesť k podvodu, sprístupneniu údajov alebo prerušeniu služieb?
3. Ktoré rozhodnutia v návrhu znižujú riziko ešte pred napísaním kódu?
4. Aké dôkazy budú o šesť mesiacov postačovať posudzovateľom ISO 27001, NIS2, DORA, CRA a GDPR?

Pri štvrtej otázke zlyháva mnoho organizácií. Modelovanie hrozieb sa často vníma ako užitočný vývojársky workshop, ktorý sa následne stratí na wiki stránke. V roku 2026 to už nestačí. Pre poskytovateľov SaaS, fintech spoločnosti, cloudové platformy, poskytovateľov riadených služieb (MSP), poskytovateľov riadených bezpečnostných služieb (MSSP), prevádzkovateľov digitálnej infraštruktúry a výrobcov softvéru sa modelovanie hrozieb stalo mechanizmom na tvorbu dôkazov súladu.

Vyspelý proces modelovania hrozieb premieňa zistenia STRIDE, scenáre zneužitia a architektonické rozhodnutia na položky registra rizík, bezpečnostné požiadavky, plány ošetrenia rizík, testovacie prípady, úlohy uistenia dodávateľov, dôkazy ochrany súkromia už od návrhu a sledovateľnosť voči vyhláseniu o aplikovateľnosti (SoA).

Prečo dnes záleží na dôkazoch bezpečnosti už od návrhu

Moderné predpisy sa zbiehajú v rovnakom očakávaní: organizácie musia včas identifikovať bezpečnostné riziká a riziká ochrany súkromia, priradiť vlastníctvo, implementovať primerané opatrenia a uchovávať dôkazy.

ISO/IEC 27001:2022 vyžaduje systém manažérstva informačnej bezpečnosti založený na rizikách. Kapitoly 6.1.2 a 6.1.3 vyžadujú posúdenie a ošetrenie rizík informačnej bezpečnosti. Kapitola 8.1 vyžaduje prevádzkové plánovanie a riadenie. Príloha A poskytuje opatrenia, ktoré sa musia vyberať prostredníctvom vyhlásenia o aplikovateľnosti na základe rizík, zákonných požiadaviek a potrieb organizácie.

NIS2 prenáša rovnaký princíp do riadenia kybernetickej bezpečnosti. Článok 20 vyžaduje, aby riadiace orgány schvaľovali opatrenia na riadenie rizík kybernetickej bezpečnosti a dohliadali na ich implementáciu. Článok 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane analýzy rizík, zvládania incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, bezpečnosti pri obstarávaní, vývoji a údržbe, zvládania zraniteľností, kybernetickej hygieny, šifrovania, riadenia prístupu, správy aktív a MFA tam, kde je to vhodné.

DORA od 17. januára 2025 uplatňuje na finančný sektor pohľad prevádzkovej odolnosti. Vyžaduje, aby finančné subjekty v rozsahu pôsobnosti udržiavali spoľahlivý, komplexný a zdokumentovaný rámec riadenia rizík IKT, identifikovali aktíva IKT a závislosti, uplatňovali ochranné a preventívne opatrenia, detegovali anomálne aktivity, testovali digitálnu prevádzkovú odolnosť, riadili riziko externých poskytovateľov IKT služieb a pripravili schopnosti reakcie a obnovy. Pre finančné subjekty v rozsahu pôsobnosti je DORA odvetvovo špecifickým právnym aktom Únie pre prekrývajúce sa povinnosti podľa NIS2.

GDPR dopĺňa preukázateľnú zodpovednosť a ochranu údajov už od návrhu a štandardne. Každý systém spracúvajúci osobné údaje musí byť schopný preukázať zákonné, spravodlivé, transparentné, účelovo viazané, minimalizované, časovo obmedzené a bezpečné spracúvanie. Model hrozieb, ktorý mapuje toky osobných údajov, prístupové cesty, logy, uchovávanie, výmaz a prenosy tretím stranám, je priamo relevantný pre články 5, 25, 32 a 35 GDPR.

CRA zvyšuje tlak na produkty s digitálnymi prvkami. Produktové tímy potrebujú dôkazy naprieč životným cyklom, ktoré ukazujú, že riziká kybernetickej bezpečnosti, predvídateľné nesprávne použitie, rozhrania, mechanizmy aktualizácií, autentifikačné toky a predpoklady zvládania zraniteľností boli posúdené včas.

Poučenie je jasné: ak sa preskúmanie architektúry nedá vysledovať k rizikám, opatreniam, vlastníkom, zmierňujúcim opatreniam a testom, bude ho ťažké obhájiť pri audite alebo regulačnom preskúmaní v roku 2026.

Model Clarysec: jeden model hrozieb, viac výstupov

Prístup Clarysec vychádza z praktického princípu: model hrozieb nie je úplný, kým nevytvára rozhodnutia použiteľné pri audite.

V Zenith Blueprint: 30-krokovej cestovnej mape audítora [ZB] dáva fáza riadenia rizík v kroku 9 tímom jednoduchý formát na prevod technických pozorovaní do jazyka rizík:

„Teraz spojte aktívum + hrozbu + zraniteľnosť do stručného opisu rizikového scenára. V podstate opíšte potenciálny incident. Neskôr pôjde o riadkovú položku vo vašom registri rizík. Použite jednoduchý formát: ‚[Hrozba] zneužije [zraniteľnosť] na [aktíve], čo vedie k [dopadu].‘“

Táto veta je mostom medzi vývojom a súladom.

Poznámka na tabuli ako „riziko spoofingu partnerského API“ sa zmení na:

„Útočník zneužije slabú autentifikáciu partnerského API na API pre transakčné riziko, čo vedie k neoprávnenému prístupu k rozhodnutiam o platobnom riziku a sprístupneniu osobných údajov.“

Zistenie tak má aktívum, hrozbu, zraniteľnosť a dopad. Dá sa posúdiť, priradiť, ošetriť, otestovať a akceptovať.

Vrstva politík z toho robí opakovateľný postup. P24 Politika bezpečného vývoja [P24] uvádza:

„Všetky nové aplikácie a významné zmeny musia pred začiatkom vývoja prejsť preskúmaním bezpečnej architektúry a modelovaním hrozieb.“
Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.1.1.

Zároveň vyžaduje:

„Preskúmania návrhu musia dokumentovať diagramy tokov údajov, hranice dôvery a zmierňujúce opatrenia pre identifikované riziká.“
Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.1.2.

Tieto dva body sú silné auditné kotvy. Ukazujú, že modelovanie hrozieb nie je voliteľné a že dôkazy z návrhu musia obsahovať diagramy, hranice a rozhodnutia o zmiernení rizík.

P06 Politika riadenia rizík [P06] prepája modelovanie hrozieb s podnikovým riadením rizík:

„Všetky obchodné jednotky sú povinné proaktívne identifikovať riziká pomocou štruktúrovaných techník odvodených z ISO/IEC 27005:2024 vrátane modelovania hrozieb, mapovania závislostí aktív a identifikácie na základe scenárov.“
Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.1.1.

Ďalej uvádza:

„Identifikované riziká musia byť zdokumentované s odkazom na vlastníka aktíva, pôvodcu hrozby, zraniteľnosť a potenciálny dopad na dôvernosť, integritu a dostupnosť (CIA).“
Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.1.4.

Toto je reťazec dôkazov, ktorý audítori chcú vidieť: požiadavka politiky, aktivita v návrhu, rizikový scenár, výber opatrenia, implementácia, testovanie a schválenie.

STRIDE zabezpečuje systematické pokrytie, scenáre zneužitia ho robia reálnym

STRIDE zostáva jednou z najužitočnejších metód modelovania hrozieb vo fáze návrhu, pretože núti tímy posúdiť šesť bežných režimov zlyhania:

• Spoofing
• Manipulácia
• Popretie vykonania úkonu
• Sprístupnenie informácií
• Odmietnutie služby
• Zvýšenie oprávnení

Pri Anyinej platforme na hodnotenie platobného rizika tím použil STRIDE na každý komponent, tok údajov a hranicu dôvery.

Spoofing otvoril otázku, či by sa klient partnerského API mohol vydávať za bankového zákazníka, ak by bola vzájomná autentifikácia slabá. Manipulácia odkryla riziko, že signály zo zariadení alebo sumy transakcií by mohli byť pozmenené pred prijatím do systému. Popretie vykonania úkonu zvýraznilo potrebu administrátorských a transakčných auditných logov. Sprístupnenie informácií sa zameralo na únik cez logy, analytické exporty, podporné nástroje a reportovacie API. Odmietnutie služby prinútilo tím posúdiť špičkové transakčné okná a záplavy chybne formovaných požiadaviek. Zvýšenie oprávnení odhalilo riziká v podporných rolách, tokenoch relácií a administrátorských funkciách.

Scenáre zneužitia premenili tieto kategórie na reálne príbehy:

• Podvodník nahrá zmanipulované signály zo zariadenia, aby ovplyvnil rizikové skóre.
• Kompromitované partnerské prihlasovacie údaje zaplavia API podvodnými požiadavkami.
• Vývojár použije produkčné osobné údaje v testovacom prostredí.
• Škodlivý insider exportuje identifikátory zákazníkov a logiku skórovania.
• Výpadok dodávateľa cloudovej analytiky zablokuje rozhodovanie o riziku počas platobného okna.
• Chybná konfigurácia úložiska sprístupní nahrané doklady totožnosti.
• Pracovný tok výmazu odstráni aplikačný záznam, ale ponechá zálohy a kópie u dodávateľa.

Každý scenár zneužitia sa stal záznamom rizika návrhu s dotknutým aktívom, pôvodcom hrozby, zraniteľnosťou, dopadom, existujúcimi predpokladmi, požadovaným zmiernením, vlastníkom reziduálneho rizika, testovacím dôkazom a regulačnou relevanciou.

Takáto štruktúra bráni neurčitým zisteniam typu „riziko bezpečnosti API“. Vytvára rizikové vyhlásenia použiteľné ako dôkaz, napríklad:

„Útočník použije ukradnuté partnerské prihlasovacie údaje na odosielanie podvodných skórovacích požiadaviek cez API pre transakčné riziko, čo vedie k narušeniu integrity rizikových rozhodnutí, možnej finančnej strate zákazníkov a neoprávnenému spracúvaniu osobných údajov.“

Mapovanie modelovania hrozieb na ISO/IEC 27001:2022 a ISO/IEC 27002:2022

ISO/IEC 27001:2022 nevyžaduje modelovanie hrozieb výslovne podľa názvu. Vyžaduje konzistentné a zdokumentované posúdenie rizík a ošetrenie rizík. Modelovanie hrozieb je jednou z najsilnejších metód na vytváranie týchto dôkazov v softvérových, cloudových a produktových prostrediach.

Kľúčová je sledovateľnosť. V ZB fáza riadenia rizík, krok 13, odporúča mapovať opatrenia na riziká a kapitoly vrátane odkazov na Prílohu A v plánoch ošetrenia rizík a zaznamenať, kde opatrenia podporujú GDPR, NIS2 alebo DORA.

Zenith Controls: Sprievodca naprieč rámcami súladu [ZC] pomáha túto sledovateľnosť štruktúrovať tým, že mapuje opatrenia ISO/IEC 27002:2022 na súvisiace opatrenia, auditné očakávania a externé rámce.

Pre modelovanie hrozieb je opatrenie ISO/IEC 27002:2022 5.8, Informačná bezpečnosť v projektovom riadení, kotvou projektového riadenia. Ukazuje, že bezpečnosť je integrovaná do iniciácie, plánovania, realizácie a akceptácie projektu.

Opatrenie 8.25, Bezpečný životný cyklus vývoja, je kotvou SDLC. ZC prepája 8.25 s podpornými opatreniami, ako sú 8.26 požiadavky na bezpečnosť aplikácií, 8.27 bezpečná architektúra systémov a princípy inžinierstva, 8.28 bezpečné programovanie, 8.29 bezpečnostné testovanie počas vývoja a akceptácie, 8.30 outsourcovaný vývoj a 8.31 oddelenie vývojového, testovacieho a produkčného prostredia.

Toto mapovanie pomáha premeniť návrhový workshop na dôkaz pre vyhlásenie o aplikovateľnosti. Zároveň podporuje kapitoly 4 až 6 ISO/IEC 27001:2022, pretože požiadavky zainteresovaných strán, rozsah ISMS, záväzky vedenia a rozhodnutia o ošetrení rizík sú viditeľné.

Mapa naprieč rámcami súladu pre NIS2, DORA, CRA, GDPR a NIST CSF

Dobre vedený model hrozieb nemá vytvoriť päť oddelených pracovných tokov súladu. Má vytvoriť jeden balík dôkazov o rizikách návrhu, ktorý sa dá opakovane použiť naprieč rámcami.

NIST CSF 2.0 je osobitne užitočný pre komunikáciu s vrcholovým vedením. Jeho funkcia GOVERN podporuje zákonné, regulačné, zmluvné povinnosti a povinnosti ochrany súkromia, zatiaľ čo výsledky v oblasti dodávateľského reťazca pomáhajú prepojiť kritickosť dodávateľov, zmluvné požiadavky, due diligence, monitorovanie a plánovanie incidentov s rovnakými dôkazmi z modelu hrozieb.

GDPR si vyžaduje osobitnú pozornosť, pretože modelovanie hrozieb a DPIA sa majú navzájom podporovať. P17 Politika ochrany údajov a súkromia [P17] uvádza:

„Modelovanie hrozieb a posúdenia vplyvu na ochranu údajov (DPIA) sú povinné pre vysoko rizikové systémy spracúvania.“
Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.3.4.

Pre menšie tímy P17S Politika ochrany údajov a súkromia pre MSP [P17S] uvádza:

„Ochrana súkromia už od návrhu a štandardne sa musí uplatňovať vo všetkých nových systémoch a službách“
Zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.3.1.

Výsledkom je praktický prevádzkový model: používajte tie isté diagramy tokov údajov, hranice dôvery a scenáre zneužitia pre bezpečnostné riziko, riziko ochrany súkromia, preskúmanie dodávateľov a regulačné dôkazy.

90-minútový sprint rizika návrhu pre vysoko rizikové funkcie

Modelovanie hrozieb nemusí začínať ako rozsiahly program. Pre nové platobné API, pracovný tok onboardingu, funkciu podporenú AI, službu identity, migráciu do cloudového prostredia alebo externú integráciu dokáže 90-minútový sprint rizika návrhu vytvoriť hodnotné dôkazy.

1. Otvorte projektový bezpečnostný kontrolný bod

Použite bod P24 6.1.1 ako spúšťač. Pre každú novú aplikáciu alebo významnú zmenu vytvorte priečinok dôkazov s týmito položkami:

• Diagram architektúry
• Diagram tokov údajov
• Mapa hraníc dôvery
• Zoznam aktív
• Poznámky k osobným údajom
• Zoznam dodávateľov a závislostí IKT
• Počiatočné bezpečnostné požiadavky
• Pracovný hárok modelu hrozieb
• Položky registra rizík
• Sledovateľnosť zmierňujúcich opatrení a testov
• Schvaľovací záznam

Pre menšie organizácie P24S Politika bezpečného vývoja pre MSP [P24S] podporuje rovnakú disciplínu tým, že prepája procesy bezpečného vývoja s riadením prístupu vývojárov, testovaním, modelovaním hrozieb a dokumentáciou. Vyžaduje aj centralizované uchovávanie kontrolných zoznamov, schválení preskúmaní, testovacích správ a evidencií komponentov na účely auditu. Bod 11.3.1 odkazuje na SA-3 až SA-15 na definovanie procesov bezpečného vývoja vrátane modelovania hrozieb.

2. Nakreslite minimálny použiteľný tok údajov

Nezačínajte vylešteným diagramom. Začnite tokmi, ktoré vytvárajú riziko:

• Používateľ nahráva doklady totožnosti alebo transakčné údaje.
• Webová aplikácia odosiela požiadavky na API.
• API zapisuje do spravovaného úložiska alebo databázy.
• Dodávateľ prijíma overovacie alebo analytické údaje.
• Interný analytický portál zobrazuje výsledky.
• Systém zákazníka získava stav alebo rozhodnutia.
• Logy, monitorovacie nástroje a zálohy prijímajú kópie.

Označte každú hranicu dôvery: internet voči aplikácii, aplikácia voči API, interná služba voči dodávateľovi, produkčný systém voči analytike, administrátor voči privilegovanej funkcii a produkčné voči neprodukčnému prostrediu.

3. Spustite STRIDE a scenáre zneužitia spoločne

Pri každej hranici položte otázky STRIDE a zapíšte scenáre zneužitia v bežnom obchodnom jazyku. Cieľom nie je vymenovať každý predstaviteľný útok. Cieľom je identifikovať pravdepodobné a významné scenáre, ktoré ovplyvňujú dôvernosť, integritu, dostupnosť, súkromie, odolnosť alebo bezpečnosť.

4. Premeňte zistenia na rizikové scenáre

Použite vzorec z kroku 9 v ZB:

„[Hrozba] zneužije [zraniteľnosť] na [aktíve], čo vedie k [dopadu].“

Napríklad:

„Útočník zneužije slabé kontroly prístupu k objektovému úložisku v repozitári dokladov totožnosti, čo vedie k neoprávnenému sprístupneniu osobných údajov a regulačnej expozícii v súvislosti s oznamovaním.“

Potom doplňte vlastníka, pravdepodobnosť, dopad, inherentné riziko, možnosť ošetrenia, cieľové opatrenie, reziduálne riziko a dôkazy.

5. Odvoďte požiadavky a testy

Model hrozieb nie je hotový vtedy, keď sú riziká zapísané. Je hotový vtedy, keď sú zmierňujúce opatrenia implementované, otestované alebo formálne akceptované.

Politika riadenia zmien pre MSP poskytuje praktický spúšťač:

„Ak zmena zahŕňa citlivé údaje, prístupové práva k systémom alebo externé integrácie, vyžaduje sa preskúmanie bezpečnostného dopadu. Určený bezpečnostný alebo compliance kontakt musí posúdiť, či zmena zavádza dodatočné riziká, a odporučiť dodatočné ochranné opatrenia.“
Zo sekcie „Ošetrenie rizík a výnimky“, bod politiky 7.5.1.

Citlivé údaje, prístupové práva a externé integrácie sú presne tie zmeny, ktoré vyžadujú preskúmanie rizika návrhu.

Na čo sa budú pýtať rôzni audítori

Audítor ISO/IEC 27001:2022 sa bude pýtať, či je modelovanie hrozieb súčasťou definovaného procesu posudzovania rizík, či sú kritériá konzistentné, či vlastníci rizík schválili reziduálne riziká, či sú plány ošetrenia rizík prepojené so SoA a či sa dôkazy uchovávajú. Bude hľadať opakovateľnosť, evidenciu verzií, viditeľnosť pri preskúmaní manažmentom a pokrytie interným auditom.

Pri Prílohe A prepojí dôkazy s 5.8, 8.25, 8.26, 8.27 a 8.29. ZB krok 21, Opatrenia v praxi, zvýrazňuje bezpečnú architektúru systémov a princípy inžinierstva otázkou, aké princípy usmerňujú bezpečnú architektúru. Audítori sa môžu pýtať, či sa modelovanie hrozieb vykonáva počas návrhu metódami ako STRIDE alebo stromy útokov a či sa architektonické rozhodnutia preskúmavajú pred implementáciou.

Posudzovateľ NIS2 sa zameria na správu a riadenie a proporcionalitu. Môže sa pýtať, či vedenie schválilo prístup k riadeniu rizík kybernetickej bezpečnosti, či sú pokryté bezpečné obstarávanie, vývoj a údržba, či sa zohľadňujú zraniteľnosti dodávateľov, či sú scenáre incidentov prepojené s pracovnými tokmi oznamovania a či sa analyzujú scenáre kontinuity. Fázové hlásenie významných incidentov podľa NIS2 Article 23 vrátane včasného varovania do 24 hodín, oznámenia do 72 hodín a záverečnej správy do jedného mesiaca robí jasnosť scenárov osobitne hodnotnou.

Kontrolór DORA sa zameria na správu rizík IKT, kritické funkcie, aktíva IKT, externé závislosti, testovanie odolnosti a služby externých poskytovateľov IKT. Ak systém podporuje kritickú alebo dôležitú funkciu, bude očakávať silnejšie dôkazy prepájajúce scenáre hrozieb s evidenciou aktív, mapami závislostí, testovacími plánmi, zmluvami s tretími stranami a opatreniami obnovy.

Posudzovateľ ochrany súkromia skontroluje toky údajov a bude sa pýtať, či je spracúvanie osobných údajov nevyhnutné, zákonné, minimalizované a chránené. Bude sa pýtať, či ide o osobitné kategórie údajov, či sa používa pseudonymizácia alebo šifrovanie, či je uchovávanie odôvodnené a či sa vyžaduje DPIA. Modelovanie hrozieb a DPIA sú odlišné aktivity, ale mali by zdieľať diagramy, scenáre a zmierňujúce opatrenia.

Posudzovateľ orientovaný na NIST CSF alebo COBIT 2019 bude hľadať správu a riadenie, vlastníctvo procesu, výkonnosť, preukázateľnú zodpovednosť a neustále zlepšovanie. Samotný pracovný hárok STRIDE ho môže zaujímať menej než to, či je proces spoľahlivý, meraný, schválený a zlepšovaný.

Bežné zlyhania dôkazov pri modelovaní hrozieb

Najčastejšie zlyhania nie sú technické. Sú to zlyhania dôkazov.

Tímy vykonávajú modelovanie hrozieb príliš neskoro, až po vybudovaní systému. Vtedy sa workshop mení na brífing pred penetračným testom namiesto kontroly návrhu.

Zistenia sa neprevádzajú do jazyka rizík. „Doplniť autentifikáciu“ alebo „problém s logovaním“ môže pomôcť inžinierom, ale audítori potrebujú aktívum, hrozbu, zraniteľnosť, dopad, vlastníka, ošetrenie a reziduálne riziko.

Ochrana súkromia a bezpečnosť sú oddelené. Jeden tím dokumentuje riziko spoofingu a injection, zatiaľ čo druhý dokumentuje uchovávanie a právny základ. Preukázateľná zodpovednosť podľa GDPR funguje lepšie, keď sú toky údajov, scenáre zneužitia a spúšťače DPIA prepojené.

Predpoklady týkajúce sa dodávateľov zostávajú nezdokumentované. NIS2, DORA a NIST CSF zvyšujú očakávania pre riziko dodávateľského reťazca IKT. Ak zmierňujúce opatrenie závisí od šifrovania, logovania, výmazu, odolnosti alebo reakcie na incidenty u dodávateľa, zozbierajte dôkazy.

Testy sa nemapujú späť na hrozby. Správa z penetračného testovania môže byť užitočná, ale nemusí preukázať, že konkrétne riziká návrhu boli zmiernené. Každé významné zistenie hrozby má mať validačný dôkaz.

Akceptácia reziduálneho rizika je neformálna. „Pre MVP to akceptujeme“ nestačí. ISO/IEC 27001:2022 očakáva akceptáciu reziduálneho rizika príslušnými vlastníkmi rizík ako zdokumentovanú informáciu.

Váš balík dôkazov z modelovania hrozieb na rok 2026

Pre každý významný systém alebo významnú zmenu uchovávajte štandardný balík dôkazov, ktorý podporí ISO 27001, NIS2, DORA, CRA, GDPR a uistenie zákazníkov.

Politika riadenia rizík pre MSP dobre vystihuje prevádzkový model:

„Zabezpečuje, aby bolo riadenie rizík aktívnou súčasťou plánovania, realizácie projektov, výberu dodávateľov a reakcie na incidenty v súlade s ISO 27001, ISO 31000 a príslušnými regulačnými požiadavkami.“
Zo sekcie „Účel“, bod politiky 1.2.

To je správny cieľ. Modelovanie hrozieb má ovplyvňovať plánovanie, vývoj, výber dodávateľov, reakciu na incidenty a pripravenosť na audit.

Pripravte modelovanie hrozieb na audit pred ďalším vydaním

Organizácie, ktoré najlepšie zvládnu tlak na súlad v roku 2026, nebudú tie s najväčším počtom diagramov. Budú to tie, ktoré dokážu preukázať jednoduchý reťazec:

Riziko návrhu bolo identifikované. Riziko bolo posúdené. Opatrenia boli vybrané. Zmierňujúce opatrenia boli implementované. Testy validovali zmierňujúce opatrenia. Reziduálne riziko bolo schválené. Dôkazy sú mapované na relevantné rámce.

Začnite jednou vysoko rizikovou zmenou: platobnou integráciou, novým API, pracovným tokom podporeným AI, funkciou identity, migráciou do cloudového prostredia, produktovým vydaním pre zákazníkov alebo službou prepojenou s dodávateľom. Spustite 90-minútový sprint rizika návrhu. Použite ZB na prevod zistení na rizikové scenáre, plány ošetrenia rizík a sledovateľnosť SoA. Použite ZC na mapovanie opatrení ISO/IEC 27002:2022, ako sú 5.8, 8.25, 8.26, 8.27 a 8.29, na podporné opatrenia, dodávateľské riziko, ochranu súkromia, testovanie a auditné dôkazy. Zosúlaďte P24, P06, P17, P24S a svoj postup riadenia zmien tak, aby sa modelovanie hrozieb stalo povinným, opakovateľným a preskúmateľným.

Ak chcete pomoc od Clarysec, začnite preskúmaním dôkazov z modelovania hrozieb. Posúdime jeden reálny projekt, identifikujeme medzery voči očakávaniam ISO/IEC 27001:2022, NIS2, DORA, CRA a GDPR a poskytneme vám praktickú cestovnú mapu nápravy, ktorej budú rozumieť vaši inžinieri, audítori aj predstavenstvo.