ISO 27001 SoA pro připravenost na NIS2 a DORA

Je pondělí 08:30 a Elena, CISO rychle rostoucího poskytovatele B2B FinTech SaaS, otevírá urgentní požadavek představenstva. Společnost právě získala certifikaci ISO/IEC 27001:2022, ale významný bankovní zájemce z EU klade náročnější otázky než v běžném bezpečnostním dotazníku.

Neptá se pouze na to, zda společnost šifruje data, používá MFA nebo má zprávu z penetračního testu. Chce vědět, zda platforma SaaS podporuje jeho povinnosti podle DORA, zda by poskytovatel mohl spadat do rozsahu NIS2 jako služba ICT nebo závislost digitální infrastruktury a zda Prohlášení o použitelnosti podle ISO 27001 dokáže odůvodnit každé zahrnuté opatření, každé vyloučené opatření a každý důkaz.

Představenstvo pokládá otázku, kterou každý CISO, manažer souladu i zakladatel SaaS slyší stále častěji:

Může naše ISO 27001 SoA prokázat připravenost na NIS2 a DORA?

Elena ví, že špatnou odpovědí by bylo spustit tři samostatné programy souladu: jeden pro ISO 27001, jeden pro NIS2 a jeden pro DORA. Vznikly by duplicitní důkazy, konfliktní vlastníci opatření a permanentní shon před každým zákaznickým posouzením. Lepší odpovědí je použít stávající ISMS jako provozní model pro soulad a Prohlášení o použitelnosti, tedy SoA, jako hlavní dokument dohledatelnosti.

SoA není jen tabulka pro certifikaci ISO. V prostředí kybernetické bezpečnosti a provozní odolnosti v EU jde o místo, kde organizace dokládá, proč opatření existují, proč jsou vyloučení obhajitelná, kdo každé opatření vlastní, jaké důkazy podporují implementaci a jak soubor opatření pokrývá NIS2, DORA, GDPR, zákaznické smlouvy a interní ošetření rizik.

Podniková Politika bezpečnosti informací společnosti Clarysec Politika bezpečnosti informací stanoví:

ISMS musí zahrnovat vymezené hranice rozsahu, metodiku hodnocení rizik, měřitelné cíle a dokumentovaná opatření odůvodněná v Prohlášení o použitelnosti (SoA).

Tento požadavek z kapitoly 6.1.2 Politiky bezpečnosti informací je základem auditně připraveného přístupu. SoA se musí stát mostem mezi povinnostmi, riziky, opatřeními, důkazy a rozhodnutími vedení.

Proč NIS2 a DORA změnily význam slova „použitelné“

Tradiční SoA podle ISO/IEC 27001:2022 často začíná jednoduchou otázkou: „Která opatření z přílohy A se vztahují k našemu plánu ošetření rizik?“ To je stále správně, ale pro poskytovatele SaaS, cloudu, řízených služeb, fintech a kritických dodavatelských řetězců to již nestačí.

NIS2 zvyšuje základní úroveň řízení rizik kybernetické bezpečnosti u základních a důležitých subjektů v EU. Pokrývá sektory, jako jsou digitální infrastruktura, poskytovatelé služeb cloud computingu, poskytovatelé služeb datových center, sítě pro doručování obsahu, poskytovatelé řízených služeb, poskytovatelé řízených bezpečnostních služeb, bankovnictví a infrastruktury finančních trhů. Členské státy musí identifikovat základní a důležité subjekty a poskytovatele služeb registrace doménových jmen. Mnoho technologických poskytovatelů, kteří dříve považovali regulaci kybernetické bezpečnosti za problém zákazníka, je nyní buď přímo v rozsahu, nebo vystaveno požadavkům smluvně přeneseným z vyšších úrovní dodavatelského řetězce.

NIS2 Article 21 vyžaduje přiměřená a úměrná technická, provozní a organizační opatření v oblastech analýzy rizik, bezpečnostních politik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování a vývoje, posuzování účinnosti opatření, kybernetické hygieny, školení, kryptografie, personální bezpečnosti, řízení přístupu, správy aktiv a autentizace, pokud je to vhodné. NIS2 Article 23 doplňuje postupná očekávání pro hlášení incidentů, včetně včasného varování, oznámení, aktualizací a závěrečné zprávy u významných incidentů.

