ISO 27001 SoA pre pripravenosť na NIS2 a DORA

Je pondelok 08:30 a Elena, riaditeľka informačnej bezpečnosti (CISO) rýchlo rastúceho poskytovateľa SaaS riešení pre B2B fintech sektor, otvára urgentnú požiadavku predstavenstva. Spoločnosť práve získala certifikáciu ISO/IEC 27001:2022, no významný bankový záujemca z EÚ kladie náročnejšie otázky než v bežnom bezpečnostnom dotazníku.

Nepýta sa iba na to, či spoločnosť šifruje údaje, používa MFA alebo má správu z penetračného testovania. Chce vedieť, či SaaS platforma podporuje jeho povinnosti podľa DORA, či poskytovateľ môže spadať do rozsahu NIS2 ako služba IKT alebo závislosť digitálnej infraštruktúry a či vyhlásenie o uplatniteľnosti ISO 27001 dokáže odôvodniť každú zahrnutú kontrolu, každú vylúčenú kontrolu a každý dôkaz.

Predstavenstvo kladie otázku, ktorú riaditelia informačnej bezpečnosti, manažéri súladu aj zakladatelia SaaS spoločností počúvajú čoraz častejšie:

Dokáže naša ISO 27001 SoA preukázať pripravenosť na NIS2 a DORA?

Elena vie, že nesprávnou odpoveďou by bolo spustiť tri samostatné programy súladu: jeden pre ISO 27001, jeden pre NIS2 a jeden pre DORA. Vznikli by duplicitné dôkazy, konfliktní vlastníci kontrol a neustály zhon pred každým zákazníckym posúdením. Lepšou odpoveďou je použiť existujúci ISMS ako prevádzkový systém súladu, pričom vyhlásenie o uplatniteľnosti, teda SoA, slúži ako hlavný dokument sledovateľnosti.

SoA nie je iba tabuľka pre certifikáciu ISO. V prostredí kybernetickej bezpečnosti a prevádzkovej odolnosti v EÚ je to miesto, kde organizácia preukazuje, prečo kontroly existujú, prečo sú vylúčenia obhájiteľné, kto vlastní jednotlivé kontroly, aké dôkazy podporujú implementáciu a ako súbor kontrol adresuje NIS2, DORA, GDPR, zákaznícke zmluvy a interné ošetrenie rizík.

Podniková Politika informačnej bezpečnosti spoločnosti Clarysec Politika informačnej bezpečnosti uvádza:

ISMS musí zahŕňať definované hranice rozsahu, metodiku posudzovania rizík, merateľné ciele a zdokumentované kontroly odôvodnené vo vyhlásení o uplatniteľnosti (SoA).

Táto požiadavka z bodu politiky 6.1.2 v Politike informačnej bezpečnosti je základom auditovateľného prístupu. SoA sa musí stať mostom medzi povinnosťami, rizikami, kontrolami, dôkazmi a rozhodnutiami manažmentu.

Prečo NIS2 a DORA zmenili význam pojmu „uplatniteľné“

Tradičná SoA podľa ISO/IEC 27001:2022 často začína jednoduchou otázkou: „Ktoré kontroly z prílohy A sa vzťahujú na náš plán ošetrenia rizík?“ To je stále správne, ale pre SaaS, cloud, riadené služby, fintech spoločnosti, finančné technológie a poskytovateľov v kritickom dodávateľskom reťazci to už nestačí.

NIS2 zvyšuje základnú úroveň riadenia kybernetických rizík pre základné a dôležité subjekty v EÚ. Zahŕňa sektory, ako sú digitálna infraštruktúra, poskytovatelia cloudových výpočtových služieb, poskytovatelia služieb dátových centier, siete na doručovanie obsahu, poskytovatelia riadených služieb, poskytovatelia riadených bezpečnostných služieb, bankovníctvo a infraštruktúry finančných trhov. Členské štáty musia identifikovať základné a dôležité subjekty a poskytovateľov služieb registrácie doménových mien. Mnohí technologickí poskytovatelia, ktorí predtým vnímali reguláciu kybernetickej bezpečnosti ako problém zákazníka, sú dnes buď priamo v rozsahu pôsobnosti, alebo čelia požiadavkám preneseným zmluvne.

