Modelování hrozeb pro ISO 27001, NIS2 a DORA

Anya, CISO rychle rostoucí fintech společnosti, dostala za úkol schválit plán uvedení nové B2B platformy pro hodnocení platebních rizik. Představenstvo chtělo vstoupit na trh před koncem čtvrtletí. Obchodní tým už měl připravené bankovní zákazníky. Vývojový tým načrtl cloudově nativní architekturu s atributy identity, signály zařízení, metadaty transakcí, behaviorálním rizikovým skóre, spravovanou databází a poskytovatelem analytiky třetí strany.

Na papíře platforma vypadala jako obchodní průlom. Pro Anyu to znamenalo pět rozhovorů o souladu, které přicházely najednou.

Jako poskytovatel finančních technologií byla společnost pod tlakem DORA. Jako poskytovatel cloudové služby a digitální platformy potřebovala porozumět své expozici vůči NIS2. Protože platforma zpracovávala osobní údaje osob v EU, uplatnilo se GDPR. Podnikoví zákazníci očekávali certifikaci ISO/IEC 27001:2022. Pokud by se služba stala součástí propojeného softwarového produktu, očekávání podle Aktu o kybernetické odolnosti (CRA) by přidala požadavek na produktové důkazy bezpečnosti již od návrhu.

Vývojový tým navrhl obvyklý bezpečnostní plán: provést sken závislostí, spustit sken zranitelností, objednat penetrační test a před nasazením do produkčního prostředí opravit kritická zjištění. Anya věděla, že to nestačí. Tyto činnosti testují to, co už bylo vytvořeno. Nedokládají, že architektura byla bezpečná již od návrhu, že byly pochopeny hranice důvěry, že datové toky osobních údajů byly minimalizovány, že byly přezkoumány předpoklady týkající se dodavatelů ani že byly před spuštěním posouzeny scénáře narušení služby.

Proto poradu zpomalila čtyřmi otázkami:

1. Kde jsou hranice důvěry?
2. Které scénáře zneužití by mohly vést k podvodu, expozici dat nebo narušení služby?
3. Která návrhová rozhodnutí snižují riziko ještě před napsáním kódu?
4. Jaké důkazy uspokojí přezkoumávající osoby pro ISO 27001, NIS2, DORA, CRA a GDPR za šest měsíců?

Právě u čtvrté otázky mnoho organizací selhává. Modelování hrozeb se často bere jako užitečný technický workshop a poté skončí zapomenuté na stránce wiki. V roce 2026 to nestačí. Pro poskytovatele SaaS, fintech společnosti, cloudové platformy, MSP, MSSP, provozovatele digitální infrastruktury a výrobce softwaru se modelování hrozeb stalo nástrojem pro vytváření důkazů o souladu.

Vyspělý proces modelování hrozeb převádí zjištění STRIDE, scénáře zneužití a architektonická rozhodnutí do položek registru rizik, bezpečnostních požadavků, plánů ošetření rizik, testovacích případů, úkolů pro ujištění dodavatelů, důkazů ochrany osobních údajů již od návrhu a dohledatelnosti vůči Prohlášení o použitelnosti.

Proč jsou důkazy bezpečnosti již od návrhu nyní zásadní

Moderní regulace se sbližují kolem stejného očekávání: organizace musí včas identifikovat bezpečnostní rizika a rizika pro soukromí, přiřadit vlastnictví, zavést přiměřená opatření a uchovávat důkazy.

ISO/IEC 27001:2022 vyžaduje systém řízení bezpečnosti informací založený na rizicích. Kapitoly 6.1.2 a 6.1.3 vyžadují posouzení a ošetření rizik bezpečnosti informací. Kapitola 8.1 vyžaduje provozní plánování a řízení. Příloha A obsahuje bezpečnostní opatření, která musí být vybrána prostřednictvím Prohlášení o použitelnosti na základě rizik, právních požadavků a obchodních potřeb.

NIS2 přenáší stejný princip do správy a řízení kybernetické bezpečnosti. Article 20 vyžaduje, aby řídicí orgány schvalovaly opatření pro řízení rizik kybernetické bezpečnosti a dohlížely na jejich implementaci. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečnosti při pořizování, vývoji a údržbě, řízení zranitelností, kybernetické hygieny, šifrování, řízení přístupu, správy aktiv a vícefaktorové autentizace tam, kde je to vhodné.