DORA, Digital Operational Resilience Act, se použije od 17. ledna 2025 a zaměřuje se na finanční subjekty a jejich ekosystém rizik ICT. Pokrývá řízení rizik v oblasti ICT, hlášení incidentů souvisejících s ICT, hlášení provozních nebo bezpečnostních platebních incidentů u určitých subjektů, testování digitální provozní odolnosti, sdílení informací o kybernetických hrozbách, řízení rizik třetích stran v oblasti ICT, smluvní ujednání a dohled nad kritickými poskytovateli služeb třetích stran v oblasti ICT.

U finančních subjektů, které jsou zároveň základními nebo důležitými subjekty podle NIS2, funguje DORA jako odvětvový režim pro rovnocenné povinnosti v oblasti řízení rizik ICT a hlášení incidentů. Pro poskytovatele SaaS, cloudové poskytovatele, MSP a poskytovatele MDR obsluhující finanční zákazníky však praktická realita spočívá v tom, že očekávání DORA přicházejí prostřednictvím nákupu, smluv, práv na audit, povinností podpory při incidentech, plánování ukončení služby, transparentnosti subdodavatelů a důkazů o odolnosti.

To mění diskusi o SoA. Otázka již nezní: „Obsahuje příloha A toto opatření?“ Lepší otázka zní:

Dokážeme prokázat, že výběr opatření vychází z rizik, zohledňuje povinnosti, je přiměřený, má vlastníky, je implementovaný, monitorovaný, doložený důkazy a schválený?

ISO 27001 je univerzálním překladačem pro NIS2 a DORA

ISO/IEC 27001:2022 je cenná, protože jde o normu systému řízení, nikoli o úzký kontrolní seznam. Vyžaduje, aby byl ISMS začleněn do procesů organizace a přizpůsoben jejím potřebám. Díky tomu je účinným univerzálním překladačem překrývajících se požadavků na soulad.

Kapitoly 4.1 až 4.4 vyžadují, aby organizace porozuměla svému kontextu, identifikovala zainteresované strany, určila relevantní požadavky a vymezila rozsah ISMS. U poskytovatele FinTech SaaS, jako je Elenina společnost, mohou požadavky zainteresovaných stran zahrnovat zákazníky z EU, finanční zákazníky dotčené DORA, sektorovou expozici vůči NIS2, povinnosti správce a zpracovatele podle GDPR, outsourcované cloudové závislosti, rozhraní dodavatelů a očekávání představenstva.

Kapitoly 6.1.1 až 6.1.3 vyžadují plánování rizik a příležitostí, opakovatelný proces posouzení rizik bezpečnosti informací, proces ošetření rizik, porovnání s přílohou A a Prohlášení o použitelnosti, které identifikuje zahrnutá opatření, stav implementace a odůvodnění vyloučení.

Zde se SoA stává záznamem rozhodnutí o opatřeních. Opatření může být zahrnuto proto, že ošetřuje riziko, splňuje právní požadavek, naplňuje zákaznickou smlouvu, podporuje obchodní cíl nebo představuje základní bezpečnostní hygienu. Opatření může být vyloučeno pouze poté, co jej organizace vědomě posoudila, zjistila, že není relevantní pro rozsah ISMS, zdokumentovala odůvodnění a získala odpovídající schválení.

Podniková Politika řízení rizik společnosti Clarysec Politika řízení rizik stanoví:

Prohlášení o použitelnosti (SoA) musí odrážet všechna rozhodnutí o ošetření rizik a musí být aktualizováno vždy, když se změní pokrytí opatřeními.

Tento požadavek z kapitoly 5.4 Politiky řízení rizik je zásadní pro připravenost na NIS2 a DORA. Nový regulovaný zákazník, nová cloudová závislost, nová oznamovací povinnost k incidentům nebo nové riziko koncentrace dodavatelů mohou změnit použitelnost opatření.

Začněte registrem souladu, nikoli seznamem opatření

Slabé SoA začíná přílohou A a ptá se: „Která opatření už máme?“ Silné SoA začíná provozní realitou organizace a ptá se: „Jaké povinnosti, služby, rizika, data, dodavatele a zákazníky musí ISMS řešit?“

ISO/IEC 27005:2022 tento přístup podporuje důrazem na požadavky zainteresovaných stran, kritéria rizik a nutnost zohlednit normy, interní pravidla, zákony, právní předpisy, smlouvy a stávající opatření. Zároveň zdůrazňuje, že nepoužitelnost nebo nesoulad musí být vysvětleny a odůvodněny.