NIS2 Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia v oblastiach analýzy rizík, bezpečnostných politík, riešenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, bezpečného obstarávania a vývoja, posudzovania účinnosti kontrol, kybernetickej hygieny, školení, kryptografie, bezpečnosti ľudských zdrojov, riadenia prístupu, správy aktív a autentifikácie, ak je to primerané. NIS2 Article 23 pridáva očakávania týkajúce sa postupného nahlasovania incidentov vrátane včasného varovania, oznámenia, aktualizácií a záverečnej správy o významných incidentoch.

DORA, Digital Operational Resilience Act, sa uplatňuje od 17. januára 2025 a zameriava sa na finančné subjekty a ich ekosystém rizík IKT. Zahŕňa riadenie rizík IKT, nahlasovanie incidentov súvisiacich s IKT, nahlasovanie prevádzkových alebo bezpečnostných incidentov súvisiacich s platbami pre určité subjekty, testovanie digitálnej prevádzkovej odolnosti, zdieľanie informácií o kybernetických hrozbách, riadenie rizík tretích strán v oblasti IKT, zmluvné dojednania a dohľad nad kritickými externými poskytovateľmi IKT.

Pre finančné subjekty, ktoré sú zároveň základnými alebo dôležitými subjektmi podľa NIS2, funguje DORA ako odvetvový režim pre rovnocenné povinnosti riadenia rizík IKT a nahlasovania incidentov. Pre poskytovateľov SaaS, cloudových poskytovateľov, poskytovateľov riadených služieb (MSP) a poskytovateľov MDR obsluhujúcich finančných zákazníkov však praktická realita znamená, že očakávania DORA prichádzajú cez obstarávanie, zmluvy, práva na audit, povinnosti podpory pri incidentoch, plánovanie ukončenia, transparentnosť subdodávateľov a dôkazy o odolnosti.

To mení diskusiu o SoA. Otázka už neznie: „Obsahuje príloha A túto kontrolu?“ Lepšia otázka znie:

Dokážeme preukázať, že výber kontrol je založený na rizikách, zohľadňuje povinnosti, je primeraný, má vlastníkov, je implementovaný, monitorovaný, podložený dôkazmi a schválený?

ISO 27001 je univerzálny prekladač pre NIS2 a DORA

ISO/IEC 27001:2022 je hodnotná preto, že ide o normu systému manažérstva, nie o úzky kontrolný zoznam. Vyžaduje, aby bol ISMS integrovaný do procesov organizácie a prispôsobený jej potrebám. Preto je účinným univerzálnym prekladačom pre prekrývajúce sa požiadavky súladu.

Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia pochopila svoj kontext, identifikovala zainteresované strany, určila relevantné požiadavky a definovala rozsah ISMS. Pre poskytovateľa SaaS riešení vo fintech sektore, akým je Elenina spoločnosť, môžu požiadavky zainteresovaných strán zahŕňať zákazníkov z EÚ, finančných zákazníkov dotknutých DORA, sektorové vystavenie voči NIS2, povinnosti prevádzkovateľa a sprostredkovateľa podľa GDPR, outsourcované cloudové závislosti, rozhrania dodávateľov a očakávania predstavenstva.

Kapitoly 6.1.1 až 6.1.3 vyžadujú plánovanie rizík a príležitostí, opakovateľný proces posudzovania rizík informačnej bezpečnosti, proces ošetrenia rizík, porovnanie s prílohou A a vyhlásenie o uplatniteľnosti, ktoré identifikuje zahrnuté kontroly, stav implementácie a odôvodnenia vylúčení.

Práve tu sa SoA stáva záznamom rozhodnutí o kontrolách. Kontrola môže byť zahrnutá preto, že ošetruje riziko, spĺňa zákonnú požiadavku, plní zákaznícku zmluvu, podporuje cieľ organizácie alebo predstavuje základnú bezpečnostnú hygienu. Kontrola môže byť vylúčená iba po tom, čo ju organizácia vedome posúdila, určila ju ako nerelevantnú pre rozsah ISMS, zdokumentovala odôvodnenie a získala primerané schválenie.