DORA uplatňuje od 17. ledna 2025 optiku provozní odolnosti finančního sektoru. Vyžaduje, aby dotčené finanční subjekty udržovaly řádný, komplexní a dokumentovaný rámec řízení rizik v oblasti ICT, identifikovaly ICT aktiva a závislosti, uplatňovaly ochranná a preventivní opatření, detekovaly anomální činnost, testovaly digitální provozní odolnost, řídily rizika třetích stran v oblasti ICT a připravily schopnosti reakce a obnovy. Pro dotčené finanční subjekty je DORA odvětvovým právním aktem Unie pro překrývající se povinnosti podle NIS2.

GDPR přidává odpovědnost a ochranu osobních údajů již od návrhu a ve výchozím nastavení. Každý systém zpracovávající osobní údaje musí být schopen prokázat zákonné, korektní, transparentní, účelově omezené, minimalizované, časově omezené a bezpečné zpracování. Model hrozeb, který mapuje toky osobních údajů, přístupové cesty, logy, uchovávání, výmaz a předávání třetím stranám, je přímo relevantní pro GDPR Articles 5, 25, 32 and 35.

Akt o kybernetické odolnosti (CRA) vytváří další tlak u produktů s digitálními prvky. Produktové týmy potřebují důkazy za celý životní cyklus, které ukazují, že rizika kybernetické bezpečnosti, předvídatelné zneužití, rozhraní, mechanismy aktualizací, autentizační toky a předpoklady řízení zranitelností byly zohledněny včas.

Poučení je jasné: pokud přezkum architektury nelze dohledat k rizikům, opatřením, vlastníkům, zmírňujícím opatřením a testům, bude obtížné jej obhájit při auditu nebo regulačním přezkumu v roce 2026.

Model Clarysec: jeden model hrozeb, mnoho výstupů

Přístup Clarysec vychází z praktického principu: model hrozeb není dokončen, dokud nevytváří auditovatelná rozhodnutí.

V Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB] poskytuje fáze Řízení rizik, krok 9, týmům jednoduchý formát pro převod technických pozorování do jazyka rizik:

„Nyní spojte aktivum + hrozbu + zranitelnost do stručného popisu scénáře rizika. V podstatě popište možný incident. Později z toho bude řádková položka v registru rizik. Použijte jednoduchý formát: ‚[Hrozba] zneužije [zranitelnost] na [aktivu], což vede k [dopadu].‘“

Tato věta je mostem mezi vývojem a souladem.

Poznámka na tabuli typu „riziko podvržení identity u partnerského API“ se změní na:

„Útočník zneužije slabou autentizaci partnerského API na API pro hodnocení transakčních rizik, což vede k neoprávněnému přístupu k rozhodnutím o platebních rizicích a expozici osobních údajů.“

Zjištění nyní obsahuje aktivum, hrozbu, zranitelnost a dopad. Lze je posoudit, přiřadit, ošetřit, otestovat a akceptovat.

Vrstva politik zajišťuje opakovatelnost. P24 Secure Development Policy [P24] stanoví:

„Všechny nové aplikace a významné změny musí před zahájením vývoje projít přezkumem bezpečnostní architektury a modelováním hrozeb.“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.

Dále vyžaduje:

„Přezkumy návrhu musí dokumentovat diagramy toků dat, hranice důvěry a opatření ke zmírnění identifikovaných rizik.“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.2.

Tato dvě ustanovení jsou silnými auditními kotvami. Ukazují, že modelování hrozeb není volitelné a že důkazy k návrhu musí obsahovat diagramy, hranice a rozhodnutí o zmírnění rizik.

P06 Risk Management Policy [P06] propojuje modelování hrozeb s podnikovým řízením rizik:

„Všechny obchodní jednotky musí proaktivně identifikovat rizika pomocí strukturovaných technik odvozených z ISO/IEC 27005:2024, včetně modelování hrozeb, mapování závislostí aktiv a identifikace rizik na základě scénářů.“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.

Dále uvádí:

„Identifikovaná rizika musí být dokumentována s odkazem na vlastníka aktiva, aktéra hrozby, zranitelnost a možný dopad na důvěrnost, integritu a dostupnost (CIA).“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.4.

Toto je řetězec důkazů, který auditoři chtějí vidět: požadavek politiky, návrhová činnost, scénář rizika, výběr opatření, implementace, testování a schválení.