Politika právního a regulačního souladu pro SME společnosti Clarysec Politika právního a regulačního souladu pro SME zachycuje stejný provozní princip:

Generální ředitel musí udržovat jednoduchý, strukturovaný registr souladu, který uvádí:

Tento požadavek vychází z kapitoly 5.1.1 Politiky právního a regulačního souladu pro SME. U menší organizace může být registr jednoduchý. U podniku by měl být podrobnější. Logika je stejná: povinnosti musí být viditelné dříve, než je lze mapovat.

Podniková Politika právního a regulačního souladu společnosti Clarysec Politika právního a regulačního souladu je explicitní:

Veškeré právní a regulační povinnosti musí být v rámci systému řízení bezpečnosti informací (ISMS) namapovány na konkrétní politiky, opatření a vlastníky.

To je kapitola 6.2.1 Politiky právního a regulačního souladu. Jde o páteř správy pro využití Prohlášení o použitelnosti podle ISO 27001 k připravenosti na soulad s NIS2 a DORA.

Vytvořte kritéria rizik, která zohledňují odolnost, soukromí, dodavatele a regulaci

Mnohá odůvodnění v SoA selhávají, protože model hodnocení rizik je příliš úzký. Měří technickou pravděpodobnost a dopad, ale nezachycuje regulační expozici, kritičnost služby, újmu zákazníka, závislost na dodavateli, dopad na soukromí ani systémové provozní narušení.

NIS2 není pouze o důvěrnosti. Zaměřuje se na prevenci a minimalizaci dopadu incidentů na služby a jejich příjemce. DORA definuje kritické nebo důležité funkce podle toho, zda by narušení podstatně zhoršilo finanční výkonnost, kontinuitu služeb nebo regulační soulad. GDPR doplňuje odpovědnost, integritu, důvěrnost, připravenost na porušení zabezpečení a újmu subjektu údajů.

Politika řízení rizik pro SME společnosti Clarysec Politika řízení rizik pro SME stanoví praktické minimum:

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

To je kapitola 5.1.2 Politiky řízení rizik pro SME. Pro připravenost na NIS2 a DORA Clarysec toto minimum rozšiřuje o pole, jako jsou zdroj povinnosti, dotčená služba, kategorie dat, závislost na dodavateli, vlastník na straně organizace, regulační dopad, zbytkové riziko, stav ošetření a zdroj důkazů.

Všimněte si formulace. Silné odůvodnění neříká pouze „implementováno“. Vysvětluje, proč je opatření použitelné v obchodním, regulačním a rizikovém kontextu organizace.

Mapujte domény NIS2 a DORA na opatření ISO 27001:2022

Jakmile jsou registr souladu a kritéria rizik zavedeny, praktickou prací je namapovat regulační domény na opatření přílohy A. Toto mapování samo o sobě neprokazuje soulad, ale poskytuje auditorům a zákazníkům jasný index pro testování důkazů.

U Eleny toto mapování změnilo diskusi s představenstvem. Místo aby NIS2 a DORA prezentovala jako samostatné projekty, mohla ukázat jejich překryv: správu, řízení rizik, incidenty, kontinuitu, dodavatele, testování, řízení přístupu a kryptografii.

Tři opatření ISO, na kterých závisí každé SoA pro NIS2 a DORA

V příručce Zenith Controls: The Cross-Compliance Guide Zenith Controls považuje Clarysec tři opatření ISO/IEC 27002:2022 za klíčová pro auditně připravenou správu SoA v kontextu NIS2 a DORA. Jde o opatření ISO obohacená v příručce Zenith Controls o atributy napříč rámci.

Tato opatření nejsou izolovaná. Přímo navazují na opatření vztahů s dodavateli A.5.19 až A.5.23, opatření řízení incidentů A.5.24 až A.5.28, opatření kontinuity A.5.29 a A.5.30, opatření ochrany soukromí A.5.34, řízení zranitelností A.8.8, řízení konfigurace A.8.9, zálohování informací A.8.13, protokolování A.8.15, monitorovací činnosti A.8.16, kryptografii A.8.24, opatření bezpečného vývoje A.8.25 až A.8.29 a řízení změn A.8.32.