Podniková Politika riadenia rizík spoločnosti Clarysec Politika riadenia rizík uvádza:

Vyhlásenie o uplatniteľnosti (SoA) musí odrážať všetky rozhodnutia o ošetrení rizík a musí sa aktualizovať vždy, keď sa zmení pokrytie kontrolami.

Táto požiadavka z bodu politiky 5.4 v Politike riadenia rizík je zásadná pre pripravenosť na NIS2 a DORA. Nový regulovaný zákazník, nová cloudová závislosť, nová oznamovacia povinnosť pri incidentoch alebo nové riziko koncentrácie dodávateľov môžu zmeniť uplatniteľnosť kontrol.

Začnite registrom súladu, nie zoznamom kontrol

Slabá SoA začína prílohou A a pýta sa: „Ktoré kontroly už máme?“ Silná SoA začína prevádzkovou realitou organizácie a pýta sa: „Ktoré povinnosti, služby, riziká, údaje, dodávateľov a zákazníkov musí ISMS pokrývať?“

ISO/IEC 27005:2022 tento prístup podporuje tým, že zdôrazňuje požiadavky zainteresovaných strán, kritériá rizík a potrebu zohľadniť normy, interné pravidlá, zákony, predpisy, zmluvy a existujúce kontroly. Zároveň zdôrazňuje, že neuplatniteľnosť alebo nesúlad majú byť vysvetlené a odôvodnené.

SME Politika právneho a regulačného súladu spoločnosti Clarysec Politika právneho a regulačného súladu pre SME zachytáva rovnaký prevádzkový princíp:

Generálny manažér musí viesť jednoduchý, štruktúrovaný register súladu, ktorý uvádza:

Táto požiadavka pochádza z bodu 5.1.1 Politiky právneho a regulačného súladu pre SME. V menšej organizácii môže byť register jednoduchý. V podniku má byť podrobnejší. Logika je rovnaká: povinnosti musia byť viditeľné skôr, než ich možno mapovať.

Podniková Politika právneho a regulačného súladu spoločnosti Clarysec Politika právneho a regulačného súladu je explicitná:

Všetky zákonné a regulačné povinnosti musia byť v rámci systému manažérstva informačnej bezpečnosti (ISMS) namapované na konkrétne politiky, kontroly a vlastníkov.

Ide o bod politiky 6.2.1 v Politike právneho a regulačného súladu. Je to chrbtica správy a riadenia pri používaní vyhlásenia o uplatniteľnosti ISO 27001 na pripravenosť súladu s NIS2 a DORA.

Vytvorte kritériá rizík, ktoré odrážajú odolnosť, súkromie, dodávateľov a reguláciu

Mnohé odôvodnenia v SoA zlyhávajú preto, že model hodnotenia rizík je príliš úzky. Meria technickú pravdepodobnosť a dopad, ale nezachytáva regulačné vystavenie, kritickosť služby, ujmu zákazníka, závislosť od dodávateľa, dopad na súkromie ani systémové prevádzkové narušenie.

NIS2 sa netýka iba dôvernosti. Zameriava sa na prevenciu a minimalizáciu dopadu incidentov na služby a ich príjemcov. DORA definuje kritické alebo dôležité funkcie podľa toho, či by narušenie podstatne zhoršilo finančnú výkonnosť, kontinuitu služby alebo regulačný súlad. GDPR pridáva zodpovednosť, integritu, dôvernosť, pripravenosť na porušenie ochrany osobných údajov a ujmu dotknutých osôb.

SME Politika riadenia rizík spoločnosti Clarysec Politika riadenia rizík pre SME poskytuje praktické minimum:

Každý záznam rizika musí obsahovať: opis, pravdepodobnosť, dopad, skóre, vlastníka a plán ošetrenia.

Ide o bod 5.1.2 Politiky riadenia rizík pre SME. Pre pripravenosť na NIS2 a DORA Clarysec rozširuje toto minimum o polia, ako sú zdroj povinnosti, dotknutá služba, kategória údajov, závislosť od dodávateľa, organizačný vlastník, regulačný dopad, zostatkové riziko, stav ošetrenia a zdroj dôkazov.