STRIDE zajišťuje systematické pokrytí, scénáře zneužití ho převádějí do praxe

STRIDE zůstává jednou z nejužitečnějších metod modelování hrozeb ve fázi návrhu, protože nutí týmy posoudit šest běžných způsobů selhání:

• podvržení identity,
• manipulace,
• popření provedení akce,
• zpřístupnění informací,
• odepření služby,
• zvýšení oprávnění.

U Anyiny platformy pro hodnocení platebních rizik tým použil STRIDE na každou komponentu, tok dat a hranici důvěry.

Podvržení identity otevřelo otázku, zda by klient partnerského API mohl vystupovat jako bankovní zákazník, pokud by vzájemná autentizace byla slabá. Manipulace odhalila riziko, že signály zařízení nebo částky transakcí mohou být před příjmem dat upraveny. Popření provedení akce zdůraznilo potřebu auditních logů administrátorů a transakcí. Zpřístupnění informací se zaměřilo na únik přes logy, exporty analytiky, nástroje podpory a reportovací API. Odepření služby přinutilo tým posoudit špičková transakční okna a záplavy nevalidních požadavků. Zvýšení oprávnění odhalilo rizika v rolích podpory, tokenech relací a administrátorských funkcích.

Scénáře zneužití převedly tyto kategorie do reálných příběhů:

• Podvodník nahraje zmanipulované signály zařízení, aby ovlivnil skóre rizika.
• Kompromitované partnerské přihlašovací údaje zahltí API podvodnými požadavky.
• Vývojář použije produkční osobní údaje v testovacím prostředí.
• Škodlivý insider vyexportuje identifikátory zákazníků a logiku skórování.
• Výpadek dodavatele cloudové analytiky zablokuje rozhodování o riziku během platebního okna.
• Chybná konfigurace úložiště zpřístupní nahrané doklady identity.
• Pracovní postup výmazu odstraní aplikační záznam, ale ponechá zálohy a kopie u dodavatelů.

Každý scénář zneužití se stal záznamem o návrhovém riziku s dotčeným aktivem, aktérem hrozby, zranitelností, dopadem, stávajícími předpoklady, požadovaným zmírněním, vlastníkem zbytkového rizika, testovacími důkazy a regulační relevancí.

Tato struktura brání vágním zjištěním typu „riziko zabezpečení API“. Vytváří riziková tvrzení v důkazní kvalitě, například:

„Útočník použije odcizené partnerské přihlašovací údaje k odesílání podvodných požadavků na skórování přes API pro hodnocení transakčních rizik, což vede k narušení integrity rozhodnutí o riziku, možné finanční ztrátě zákazníků a neoprávněnému zpracování osobních údajů.“

Mapování modelování hrozeb na ISO/IEC 27001:2022 a ISO/IEC 27002:2022

ISO/IEC 27001:2022 modelování hrozeb výslovně nevyžaduje. Vyžaduje konzistentní, dokumentované posouzení rizik a ošetření rizik. Modelování hrozeb je jednou z nejsilnějších metod pro vytváření těchto důkazů v softwarových, cloudových a produktových prostředích.

Klíčová je dohledatelnost. V ZB fáze Řízení rizik, krok 13, doporučuje mapovat opatření na rizika a kapitoly, včetně odkazů na Přílohu A v plánech ošetření rizik a poznámek, kde opatření podporují GDPR, NIS2 nebo DORA.

Zenith Controls: The Cross-Compliance Guide [ZC] pomáhá tuto dohledatelnost strukturovat tím, že mapuje opatření ISO/IEC 27002:2022 na související opatření, auditní očekávání a externí rámce.

Pro modelování hrozeb je opatření ISO/IEC 27002:2022 5.8, bezpečnost informací v projektovém řízení, kotvou projektového řízení. Ukazuje, že bezpečnost je integrována do zahájení, plánování, realizace a akceptace projektu.

Opatření 8.25, životní cyklus bezpečného vývoje, je kotvou SDLC. ZC propojuje 8.25 s podpůrnými opatřeními, jako jsou 8.26 požadavky na zabezpečení aplikací, 8.27 principy bezpečné systémové architektury a inženýrství, 8.28 bezpečné kódování, 8.29 bezpečnostní testování během vývoje a akceptace, 8.30 outsourcovaný vývoj a 8.31 oddělení vývojových, testovacích a produkčních prostředí.

