Auditně připravené posouzení rizik podle ISO 27001 pro NIS2 a DORA

Káva na Sářině stole vystydla.

Jako CISO rychle rostoucí fintech společnosti byla na tlak zvyklá. Společnost právě získala významného bankovního partnera a dotazník due diligence na její obrazovce měl být formalitou. První otázky byly známé: předložte Prohlášení o použitelnosti podle ISO/IEC 27001:2022, sdílejte poslední registr rizik, vysvětlete metodiku hodnocení rizik.

Pak se dotazník změnil.

Doložte, jak váš program řízení rizik pokrývá DORA. Vysvětlete připravenost na NIS2, včetně odpovědnosti vedení a opatření pro rizika dodavatelského řetězce. Poskytněte důkazy, že kritičtí dodavatelé ICT jsou posuzováni, monitorováni a zahrnuti do plánů reakce na incidenty a kontinuity činností.

V pondělí ráno byl stejný problém na programu rizikového výboru správní rady. Certifikační audit ISO 27001 za osm týdnů. Tlak DORA ze strany zákazníků z finančního sektoru. Klasifikační otázky podle NIS2 pro službu hostovanou v cloudu, která expanduje do EU. Nákup tvrdil, že přezkumy dodavatelů existují, ale důkazy byly rozdělené mezi e-maily, smluvní složky a tabulku dodavatelů. Právní oddělení uvedlo, že regulatorní mapování stále probíhá. Technický tým řekl, že registr rizik je z větší části hotový.

Správní rada položila jedinou otázku, na které záleželo:

Dokážeme prokázat, že naše posouzení rizik a plán ošetření rizik jsou dostatečné?

To je skutečný problém pro SaaS, fintech, poskytovatele řízených služeb, cloudové služby a digitální platformy. Ne to, zda existuje registr rizik. Ne to, zda byla opatření z Annex A zkopírována do tabulky. Podstatné je, zda organizace dokáže při auditu a pod tlakem zákazníků doložit, že její proces posouzení rizik podle ISO 27001 je opakovatelný, založený na rizicích, schválený vlastníky rizik, propojený s opatřeními k ošetření rizik, namapovaný na právní povinnosti a provozně živý.

Je-li provedeno dobře, jedno posouzení rizik podle ISO 27001 a jeden plán ošetření rizik mohou podpořit certifikaci podle ISO/IEC 27001:2022, opatření k řízení rizik kybernetické bezpečnosti podle NIS2 Article 21, požadavky DORA na řízení rizik v oblasti ICT, odpovědnost podle GDPR, dodavatelské ujištění, připravenost na incidenty a reporting správní radě.

Je-li provedeno špatně, stane se z něj tabulka, kterou auditoři rozeberou za třicet minut.

Tento průvodce ukazuje, jak Clarysec vytváří auditně připravené důkazy pro posouzení rizik a ošetření rizik podle ISO 27001 s využitím Zenith Blueprint: 30krokový plán auditora, politik Clarysec a Zenith Controls: průvodce napříč předpisy.

Proč je posouzení rizik podle ISO 27001 nyní středem souladu

Regulatorní prostředí EU se sbližuje kolem jednoduchého principu: riziko kybernetické bezpečnosti musí být řízeno, dokumentováno, testováno a musí mít jasného vlastníka.

ISO/IEC 27001:2022 takto již funguje. Clauses 4.1 až 4.4 vyžadují, aby organizace před posuzováním rizik porozuměla svému kontextu, zainteresovaným stranám, rozsahu ISMS a vzájemným vazbám procesů. Clauses 6.1.2 a 6.1.3 vyžadují definovaný proces posouzení rizik bezpečnosti informací a ošetření rizik. Clauses 8.2 a 8.3 vyžadují, aby organizace prováděla posouzení rizik a implementovala plán ošetření rizik při zachování dokumentovaných informací.

NIS2 a DORA činí stejnou logiku založenou na rizicích naléhavější.