Hodnota Zenith Controls spočívá v tom, že týmům pomáhá nepovažovat SoA za artefakt jediné normy. Opatření 5.31 podporuje právní a smluvní mapování. Opatření 5.35 podporuje interní audit, nezávislý přezkum a ujištění vedení. Opatření 5.36 podporuje provozní soulad s politikami, postupy, normami a požadavky opatření.

Použijte Zenith Blueprint k vytvoření, otestování a obhájení SoA

V dokumentu Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint zařazuje Clarysec tvorbu SoA do fáze řízení rizik, krok 13: plánování ošetření rizik a Prohlášení o použitelnosti. Blueprint instruuje organizace, aby použily list SoA v šabloně „Risk Register and SoA Builder.xlsx“, rozhodly, zda je každé z 93 opatření přílohy A použitelné, a založily rozhodnutí na ošetření rizik, právních a smluvních požadavcích, relevanci rozsahu a kontextu organizace.

Blueprint uvádí:

SoA je ve skutečnosti přemosťující dokument: propojuje vaše posouzení/ošetření rizik se skutečnými opatřeními, která máte zavedena.

Tato věta vystihuje provozní model. SoA propojuje povinnosti, rizika, politiky, opatření, důkazy a auditní závěry.

Zenith Blueprint také instruuje týmy, aby v poznámkách SoA podle potřeby křížově odkazovaly na právní předpisy. Pokud je opatření implementováno kvůli GDPR, NIS2 nebo DORA, musí se to objevit v registru rizik nebo poznámkách SoA. Později, v kroku 24, Blueprint organizacím ukládá aktualizovat SoA po implementaci a křížově jej ověřit s plánem ošetření rizik. V kroku 30, Příprava na certifikaci, závěrečný přezkum a simulovaný audit, Blueprint týmy vede k potvrzení, že každé použitelné opatření přílohy A má důkazy, jako je politika, postup, report, plán nebo záznam o implementaci.

Tato posloupnost dělá ze SoA živý nástroj souladu:

1. Krok 13 jej vytváří z ošetření rizik a povinností.
2. Krok 24 jej testuje vůči skutečnému stavu implementace.
3. Krok 30 jej obhajuje prostřednictvím závěrečného přezkumu důkazů a simulovaného auditu.

Jak psát odůvodnění zahrnutí tak, aby jim auditoři rozuměli

Opatření musí být zahrnuto, pokud existuje alespoň jeden obhajitelný důvod: ošetření rizik, právní požadavek, smluvní požadavek, relevance rozsahu, základní bezpečnostní hygiena, očekávání ujištění zákazníků nebo vedením schválený cíl odolnosti.

Užitečný vzorec je:

Použitelné, protože [riziko nebo povinnost] ovlivňuje [službu, aktivum, data nebo proces] a toto opatření poskytuje [preventivní, detekční, nápravný nebo odolnostní výsledek], doložený [politikou, záznamem, testem, reportem nebo systémovým výstupem].

U poskytovatele fintech SaaS by jeden řádek SoA mohl vypadat takto:

Tento záznam je auditně připravený, protože propojuje opatření s kontextem, rizikem, povinností, implementací, vlastnictvím a důkazy.

Jak odůvodnit vyloučení bez vzniku auditní expozice

Vyloučení nejsou selháním. Selháním jsou špatně odůvodněná vyloučení.

ISO/IEC 27001:2022 vyžaduje, aby SoA odůvodnilo vyloučená opatření přílohy A. ISO/IEC 27005:2022 posiluje požadavek, že nepoužitelnost musí být vysvětlena a odůvodněna. Podniková Politika bezpečnosti informací společnosti Clarysec stanoví:

Základní soubor opatření lze přizpůsobit; vyloučení však musí být zdokumentována s formálním schválením a odůvodněním v SoA.

To je kapitola 7.2.2 Politiky bezpečnosti informací.

Politika bezpečnosti informací pro SME společnosti Clarysec Politika bezpečnosti informací pro SME stanoví:

Jakákoli odchylka od této politiky musí být zdokumentována a musí jasně vysvětlovat, proč je odchylka nezbytná, jaká alternativní ochranná opatření jsou zavedena a jaké datum je určeno pro opětovné posouzení.

Tento požadavek vychází z kapitoly 7.2.1 Politiky bezpečnosti informací pro SME.

U NIS2 a DORA vyžadují vyloučení zvláštní opatrnost. Společnost SaaS by měla jen výjimečně vylučovat protokolování, monitorování, zálohy, řízení incidentů, řízení přístupu, zabezpečení dodavatelů nebo řízení zranitelností. I tam, kde opatření není navázáno na jedno konkrétní riziko, může být stále nezbytné jako základní bezpečnost, ujištění zákazníků, smluvní očekávání nebo právní povinnost.