Toto mapování pomáhá převést návrhový workshop na důkazy pro Prohlášení o použitelnosti. Podporuje také kapitoly 4 až 6 ISO/IEC 27001:2022, protože zviditelňuje požadavky zainteresovaných stran, rozsah ISMS, závazky vedení a rozhodnutí o ošetření rizik.

Mapa napříč rámci pro NIS2, DORA, CRA, GDPR a NIST CSF

Dobře vedený model hrozeb nemá vytvářet pět oddělených pracovních proudů pro soulad. Má vytvořit jeden balíček důkazů k návrhovým rizikům, který lze opakovaně využít napříč rámci.

NIST CSF 2.0 je obzvlášť užitečný pro komunikaci s vrcholovým vedením. Jeho funkce GOVERN podporuje právní, regulační, smluvní povinnosti a povinnosti v oblasti soukromí, zatímco výstupy pro dodavatelský řetězec pomáhají propojit kritičnost dodavatelů, smluvní požadavky, náležitou péči, monitorování a plánování incidentů se stejnými důkazy z modelu hrozeb.

GDPR vyžaduje zvláštní pozornost, protože modelování hrozeb a práce na DPIA se mají vzájemně posilovat. P17 Data Protection and Privacy Policy [P17] stanoví:

„Modelování hrozeb a posouzení vlivu na ochranu osobních údajů (DPIA) jsou povinné pro vysoce rizikové systémy zpracování.“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.3.4.

Pro menší týmy P17S Data Protection and Privacy Policy - SME [P17S] stanoví:

„Ochrana soukromí již od návrhu a ve výchozím nastavení musí být vynucována ve všech nových systémech a službách.“
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.1.

Výsledkem je praktický provozní model: používejte stejné diagramy toků dat, hranice důvěry a scénáře zneužití pro bezpečnostní rizika, rizika pro soukromí, přezkum dodavatelů a regulační důkazy.

Devadesátiminutový sprint návrhových rizik pro vysoce rizikové funkce

Modelování hrozeb nemusí začínat jako rozsáhlý program. U nového platebního API, onboardingového pracovního postupu, funkce rozšířené o AI, služby identity, migrace do cloudu nebo externí integrace může devadesátiminutový sprint návrhových rizik vytvořit cenné důkazy.

1. Otevřete projektový bezpečnostní kontrolní bod

Použijte ustanovení P24 6.1.1 jako spouštěč. Pro každou novou aplikaci nebo významnou změnu vytvořte složku důkazů obsahující:

• architektonický diagram,
• diagram toku dat,
• mapu hranic důvěry,
• seznam aktiv,
• poznámky k osobním údajům,
• seznam dodavatelských a ICT závislostí,
• počáteční bezpečnostní požadavky,
• pracovní list modelu hrozeb,
• položky registru rizik,
• dohledatelnost zmírňujících opatření a testů,
• záznam o schválení.

Pro menší organizace podporuje P24S Secure Development Policy - SME [P24S] stejnou disciplínu tím, že propojuje procesy bezpečného vývoje s řízením přístupu vývojářů, testováním, modelováním hrozeb a dokumentací. Zároveň vyžaduje centralizované uchovávání kontrolních seznamů, schválení přezkumů, zpráv o testování a evidencí komponent pro účely auditu. Ustanovení 11.3.1 odkazuje na SA-3 až SA-15 pro definici procesů bezpečného vývoje včetně modelování hrozeb.

2. Nakreslete minimálně použitelný tok dat

Nezačínejte vybroušeným diagramem. Začněte toky, které vytvářejí riziko:

• Uživatel nahrává doklady identity nebo transakční data.
• Webová aplikace odesílá požadavky do API.
• API zapisuje do spravovaného úložiště nebo databáze.
• Dodavatel přijímá ověřovací nebo analytická data.
• Interní analytický portál zobrazuje výsledky.
• Zákaznický systém získává stav nebo rozhodnutí.
• Logy, monitorovací nástroje a zálohy přijímají kopie.

Označte každou hranici důvěry: internet–aplikace, aplikace–API, interní služba–dodavatel, produkční systém–analytika, administrátor–privilegovaná funkce a produkční prostředí–neprodukční prostředí.

3. Spusťte STRIDE a scénáře zneužití společně