NIS2 Article 20 vyžaduje, aby řídicí orgány základních a důležitých subjektů schvalovaly opatření k řízení rizik kybernetické bezpečnosti, dohlížely na jejich implementaci a absolvovaly školení v kybernetické bezpečnosti. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření pro řízení rizik ohrožujících síťové a informační systémy. Tato opatření zahrnují analýzu rizik, zvládání incidentů, kontinuitu činností, bezpečnost dodavatelského řetězce, bezpečný vývoj, práci se zranitelnostmi, posuzování účinnosti, kybernetickou hygienu, kryptografii, bezpečnost HR, řízení přístupu, správu aktiv a vícefaktorovou autentizaci nebo zabezpečenou komunikaci tam, kde je to vhodné.

DORA vytváří obdobný tlak na finanční subjekty. Articles 5 a 6 vyžadují, aby řídicí orgán definoval, schvaloval a dohlížel na uspořádání řízení rizik v oblasti ICT a nesl za ně odpovědnost. DORA očekává dokumentovaný rámec řízení rizik v oblasti ICT integrovaný do celkového řízení rizik, podporovaný politikami, postupy, protokoly, nástroji, interním auditem, nápravou, kontinuitou, testováním, řízením incidentů a řízením třetích stran v oblasti ICT.

Závěr je praktický a nevyhnutelný: registr rizik už není pracovní tabulkou technického týmu. Je důkazem správy a řízení.

Podniková Politika řízení rizik od Clarysec toto očekávání výslovně stanoví:

Musí být udržován formální proces řízení rizik v souladu s ISO/IEC 27005 a ISO 31000, který pokrývá identifikaci rizik, analýzu, hodnocení, ošetření, monitorování a komunikaci.

Z podnikové Politiky řízení rizik, oddíl „Požadavky na správu a řízení“, ustanovení politiky 5.1.

Tatáž politika definuje auditně připravený výsledek:

Udržovat centralizovaný, verzovaný registr rizik a plán ošetření rizik odrážející aktuální stav rizik, pokrytí kontrolami a postup zmírňování.

Z podnikové Politiky řízení rizik, oddíl „Cíle“, ustanovení politiky 3.3.

Právě formulace „aktuální stav rizik, pokrytí kontrolami a postup zmírňování“ odlišuje statický soubor pro soulad od obhajitelného programu řízení rizik.

Začněte rozsahem, povinnostmi a kritérii rizik

Mnoho slabých posouzení rizik podle ISO 27001 začíná kontrolním seznamem opatření. To je opačný postup.

ISO 27001 vyžaduje, aby organizace před výběrem opatření určila kontext, požadavky zainteresovaných stran, rozsah ISMS, odpovědnosti vedení a plánování rizik. ISO/IEC 27005:2022 to posiluje doporučením, aby organizace před posuzováním rizik identifikovaly základní požadavky zainteresovaných stran. Tyto požadavky mohou vyplývat z norem ISO, sektorových regulací, vnitrostátních právních předpisů, zákaznických smluv, interních politik, předchozích činností ošetření rizik a povinností vůči dodavatelům.

U SaaS nebo fintech společnosti působící vůči EU by měl proces řízení rizik začínat inventarizací souladu a povinností.

Pro malé a střední podniky nastavuje výchozí bod Politika právního a regulatorního souladu pro MSP od Clarysec:

Generální ředitel musí vést jednoduchý, strukturovaný registr souladu, který uvádí:

Z Politiky právního a regulatorního souladu pro MSP, oddíl „Požadavky na správu a řízení“, ustanovení politiky 5.1.1.

Tento jednoduchý registr je mostem mezi souladem a řízením rizik. Pokud uvádí, že se GDPR použije, protože jsou zpracovávány osobní údaje z EU, že NIS2 se může použít, protože organizace poskytuje digitální nebo řízené služby, nebo že DORA je relevantní prostřednictvím zákazníků z finančního sektoru, musí tyto povinnosti ovlivnit kritéria rizik a priority ošetření.

Zenith Blueprint je v tomto bodě ve fázi řízení rizik, kroku 10 „Stanovení kritérií rizik a matice dopadů“, přímočarý:

V kritériích akceptace zohledněte také právní/regulatorní požadavky. Některá rizika mohou být nepřijatelná bez ohledu na pravděpodobnost z důvodu právních předpisů.

Ze Zenith Blueprint, fáze řízení rizik, krok 10.

Uvádí také praktické pravidlo pro workshopy:

„Jakékoli riziko, které by mohlo vést k nesouladu s použitelnými právními předpisy (GDPR atd.), není přijatelné a musí být zmírněno.“