Všimnite si použitý jazyk. Silné odôvodnenie nehovorí iba „implementované“. Vysvetľuje, prečo je kontrola uplatniteľná v obchodnom, regulačnom a rizikovom kontexte organizácie.

Mapujte oblasti NIS2 a DORA na kontroly ISO 27001:2022

Po vytvorení registra súladu a kritérií rizík je praktickou úlohou mapovať regulačné oblasti na kontroly z prílohy A. Toto mapovanie samo osebe nepreukazuje súlad, ale poskytuje audítorom a zákazníkom jasný index na testovanie dôkazov.

Pre Elenu toto mapovanie zmenilo diskusiu s predstavenstvom. Namiesto toho, aby prezentovala NIS2 a DORA ako samostatné projekty, mohla ukázať prekryv: správu a riadenie, riadenie rizík, incidenty, kontinuitu, dodávateľov, testovanie, riadenie prístupu a kryptografiu.

Tri ISO kontroly, od ktorých závisí každá SoA pre NIS2 a DORA

V Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec považuje tri kontroly ISO/IEC 27002:2022 za kľúčové pre auditovateľnú správu a riadenie SoA pre NIS2 a DORA. Ide o ISO kontroly obohatené o atribúty krížového súladu v príručke Zenith Controls.

Tieto kontroly nie sú izolované. Priamo sa prepájajú s kontrolami vzťahov s dodávateľmi A.5.19 až A.5.23, kontrolami riadenia incidentov A.5.24 až A.5.28, kontrolami kontinuity A.5.29 a A.5.30, kontrolou ochrany súkromia A.5.34, riadením zraniteľností A.8.8, riadením konfigurácie A.8.9, zálohovaním informácií A.8.13, logovaním A.8.15, monitorovacími aktivitami A.8.16, kryptografiou A.8.24, kontrolami bezpečného vývoja A.8.25 až A.8.29 a riadením zmien A.8.32.

Hodnota Zenith Controls spočíva v tom, že pomáha tímom vyhnúť sa tomu, aby SoA vnímali ako artefakt jednej normy. Kontrola 5.31 podporuje mapovanie zákonných a zmluvných povinností. Kontrola 5.35 podporuje interný audit, nezávislé preskúmanie a uistenie manažmentu. Kontrola 5.36 podporuje prevádzkové dodržiavanie politík, postupov, noriem a kontrolných požiadaviek.

Použite Zenith Blueprint na vytvorenie, testovanie a obhajobu SoA

V Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint Clarysec zaraďuje tvorbu SoA do fázy riadenia rizík, krok 13: plánovanie ošetrenia rizík a vyhlásenie o uplatniteľnosti. Blueprint inštruuje organizácie, aby použili hárok SoA v šablóne „Risk Register and SoA Builder.xlsx“, rozhodli, či je každá z 93 kontrol prílohy A uplatniteľná, a založili rozhodnutie na ošetrení rizík, zákonných a zmluvných požiadavkách, relevantnosti rozsahu a kontexte organizácie.

Blueprint uvádza:

SoA je v skutočnosti premostený dokument: prepája vaše posúdenie/ošetrenie rizík so skutočnými kontrolami, ktoré máte.

Táto veta vystihuje prevádzkový model. SoA prepája povinnosti, riziká, politiky, kontroly, dôkazy a závery auditu.

Zenith Blueprint tiež inštruuje tímy, aby v poznámkach SoA podľa potreby uvádzali krížové odkazy na predpisy. Ak je kontrola implementovaná pre GDPR, NIS2 alebo DORA, musí sa to objaviť v registri rizík alebo v poznámkach SoA. Neskôr, v kroku 24, Blueprint odporúča organizáciám aktualizovať SoA po implementácii a krížovo ju overiť s plánom ošetrenia rizík. V kroku 30, príprava na certifikáciu, záverečné preskúmanie a skúšobný audit, Blueprint smeruje tímy k potvrdeniu, že každá uplatniteľná kontrola prílohy A má dôkaz, napríklad politiku, postup, správu, plán alebo záznam o implementácii.