U každé hranice položte otázky STRIDE a zapište scénáře zneužití běžným obchodním jazykem. Cílem není vypsat každý myslitelný útok. Cílem je identifikovat realistické a významné scénáře, které ovlivňují důvěrnost, integritu, dostupnost, soukromí, odolnost nebo bezpečnost.

4. Převeďte zjištění do scénářů rizik

Použijte vzorec z ZB kroku 9:

„[Hrozba] zneužije [zranitelnost] na [aktivu], což vede k [dopadu].“

Například:

„Útočník zneužije slabé řízení přístupu k objektovému úložišti v repozitáři dokladů identity, což vede k neoprávněnému zpřístupnění osobních údajů a expozici vůči regulační oznamovací povinnosti.“

Poté doplňte vlastníka, pravděpodobnost, dopad, inherentní riziko, možnost ošetření, cílové opatření, zbytkové riziko a důkazy.

5. Odvoďte požadavky a testy

Model hrozeb není hotový ve chvíli, kdy jsou rizika vypsána. Je hotový tehdy, když jsou zmírňující opatření implementována, otestována nebo formálně akceptována.

Change Management Policy - SME poskytuje praktický spouštěč:

„Pokud změna zahrnuje citlivá data, přístupová práva k systémům nebo externí integrace, je vyžadován přezkum bezpečnostních dopadů. Určená kontaktní osoba pro bezpečnost nebo soulad musí posoudit, zda změna zavádí další rizika, a doporučit další ochranná opatření.“
Ze sekce „Ošetření rizik a výjimky“, ustanovení politiky 7.5.1.

Citlivá data, přístupová práva a externí integrace jsou přesně ty změny, které vyžadují přezkum návrhových rizik.

Na co se budou ptát různí auditoři

Auditor ISO/IEC 27001:2022 se zeptá, zda je modelování hrozeb součástí definovaného procesu posouzení rizik, zda jsou kritéria konzistentní, zda vlastníci rizik schválili zbytková rizika, zda plány ošetření rizik odkazují na SoA a zda jsou důkazy uchovávány. Bude hledat opakovatelnost, historii verzí, viditelnost v přezkoumání vedením a pokrytí interním auditem.

U Přílohy A propojí důkazy s 5.8, 8.25, 8.26, 8.27 a 8.29. ZB krok 21, Controls in Action, zdůrazňuje principy bezpečné systémové architektury a inženýrství otázkou, jaké principy řídí bezpečnou architekturu. Auditoři se mohou ptát, zda se modelování hrozeb provádí během návrhu pomocí metod, jako je STRIDE nebo stromy útoků, a zda se architektonická rozhodnutí přezkoumávají před implementací.

Přezkoumávající osoba podle NIS2 se zaměří na správu a řízení a přiměřenost. Může se ptát, zda vedení schválilo přístup k řízení rizik kybernetické bezpečnosti, zda je pokryto bezpečné pořizování, vývoj a údržba, zda se zohledňují zranitelnosti dodavatelů, zda scénáře incidentů navazují na oznamovací pracovní postupy a zda se analyzují scénáře kontinuity. Stupňované hlášení významných incidentů podle NIS2 Article 23, včetně včasného varování do 24 hodin, oznámení do 72 hodin a závěrečné zprávy do jednoho měsíce, činí jasnost scénářů zvlášť cennou.

Kontrolor podle DORA se zaměří na řízení rizik v oblasti ICT, kritické funkce, ICT aktiva, externí závislosti, testování odolnosti a ICT služby třetích stran. Pokud systém podporuje kritickou nebo důležitou funkci, bude očekávat silnější důkazy propojující scénáře hrozeb s evidencí aktiv, mapami závislostí, plány testování, smlouvami s třetími stranami a opatřeními obnovy.

Přezkoumávající osoba pro ochranu soukromí zkontroluje toky dat a zeptá se, zda je zpracování osobních údajů nezbytné, zákonné, minimalizované a chráněné. Bude se ptát, zda jsou zahrnuty zvláštní kategorie údajů, zda se používá pseudonymizace nebo šifrování, zda je odůvodněno uchovávání a zda je vyžadováno DPIA. Modelování hrozeb a DPIA jsou odlišné činnosti, ale měly by sdílet diagramy, scénáře a zmírňující opatření.

Přezkoumávající osoba orientovaná na NIST CSF nebo COBIT 2019 bude hledat správu a řízení, vlastnictví procesů, výkonnost, odpovědnost a neustálé zlepšování. Samotný pracovní list STRIDE pro ni může být méně důležitý než to, zda je proces spolehlivý, měřený, schválený a zlepšovaný.