Politika řízení rizik pro SME společnosti Clarysec také týmům připomíná, jak je nutné nakládat s akceptovaným rizikem:

Akceptovat: Odůvodněte, proč není vyžadováno žádné další opatření, a zaznamenejte zbytkové riziko.

Tato kapitola 6.1.1 Politiky řízení rizik pro SME přesně vystihuje přístup potřebný pro vyloučení a rozhodnutí o zbytkovém riziku.

Hlášení incidentů: prokažte pracovní postup, ne existenci politiky

NIS2 Article 23 vyžaduje postupné hlášení významných incidentů, včetně včasného varování do 24 hodin od zjištění, oznámení do 72 hodin, aktualizací na vyžádání a závěrečné zprávy do jednoho měsíce od 72hodinového oznámení. DORA vyžaduje, aby finanční subjekty detekovaly, řídily, klasifikovaly, eskalovaly, komunikovaly a hlásily závažné incidenty související s ICT, informovaly dotčené klienty, pokud je to vyžadováno, prováděly analýzu kořenové příčiny a zlepšovaly opatření.

Poskytovatel SaaS nemusí vždy hlásit přímo orgánu podle DORA, ale může potřebovat podporovat lhůty pro hlášení svých finančních zákazníků. To činí opatření pro incidenty v SoA vysoce relevantními.

Slabé SoA říká: „Existuje politika reakce na incidenty.“

Silné SoA říká: „Použitelné, protože organizace musí detekovat, posoudit, klasifikovat, eskalovat, komunikovat, uchovávat důkazy, podporovat regulační lhůty pro hlášení, oznamovat dotčeným zákazníkům tam, kde to smlouva vyžaduje, a učit se z incidentů ovlivňujících služby, data nebo regulované zákazníky.“

Důkazy musí zahrnovat:

• Plán reakce na incidenty a eskalační matici.
• Kritéria klasifikace závažnosti.
• Pracovní postup oznamování zákazníkům.
• Rozhodovací strom regulačního oznamování, pokud je použitelný.
• Tikety incidentů a časové osy.
• Logy a monitorovací upozornění.
• Záznamy z tabletop cvičení.
• Přezkoumání po incidentu a nápravná opatření.
• Postupy uchovávání důkazů.

Podniková Politika monitorování auditu a souladu společnosti Clarysec Politika monitorování auditu a souladu vysvětluje, proč je to důležité:

Vytvářet obhajitelné důkazy a auditní stopu na podporu regulačních šetření, soudních řízení nebo požadavků zákazníků na doložení ujištění.

Tento cíl vychází z kapitoly 3.4 Politiky monitorování auditu a souladu.

U menších organizací musí být explicitní také uchovávání důkazů. Politika monitorování auditu a souladu pro SME společnosti Clarysec Politika monitorování auditu a souladu pro SME stanoví:

Důkazy musí být uchovávány nejméně dva roky nebo déle, pokud to vyžaduje certifikace nebo klientské dohody.

To je kapitola 6.2.4 Politiky monitorování auditu a souladu pro SME.

Jedno SoA, více auditních diskusí

Nejlepší SoA neduplikuje rámce. Vytváří dohledatelný příběh opatření, kterému různí auditoři rozumějí.

Auditor ISO 27001 obvykle začíná logikou kapitol: rozsah, zainteresované strany, posouzení rizik, ošetření rizik, SoA, cíle, interní audit, přezkoumání vedením a zlepšování. Přezkoumávající osoba orientovaná na NIS2 se zaměřuje na přiměřenost, odpovědnost vedení, školení, dodavatelský řetězec, lhůty incidentů a dopad na služby. Zákaznický hodnotitel orientovaný na DORA se zaměřuje na riziko ICT, kritické nebo důležité funkce, závažné incidenty ICT, testování odolnosti, smluvní doložky, práva na audit, plány ukončení služby, subdodávky a riziko koncentrace. Přezkoumávající osoba v oblasti soukromí se zaměřuje na odpovědnost podle GDPR a připravenost na porušení zabezpečení. Auditor ve stylu COBIT 2019 nebo ISACA testuje správu, metriky, vlastnictví, ujištění a nápravná opatření.