Ze Zenith Blueprint, fáze řízení rizik, krok 10.

Pro Sářin fintech to mění model skórování. Zranitelnost dodavatelského API může mít nízkou pravděpodobnost, ale pokud by její zneužití mohlo vyvolat závažný incident související s ICT podle DORA, významný incident podle NIS2, posouzení porušení zabezpečení podle GDPR, porušení zákaznické SLA nebo eskalaci na úroveň správní rady, dopad je vysoký nebo kritický. Expozice vůči povinnostem souladu se stává součástí logiky rizik, nikoli samostatnou tabulkou.

Vytvořte registr rizik, který mohou auditoři testovat

Auditoři se neptají pouze na vaše nejvýznamnější rizika. Testují, zda je vaše metoda definovaná, opakovatelná, dohledatelná a dodržovaná.

Budou se ptát:

• Jak jste tato rizika identifikovali?
• Která aktiva, služby, dodavatelé, typy dat a procesy byly v rozsahu?
• Jaká kritéria byla použita pro pravděpodobnost a dopad?
• Kdo vlastní každé riziko?
• Které stávající kontroly riziko snižují?
• Proč bylo zvoleno dané rozhodnutí o ošetření?
• Kde jsou důkazy, že ošetření proběhlo?
• Kdo schválil zbytkové riziko?
• Kdy bude riziko znovu posouzeno?

Politika řízení rizik pro MSP od Clarysec zachycuje minimální auditně připravenou položku rizika:

Každá položka rizika musí obsahovat: popis, pravděpodobnost, dopad, skóre, vlastníka a plán ošetření rizik.

Z Politiky řízení rizik pro MSP, oddíl „Požadavky na správu a řízení“, ustanovení politiky 5.1.2.

Pro podnikové programy Zenith Blueprint ve fázi řízení rizik, kroku 11 „Vytvoření a dokumentace registru rizik“, strukturu rozšiřuje. Doporučuje sloupce jako ID rizika, aktivum, hrozba, zranitelnost, popis rizika, pravděpodobnost, dopad, úroveň rizika, stávající kontroly, vlastník rizika, rozhodnutí o ošetření, plán ošetření rizik nebo kontroly a stav.

Silná položka rizika vypadá takto:

To je zásadně jiné než „riziko třetí strany, vysoké, zmírnit“. Auditně připravená verze propojuje aktivum, hrozbu, zranitelnost, následek, stávající kontroly, vlastníka, právní předpis, důkazy a správu a řízení.

Přeměňte ošetření rizik na plán důkazů

Plán ošetření rizik musí odpovědět na čtyři provozní otázky:

1. Co uděláme?
2. Kdo za to odpovídá?
3. Kdy to bude dokončeno?
4. Jak prokážeme, že se riziko snížilo?

ISO/IEC 27001:2022 Clause 6.1.3 vyžaduje, aby organizace zvolila možnosti ošetření, určila nezbytná opatření, porovnala je s Annex A, aby předešla opomenutím, vytvořila Prohlášení o použitelnosti, formulovala plán ošetření rizik a získala schválení vlastníků rizik pro plán a zbytková rizika. Clause 8.3 následně vyžaduje implementaci plánu ošetření rizik a uchování dokumentovaných informací o výsledcích.

Podniková Politika řízení rizik to převádí do praxe:

Manažer rizik zajistí, aby ošetření byla realistická, časově ohraničená a namapovaná na opatření ISO/IEC 27001 Annex A.

Z podnikové Politiky řízení rizik, oddíl „Požadavky na implementaci politiky“, ustanovení politiky 6.4.2.

Politika pro MSP také objasňuje, že akceptace není zkratka:

Akceptovat: Zdůvodnit, proč není vyžadována žádná další akce, a zaznamenat zbytkové riziko.

Z Politiky řízení rizik pro MSP, oddíl „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.

Akceptace musí být odůvodněna vůči kritériím, schválena příslušným vlastníkem a monitorována. Podle NIS2 a DORA se neschválené zbytkové riziko může stát selháním správy a řízení.

Úplný plán ošetření rizik by měl obsahovat tato pole:

U Sářina R-042 se plán ošetření rizik mění na akční seznam napříč požadavky na soulad.

Tento plán je silný, protože vytváří přímou linii od jednoho rizikového scénáře k opatřením ISO 27001, povinnostem NIS2, článkům DORA, vlastníkům a důkazům.