Táto postupnosť robí zo SoA živý nástroj súladu:

1. Krok 13 ju vytvára z ošetrenia rizík a povinností.
2. Krok 24 ju testuje voči realite implementácie.
3. Krok 30 ju obhajuje cez záverečné preskúmanie dôkazov a skúšobný audit.

Ako písať odôvodnenia zahrnutia, ktorým audítori porozumejú

Kontrola má byť zahrnutá, keď existuje aspoň jeden obhájiteľný dôvod: ošetrenie rizika, zákonná požiadavka, zmluvná požiadavka, relevantnosť rozsahu, základná bezpečnostná hygiena, očakávanie zákazníckeho uistenia alebo manažmentom schválený cieľ odolnosti.

Užitočný vzorec je:

Uplatniteľné, pretože [riziko alebo povinnosť] ovplyvňuje [službu, aktívum, údaje alebo proces] a táto kontrola poskytuje [preventívny, detekčný, nápravný alebo odolnostný výsledok], čo je doložené [politikou, záznamom, testom, správou alebo výstupom systému].

Pre poskytovateľa SaaS riešení vo fintech sektore môže jeden riadok SoA vyzerať takto:

Toto je pripravené na audit, pretože to prepája kontrolu s kontextom, rizikom, povinnosťou, implementáciou, vlastníctvom a dôkazmi.

Ako odôvodniť vylúčenia bez vytvárania auditného vystavenia

Vylúčenia nie sú zlyhania. Slabo odôvodnené vylúčenia sú zlyhania.

ISO/IEC 27001:2022 vyžaduje, aby SoA odôvodnila vylúčené kontroly z prílohy A. ISO/IEC 27005:2022 posilňuje požiadavku, že neuplatniteľnosť má byť vysvetlená a odôvodnená. Podniková Politika informačnej bezpečnosti spoločnosti Clarysec uvádza:

Základný súbor kontrolných opatrení môže byť prispôsobený; vylúčenia však musia byť zdokumentované s formálnym schválením a odôvodnením v SoA.

Ide o bod 7.2.2 Politiky informačnej bezpečnosti.

Politika informačnej bezpečnosti pre SME spoločnosti Clarysec Politika informačnej bezpečnosti pre SME uvádza:

Každá odchýlka od tejto politiky musí byť zdokumentovaná a musí jasne vysvetľovať, prečo je odchýlka nevyhnutná, aké alternatívne ochranné opatrenia sú zavedené a aký dátum je určený na opätovné prehodnotenie.

Táto požiadavka pochádza z bodu 7.2.1 v Politike informačnej bezpečnosti pre SME.

Pri NIS2 a DORA si vylúčenia vyžadujú osobitnú opatrnosť. SaaS spoločnosť by mala len zriedka vylúčiť logovanie, monitorovanie, zálohy, riadenie incidentov, riadenie prístupu, bezpečnosť dodávateľov alebo riadenie zraniteľností. Aj keď kontrola nie je prepojená s jedným konkrétnym rizikom, môže byť stále potrebná ako základná bezpečnosť, zákaznícke uistenie, zmluvné očakávanie alebo zákonná povinnosť.

Politika riadenia rizík pre SME spoločnosti Clarysec tímom pripomína aj spôsob nakladania s akceptovaným rizikom:

Akceptovať: Odôvodnite, prečo sa nevyžaduje ďalšie opatrenie, a zaznamenajte zostatkové riziko.

Práve tento prístup z bodu 6.1.1 v Politike riadenia rizík pre SME je potrebný pri vylúčeniach a rozhodnutiach o zostatkovom riziku.

Nahlasovanie incidentov: preukážte pracovný postup, nie existenciu politiky

NIS2 Article 23 vyžaduje postupné nahlasovanie významných incidentov vrátane včasného varovania do 24 hodín od zistenia, oznámenia do 72 hodín, aktualizácií na vyžiadanie a záverečnej správy do jedného mesiaca od 72-hodinového oznámenia. DORA vyžaduje, aby finančné subjekty detegovali, riadili, klasifikovali, eskalovali, komunikovali a nahlasovali závažné incidenty súvisiace s IKT, informovali dotknutých klientov, ak je to vyžadované, vykonali analýzu koreňovej príčiny a zlepšili kontroly.