Proto SoA nemůže udržovat pouze bezpečnostní tým. Potřebuje právní oddělení, ochranu soukromí, nákup, engineering, provoz, HR a vlastnictví ze strany vrcholového vedení.

Běžná selhání SoA v projektech připravenosti na NIS2 a DORA

Clarysec v projektech připravenosti opakovaně nachází stejné problémy:

1. SoA označuje opatření jako použitelná, ale není zaznamenáno žádné riziko, povinnost ani obchodní odůvodnění.
2. NIS2 a DORA jsou zmíněny v politikách, ale nejsou namapovány na opatření, vlastníky ani důkazy.
3. Opatření pro dodavatele jsou označena jako implementovaná, ale neexistuje registr dodavatelů, hodnocení kritičnosti, smluvní přezkum ani plán ukončení služby.
4. Opatření pro incidenty existují, ale proces nepodporuje 24hodinový, 72hodinový, zákaznický ani závěrečný pracovní postup hlášení.
5. Schválení vedením se předpokládá, ale neexistuje záznam o akceptaci rizika, schválení SoA ani rozhodnutí o zbytkovém riziku.
6. Vyloučení jsou zkopírována ze šablony a neodpovídají skutečnému provoznímu modelu v cloudu, vzdáleném provozu, SaaS nebo fintech.
7. Důkazy existují napříč nástroji, ale žádná auditní stopa je nepropojuje se SoA.
8. Zpracování osobních údajů podle GDPR není propojeno s bezpečnostními opatřeními, reakcí na porušení zabezpečení, smlouvami s dodavateli ani uchováváním.
9. Interní audit kontroluje dokumenty, ale netestuje, zda SoA odráží skutečnou implementaci.
10. SoA se aktualizuje pouze před certifikací, nikoli po nových zákaznících, dodavatelích, incidentech, zjištěních auditu nebo regulačních změnách.

Nejde o papírové problémy. Jde o problémy správy.

Praktický kontrolní seznam pro auditně připravené ISO 27001 SoA

Použijte tento kontrolní seznam před certifikačním auditem ISO 27001, přezkumem připravenosti na NIS2, zákaznickým posouzením DORA, jednáním představenstva nebo procesem investorské náležité péče.

Proměňte SoA v obhajitelný most souladu

Elenina prezentace představenstvu uspěla, protože nepředstavila tři nesouvisející projekty souladu. Představila jeden řízený, důkazy podložený provozní model vybudovaný na ISO/IEC 27001:2022, se SoA jako mostem mezi regulací, rizikem, implementací opatření, důkazy a dohledem vedení.

NIS2 a DORA nečiní ISO 27001 zastaralou. Naopak zvyšují hodnotu dobře vybudovaného Prohlášení o použitelnosti podle ISO 27001. SoA se může stát jediným místem, kde vaše organizace vysvětluje, proč opatření existují, proč jsou vyloučení obhajitelná, jak jsou uchovávány důkazy, jak jsou řízeni dodavatelé, jak jsou eskalovány incidenty a jak vedení ví, že ISMS funguje.

Váš okamžitý další krok je jednoduchý:

1. Otevřete své aktuální SoA.
2. Vyberte pět opatření označených jako použitelná a zeptejte se: „Jaké riziko, povinnost nebo smlouva toto odůvodňuje?“
3. Vyberte pět vyloučení a zeptejte se: „Dávalo by to stále smysl auditorovi NIS2, DORA, GDPR nebo ISO/IEC 27001:2022?“
4. Ověřte, zda má každé použitelné opatření aktuální důkazy.
5. Potvrďte, že vedení schválilo zbytková rizika a rozhodnutí v SoA.
6. Aktualizujte registr souladu, registr rizik a SoA vždy, když se změní služby, dodavatelé, zákazníci, právní předpisy nebo incidenty.

Clarysec pomáhá organizacím provést tyto kroky prostřednictvím Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, sad podnikových politik a politik pro SME, nástrojů pro registr rizik, šablon SoA, přípravy na audit a mapování napříč rámci pro NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 a ujištění zákazníků.

Pokud vaše SoA nedokáže odpovědět, proč opatření existuje, kdo je jeho vlastníkem, jaké důkazy jej prokazují a kterou povinnost podporuje, ještě není připravené. Využijte Clarysec a proměňte jej v auditně připravený most souladu dříve, než stejné otázky položí regulační orgán, auditor nebo zákazník.