Nechte Prohlášení o použitelnosti odvést více práce

Prohlášení o použitelnosti se často považuje za certifikační artefakt. Mělo by být něčím více.

ISO/IEC 27001:2022 Clause 6.1.3 vyžaduje, aby SoA obsahovalo nezbytná opatření, zdůvodnění jejich zahrnutí, stav implementace a zdůvodnění vyloučení. Pokyny ISO/IEC 27005:2022 posilují potřebu porovnat vybraná opatření s ISO/IEC 27001 Annex A, aby se předešlo opomenutím.

V auditně připraveném programu se SoA stává mostem mezi ošetřením rizik a důkazy napříč požadavky na soulad. Pokud plán ošetření rizik vyžaduje MFA, protokolování, monitorování dodavatelů, obnovu ze záloh, bezpečný vývoj, eskalaci incidentů nebo plánování ukončení cloudové služby, SoA by mělo ukázat, že příslušná opatření Annex A jsou zahrnuta, zdůvodněna, implementována nebo plánována a doložena.

To také pomáhá předejít častému selhání při auditu: registr rizik říká jednu věc, plán ošetření rizik druhou a SoA mlčí. Když si tyto artefakty odporují, auditoři rychle ztrácejí důvěru.

Mapování ošetření rizik podle ISO 27001 na NIS2, DORA a GDPR

ISO 27001 nenahrazuje NIS2, DORA ani GDPR. Poskytuje strukturovaný mechanismus, jak pro ně vytvářet důkazy.

Klíčem je zabudovat mapování do procesu řízení rizik, nikoli jej přidávat dodatečně.

Toto mapování je obzvlášť důležité tam, kde se regulace překrývají. DORA je sektorově specifický režim odolnosti ICT pro mnoho finančních subjektů, zatímco NIS2 může zůstat přímo relevantní pro určité poskytovatele, koordinaci nebo subjekty mimo rozsah DORA. Fintech může potřebovat DORA jako svůj primární rámec odolnosti ICT, zatímco poskytovatel řízených služeb podporující tento fintech může čelit povinnostem NIS2 přímo.

Registr rizik musí být schopen ukázat obě strany této závislosti.

Použijte Zenith Controls jako kompas napříč požadavky na soulad

Clarysec používá Zenith Controls jako průvodce napříč požadavky na soulad, aby předešel častému selhání, kdy opatření ISO, regulatorní články a auditní otázky existují v oddělených světech. Nevytváří samostatný rámec opatření. Mapuje oblasti opatření ISO/IEC 27001:2022 a ISO/IEC 27002:2022 na jiné normy, očekávání auditu a pohledy na soulad.

Pro posouzení rizik a ošetření rizik podle ISO 27001 jsou zvlášť důležité tyto odkazy:

Poučení napříč požadavky na soulad je jednoduché. Pokud právní povinnosti nejsou v metodě posouzení rizik, vaše skórování je neúplné. Pokud je skórování neúplné, priority ošetření mohou být chybné. Pokud jsou priority chybné, SoA a reporting správní radě se stávají nespolehlivými.

Zenith Blueprint uvádí totéž ve fázi řízení rizik, kroku 14 „Politiky ošetření rizik a regulatorní křížové odkazy“. Doporučuje organizacím vytvořit mapovací tabulku uvádějící klíčové regulatorní bezpečnostní požadavky a odpovídající opatření nebo politiky v ISMS. Pro certifikaci ISO 27001 to není povinné, ale je to velmi užitečné pro prokázání, že bezpečnost je řízena v právním a smluvním kontextu.

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

Certifikační auditor, posuzovatel zaměřený na NIS2, zákazník orientovaný na DORA, posuzovatel GDPR, hodnotitel podle NIST nebo praktik COBIT mohou zkoumat stejné důkazy, ale klást jiné otázky.

Proto záleží na architektuře důkazů. Stejná položka rizika by měla být dohledatelná od obchodního cíle k aktivu, hrozbě, zranitelnosti, kontrole, vlastníkovi, regulatornímu důvodu, opatření ošetření, výsledku testu a rozhodnutí vedení.

Politiky Clarysec jsou navrženy tak, aby tuto architekturu podporovaly. Podniková Politika řízení rizik v oddílu „Referenční normy a rámce“ uvádí:

Article 5: Nařizuje dokumentovaný rámec řízení rizik ICT, plně pokrytý strukturou této politiky, včetně mapování SoA a KRI.

Tím se politika mění ze statického dokumentu na auditní důkaz ukazující, že správa rizik ICT byla záměrně navržena s ohledem na DORA.

Častá zjištění, která narušují programy řízení rizik

Když Clarysec přezkoumává důkazy posouzení rizik a ošetření rizik podle ISO 27001, opakovaně se objevují stejná zjištění.

Zaprvé, kritéria rizik ignorují právní, regulatorní, smluvní, dodavatelské dopady a dopady na soukromí. To vede ke slabému skórování. Porušení zabezpečení osobních údajů nebo selhání kritického dodavatele může být hodnoceno jako střední, protože pravděpodobnost je nízká, přestože dopad podle GDPR, NIS2, DORA nebo na zákazníka by z něj měl učinit riziko vysoké nebo kritické.

Zadruhé, vlastníci rizik jsou generičtí. „IT“ není vlastník rizika. Vlastníkem rizika má být role nebo osoba odpovědná za rozhodnutí o ošetření, rozpočet, termíny a zbytkové riziko.

Zatřetí, plány ošetření rizik nejsou časově ohraničené. „Zlepšit monitorování“ není plán. „Nasadit upozornění na privilegované relace v SIEM pro produkční administrátorské účty do 30. června, vlastník manažer SOC, otestováno simulovaným administrátorským přihlášením, s přiloženými důkazy upozornění“ je plán.

Začtvrté, SoA je odpojeno od ošetření. Pokud plán ošetření rizik vyžaduje monitorování dodavatelů, testování záloh, eskalaci incidentů, MFA nebo protokolování, SoA má odrážet příslušná opatření a stav implementace.

Zapáté, zbytkové riziko není schváleno. ISO 27001 vyžaduje schválení plánu ošetření rizik a zbytkových rizik vlastníkem rizika. NIS2 a DORA to činí ještě důležitějším, protože odpovědnost vedení je výslovná.

Zašesté, dodavatelské riziko je považováno za administrativu nákupu. Podle NIS2 Article 21(2)(d) a DORA Articles 28 a 30 musí být dodavatelské riziko a riziko třetích stran v oblasti ICT součástí řízení rizik, nikoli roční dotazník uložený izolovaně.

Zasedmé, chybí důkazy o účinnosti. ISO 27001 Clause 6.1.1 vyžaduje vyhodnocování účinnosti plánovaných opatření. NIS2 zahrnuje posuzování účinnosti v Article 21(2)(f). DORA očekává testování a nápravu. Kontrola, která existuje, ale nikdy není testována, je slabým důkazem.

Politika řízení rizik pro MSP stanoví očekávání jasně:

Generální ředitel a koordinátor rizik musí zajistit, aby činnosti řízení rizik byly připravené na audit. Registr rizik a související opatření podléhají internímu a externímu auditu.

Z Politiky řízení rizik pro MSP, oddíl „Vynucování a dodržování“, ustanovení politiky 8.2.1.

Reporting správní radě bez zahlcení vedení

NIS2, DORA a ISO 27001 směřují k odpovědnosti vedení, ale správní rady nepotřebují každý řádek rizik. Potřebují reporting využitelný pro rozhodování.

Dobrý balíček rizik pro správní radu by měl ukazovat:

• Vysoká a kritická rizika podle domén
• Opožděná opatření ošetření
• Regulatorní rizika zahrnující NIS2, DORA, GDPR nebo smlouvy
• Dodavatelská rizika ovlivňující kritické nebo důležité služby
• Trendy incidentů a téměř vzniklých incidentů
• Zbytková rizika čekající na akceptaci
• Výsledky testů účinnosti kontrol
• Významné změny rozsahu, dodavatelů, technologií nebo právních předpisů
• Zjištění interního auditu a nápravná opatření

Clarysec obvykle doporučuje měsíční provozní přezkumy rizik a čtvrtletní přezkoumání vedením. Měsíční přezkumy se zaměřují na realizaci ošetření. Čtvrtletní přezkoumání se zaměřují na akceptaci, financování, prioritizaci, regulatorní expozici a strategická rozhodnutí o rizicích.