SaaS poskytovateľ nemusí vždy nahlasovať priamo orgánu podľa DORA, ale môže potrebovať podporovať lehoty nahlasovania svojich finančných zákazníkov. To robí kontroly incidentov v SoA vysoko relevantnými.

Slabá SoA hovorí: „Existuje politika reakcie na incidenty.“

Silná SoA hovorí: „Uplatniteľné, pretože organizácia musí detegovať, posudzovať, klasifikovať, eskalovať, komunikovať, uchovávať dôkazy, podporovať regulačné lehoty nahlasovania, oznamovať dotknutým zákazníkom, ak to vyžaduje zmluva, a učiť sa z incidentov ovplyvňujúcich služby, údaje alebo regulovaných zákazníkov.“

Dôkazy majú zahŕňať:

• Plán reakcie na incidenty a maticu eskalácie.
• Kritériá klasifikácie závažnosti.
• Pracovný postup notifikácie zákazníkov.
• Rozhodovací strom regulačného oznámenia, ak je uplatniteľný.
• Tickety incidentov a časové osi.
• Logy a monitorovacie upozornenia.
• Záznamy zo stolových cvičení.
• Poincidentnú revíziu a nápravné opatrenia.
• Postupy uchovávania dôkazov.

Podniková Politika monitorovania auditov a súladu spoločnosti Clarysec Politika monitorovania auditov a súladu vysvetľuje, prečo je to dôležité:

Vytvárať obhájiteľné dôkazy a auditnú stopu na podporu regulačných preverení, právnych konaní alebo požiadaviek zákazníkov na preukázanie súladu.

Tento cieľ pochádza z bodu 3.4 Politiky monitorovania auditov a súladu.

Pre menšie organizácie musí byť explicitné aj uchovávanie dôkazov. Politika monitorovania auditov a súladu pre SME spoločnosti Clarysec Politika monitorovania auditov a súladu pre SME uvádza:

Dôkazy musia byť uchovávané najmenej dva roky alebo dlhšie, ak to vyžaduje certifikácia alebo klientské dohody.

Ide o bod 6.2.4 v Politike monitorovania auditov a súladu pre SME.

Jedna SoA, viacero auditných rozhovorov

Najlepšia SoA neduplikuje rámce. Vytvára sledovateľný kontrolný príbeh, ktorému rôzni audítori rozumejú.

Audítor ISO 27001 zvyčajne začína logikou kapitol: rozsah, zainteresované strany, posúdenie rizík, ošetrenie rizík, SoA, ciele, interný audit, preskúmanie manažmentom a zlepšovanie. Posudzovateľ orientovaný na NIS2 sa zameriava na proporcionalitu, zodpovednosť manažmentu, školenia, dodávateľský reťazec, lehoty incidentov a dopad na služby. Zákaznícky posudzovateľ orientovaný na DORA sa zameriava na riziká IKT, kritické alebo dôležité funkcie, závažné incidenty IKT, testovanie odolnosti, zmluvné doložky, práva na audit, plány ukončenia, subdodávky a riziko koncentrácie. Posudzovateľ ochrany súkromia sa zameriava na zodpovednosť podľa GDPR a pripravenosť na porušenie ochrany osobných údajov. Audítor v štýle COBIT 2019 alebo ISACA testuje správu a riadenie, metriky, vlastníctvo, uistenie a nápravné opatrenia.

Preto SoA nemôže udržiavať iba bezpečnostný tím. Vyžaduje právne oddelenie, ochranu súkromia, obstarávanie, engineering, prevádzku, HR a vlastníctvo vrcholového vedenia.

Bežné zlyhania SoA v projektoch pripravenosti na NIS2 a DORA

Clarysec v projektoch pripravenosti opakovane nachádza rovnaké problémy:

1. SoA označuje kontroly ako uplatniteľné, ale nezaznamenáva riziko, povinnosť ani dôvod organizácie.
2. NIS2 a DORA sú spomenuté v politikách, ale nie sú namapované na kontroly, vlastníkov alebo dôkazy.
3. Kontroly dodávateľov sú označené ako implementované, ale neexistuje register dodávateľov, hodnotenie kritickosti, preskúmanie zmluvy ani plán ukončenia.
4. Kontroly incidentov existujú, ale proces nepodporuje 24-hodinové, 72-hodinové, zákaznícke ani záverečné pracovné postupy nahlasovania.
5. Schválenie manažmentom sa predpokladá, ale neexistuje záznam o akceptácii rizika, schválení SoA ani rozhodnutí o zostatkovom riziku.
6. Vylúčenia sú skopírované zo šablóny a nezodpovedajú skutočnému cloudovému, vzdialenému, SaaS alebo fintech prevádzkovému modelu.
7. Dôkazy existujú v rôznych nástrojoch, ale žiadna auditná stopa neprepája dôkazy so SoA.
8. Spracúvanie osobných údajov podľa GDPR nie je prepojené s bezpečnostnými kontrolami, reakciou na porušenie ochrany osobných údajov, zmluvami s dodávateľmi alebo uchovávaním.
9. Interný audit kontroluje dokumenty, ale netestuje, či SoA odráža skutočnú implementáciu.
10. SoA sa aktualizuje iba pred certifikáciou, nie po nových zákazníkoch, dodávateľoch, incidentoch, auditných zisteniach alebo regulačných zmenách.

Toto nie sú papierové problémy. Sú to problémy správy a riadenia.

Praktický kontrolný zoznam pre auditovateľnú ISO 27001 SoA

Použite tento kontrolný zoznam pred certifikačným auditom ISO 27001, preskúmaním pripravenosti na NIS2, zákazníckym posúdením DORA, zasadnutím predstavenstva alebo procesom investor due diligence.

Premeňte SoA na obhájiteľný most súladu

Elenina prezentácia predstavenstvu uspela preto, že neprezentovala tri nesúvisiace projekty súladu. Predstavila jeden riadený, dôkazmi podložený prevádzkový model vybudovaný na ISO/IEC 27001:2022, v ktorom SoA tvorí most medzi reguláciou, rizikom, implementáciou kontrol, dôkazmi a dohľadom manažmentu.

NIS2 a DORA nerobia ISO 27001 zastaranou. Zvyšujú hodnotu dobre vybudovaného vyhlásenia o uplatniteľnosti ISO 27001. SoA sa môže stať jediným miestom, kde vaša organizácia vysvetľuje, prečo kontroly existujú, prečo sú vylúčenia obhájiteľné, ako sa uchovávajú dôkazy, ako sú riadení dodávatelia, ako sa eskalujú incidenty a ako manažment vie, že ISMS funguje.

Vaša okamžitá akcia je jednoduchá:

1. Otvorte svoju aktuálnu SoA.
2. Vyberte päť kontrol označených ako uplatniteľné a opýtajte sa: „Aké riziko, povinnosť alebo zmluva to odôvodňuje?“
3. Vyberte päť vylúčení a opýtajte sa: „Dávalo by to stále zmysel audítorovi NIS2, DORA, GDPR alebo ISO/IEC 27001:2022?“
4. Skontrolujte, či má každá uplatniteľná kontrola aktuálne dôkazy.
5. Potvrďte, že manažment schválil zostatkové riziká a rozhodnutia SoA.
6. Aktualizujte register súladu, register rizík a SoA vždy, keď sa zmenia služby, dodávatelia, zákazníci, predpisy alebo incidenty.

Clarysec pomáha organizáciám robiť to prostredníctvom Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, podnikových a SME súborov politík, nástrojov registra rizík, šablón SoA, prípravy na audit a mapovania krížového súladu pre NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 a zákaznícke uistenie.

Ak vaša SoA nedokáže odpovedať, prečo kontrola existuje, kto ju vlastní, aké dôkazy ju preukazujú a ktorú povinnosť podporuje, ešte nie je pripravená. Použite Clarysec na jej premenu na auditovateľný most súladu skôr, než rovnaké otázky položí regulátor, audítor alebo zákazník.