Častá selhání důkazů z modelování hrozeb

Nejčastější selhání nejsou technická. Jsou to selhání v důkazech.

Týmy provádějí modelování hrozeb příliš pozdě, až po vytvoření systému. V tu chvíli se workshop stává přípravou před penetračním testem místo návrhového opatření.

Zjištění nejsou převedena do jazyka rizik. „Přidat autentizaci“ nebo „problém s protokolováním“ může pomoci vývojářům, ale auditoři potřebují aktivum, hrozbu, zranitelnost, dopad, vlastníka, ošetření a zbytkové riziko.

Ochrana soukromí a bezpečnost jsou oddělené. Jeden tým dokumentuje riziko podvržení identity a útoky typu injection, zatímco jiný dokumentuje uchovávání a právní základ. Odpovědnost podle GDPR funguje lépe, když jsou toky dat, scénáře zneužití a spouštěče DPIA propojeny.

Předpoklady týkající se dodavatelů zůstávají nedokumentované. NIS2, DORA a NIST CSF zvyšují očekávání pro rizika dodavatelského řetězce ICT. Pokud zmírňující opatření závisí na šifrování, protokolování, výmazu, odolnosti nebo reakci na incidenty dodavatele, shromážděte důkazy.

Testy nejsou namapovány zpět na hrozby. Zpráva z penetračního testování může být užitečná, ale nemusí prokázat, že konkrétní návrhová rizika byla zmírněna. Každé významné zjištění hrozby má mít validační důkazy.

Přijetí zbytkového rizika je neformální. „Pro MVP to akceptujeme“ nestačí. ISO/IEC 27001:2022 očekává přijetí zbytkového rizika příslušnými vlastníky rizik jako dokumentované informace.

Váš balíček důkazů z modelování hrozeb pro rok 2026

Pro každý významný systém nebo významnou změnu uchovávejte standardní balíček důkazů, který může podpořit ISO 27001, NIS2, DORA, CRA, GDPR a ujištění zákazníků.

Risk Management Policy - SME dobře vystihuje provozní model:

„Zajišťuje, že řízení rizik je aktivní součástí plánování, realizace projektů, výběru dodavatelů a reakce na incidenty, v souladu s ISO 27001, ISO 31000 a použitelnými regulačními požadavky.“
Ze sekce „Účel“, ustanovení politiky 1.2.

To je správný cíl. Modelování hrozeb má ovlivňovat plánování, vývoj, výběr dodavatelů, reakci na incidenty a připravenost na audit.

Připravte modelování hrozeb na audit před dalším vydáním

Organizace, které nejlépe zvládnou tlak na soulad v roce 2026, nejsou ty s největším počtem diagramů. Jsou to ty, které dokážou prokázat jednoduchý řetězec:

Návrhové riziko bylo identifikováno. Riziko bylo posouzeno. Opatření byla vybrána. Zmírňující opatření byla implementována. Testy validovaly zmírňující opatření. Zbytkové riziko bylo schváleno. Důkazy jsou namapovány na relevantní rámce.

Začněte jednou vysoce rizikovou změnou: platební integrací, novým API, pracovním postupem rozšířeným o AI, funkcí identity, migrací do cloudu, vydáním produktu pro zákazníky nebo službou napojenou na dodavatele. Proveďte devadesátiminutový sprint návrhových rizik. Použijte ZB k převodu zjištění do scénářů rizik, plánů ošetření rizik a dohledatelnosti SoA. Použijte ZC k mapování opatření ISO/IEC 27002:2022, jako jsou 5.8, 8.25, 8.26, 8.27 a 8.29, na podpůrná opatření, dodavatelské riziko, soukromí, testování a auditní důkazy. Slaďte P24, P06, P17, P24S a svůj postup řízení změn tak, aby modelování hrozeb bylo povinné, opakovatelné a přezkoumatelné.

Pokud chcete, aby vám Clarysec pomohl, začněte přezkumem důkazů z modelování hrozeb. Posoudíme jeden skutečný projekt, identifikujeme mezery vůči očekáváním ISO/IEC 27001:2022, NIS2, DORA, CRA a GDPR a připravíme praktický plán nápravy, kterému budou rozumět vaši vývojáři, auditoři i představenstvo.