Tento rytmus podporuje také neustálé zlepšování. Posouzení rizik se mají aktualizovat při vzniku incidentů, objevení zranitelností, zavedení nových aktiv, změně technologií, změně dodavatelů, změně právních předpisů, změně zákaznických povinností nebo změně ochoty podstupovat riziko.

Implementační postup Clarysec

Jednotný program řízení rizik se vyhýbá odděleným tabulkám pro ISO, NIS2, DORA, GDPR a zákaznické ujištění. Praktický postup je:

1. Potvrďte rozsah ISMS, služby, aktiva, dodavatele, jurisdikce a zákaznické povinnosti.
2. Vytvořte nebo aktualizujte registr souladu s využitím Politiky právního a regulatorního souladu pro MSP, kde je to vhodné.
3. Definujte metodiku rizik, kritéria akceptace, škály pravděpodobnosti, škály dopadu a pravidla regulatorního dopadu.
4. Vytvořte registr rizik s využitím fáze řízení rizik v Zenith Blueprint a přístupu Clarysec k nástroji Risk Register and SoA Builder.
5. Identifikujte rizika založená na aktivech a scénářích, včetně scénářů dodavatelů, cloudu, soukromí, kontinuity, incidentů, zranitelností, bezpečného vývoje a přístupu.
6. Skórujte rizika pomocí kritérií, která zahrnují právní, regulatorní, smluvní, provozní, soukromí, dodavatelský a finanční dopad.
7. Vyberte možnosti ošetření: zmírnit, vyhnout se, přenést nebo akceptovat.
8. Namapujte nezbytná opatření na ISO/IEC 27001:2022 Annex A a pokyny ISO/IEC 27002:2022.
9. Vytvořte nebo aktualizujte Prohlášení o použitelnosti.
10. Namapujte ošetření na NIS2 Article 21, řízení rizik ICT a očekávání DORA vůči třetím stranám, odpovědnost podle GDPR a smluvní povinnosti zákazníků.
11. Shromážděte důkazy, ověřte účinnost kontrol a získejte schválení zbytkového rizika.
12. Připravte auditní balíček uspořádaný podle rizika, kontroly, regulace a důkazního artefaktu.
13. Promítněte výsledky do přezkoumání vedením, interního auditu, nápravných opatření a neustálého zlepšování.

Nejde o papírování samo pro sebe. Je to operační systém obhajitelné správy a řízení kybernetické bezpečnosti.

Vytvořte auditně připravený balíček ošetření rizik

Sářin příběh končí dobře, protože přestala považovat ISO 27001, NIS2 a DORA za oddělené projekty souladu. Použila posouzení rizik podle ISO 27001 jako centrální mechanismus, začlenila regulatorní povinnosti do kritérií rizik, namapovala opatření ošetření na Annex A a požadavky EU a shromáždila důkazy, kterým zákazníci, auditoři i správní rada rozuměli.

Vaše organizace může udělat totéž.

Použijte Zenith Blueprint: 30krokový plán auditora k definování kritérií rizik, vytvoření registru rizik, vytvoření plánu ošetření rizik a křížovému propojení regulatorních požadavků.

Použijte Zenith Controls: průvodce napříč předpisy k propojení oblastí opatření ISO/IEC 27001:2022 Annex A se správou a řízením, právním souladem, ujištěním a pohledy auditu.

Použijte Politiku řízení rizik, Politiku řízení rizik pro MSP a Politiku právního a regulatorního souladu pro MSP od Clarysec ke standardizaci vlastnictví, registrů, rozhodnutí o ošetření a auditně připravených důkazů.

Nejrychlejší praktický další krok je vzít deset nejvýznamnějších rizik a otestovat je proti pěti otázkám:

1. Je regulatorní dopad viditelný?
2. Je plán ošetření rizik časově ohraničený a má vlastníka?
3. Je každé ošetření namapováno na Annex A a SoA?
4. Je tam, kde je to použitelné, dokumentována relevance NIS2, DORA, GDPR nebo zákazníka?
5. Existují důkazy, že kontrola funguje?

Pokud je odpověď ne, Clarysec vám může pomoci přeměnit registr rizik na obhajitelný program ošetření rizik napříč požadavky na soulad, kterému mohou důvěřovat auditoři, regulační orgány, zákazníci i správní rady.